Hi again,
Disclaimer: although discussions about this topic tend to be heated (and
hated) this is not the usual short_open_tag thread. Please refrain from
talking about other previous proposals and whether short_open_tag should be
dropped or not.
As mentioned on my other post, at Debian we are planning to include 5.3 in
Squeeze. Given that the development and production php.ini files both turn
short_open_tag by default but many applications shipped by Debian itself
still require it to be enabled, we have decided to enable it again on the
.ini files.
However, we would like to contribute in the quest to make applications stop
using short_open_tag. To do so, we have decided to throw an E_DEPRECATED
warning when an application makes use of short_open_tag. The current
implementation can be found at [1].
How does this sound?
[1] http://git.debian.org/?p=pkg-
php/php.git;a=blob;f=debian/patches/deprecate_short_open_tag;h=57a79c6215afdc8654c6d18e791a9b7c8f5e373b
Cheers,
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Raphael Geissert wrote:
However, we would like to contribute in the quest to make applications stop
using short_open_tag. To do so, we have decided to throw anE_DEPRECATED
warning when an application makes use of short_open_tag. The current
implementation can be found at [1].How does this sound?
We have no plans to deprecate the short open tag. So throwing an
E_DEPRECATED would not be appropriate.
-Rasmus
Rasmus Lerdorf wrote:
Raphael Geissert wrote:
However, we would like to contribute in the quest to make applications
stop using short_open_tag. To do so, we have decided to throw an
E_DEPRECATEDwarning when an application makes use of short_open_tag. The
current implementation can be found at [1].How does this sound?
We have no plans to deprecate the short open tag. So throwing an
E_DEPRECATEDwould not be appropriate.
True. An idea I just had was to continue throwing E_DEPRECATED (or a warning
with a most appropriate name, if one is added) iff short tags are used
without explicitly enabling them at runtime.
I haven't looked at how the short_open_tag runtime switch was implemented so
I don't know if it's possible or not.
This would for example make the following code throw a warning:
foo.php
<?
// ...
?>
But not this one:
bar.php
<?php
// ...
include("./foo.php");
?>
Does that sound more reasonable? or do you have another idea?
Cheers,
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Raphael Geissert wrote:
Rasmus Lerdorf wrote:
Raphael Geissert wrote:
However, we would like to contribute in the quest to make applications
stop using short_open_tag. To do so, we have decided to throw an
E_DEPRECATEDwarning when an application makes use of short_open_tag. The
current implementation can be found at [1].How does this sound?
We have no plans to deprecate the short open tag. So throwing an
E_DEPRECATEDwould not be appropriate.True. An idea I just had was to continue throwing
E_DEPRECATED(or a warning
with a most appropriate name, if one is added) iff short tags are used
without explicitly enabling them at runtime.I haven't looked at how the short_open_tag runtime switch was implemented so
I don't know if it's possible or not.This would for example make the following code throw a warning:
foo.php
<?
// ...
?>But not this one:
bar.php
<?php
// ...
include("./foo.php");
?>Does that sound more reasonable? or do you have another idea?
Then we have to have logic to differentiate <? from <?xml, for example.
It would make the parser quite a bit more complex if we have to start
parsing stuff outside of the active open tags. Not sure it is worth the
effort nor the extra overhead.
-Rasmus
Rasmus Lerdorf wrote:
Then we have to have logic to differentiate <? from <?xml, for example.
It would make the parser quite a bit more complex if we have to start
parsing stuff outside of the active open tags. Not sure it is worth the
effort nor the extra overhead.
Isn't something similar already done?
I was thinking that making short_open_tag runtime-only would be the best
solution (applying it only to include/require files, not on the same script
enabling the option), but given the amount of necessary code and behaviour
changes it is unsuitable for 5.3 (and somebody needs to be willing to do
that).
I'm not aware of something similar being proposed before, so, what do you
think?
I'm still looking for a way to warn about the use of open_short_tag not
being explicitly enabled on the PERDIR level. Otherwise the only thing I see
would make applications change would be when the default is Off and they
break.
Cheers,
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Raphael Geissert wrote:
I'm still looking for a way to warn about the use of open_short_tag not
being explicitly enabled on the PERDIR level. Otherwise the only thing I see
would make applications change would be when the default is Off and they
break.
But why do you want them to change? Short tags are convenient and if
the app doesn't have to worry about <?xml or <?xsl type stuff, it can
run happily with short tags enabled.
-Rasmus
Rasmus Lerdorf wrote:
Raphael Geissert wrote:
I'm still looking for a way to warn about the use of open_short_tag not
being explicitly enabled on the PERDIR level. Otherwise the only thing I
see would make applications change would be when the default is Off and
they break.But why do you want them to change? Short tags are convenient and if
the app doesn't have to worry about <?xml or <?xsl type stuff, it can
run happily with short tags enabled.
Because it is just not about the application but the whole system. With the
apache filter SAPI enabling short_open_tag is really a no-op. As for the
other SAPIs it mostly depends on what kind of files are used and whether an
extension such as htscanner is at hand or not.
If that's not available, having to change the settings for every application
is a mess. By making it a runtime-only option they would always work.
Cheers,
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Raphael Geissert wrote:
Rasmus Lerdorf wrote:
Raphael Geissert wrote:
I'm still looking for a way to warn about the use of open_short_tag not
being explicitly enabled on the PERDIR level. Otherwise the only thing I
see would make applications change would be when the default is Off and
they break.
But why do you want them to change? Short tags are convenient and if
the app doesn't have to worry about <?xml or <?xsl type stuff, it can
run happily with short tags enabled.Because it is just not about the application but the whole system. With the
apache filter SAPI enabling short_open_tag is really a no-op. As for the
other SAPIs it mostly depends on what kind of files are used and whether an
extension such as htscanner is at hand or not.If that's not available, having to change the settings for every application
is a mess. By making it a runtime-only option they would always work.
A runtime option to turn them on would require a really ugly hack, or a
really ugly tag at the top of all short tag files like:
<?php ini_set('short_open_tag',true)?>
<?
...
?>
That doesn't seem like a very nice solution to me. I think your goal of
making all apps run under the same config is a lost cause. I know the
Gallery3 guys are very much sticking with the short_open_tag in their
new version, for example, and I don't blame them.
Wouldn't it make more sense to come up with a nice way of having per-app
configs instead? Drop an app_name.conf file in a server config
directory and off you go.
-Rasmus
Raphael Geissert wrote:
Rasmus Lerdorf wrote:
But why do you want them to change? Short tags are convenient and if
the app doesn't have to worry about <?xml or <?xsl type stuff, it can
run happily with short tags enabled.Because it is just not about the application but the whole system. With the
apache filter SAPI enabling short_open_tag is really a no-op. As for the
other SAPIs it mostly depends on what kind of files are used and whether an
extension such as htscanner is at hand or not.If that's not available, having to change the settings for every application
is a mess. By making it a runtime-only option they would always work.Cheers,
What about having a new value?
short_open_tag = Warn
People who is knowingly wanting to use short tags can enable it. People
concerned with portability
fix the application. And people which don't bother to change defaults...
get warnings. Until an update
which disables it for true.
As mentioned on my other post, at Debian we are planning to include
5.3 in Squeeze. Given that the development and production php.ini
files both turn short_open_tag by default but many applications
shipped by Debian itself still require it to be enabled, we have
decided to enable it again on the .ini files.
Would it be possible to force short_open_tag to a specific value for
those applications alone? Perhaps through an .htaccess file? That way,
Debian keeps the "PHP default" but still allows those apps to work.
However, we would like to contribute in the quest to make applications
stop using short_open_tag. To do so, we have decided to throw an
E_DEPRECATEDwarning when an application makes use of short_open_tag.
The current implementation can be found at [1].How does this sound?
Like Rasmus said, we've no intention of deprecating it. It's just that
apps requiring short open tags are not really portable (because they
don't work when short_open_tag is set to 0).
with kind regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
twitter: @derickr
2010/1/13 Derick Rethans derick@php.net:
[snip]
Would it be possible to force short_open_tag to a specific value for
those applications alone? Perhaps through an .htaccess file? That way,
Debian keeps the "PHP default" but still allows those apps to work.
Raphael, you didn't seem to react on Derick's suggestion above
although it seems one of the best proposition so far.
[snip]
Patrick
Patrick ALLAERT wrote:
2010/1/13 Derick Rethans derick@php.net:
[snip]
Would it be possible to force short_open_tag to a specific value for
those applications alone? Perhaps through an .htaccess file? That way,
Debian keeps the "PHP default" but still allows those apps to work.Raphael, you didn't seem to react on Derick's suggestion above
although it seems one of the best proposition so far.
I sort of commented about it on one of my replies to Rasmus. The problem
with that approach is that not all SAPIs can be configured via a .htaccess,
and changing the global value affects all applications (and if they all use
a SAPI where .htaccess files can't change the settings there's not much they
can do).
Cheers,
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Raphael Geissert wrote:
Patrick ALLAERT wrote:
2010/1/13 Derick Rethans derick@php.net:
[snip]
Would it be possible to force short_open_tag to a specific value for
those applications alone? Perhaps through an .htaccess file? That way,
Debian keeps the "PHP default" but still allows those apps to work.
Raphael, you didn't seem to react on Derick's suggestion above
although it seems one of the best proposition so far.I sort of commented about it on one of my replies to Rasmus. The problem
with that approach is that not all SAPIs can be configured via a .htaccess,
and changing the global value affects all applications (and if they all use
a SAPI where .htaccess files can't change the settings there's not much they
can do).
I think you are again becoming a victim of too much generalization.
Like using the slower re-entrant mysql client library, for example, just
in case you have a threaded SAPI that needs it. 99% of people are going
to be using the prefork Apache SAPI or fastcgi, neither of which needs
this, and thus you are penalizing the majority in order to support edge
cases more easily.
Same goes for per-package configuration. The common case, Apache and
fastcgi, can do per-directory configuration, but you are choosing not to
use it in order to support edge cases. Instead of trying to change PHP
here, I'd be going after your problematic edge cases and bringing them
up to speed so they can support per-app configuration.
-Rasmus
Rasmus Lerdorf wrote:
I think you are again becoming a victim of too much generalization.
Like using the slower re-entrant mysql client library, for example, just
in case you have a threaded SAPI that needs it. 99% of people are going
to be using the prefork Apache SAPI or fastcgi, neither of which needs
this, and thus you are penalizing the majority in order to support edge
cases more easily.
The switch to libmysqlclient_r was because the mysql driver of apr-util was
going to be enabled and would cause a symbols conflict. MySQL 5.1 did not
change the symbols and as such we still can't link to the non-reentrant
library.
Same goes for per-package configuration. The common case, Apache and
fastcgi, can do per-directory configuration, but you are choosing not to
use it in order to support edge cases. Instead of trying to change PHP
here, I'd be going after your problematic edge cases and bringing them
up to speed so they can support per-app configuration.
That would be the ideal situation. Sadly it is not that easy to accomplish,
hence the need to support more configuration options.
Cheers,
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net