# Throwing an E_DEPRECATED for short_open_tag - Thread: https://externals.io/message/46662 - Original archive: https://news-web.php.net/php.internals/46662 - Started by Raphael Geissert on 2010-01-13T01:48:33+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #46662 — Raphael Geissert — 2010-01-13T01:48:33+00:00 URL: https://externals.io/message/46662#46662 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 --- ## #46663 — Rasmus Lerdorf — 2010-01-13T01:57:23+00:00 URL: https://externals.io/message/46662#46663 · In reply to: #46662 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_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 --- ## #46678 — Derick Rethans — 2010-01-13T10:48:50+00:00 URL: https://externals.io/message/46662#46678 · In reply to: #46662 > 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_DEPRECATED` warning 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 --- ## #46707 — Raphael Geissert — 2010-01-13T17:06:56+00:00 URL: https://externals.io/message/46662#46707 · In reply to: #46663 Rasmus Lerdorf wrote: > Raphael Geissert wrote: > > […] > > We have no plans to deprecate the short open tag. So throwing an > `E_DEPRECATED` would 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 Does that sound more reasonable? or do you have another idea? Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net --- ## #46708 — Rasmus Lerdorf — 2010-01-13T17:13:42+00:00 URL: https://externals.io/message/46662#46708 · In reply to: #46707 Raphael Geissert wrote: > Rasmus Lerdorf wrote: > > > […] > > 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 > // ... > include("./foo.php"); > ?> > > Does that sound more reasonable? or do you have another idea? Then we have to have logic to differentiate > Then we have to have logic to differentiate 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 --- ## #46737 — Rasmus Lerdorf — 2010-01-14T21:07:54+00:00 URL: https://externals.io/message/46662#46737 · In reply to: #46735 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 Raphael Geissert wrote: > > […] > > But why do you want them to change? Short tags are convenient and if > the app doesn't have to worry about 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 --- ## #46740 — Rasmus Lerdorf — 2010-01-14T21:54:24+00:00 URL: https://externals.io/message/46662#46740 · In reply to: #46739 Raphael Geissert wrote: > Rasmus Lerdorf wrote: > > > […] > > 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: 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 --- ## #46744 — Patrick ALLAERT — 2010-01-15T07:50:11+00:00 URL: https://externals.io/message/46662#46744 · In reply to: #46678 2010/1/13 Derick Rethans : > [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 --- ## #46747 — keisial@gmail.com — 2010-01-15T15:50:33+00:00 URL: https://externals.io/message/46662#46747 · In reply to: #46739 Raphael Geissert wrote: > Rasmus Lerdorf wrote: > > > […] > > 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. --- ## #46752 — Raphael Geissert — 2010-01-16T17:09:09+00:00 URL: https://externals.io/message/46662#46752 · In reply to: #46744 Patrick ALLAERT wrote: > 2010/1/13 Derick Rethans : > > […] > > [snip] > > > […] > > 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 --- ## #46753 — Rasmus Lerdorf — 2010-01-16T17:16:50+00:00 URL: https://externals.io/message/46662#46753 · In reply to: #46752 Raphael Geissert wrote: > Patrick ALLAERT wrote: > > > […] > > 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 --- ## #46788 — Raphael Geissert — 2010-01-18T22:10:34+00:00 URL: https://externals.io/message/46662#46788 · In reply to: #46753 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