I’m trying to make a case to not allow PHP code in .html files to be parsed. But the head of a project wants to do this. I know there will be a performance hit as every .html page will now go through the PHP parser, but are there any other issues out there? I haven’t found any other compelling reason to not do it.
I doubt that you would see real-world performance implications that can be easily solved by having the php parser look at the html files. Most of the other stacks I work with punch every single request through an app server much heavier than most apache configs I’ve seen and they seem to be doing just fine.
The most compelling reason I can think of not to do it is that you are looking at a configuration / tooling landmine as the world kinds of expects .html to be pure html/js and .php to be a combination of php / html / js. The question I would ask is “what do we gain by doing this? Why not just do the more conventional .php thing? Or if we care about pretty urls why don’t we use something that has real routing and get off the file system.”
That’s pretty much all I came up with as well. Thanks for the input.
There was a time years ago where some wanted to “hide” the fact that their files were PHP
IMHO any such logic is now moot.
I agree with wwb_99 as to server performance.
What’s the difference between PHP parsing 100 .php pages or 100 .html pages?
I also agree with the getting rid of the php extension logic. If you don’t want it there go with routing.
Sounds more like the project head is “stuck” in an idea of how they think things should be rather than the reality.
But other than being pointless, I can’t think of any reason why doing it that way could cause many problems other than some initial confusion.
he didn’t really explain why he did it, so I’m not sure of his reasoning either. But this guy seems a bit old-school in how he does things anyway. Thanks!