On Mon, Apr 9, 2012 at 7:02 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> 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. > Yeah I get that. I'm just not sure I see the point. Aren't there already text editors that handle the <?php tag for you? I'm just really nervous about creating an INI setting that would bork everything if there's a conflict between parallel running libraries and doesn't really provide any benefit other than an extremely minor convenience for some. It's a slight convenience, but at the cost of creating a single INI setting that radically alters the way PHP scripts are executed. What you're looking to do does have some merit, but it just doesn't pass the cost/benefit test for me. Btw I did see that RFC, but I was under the impression that it was just an April Fool's prank. ;P --Kris > 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 > >> >> > >> >> > >> > >> > >> >
