Deprecate short_open_tag ini directive?

Hello internals,

I'm currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only affects
the availability of <? tags as <?=is always available as of PHP 5.4.
From my understanding, the <? tag is not available without the directive,
so maybe we should deprecate PHP's short tag altogether?

Best regards

George P. Banyard

[1] https://secure.php.net/manual/en/ini.core.php#ini.short-open-tag

From my understanding, the <? tag is not available without the directive,
so maybe we should deprecate PHP's short tag altogether?

I think when that's been proposed in the past, people have said they like
it for use in simple templates, often along with the "alternative control
structures", e.g.:

<? foreach ( $things as $thing ): ?>
<? if ( $thing->quantity > 1 ): ?><p><?= $thing->description; ?></p><?
endif; ?>
<? endforeach; ?>

I couldn't find any discussions for a few years, though, so it's possible
opinions have changed.

Regards,

Rowan Collins
[IMSoP]

Hello,

From my understanding, the <? tag is not available without the directive,
so maybe we should deprecate PHP's short tag altogether?

I think when that's been proposed in the past, people have said they like
it for use in simple templates, often along with the "alternative control
structures", e.g.:

<? foreach ( $things as $thing ): ?>
<? if ( $thing->quantity > 1 ): ?><p><?= $thing->description; ?></p><?
endif; ?>
<? endforeach; ?>

I couldn't find any discussions for a few years, though, so it's possible
opinions have changed.

Regards,

Rowan Collins
[IMSoP]

PHP based template engines today most likely use only <?php and <?=
because of this topic today exactly. Possibility of being deprecated
:) I think the short opening tags are good to go so things are more
simple.

A side question is there any plan to move the idea of removing opening
<?php tag for PHP only files or is this off topic here? PHP has long
moved out of the template engines world and left that task to more
dedicated so called compiled or parsed template engines (such as Twig
or Blade), so maybe something to think about as well.

--
Peter Kokot

PHP based template engines today most likely use only <?php and <?=
because of this topic today exactly. Possibility of being deprecated
:) I think the short opening tags are good to go so things are more
simple.

A quick search of the list archives showed the opposite: reassurances that
short open tags are not deprecated, and vocal support for keeping them.

A side question is there any plan to move the idea of removing opening
<?php tag for PHP only files or is this off topic here? PHP has long
moved out of the template engines world and left that task to more
dedicated so called compiled or parsed template engines (such as Twig
or Blade), so maybe something to think about as well.

I think that's a different discussion - and also one that's happened a few
times in the past. I think the general conclusion was that the gain isn't
big enough to bother changing every tool that works with PHP.

Regards,

Rowan Collins
[IMSoP]

Hi,

I guess that short_open_tag ini settings can be deprecated/removed.
But that would mean that short open tags will be always available, not that
it will be removed.

Regards,
Alex

On Tue, Mar 12, 2019 at 12:39 PM Rowan Collins rowan.collins@gmail.com
wrote:

PHP based template engines today most likely use only <?php and <?=
because of this topic today exactly. Possibility of being deprecated
:) I think the short opening tags are good to go so things are more
simple.

A quick search of the list archives showed the opposite: reassurances that
short open tags are not deprecated, and vocal support for keeping them.

A side question is there any plan to move the idea of removing opening
<?php tag for PHP only files or is this off topic here? PHP has long
moved out of the template engines world and left that task to more
dedicated so called compiled or parsed template engines (such as Twig
or Blade), so maybe something to think about as well.

I think that's a different discussion - and also one that's happened a few
times in the past. I think the general conclusion was that the gain isn't
big enough to bother changing every tool that works with PHP.

Regards,

Rowan Collins
[IMSoP]

Hi,

I guess that short_open_tag ini settings can be deprecated/removed.
But that would mean that short open tags will be always available, not that
it will be removed.

Regards,
Alex

Oh, the main idea is to remove the ini directive which will make the
short tags by default then on? So the currently not enabled short tags
will be again enabled by default?

From what I understand here, probably deprecation is referring also to
the short tags themselves in favour of the <?php tag only.

--
Peter Kokot

I was more going along the lines of removing short tags altogether with the
ini setting as they are not available out of the box except if you use a
special compile flag. However, I didn't know they were used with template
engines but wouldn't they just use <?= which is always available?
I mean I don't really have any strong opinions about it. It just seems a
bit odd considering we removed ASP tags in, IIRC, PHP 7.

