Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I can't remember what site I glanced over and picked up that tidbit, but someone suggested that you should keep PHP parsing to .PHP files, and not modify one's webserver's htaccess to include PHP parsing within .HTML files.

Is this true? Is there any generally agreed upon reason as to doing it one way or the other?

share|improve this question
3  
I'm going to answer this question with a question: why would you give a file an .html extension if contains PHP? –  user16764 Mar 2 '12 at 0:36
    
@user16764 Because it's not necessary for end-users to know what language a site is implemented in, and for most people, ".html" is akin to "that internet language". –  Izkata Mar 2 '12 at 3:47
1  
@user16764, if you want to add a bit of php to existing pages without changing the url, thats certainly the simplest way. –  GrandmasterB Mar 3 '12 at 6:04
2  
@Izkata: It's not necessary to abuse server-side file extensions in order to hide your development platform from the public. A better way of achieving the same thing would be to use URL-rewriting to hide file extension or replace with the extension of the output format (whether it's HTML, XML, RSS, etc.). For server-side processing, your files should still use the correct file extensions. –  Lèse majesté Mar 3 '12 at 9:32

5 Answers 5

I would say yes it is true. I don't know how to prove that it is generally agreed upon.

Ideally, all of your .html files have no php code in them, and you should not have the server parse them for php.

If for some reason you did have php code in .html files, then obviously you do need to have them parsed for php. In this case, you should consider changing those files to ".php", but make sure you update any references to them, and make some kind of redirect if their urls were public.

share|improve this answer
    
+1 - I've seen some servers configured to where there is automatic forwarding of files to the sister file. Like myfile.html. If it's not found, then redirect to myfile.php. –  jmort253 Mar 3 '12 at 18:27

I'd say there are two major points to consider when making this, or any, programming/configuration decision:

1. Communication:

By default, HTML files are treated as HTML only. Most developers coming into your environment may assume a default configuration. However, if it's a general practice for system admins to change this, then those developers may assume the HTML files may contain PHP.

I believe that leaving HTML files as HTML-only is a great way to communicate to any other developers that page1.html is a pure-HTML file. This can make it easy for new team members to reverse engineer an existing project if this was the configuration used. In this case, there is no need to open the file for editing as one can simply look at the file extension.

2. Could this Create Unnecessary Overhead?:

Let's say you do have several static HTML files. Well, now your PHP server is going to have to parse your HTML files to look for non-existent PHP code. While I'm sure Apache is fast enough to where this isn't a huge, noticeable problem, it's still something to potentially take into consideration.

Summary:

In summary, my general approach to development is that if it ain't broke, don't fix it. There are a lot of things you can do if you do in fact need to do them, but if you don't have a very strong reason for using non-standard configuration, then it's probably not worth the cost of leaving your potential successor with misunderstandings or confusion.

With that said, I'm not a professional PHP developer, so making HTML files parseable by the server may or may not be considered standard procedure. I would opt to go with whatever is going to be easiest for other PHP developers who join me in my project.

share|improve this answer
    
I still see the .phtml extension used out in the wild periodically to prevent PHP from parsing purely static content. I asked a client once why they were doing that at all, and the answer was 'So people don't know we're using PHP, because the files don't end in .php!' Indeed, a 'smile and nod' moment if there ever was one. –  Tim Post Mar 3 '12 at 15:36
    
Funny, people act like it's a deep dark secret. –  jmort253 Mar 3 '12 at 18:25

The way I see it, if you have choice, change the file extension to .php, but if you inherit a website and don't want all the addresses to change when you start putting in includes and what-not, then you can either parse php inside html files or use mod-rewrite to fake it. (Since you mentioned .htaccess, I am continuing the assumption of Apache.)

The only time I've run in to trouble with this is that I inherited a site that had XML tags in it, (I really don't know why) and php short tags were enabled, so it tried to parse the XML as PHP. What I did for that was used a search/replace tool to:

//change all the <?XML tags to 
echo'<?XML';

At the time I REALLY didn't know what I was doing. Now I might sometimes know what I'm doing. ;)

share|improve this answer

parsing a .php file to html on server side is just overload to server I/O i think you wanted to ask about caching of web pages (this will reduce network, CPU, RAM load on the server if you have huge number of web requests that your server can't handle)

please have a look on web chaching here

share|improve this answer

Parsing HTML for PHP tags will create extra overhead. But unless you are talking about a fairly high traffic site, that extra overhead wont have a noticable impact on the performance of the site.

The bigger issue might be maintenance. Will the next guy know there's PHP in those html files? Whether thats a big issue or not would depend on your specific situation.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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