Alternative approach to short tags deprecation

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 <? 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.)
• If short_open_tag is disabled: <? is considered normal text.

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.

At a later point in time:

• The short_open_tag option is removed.
• <? is always considered normal text.

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.

Thoughts?

Regards,
Nikita

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 <? 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.)
• If short_open_tag is disabled: <? is considered normal text.

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.

At a later point in time:

• The short_open_tag option is removed.
• <? is always considered normal text.

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 <? usage is a potential
trap, and I'd like to see those traps removed from the language, so long as
it's in an orderly fashion.

Respecting your proposal, I feel warning those who explicitly enable
short_open_tag is good, because such usage is now officially deprecated.
But not warning those who both use <? and accept the default is not ideal:
they are the users in the trap. They'll keep moving along accepting the
status quo, potentially unaware that <? is unportable and also that <?
removal is planned, until "at a later point in time" their code stops
running and instead starts being output. So, not warning them is just
delaying the inevitable, is it not?

I'd suggest therefore an amendment to your proposal, targeting 7.4:
simultaneous usage of <? and the default setting is a compile time error.
"Use of <? without explicitly setting short_open_tag = On is unsupported.".
Such code installations will be forced to either (a) update their code to
<?php or (b) opt-in to the now-officially-deprecated short_open_tag = On
behavior. Whichever is least painful for them right now (*).

This amendment effectively removes <? from the language as of 8.0, because
any usage of <? in 8.0 would be a compile time error. We can then, as you
say at a later point in time, remove the configuration option and token
parsing of <?. This implementation seems compatible with the intent of the
RFC, while addressing the exposure-of-code security concern in the near
term.

bishop

(*) The only corner case I see here is for a hosting install that cannot
modify their php.ini settings, and simultaneously are reliant on a
third-party library that uses <?. That seems unlikely to me, because
library authors have long had to deal with <? potentially being disabled
and have stopped shipping their library code in that configuration. So the
library would have to be quite old, circa 5.4 perhaps, and would likely
have other issues upgrading to 7.4. Notwithstanding, the way around this
would be local modification of the library to <?php, which given the age of
the library, is likely just copy & paste included in the code base.

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.

It is certainly my opinion that IF short open tags are to be removed,
it makes significantly more sense to fail-safe with a compiler error,
than it does to fail-unsafe with potential code/data exposure.

If the operations guys or devops want to explicitly remove the safety
net with full knowledge of the consequences, on their own heads be it.

Without wanting to seem too melodramatic, the behaviour of the
already-passed RFC could lead to code and data leakage, identity theft,
even complete server compromise.

People could quite literally lose their livelihoods because of this
change, and companies could be compromised in a way from which they
could never recover.

IMO PHP as an language is likely to suffer significant reputational
damage as a result.

It shouldn't happen of course, because engineers and operations should
be going line-by-line through the change logs and checking their entire
codebase against each one. But we all know that's not how the real world
works.

For all those reasons, I am in favour of your proposal to fail-safe with
a compiler error.

(Also: Did I miss a vote option which would have made short_open_tags
always on?)

--
Mark Randall

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:

First of all thanks for tackling this as it seems a lot of issues are
arrising now
instead of during the discussion/voting phase.

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 <? 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.)
• If short_open_tag is disabled: <? is considered normal text.

As I said on the PR implementation I am totally okay to leave the current
default
as it is.

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.

In my mind I do think that making the default change in PHP 8 would be
better
but what do I know.

At a later point in time:

• The short_open_tag option is removed.
• <? is always considered normal text.

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.

Thoughts?

Regards,
Nikita

I do not mind the timeline to be significantly altered as I said in one of
my emails
during the initial discussion for the RFC.

Respecting your proposal, I feel warning those who explicitly enable
short_open_tag is good, because such usage is now officially deprecated.
But not warning those who both use <? and accept the default is not ideal:
they are the users in the trap. They'll keep moving along accepting the
status quo, potentially unaware that <? is unportable and also that <?
removal is planned, until "at a later point in time" their code stops
running and instead starts being output. So, not warning them is just
delaying the inevitable, is it not?

I'd suggest therefore an amendment to your proposal, targeting 7.4:
simultaneous usage of <? and the default setting is a compile time error.
"Use of <? without explicitly setting short_open_tag = On is unsupported.".
Such code installations will be forced to either (a) update their code to
<?php or (b) opt-in to the now-officially-deprecated short_open_tag = On
behavior. Whichever is least painful for them right now (*).

This amendment effectively removes <? from the language as of 8.0, because
any usage of <? in 8.0 would be a compile time error. We can then, as you
say at a later point in time, remove the configuration option and token
parsing of <?. This implementation seems compatible with the intent of the
RFC, while addressing the exposure-of-code security concern in the near
term.

bishop

I really like this approach to signal intent in using the short_open_tag
config
As this means people opting in are fully aware of the fact that it is now
deprecated.

(Also: Did I miss a vote option which would have made short_open_tags
always on?)

No you didn't, I did not propose this voting choice.

Best regards

George P. Banyard

Hello,

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 <? 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.)
• If short_open_tag is disabled: <? is considered normal text.

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.

At a later point in time:

• The short_open_tag option is removed.
• <? is always considered normal text.

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.

Thoughts?

Regards,
Nikita

Sure. I think we can do that also for people who haven't upgraded
their code yet and can do that at their own pace by ~ 2025/2026. By
that time the rest of us will be using "Jitted", "asynced", more
consistent, and slick-syntaxed PHP everywhere already so they can
catch us up... :) No worries.

The approach described sounds ok to me. Would be also good to think
even more in advance - like making <?php opening tag optional in
source code files only etc. So we can write a class file without
opening PHP tag at all and similar syntactical sugars. That would be
really neat I think.

Cheers.

--
Peter Kokot

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.

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

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.

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).

Hi! Thanks for providing an alternative to solve this. But I'd say to
generate the deprecation notice on first use of the short tag both when the
user is relying on the default and when explicitly enabled. Although it may
be annoying that we are throwing that notice on default config, it's the
only way to warn everyone who would be affected when the default changes or
the option is removed. I'd prefer to be annoyed than the alternative.
Also, given that the notice will go away once you got rid of all your
usages of the short tag, it sounds manageable to me.

Regards,
Pedro

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.

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).

Hi! Thanks for providing an alternative to solve this. But I'd say to
generate the deprecation notice on first use of the short tag both when the
user is relying on the default and when explicitly enabled. Although it may
be annoying that we are throwing that notice on default config, it's the
only way to warn everyone who would be affected when the default changes or
the option is removed. I'd prefer to be annoyed than the alternative.
Also, given that the notice will go away once you got rid of all your
usages of the short tag, it sounds manageable to me.

Yes, usage of <? should throw a deprecation warning regardless of whether
short_open_tag is enabled by default or explicitly. What I meant here is
that enabling short_open_tag does not throw a deprecation by itself, only
the actual use of <? generates a deprecation.

Nikita