Best regards

George P. Banyard

I was more going along the lines of removing short tags altogether with the
ini setting as they are not available out of the box except if you use a
special compile flag.

To my knowledge, short_open_tag=1 always enables short open tags,
regardless of the configure option --disable-short-tags or others.

--
Christoph M. Becker

I was more going along the lines of removing short tags altogether with
the
ini setting as they are not available out of the box except if you use a
special compile flag.

To my knowledge, short_open_tag=1 always enables short open tags,
regardless of the configure option --disable-short-tags or others.

--
Christoph M. Becker

I really need to get better at articulating what I mean.
From what I know this is the case but when I meant out of the box I
meant without using the ini configuration.
So it is possible to use it if you declare the INI config.
However it may clash with XML from my understanding of the doc.

Best Regards

George P. Banyard

I was more going along the lines of removing short tags altogether with the
ini setting as they are not available out of the box except if you use a
special compile flag.

I don't really follow this reasoning: if we removed every feature which
wasn't enabled out of the box, we wouldn't need an INI file at all.

The question has to be whether including the option to turn this on is
still useful to people.

However, I didn't know they were used with template
engines but wouldn't they just use <?= which is always available?

No, as shown in my previous example, I've seen people use short-tags for
logic, like <? if($foo): ?> some HTML <? endif; ?>

I mean I don't really have any strong opinions about it. It just seems a
bit odd considering we removed ASP tags in, IIRC, PHP 7.

ASP tags were removed because they were very rarely used, and most people
probably didn't even know they existed. Short tags, in contrast, are
actually older than the full "<?php" tag, and were at one time extremely
common.

Again, it's possible that in the years since this was last discussed that
their usage has declined, but as with so many existing features, it's hard
to know who is still relying on it, particularly in private code, so we
should be very cautious of "just tidying up".

Regards,

Rowan Collins
[IMSoP]

Hi!

I'm currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only affects
the availability of <? tags as <?=is always available as of PHP 5.4.
From my understanding, the <? tag is not available without the directive,
so maybe we should deprecate PHP's short tag altogether?

Why? What would it improve for people that are using it? For people that
aren't, it obviously won't change anything. So what would be the
motivation for this change?

--
Stas Malyshev
smalyshev@gmail.com

On Tue, 12 Mar 2019 at 13:28, G. P. B. george.banyard@gmail.com
wrote:

I was more going along the lines of removing short tags altogether
with the
ini setting as they are not available out of the box except if you
use a
special compile flag.

I don't really follow this reasoning: if we removed every feature
which wasn't enabled out of the box, we wouldn't need an INI file at
all.

Which would be good - as all those things make writing portable code
harder.

   $ echo '<?xml ?>' | php

Is a valid program, which will behave vastly different based on the ini
setting.

Of course for some things having a config is good (error levels
arguably, extension loading, ...) but for the raw language syntax and
behavior not so.

johannes

Hello,

On Tue, 12 Mar 2019 at 13:28, G. P. B. george.banyard@gmail.com
wrote:

I was more going along the lines of removing short tags altogether
with the
ini setting as they are not available out of the box except if you
use a
special compile flag.

I don't really follow this reasoning: if we removed every feature
which wasn't enabled out of the box, we wouldn't need an INI file at
all.

Which would be good - as all those things make writing portable code
harder.

$ echo '<?xml ?>' | php

Is a valid program, which will behave vastly different based on the ini
setting.

Of course for some things having a config is good (error levels
arguably, extension loading, ...) but for the raw language syntax and
behavior not so.

johannes

--

In reality if developer wants to write "portable" and proper PHP code,
no one actually should use these short tags anymore. If they are still
used somewhere as part of some legacy code, they won't work on
majority of PHP installations anymore because the mostly have these
turned off today in the php.ini files. So, the question here is more
why supporting a feature that no one should use anymore...

--
Peter Kokot

 

Which would be good - as all those things make writing portable
code
harder.

   $ echo '<?xml ?>' | php

Is a valid program, which will behave vastly different based on the
ini
setting.

