5

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.

|improve this question
  • 4
    You don't have to fire up PHP each time just to include bits of HTML you reuse. There's SSI for that. – Daerdemandt Jan 4 '17 at 13:46
  • Not for SEO. It might be a security vulnerability, though - most systems don't treat HTML files as inherently dangerous, so it might be possible for someone to slip an HTML file through some upload dialog or something and use it for executing arbitrary code on your server. You're removing one of the layers of security - not necessarily a vulnerability, but might be if you also made other mistakes (like not disabling execution for the upload directory etc.). – Luaan Jan 4 '17 at 15:38
  • 1
    for SSI I will still have to forgo the .html preference and switch to shtm as a "preference" downside. That's clearly another option of how to do what I want that I wasn't aware of though, thank you for pointing that out. – Kyle Postlewait Jan 5 '17 at 0:29
  • perhaps I should be looking to a JavaScript or some other solution and forgo PHP processing altogether? stackoverflow.com/questions/8988855/… – Kyle Postlewait Jan 5 '17 at 0:44
  • You can still use .html files with SSI if you want to. But again, you need to enable this in .htaccess. You can also be selective on Linux with the XBitHack directive. – MrWhite Jan 5 '17 at 0:57
8

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.

|improve this answer
  • 1
    I disagree with the "the easiest for you". HTML files should contain html, PHP files are for PHP. Keeping your code neat will help you in the long run. – Martijn Jan 4 '17 at 10:27
  • 7
    HTML files often have more than HTML in them. And PHP files often have HTML in them. This isn't cut and dry and you make it out to be. – John Conde♦ Jan 4 '17 at 12:01
  • "HTML files often have more than HTML in them." And who is this helping in the long run? Not a reason to mix technologies willy nilly. – ESR Jan 4 '17 at 16:31
  • 2
    Separating components isn't always the right thing to do. Sometimes having them all together is okay. Not every script or application has to be a big project. Sometimes throwing it all together is the best option. There are no universal rules to how this should be done. – John Conde♦ Jan 4 '17 at 16:33
  • so I'm understanding this as though forcing html to be read as PHP because (let's assume) I need PHP in my html, will not inherently, or at least enough for a small business to worry about, affect SEO. So, I can force the change without much worry, or switch to index.php in a cool url structure, again without worry as far as SEO and ease of use goes. Thanks. – Kyle Postlewait Jan 5 '17 at 0:32
4

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.

|improve this answer
  • Agreed. I don't really like the making everything an index.php file in its own folder... I'm clearly just overly used to webpage files ending in html, I just don't want them to look complicated and extentioned as .php. If there's not much of a difference from the SEO perspective, I would prefer to parse the HTML as PHP, and so will stick with that route for both sites. Thanks. – Kyle Postlewait Jan 5 '17 at 0:36
  • How does something ending in .php look complicated? Better yet, why have any extension at all? It dosn't really make any difference SEO-wise, other than it is ugly. – Nate Beers Mar 2 '17 at 20:25
4

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!"

|improve this answer
  • 1
    This answer appears to be 100% opinion. You don't give any reasons why .html files shouldn't contain PHP code other than you wouldn't do so yourself. – Stephen Ostermiller♦ Jan 4 '17 at 11:50
  • Best practices are often an opinion, just one many agree upon. I've changed the emphasis of my opinion to "worth some extra effort", the exta effort is what you prefer :) Splitting code like I suggest is very very common. – Martijn Jan 4 '17 at 12:47
  • There are usually reasons for best practices. Things like "My text editor doesn't color code PHP properly when there is a .html" extension. It takes about 10 seconds to see that your .html file contains PHP. The benefits of a central place for header and footer code would seem to outweigh the benefits of momentary developer confusion to me. – Stephen Ostermiller♦ Jan 4 '17 at 14:46
  • I agree with you about the header and footer. It's the "using PHP in a .html file" part I think is bad practice. Seperating the sections is a very good thing to do. – Martijn Jan 4 '17 at 15:15
  • the only reason I'm using the PHP is to include the separate file. If there was a way to do that without PHP I would have no interest in relying on PHP sepcifically. – Kyle Postlewait Jan 5 '17 at 0:40
3

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.

|improve this answer
  • 1
    I have PHP completely unavailable to Apache. People forget that just the environment can be vulnerable and that no PHP code is required for this. While the environment has had less known vulnerabilities in the past few years, it does not mean that there isn't one. As well, as you state, any HTML marked as PHP spins up the interpreter only to do nothing at all. This is on a per request basis. It is a resource waste! Just going back to HTML should speed up the system by quite a bit. Cheers!! – closetnoc Jan 4 '17 at 4:34
  • @closetnoc, why not make that an answer? I agree that turning off the PHP interpreter will speed up the time to server response - but whether it amounts to "quite a bit" depends on a lot of things, and can only really be known by testing, as I've mentioned. – Tim Grant Jan 4 '17 at 14:19
  • 1
    While this answer isn't incorrect, if you get enough traffic that parsing plain HTML files as PHP causes problems, turning off PHP isn't going to solve that problem. The better solution would be caching at the server level. – DisgruntledGoat Jan 31 '17 at 18:10
2

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.

|improve this answer
0

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.