Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105440 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 73062 invoked from network); 25 Apr 2019 12:26:46 -0000 Received: from unknown (HELO mail-vk1-f178.google.com) (209.85.221.178) by pb1.pair.com with SMTP; 25 Apr 2019 12:26:46 -0000 Received: by mail-vk1-f178.google.com with SMTP id x2so4685564vkx.13 for ; Thu, 25 Apr 2019 02:27:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=8H1kL5QNm/jDdm0qDr4a/+4FBbL4spms1Brp186+CVY=; b=JTqBvD2j0SB9oSV6+T7RllRjOzPGJImlrp/q3XS28M4A1cTlVUN4ua0LI469KJ6Bqh lhCtRcQZt13ZJ1nFBgxxPgY9Mnq+idmnCnkQuxSwXKhfy0pwHjF50h4e1wwIHB1lpDNH tYT8Nmo3Sqbd6cOZw+H52xbIkKUxnuG8vPm82iv1sgQTCiXtO9ZxdHeXqQnlnWLQSJji C1Na8jc3eLmpzG5NCmJg/ZP7ajD05coxtaRMh5LMZeecS9mOEfegsLiKsjQaKjZZ9fqM 7EbZroeN6jdwlXFNNFBGMo7SWes1l3XoeLFmZxJI6N22SFXcK67pHjr8MVoLQ2J/dbT4 c2Kw== X-Gm-Message-State: APjAAAUUjW4QXocZRzKw6aHD+GKZ2cponzYu+jFoSFt4ncCVszLraJUZ ejHd/ddfRzHcdKZHhYkoClYk+hOMWdUXx1BN/cQ= X-Google-Smtp-Source: APXvYqzQN4KwyVh3zc+IUdp3PfFCsV0DOBPys4k56ecVSECQO2AkXeucEKrGUcnaNEGH6KjfsteQ8x6eHNI2sg72i2U= X-Received: by 2002:a1f:1284:: with SMTP id 126mr20052028vks.72.1556184456796; Thu, 25 Apr 2019 02:27:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: bishop@php.net Date: Thu, 25 Apr 2019 05:27:11 -0400 Message-ID: To: Nikita Popov Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000c0a05e0587576d2d" Subject: Re: [PHP-DEV] Alternative approach to short tags deprecation From: bishop@php.net (Bishop Bettini) --000000000000c0a05e0587576d2d Content-Type: text/plain; charset="UTF-8" On Thu, Apr 25, 2019 at 3:16 AM Nikita Popov wrote: > Hi internals, > > As already discussed in the corresponding voting thread, the deprecation of > short tags as proposed has a high risk of causing inadvertent source code > leakage. The RFC proposes to change the default of short_open_tag from On > to Off in PHP 7.4. Any website using short_open_tags without explicitly > enabling it (relying on the default) will leak source code unless proper > precautions are taken before switching to PHP 7.4. > > Disregarding the question of whether short tags should be removed at all > (let's keep that question in the other thread), I do think we need to > reconsider the deprecation approach. In particular, I would like to > propose: > > In PHP 7.4: > * The default value of short_open_tag remains as is and enabling > short_open_tag does not generate a deprecation warning (otherwise PHP would > warn in a default config). > * If short_open_tag is enabled: The first use of deprecation warning. (Potentially every use could throw a deprecation, but > generally, if noise in the error log.) > * If short_open_tag is disabled: > In PHP 8.0: > * The default value of short_open_tag remains as is and enabling > short_open_tag does not generate a deprecation warning or error. > * If short_open_tag is enabled: Any use of * If short_open_tag is disabled: > At a later point in time: > * The short_open_tag option is removed. > * I voted for 7.4 deprecation to align engine behavior with long-established documentation, and abstained from the 8.0 removal vote because I have no opinion on the timeline. My rationale being that