In reality if developer wants to write "portable" and proper PHP
code, no one actually should use these short tags anymore. If they
are still used somewhere as part of some legacy code, they won't work
on majority of PHP installations anymore because the mostly have
these turned off today in the php.ini files. So, the question here is
more why supporting a feature that no one should use anymore...

the point is: The program I have shown is valid in both modes. One
version is obviously stupid (referring to the constant 'xml' and not
doing anything further) but still valid.

Being just a developer from down the street I might not have been aware
of that and delivered the program to a user who, for whatever reason,
had short tags enabled and probably won't see a proper error. If they
know there are workarounds ( <?='<?xml ?>'?>  is a portable version)
but such things are a real pain.

Having langage changing based on an ini setting is bad. (ze1
compatibility mode was really really fun in early PHP 5 ... not)

johannes

Just gonna do general reply instead of pointing at specific points.

But as it has been pointed out using short tags makes the code less
portable,
which IMO isn't ideal.

I personally don't tinker with INI settings withing PHP with ini_set as
IMHO if you
need to change them it should be done in the php.ini file.
However, I'm not sure of the behavior if someone sets this behavior within
a file/class
does this only affect this specific instance or is it globally?
Because if it is globally I can see code that writes/uses XML be affected
as pointed
out by Johannes

As it seems that there are people for and against; I suppose I could write
an RFC
for this, but would need the karma to do so.

Best regards

George P. Banyard

However, I'm not sure of the behavior if someone sets this behavior within
a file/class
does this only affect this specific instance or is it globally?

Not all settings can be altered with ini_set; this one is listed at
http://php.net/manual/en/ini.core.php#ini.short-open-tag as PHP_INI_PERDIR,
which http://php.net/manual/en/configuration.changes.modes.php describes as:

Entry can be set in php.ini, .htaccess, httpd.conf or .user.ini (since
PHP 5.3)

Regards,

Rowan Collins
[IMSoP]

However, I'm not sure of the behavior if someone sets this behavior
within
a file/class
does this only affect this specific instance or is it globally?

Not all settings can be altered with ini_set; this one is listed at
http://php.net/manual/en/ini.core.php#ini.short-open-tag as
PHP_INI_PERDIR,
which http://php.net/manual/en/configuration.changes.modes.php describes
as:

Entry can be set in php.ini, .htaccess, httpd.conf or .user.ini (since
PHP 5.3)

Regards,

Rowan Collins
[IMSoP]

Huh didn't know about this behavior, thanks for pointing it out.

Best regards

George P. Banyard

G. P. B. wrote:

currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only affects
the availability of <? tags as <?=is always available as of PHP 5.4.
From my understanding, the <? tag is not available without the directive,
so maybe we should deprecate PHP's short tag altogether?

I would like to see that. "Question mark equals what?".

If you want to go further, dropping the PHP tag altogether would be
nice, since it would prevent context switching between
PHP/HTML/JS/whatever. That would force Wordpress to update their whole
code base. >:{)

If you want to go further, dropping the PHP tag altogether would be nice,
since it would prevent context switching between PHP/HTML/JS/whatever.
That would force Wordpress to update their whole
code base. >:{)>

I wholeheartedly support this initiative but I do not see it going through
without a lot of resistance. Using PHP itself as a templating engine is
part of what makes it so "newbie friendly".

On Sat, 16 Mar 2019 at 03:44, Kenneth Ellis McCall xellisx@gmail.com
wrote:

G. P. B. wrote:

currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only affects
the availability of <? tags as <?=is always available as of PHP 5.4.
From my understanding, the <? tag is not available without the
directive,
so maybe we should deprecate PHP's short tag altogether?

I would like to see that. "Question mark equals what?".

If you want to go further, dropping the PHP tag altogether would be
nice, since it would prevent context switching between
PHP/HTML/JS/whatever. That would force Wordpress to update their whole
code base. >:{)>

As I don't know how to email I already sent a private response which
basically states
that the <?= is equivalent to <?php echo as shown on the note on the
ini setting:
https://secure.php.net/manual/en/ini.core.php#ini.short-open-tag
(thinking of it this feature maybe could be better documented)

Also I could write an RFC for the deprecation as it is controversial but as
I said
before I would need someone to grant me RFC karma to my PHP.net account
girgias

Best regards

George P. Banyard

Hello,

If you want to go further, dropping the PHP tag altogether would be nice,
since it would prevent context switching between PHP/HTML/JS/whatever.
That would force Wordpress to update their whole
code base. >:{)>

