check if PHP is parsed in HTML files

This is a pretty cool tweak, but it removes the benefit the static HTML files, and there are better ways to do it IMO.

Apache can easily saturate your bandwidth limit serving static HTML files and images, but it can come crashing down serving too many PHP files because it requires server-side processing before the content is delivered to the client. I'm just saying this because I still like the option to serve static HTML files when I want to.

Why not just use PHP files?

In some cases the PHP is added to HTML files, which makes this mod necessary.

Still not necessary. The files could be renamed to .php, and then put a mod_rewrite rule to rewrite .html to .php. I've never had to do this, so it might get too confusing, but I still would want the ability to have truely static files.

the files themselves are pretty lightweight.

Just the fact that the PHP engine has to be loaded for that request makes a big difference, which is the point I'm trying to make. Having a PHP file with no PHP code at all loads slower than an identical file saved as a .html file.

Edit: I should note that I'm splitting hairs here. If this is hosted on a beefy shared hosting server, it probably won't matter, but something good to know.

I agree that in your scenario of having a bunch of files already existing is a "valid" use of this, however I still recommend that when starting out, it is best to use the extension for the type of file it is, not only for your sake, but down the road when someone else needs to work on the project it is less confusing.

If it is an issue with needing the browser to see a .html, that can be easily handled with a mod rewrite rule. Our CMS we put on sites at work uses links of .html, but behind the scenes mod rewrite takes it and passes it as a get variable to the main CMS system. (actually the pages can have any extension and it works).

-Greg

I agree that it is a pretty cool tweak but i was wondering which of the ways is more beneficial.

Is it using the way first highlighted above or is it easier to just use PHP files, i may be looking at it wrong but i believe that both would give the same benefits?

Only use it if you have to.

If you have PHP requirements in a file, and no requirements for the file to be shown as .html, then just use a .php file extension with PHP code in it.

Exposing a suffix in the first place is bad form, in my opinion. If you had to do it, a ".html" suffix would be best. I'll give two reasons as to why -- one from the website user's perspective and one from the developer's.

A file-oriented view of a website often makes little sense for users, though it might for the developer. Users have only an arbitrary, partial view of the filesystem, which is of no concern to them anyway. A route-oriented view is superior, as it more closely matches the logical topology of a website, no matter how it's technically generated.

In that case, however, it could be argued that a ".html" suffix doesn't indicate a part of a filename stored on the server, but a HTTP resource that includes primarily HTML code for the client to consume.

Think of it this way: when you, as a developer, open a ".php" file on the server, you can read the embedded PHP code. When your user 'opens' the file (via HTTP), all they see is HTML. It's better to contain that dissonance on the server side than to expose it to users.

The other reason is implied in your acceptance that maintaining existing URIs justify this use. What if in the future you switched to a different technology on the server side? If you then wanted to keep the same URIs, your server will have to treat ".php" as ".asp" or whatever.

My basic point is that decoupling HTTP URIs from physical filesystems is generally a good thing, and that means you're better off without suffixes for HTML content at least. And if you had to use a suffix, ".html" does make sense.

(One exception to the rule is if you're intentionally file-serving over HTTP, such as with a filesystem browser web-app or something.)

Anyway, the technique shown above isn't terribly clean, but it works pretty well. There is merit to the performance argument, but as decibel.places has shown you can set up exceptions one way or another to accommodate this. Above that, a caching HTTP proxy or dedicated content-delivery server can also help. It's not a bad idea.

Sometimes cheese is just cheese.

As in, it is sometimes better for the greater good to just use simplicity and stick to straight forward common usages as they were intended to be used.