Bumping this after about a 3 week lull. How would I go about adding this to the wiki??
On Tue, Dec 21, 2010 at 11:43 AM, Michael Morris <dmgx.mich...@gmail.com>wrote: > That would make for an easier situation. If we don't worry about legacy > for a moment that would give us this cleaner bitfield. > > Bit > 0 -- Standard tags toggle > 1 -- Short tags toggle > 2 -- ASP tags toggle > 3 -- Script tags toggle > 4 -- Short echo toggle. > > For backwards compat ship with bits 0 and 3 set on. The existing short tags > mode is bits 1 and 4 on. If all the bits are turned off then we have the > PHP_TAGS_NONE setting. In that mode the engine must assume the whole file is > going to be PHP code since there are no tags to look for. > > I honestly like this best of what has been suggested so far, BUT the need > to adjust settings after upgrade is a major concern. Admins who never > enabled asp or short tags to begin with wouldn't notice the settings going > away, and those that have I would expect to be savvy enough to transfer the > setting change themselves. > > Another possbility is to have PHP set tag_style according to whether it > sees short_open_tags and asp_tags in the ini file. If either of them are > on, and tag_style wasn't explicitly set, then php will set tag style to the > values it must have to mimic the intent of the setting. If tag_style is > explicitly set then it wins out - but a deprecated notice gets thrown to > alert the user that they have both tag_style set and short_open_tags and/or > asp_tags set on. > > If an htaccess or httpd.conf directive explicitly calls for short_tags or > asp_tags after tag_style was explicitly set a warning of some sort is thrown > informing the user that they must switch that declaration to one compatible > with the php.ini file. Ditto for sets occurring at runtime with one > exception - if the user specifies tag style from the include or require > statement itself this shouldn't raise any error. > > (That there's no comment on the adding of the second param to those > function as of yet concerns me a little - it is somewhat key to the > proposal.) > > Anyway, the trickiest part of this is balancing the past with the future. > > >