I wholeheartedly support this initiative but I do not see it going through
without a lot of resistance. Using PHP itself as a templating engine is
part of what makes it so "newbie friendly".

I think using PHP tags for templates and option to write code without
opening tag might go through also. After all, text files are simple.

Something on this was already being done and probably also discussed:
https://wiki.php.net/rfc/nophptags

On the other hand, shebangs will still be present in CLI scripts. For example:
#!/usr/bin/env php

--
Peter Kokot

On Tue, Mar 12, 2019 at 11:57 AM Stanislav Malyshev smalyshev@gmail.com
wrote:

I'm currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only
affects
the availability of <? tags as <?=is always available as of PHP 5.4.
From my understanding, the <? tag is not available without the
directive,
so maybe we should deprecate PHP's short tag altogether?

Why? What would it improve for people that are using it? For people that
aren't, it obviously won't change anything. So what would be the
motivation for this change?

I'm with Stas (and some others in disconnected sub-threads because email is
hard). This RFC needs a better "why this is important" section. Yeah, I
get that it being an option makes writing portable code harder, I get that
the XML open tag is something that can be tripped on, but why is removing
it a sufficiently better solution to the "problem"?

As we stand now, code using short open tags works when those tags are
enabled. As we'd stand in the future, that code would not work. That
level of BC break requires a strong justification.

-Sara

As we stand now, code using short open tags works when those tags are
enabled.  As we'd stand in the future, that code would not work. 
That
level of BC break requires a strong justification.

The code would not simply "not work" but even potentially leak to the
client (as PHP would not treat it as code) which could leak credentials
or other sensitive information.

I still think that long-term goal should be that language behavior
doesn't depend on ini configuration. 

Also creating a tool which does the conversion is relatively simple.

johannes

Hi,

On Mon, Mar 25, 2019 at 5:16 PM Johannes Schlüter
johannes@schlueters.de wrote:

As we stand now, code using short open tags works when those tags are
enabled. As we'd stand in the future, that code would not work.
That
level of BC break requires a strong justification.

The code would not simply "not work" but even potentially leak to the
client (as PHP would not treat it as code) which could leak credentials
or other sensitive information.

I still think that long-term goal should be that language behavior
doesn't depend on ini configuration.

OK, so why not flip it and make it always available instead? I'm aware
of the potential XML conflict, but I've personally never seen it, so
to me that looks like the lesser evil compared to a massive BC break.

Cheers,
Andrey.

OK, so why not flip it and make it always available instead? I'm aware
of the potential XML conflict, but I've personally never seen it, so
to me that looks like the lesser evil compared to a massive BC break.

I slightly lean towards removing support for '<?', but in contrast, I've
seen echo '<?xml' quite a lot due to fear of short_open_tags.

--
Regards,
Mike

For the record, we're a mid-size organization, building a modern product on
PHP 7 with a PSR-based stack.

We've shunned template engines and rely heavily on short open tags and
alternative control-structures - mainly because we insist on static
analysis and IDE support, which we get by manually type-hinting a single
view-model variable $view at the beginning of each template.

No other template engine gives us what we want in terms of static analysis,
type-checking or IDE support.

The choice to rebuild a very large product in PHP vs e.g. Node, at the
time, was in part motivated by PHP's template features - which, while it
may look pretty verbose and ugly on the surface, has a huge advantage over
basically anything else, e.g. static analysis with various QA tools,
automated refactorings (rename etc.) in PHP Storm, and so on.

The loss of this feature would be a substantial setback for our
organization - for which there is no really good replacement.

On Tue, Mar 12, 2019 at 10:51 AM Rowan Collins rowan.collins@gmail.com
wrote:

From my understanding, the <? tag is not available without the
directive,
so maybe we should deprecate PHP's short tag altogether?

I think when that's been proposed in the past, people have said they like
it for use in simple templates, often along with the "alternative control
structures", e.g.:

<? foreach ( $things as $thing ): ?>
<? if ( $thing->quantity > 1 ): ?><p><?= $thing->description; ?></p><?
endif; ?>
<? endforeach; ?>

I couldn't find any discussions for a few years, though, so it's possible
opinions have changed.

Regards,

Rowan Collins
[IMSoP]