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....@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 chasepee...@gmail.com
