Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
Patrick ALLAERT wrote: 2010/1/13 Derick Rethans der...@php.net: On Tue, 12 Jan 2010, Raphael Geissert wrote: [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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
Raphael Geissert wrote: Patrick ALLAERT wrote: 2010/1/13 Derick Rethans der...@php.net: On Tue, 12 Jan 2010, Raphael Geissert wrote: [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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
Hi, and why Debian still use the php module version by default ? By using the fcgi version each application can have it's own php.ini. Furthermore, it's a different problem but this will also allow use of a specific unix account for each apps. In the actual Debian's php.ini we can found about safe_mode : NOTE: this is considered a broken security measure. Applications relying on this feature will not recieve full support by the security team. For more information please see /usr/share/doc/php5-common/README.Debian.security I agree with that, but there is no security at all on default Debian install : any PHP application can read configuration (DB passwords, encryption keys, etc) of other PHP applications. As a Debian user, I always modify the default behaviour to have phpmyadmin running under the phpmyadmin account and using my /etc/phpmyadmin/php.ini file. Same problem with roundcube too, and other apps. So, maybe Debian should change if way of deploying PHP apps, to allow better security and per-apps config file, no ? In any case, I really really don't want PHP throw an E_DEPRECATED on apps using short_open_tag. Olivier Derick Rethans a écrit : On Tue, 12 Jan 2010, Raphael Geissert wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
2010/1/13 Derick Rethans der...@php.net: On Tue, 12 Jan 2010, Raphael Geissert wrote: [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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
On Tue, 12 Jan 2010, Raphael Geissert wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
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_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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
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_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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
