Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105448
MIME-Version: 1.0
References: <CAF+90c-dXndgoPr6GfYsY3gudD3wEhL7YVx=pR=5SUjo2_7_WA@mail.gmail.com>
In-Reply-To: <CAF+90c-dXndgoPr6GfYsY3gudD3wEhL7YVx=pR=5SUjo2_7_WA@mail.gmail.com>
Date: Thu, 25 Apr 2019 12:08:37 -0400
Message-ID: <CAPKYkKzvXap37fUN-_0vPuF7MB72DgE9w+8fkdaZ+xpg7PDT7g@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000094988d05875d08e6"
Subject: Re: [PHP-DEV] Alternative approach to short tags deprecation
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000094988d05875d08e6
Content-Type: text/plain; charset="UTF-8"

A lot of this will echo what other people have said. As someone that has
been very vocal on the other thread (both before and after the vote) I felt
I should comment as well. I definitely appreciate Nikita for taking the
time to propose a compromise/alternate solution.

On Thu, Apr 25, 2019 at 3:15 AM Nikita Popov <nikita.ppv@gmail.com> 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 the goal is to eventually remove support for short open tags and/or
change the default value of this configuration option, I think you DO need
to generate a deprecation warning if the ini option is enabled (whether
explicitly or by default). A deprecation warning is meant to tell the user
"We'll let you keep doing this for now, but in the future, you won't be
allowed" - I guess, technically, deprecation warnings reference things that
will be removed, not changed, but since we don't have a 'pending change'
notice, I think a deprecation notice would suffice. We are deprecating the
current behavior.

I'm split on whether the notice should be provided based on just having the
option enabled (explicitly or by default) or whether encountering a <?
should also be necessary. My argument for basing it on the configuration
only would be that some people might have some code that isn't executed
very often and might never get the notice as a result - or get it so rarely
they overlook it.

>  * If short_open_tag is enabled: The first use of <? generates a
> deprecation warning. (Potentially every use could throw a deprecation, but
> generally, if <? is used, it's used a lot and this would cause a lot of
> noise in the error log.)

Given the fact that this could quickly flood logs and make them unusable, I
think a single notice per execution makes sense. If it's config file only
based, then it would only generate one to begin with.

>  * If short_open_tag is disabled: <? is considered normal text.
>
Which is the current behavior and is fine.


> 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 <? generates a compile error.
>  * If short_open_tag is disabled: <? is considered normal text.
>
> I'm OK with that.


> At a later point in time:
>  * The short_open_tag option is removed.
>  * <? is always considered normal text.
>
It would probably need to be PHP 9 where this happens - but I think with
proper warnings and the fail-safe you've introduced, that would be the
appropriate place to do so.


> The advantage of such an approach would be that no source code leakage
> could occur when switching to PHP 7.4 or PHP 8.0. The disadvantage is that
> we'll only be able to fully remove short tags support at a later point in
> time.
>
> While I personally wouldn't like such an accelerated timeline, I don't
think it would be the worst thing in the world to make your 8.0 changes in
7.4, and then the "later point in time" changes in 8.0. That would at least
be better than the current solution as it would prevent code leaks.


> Thoughts?
>
> Regards,
> Nikita
>

While one of the main areas I focused on in the other thread was the fact
that the additional work that would be required by these changes could
prevent people from upgrading in a timely manner, that wasn't actually my
biggest concern. That's where the discussion usually ended up due to the
fact that most responses just said "it's easy to make the updates." The
potential for code leaks actually concerned me more. I think the above
proposal addresses that well.





-- 
Chase Peeler
chasepeeler@gmail.com

--00000000000094988d05875d08e6--