2012/4/10 Kris Craig <kris.cr...@gmail.com>: > On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott <l...@cywh.com> wrote: > >> On 4/9/12 5:02 PM, "Kris Craig" <kris.cr...@gmail.com> wrote: >> >> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell <t...@punkave.com> wrote: >> > >> >> Let me be very clear about that... I am NOT proposing that <?php at >> >> the top be mandatory in a file loaded in code mode! I don't want to >> >> type it ever again outside of a template file, personally. See the >> >> title of the RFC. >> >> >> > >> >But again, how then do you intend to make it so that a pure-code file can >> >be called directly from the webserver on a host where the developer >> >doesn't >> >have access to most config options? This is a very common scenario that >> >cannot be ignored. If not a <?phpp tag, then *something* in that file has >> >to identify it as pure code otherwise this just isn't workable. >> > >> >Any INI option would be problematic because that would essentially cause >> >all scripts relying on the setting you didn't choose to break. And >> >unfortunately, recognizing a new file extension could pose problems for >> >people running on heavily restricted hosts that currently have PHP support >> >"built-in". While I would never host on one of those services myself, I >> >don't like the idea of suddenly alienating everyone who does. >> > >> >I'd totally be open to an alternative to the <?phpp tag that can withstand >> >scrutiny, but so far I haven't seen one. And absent that, there's no way >> >I >> >could support this, which really sucks because at least conceptually I >> >think it's a really good idea. >> >> >> If the default is "template mode" and the "<?php" tag is optional (at the >> top) in "code" mode there shouldn't be any problems. >> >> We don't need to change or leave out the tag entirely. >> >> Is there a problem with people being able to choose "template mode" or >> "code mode" as the default in the php.ini file if "template mode" is the >> default if not specified? >> > > I think so, yes. A config option that causes massive BC breakage doesn't > become ok simply because it defaults to current behavior. I just can't > envision any situation in which having that option switched on would not > cause problems, unless that server is *only* running scripts that assume > code mode. However, what if you want to use two scripts, but one assumes > code and the other assumes HTML? The ini_set() function would be pretty > much useless given the circumstances. > > Instead, I would have an optional <?phpp tag at the top of the file. This > would be in addition to the file extension/SAPI approach and the require > keyword approach. In other words, perhaps an "all of the above" strategy > is what's neeeded here. But either way, I just don't think an INI setting > would be feasible.
Hi, I guess you are trying to fix other problem than me, but please have a look this RFC https://wiki.php.net/rfc/nophptags INI setting is feasible for controlling template(embed) mode. It's easy to understand what it does also. PHP programmers may write ini_set('template_mode', 'off'); // in bootstrap. older PHP just ignores this. // Admin may put it in php.ini or .htaccess also. then they would set template_mode="on"/"off" just before/afeter render templates. ini_set('template_mode', on); // old PHP ignores render_template($my_tpl, $my_tpl_vars); // do whatever is needed as template engine ini_set('template_mode', off); // old PHP ignores Above code works for both template_mode="on" and "off" in php.ini. In real world, programmer would write ini_set() inside of render_template(). This simple change makes PHP free from fatal LFI mess while maintaining compatibility with older PHP. If you don't want to write needless PHP tags, you don't have to with this RFC, too. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net > > --Kris > > >> Luke >> >> >> > >> >--Kris >> > >> > >> > >> >> >> >> On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott <l...@cywh.com> wrote: >> >> > On 4/9/12 3:53 PM, "Tom Boutell" <t...@punkave.com> wrote: >> >> > >> >> >>I see why you want to allow <?php at the top to be optional in 'code >> >> >>mode,' rather than disallowed in code mode. But your purpose is to >> >> >>allow legacy code to be autoloaded without knowing in advance whether >> >> >>it starts with <?php or not. >> >> >> >> >> >>But that would probably lead in practice to the use of a single file >> >> >>extension for old and new class files. >> >> >> >> >> >>And that, in turn, would lead to source code being spewed to the >> >> >>browser for all to see if a perfectly respectable autoloader circa PHP >> >> >>5.3 runs into one of these new files. >> >> >> >> >> >>This is a much more significant security issue than some of those >> >> >>mentioned previously because perfectly well-written code would display >> >> >>this behavior if someone unknowingly drops a newer library into, say, >> >> >>the lib/ folder of a Symfony 1.4 project. Ouch. >> >> > >> >> > >> >> > So are you saying the starting "<?php" tag should be required in "code >> >> > mode"? >> >> > >> >> > If so, I'm ok with that as long as: >> >> > >> >> > - "?>" is forbidden >> >> > >> >> > - Text before the opening <?php tag (literal text or white-spaces) is >> >> > either ignored or throws an error instead of printing to the output >> >> buffer. >> >> > >> >> > If that's not what you mean, please clarify. >> >> > >> >> > Luke >> >> > >> >> >> >> >> >>It would be much better for that autoloader to just ignore the file >> >> >>because it has a new extension. This way the problem is immediately >> >> >>apparent: >> >> >> >> >> >>"Hey, my class didn't load, something must be up. Oh my PHP is old >> >> >>and/or this autoloader doesn't know about .phpc files, what are they >> >> >>anyway... google google... aha, I need PHP 5.x and an updated >> >> >>autoloader. Grumble. Okay." >> >> >> >> >> >>This is a much safer outcome. >> >> >> >> >> >>On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott <l...@cywh.com> wrote: >> >> >>> Tom, >> >> >>> >> >> >>> On 4/9/12 3:17 PM, "Tom Boutell" <t...@punkave.com> wrote: >> >> >>> >> >> >>>>My original goal was to stop typing <?php in pure code files. That >> >> >>>>includes at the top. I think it's entirely reasonable to achieve it >> >> >>>>with an option to the require keywords for this purpose and a naming >> >> >>>>convention to be followed by autoloaders. Keep in mind how rarely >> >>you >> >> >>>>have to change them. We're talking about code maintained by a >> >> >>>>relatively small number of very sharp developers. They can handle a >> >> >>>>few flags (: >> >> >>>> >> >> >>>>The prohibition of ?> still seems unnecessary and perhaps divisive, >> >> >>>>but if it were preferable to the majority to prohibit ?> in a pure >> >> >>>>code file, I could live with that as long as classic PHP files are >> >> >>>>also 100% supported and remain the default. I'm trying to craft a >> >> >>>>broadly acceptable compromise that still achieves the original goal >> >>of >> >> >>>>allowing people to write "just code" in a class file. >> >> >>> >> >> >>> >> >> >>> I think you can you achieve that by making "template mode" default >> >>and >> >> >>>the >> >> >>> default changeable in the php.ini file. >> >> >>> >> >> >>> Something like this: >> >> >>> >> >> >>> /* >> >> >>> Code only, <?php at top optional, no ?>. >> >> >>> Text before opening <?php silently dropped >> >> >>> >> >> >>> */ >> >> >>> >> >> >>> require "/path/to/somefile.php", INCLUDE_CODE; >> >> >>> >> >> >>> /* >> >> >>> Works exactly as it is now: <?php and ?> allowed. >> >> >>> Text betweeen ?>...<?php printed to output buffer. >> >> >>> */ >> >> >>> >> >> >>> >> >> >>> >> >> >>> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is >> >>now >> >> >>> >> >> >>> /* >> >> >>> By default INCLUDE_TEMPLATE >> >> >>> Can change default mode in php.ini to be INCLUDE_CODE if desired. >> >> >>> */ >> >> >>> >> >> >>> require "/path/to/anotherfile.php"; // As it is now >> >> >>> >> >> >>> >> >> >>> Personally I would like to be able to do something like this in my >> >>auto >> >> >>> loader: >> >> >>> >> >> >>> include $file, INCLUDE_CODE & INCLUDE_SILENT; >> >> >>> >> >> >>> >> >> >>> >> >> >>> That way I can ensure pure code is being inserted and no warnings >> >>are >> >> >>> thrown if the file doesn't exist (class undefined will be thrown >> >> >>>anyway). >> >> >>> >> >> >>> I think it's important to make <?php optional at the top if you're >> >> using >> >> >>> existing or third party libraries that you can't modify. At least >> >>then >> >> >>> you'll be able to maintain backwards compatibility with most code >> >> >>>written >> >> >>> since PHP 5. >> >> >>> >> >> >>> (We don't need PHP_*. See the output of get_defined_constants() ). >> >> >>> >> >> >>> I like where this is going! Hopefully after the RFC has been >> >>finalized >> >> >>> everyone else will agree. >> >> >>> >> >> >>> >> >> >>>> >> >> >>>>On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <kris.cr...@gmail.com> >> >> wrote: >> >> >>> >> >> >>> >> >> >>> Kris, >> >> >>> >> >> >>> >> >> >>> >> >> >>>>> >> >> >>>>> >> >> >>>>> Bah, right! That damned <?xml tag.... >> >> >>>>> >> >> >>>>> I already know what everyone's reaction will be, and it is >> >>probably a >> >> >>>>>REALLY >> >> >>>>> bad idea, but I feel obligated to at least mention it: Should we >> >> >>>>>consider >> >> >>>>> replacing "<?..." with something that doesn't conflict with >> >>anything, >> >> >>>>> perhaps starting in PHP 6? No need to get out the torches and >> >> >>>>>pitchforks, >> >> >>>>> everyone! As insane and problematic as that would be (i.e. BC >> >>break >> >> >>>>>with >> >> >>>>> roughly 1/3 of the internet lol), I felt as though the subject >> >>should >> >> >>>>>at >> >> >>>>> least be broached. ;P >> >> >>> >> >> >>> >> >> >>> No need. Just keep it as <?php. It's already been well established. >> >>We >> >> >>> should ovoid overcomplicating it. >> >> >>> >> >> >>> Luke >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >>-- >> >> >>Tom Boutell >> >> >>P'unk Avenue >> >> >>215 755 1330 >> >> >>punkave.com >> >> >>window.punkave.com >> >> >> >> >> >>-- >> >> >>PHP Internals - PHP Runtime Development Mailing List >> >> >>To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Tom Boutell >> >> P'unk Avenue >> >> 215 755 1330 >> >> punkave.com >> >> window.punkave.com >> >> >> >> -- >> >> PHP Internals - PHP Runtime Development Mailing List >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> >> >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
