Re: Throwing an E_DEPRECATED for short_open_tag

From: Date: Thu, 14 Jan 2010 21:54:24 +0000
Subject: Re: Throwing an E_DEPRECATED for short_open_tag
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-46740@lists.php.net to get a copy of this message
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

« previous php.internals (#46740) next »