Is it bad practice to put PHP directives in .html files and have the server interpret them as PHP?

Question

I've been running my company's website, which uses the same header, footer and left column on every page, since late 2014. Because of this I set up the Apache server to interpret HTML documents as if they were PHP. I am using include() to bring the header.html, footer.html, and leftcolumn.html into each page, with some other minor variable exchanges, etc.

Now I'm working on my own website and was going to make the same move, but saw other questions on here being told to not force HTML to be read as PHP (in PHP form creation answers, which I successfully implemented, without forcing).

Question: Is it bad practice to configure a server to parse HTML files as PHP? Are there possible SEO repercussions for doing so? Should I forgo file extensions altogether and move into a folder structure? (.com/players/ instead of .com/players.html)

As there doesn't seem to be a clear answer on similar questions, this may be considered a "discussion" type question; if so I will turn on forcing HTML to PHP as it seems the easiest option for me, and consider rebuilding into a folder structure.

Answer 1

Is it bad practice to force html to be read as php? Are there possible SEO repercussions for doing so?

Search engines don't know nor care about how your pages are generated. They only see the output the request URL provides (in other words the output of your PHP file).

Should I forgo file extensions altogether and move into a folder structure? ( .com/players/ instead of .com/players.html)

Cool URIs don't change. It doesn't matter if you have a file extension or not, and if you do use one, it doesn't change when you change technologies. So choose whatever you think will be easiest for you to manage and stick with it.

Answer 2

If all your .html files contain PHP code and so need to be parsed by the PHP engine anyway then there is really no difference between parsing your .html files for PHP verses changing your file extensions to .php. Except from a developers standpoint, a .php file is obviously a PHP file and some editors might treat this differently (syntax highlighting, code completion, etc.)

However, if you are developing a new site or it's easy to change then there is no need to parse .html files for PHP. Just stick to the .php file extension. Also, if this code is intended to be deployed on different servers then stick with a .php file extension. Some shared servers do not permit .html files to be parsed by PHP and trying to conjure up the correct AddType / AddHandler directive for the server can be non-trivial.

Should I forgo file extensions altogether and move into a folder structure? ( .com/players/ instead of .com/players.html)

Note that when referring to .php file extensions we are literally just talking about the underlying file extension on the physical file, this isn't necessarily anything to do with the URL the user sees. The physical file on the filesystem should always have a file extension.

If by ".com/players/" you intend to rely on serving the DirectoryIndex from the respective directory, eg. .com/players/index.php, then I would avoid that approach since you will end up with 100s/1000s of "different" index.php files - which can be confusing. URLs that access a single page should not end in a slash IMO.

Answer 3

No, don't do this in a html file. I am a firm believer of putting in a bit more work to keep your code neat. CSS goes in a .css file, html in a .html file and PHP goes in a .php file*. Your current seperation of files is a good thing, it's the "im doing PHP in html files"-part which I don't recommend.
*Of course, this isn't 100% applicable, but you should try.

By doing this you (at least to a basic extent) and other people will (in the long run) create a project that is easier to maintain because you stick to best practices. While it might be possible to set up a server to handle PHP in a .html file, it isnt something that is commonly recommended.

Your code should be maintainable. I would not look for (or expect) PHP in HTML files. Keeping your code neat will help you in the long run. By keeping everything segregated you will automaticlly conform to specific coding standards, which in turn will help you improve your skill.
If you Google for "html in php" you will get plenty of answers/replies saying you cant PHP in a .html file. They're wrong, but it does show how uncommon it is.

Regarding your url: Your urls should not change when you change technology. Your urls should not have an extention of the file. However, there is a quick fix for this: Let the .htaccess rewrite the url for you internally. I have productpages where I use .htm in the url, so I can easiliy pick them up in my .htaccess, but they're not html files at all :)

---

Similar response as mine https://stackoverflow.com/a/11312349/2519416.
This might also be a nice read: "Don't mix PHP and HTML!"

Answer 4

PHP rendering will make your web server respond slightly slower

One main technical downside of parsing HTML as PHP would be the extra time, and server resources, that the processing consumes. If there are no PHP instructions in your HTML, this is not likely to be perceptible. You might save a few microseconds turning PHP parsing off.

You can measure this by testing your load time with PHP on or off with a tool like Pingdom. (Ignore their advice about week-long caches.) I don’t think you’ll see much difference.

There are probably much more effective ways to speed up your site. For example, if you aren’t scoring in the 90’s on Google PageSpeed Insights spend your energy improving your score there first (especially if you care about SEO).

High Volume Sites

The advice to ignore the PHP penalty goes for your typical website. If you are getting volume in the multiple page views per second range, then by all means switch off PHP unless you need it, to reduce the load on your web server.

Security

Having PHP processing on your site opens up a possible avenue of attack on your website. This is a little paranoid, but it’s a valid reason to shut off PHP processing if you simply aren’t using it.

Answer 5

As various answers have hinted at, you should distinguish between URLs and physical filenames. The easiest mapping of URLs is directly to the filesystem - http://example.com/foo.html pointing at a file called foo.html in some directory - but as soon as you think about URLs as an SEO (or, in an ideal world, UX) tool, then you are likely to use a more complex mapping anyway.

The choice of physical filename then has nothing to do with SEO, only performance and security. For instance, you could map http://example.com/foo.html to scripts/generate_page.php?page=foo and http://example.com/bar.html to static_pages/bar.html.

As others have said, for pages that do absolutely nothing with PHP, there is a performance (and potential security) benefit to not routing them through the PHP process at all. Reserving a physical file extension for such pages is the easiest way to do this - given the mappings above, it's easy to tell Apache to serve bar.html directly, but pass generate_page.php to the PHP processor.

For pages that do use PHP, there is a benefit to following common conventions, as you will spend less time configuring tools to recognise which files are PHP and which aren't. As with any convention, it will also be easier for other people to work with your project in future if things are where they expect.

Answer 6

The practice of mixing HTML and PHP together in the same document started a long time ago, and even though some popular open source projects such as WordPress still do this, is it starting to become outdated practice and I would even consider it bad practice from a coding perspective.

Obviously it won't have any impact on SEO since all Google care about is the output, but it does have a large impact of how you organize your code and project.

Most of today's popular framework use the MVC design pattern. Model-View-Controller. This design pattern is all about separating the logic and the views/output into separate files to make your code easier to maintain.

Unlike your current pattern where you put all the HTML and PHP together in a single file, you will follow a more object oriented approach with clear, easy to maintain classes.

An additional benefit is that it will be easier for your front end programmer to do his job because he don't have to consider the backend logic in the same files that he's working on.