I am asking this because I have been coding valid tableless CSS/XHTML markup for a while and like a idiot, I kind of stayed away from PHP.

I want to know if there is any reason not to make all my templates from now on with at least the extension of PHP and a menu that is done with a @include. I have found that using the @include function for a menu is the best way to go, I just don't know enough about PHP to know the drawbacks from doing so. Seriously why not have a menu that links through out the whole site and can be changed from one file which effects the whole site menu.

I tried to oversimplify this, but for strong valid CSS/XHTML sites, shouldn't they all be running off the php extension with external include files for things like the menu, footer, sidebar, etc which are going to be the same on all pages. Like a real light mini CMS?

Please if anyone knows drawbacks to doing this, or can figure out why most information out there doesn't really even tell people this, that would be great. Thanks, I don't know much PHP at all which is why I am asking, but I do know includes.

The only draw back is when you start splitting the files down too small. For instance, if your menu include file has 40 other includes which each contain an other 2 includes which each contain an include you are going to be drowning in too many files and when you go to make modifications you will have to jump through a dozen files just to find what you are looking for. It is another form of "spaghetti code". Otherwise, no there is no drawback to properly using include files to make overall mass site changes. We use such a method at my place of work except with ASP files. Works nicely and we host over 170 travel agency sites.

Actually, I'd like to say the more "professional" PHP programmers use a template system (Smarty seems to be the more well known). The idea behind doing so is that there will be as little as possible code.

Layers is the key here.

Layer 1: PHP Code. Everything that has to do with gathering data, parsing it, manipulating it, or anything to get the data in a "form" that is required. (Form is not the HTML Form. Form here is meaning of shape or data structures.) For the most part, nothing in this layer should directly influence the next two.

Layer 2: (X)HTML/XML. Describing data for the browser. <em>, <a>, <div>, etc. shouldn't (by themselves) tell the browser how to display the data, even though they sort of do. In other words this is like the skeleton of the final product. The really important thing to remember here is that there should be little if any code in this layer.

Layer 3: CSS. This layer deals with the "skin" or "makeup" of the final product.

Well, that's what I think anyway. Not every project can have such a system, but it helps me to think like this.

Obviously there is a good, bad, and absolutely dreadful way of of doing anything no matter what the final method of chosen application is.

PHP isn't necessarily required to do a templating system, although using a more sophisticated server-side engine does makes things alot easier and in my mind atleast, alot cleaner. You can do the same thing your wanting to do SSI(server side includes).

Obviously, you'll need to change any files using SSI to .shtml and have a server/web host that supports such.

PHP templating systems are notorious for the previously mentioned hassle of finding what file your actually wanting to update.

When I first started using PHP, I just had to program a bulletin board. Matt Mecham(Invision Power Board) was my hero and I didn't dream of doing anything else. When it came time to write my template engine, the only method of templating I had ever seen at this point in time was Matt Mechams template "functions" using in IPB. I didn't like the idea of OO programming, it intimidated me at the time, so I ended up having a file for everything. Just my main page had over 30 templates! Can you imagine how much of a pain that is?

The perfect solution for you, assuming your actual page content doesn't have dynamic content(because then you'd already be using a dynamic scripting language) would be a header and footer system.


Mixing HTML and PHP in the same file is generally flowned upon and professional programmers using such a style are usually crucified and left to die, but I'm speaking mere simplicity and ease of use for the webmaster just looking to run a simple website.

Instead of just answering your question, which I feel I would have simply provided a biased answer being a PHP programmer, I just gave you two options and left the final call to you. Hope thats alright.

I like knowing the correct way to do things but I'd like to know why it is bad to mix php and html esp when a lot of templated sites examples I've seen call for includes for the header and footer and navigation. I may have misunderstood what you said,though. I usually use includes for header,footer and navigation, then I just put in whatever content I want in the appropriate divs.
I link to my css file in the header.
This system works for me really well.
But are you saying this is bad to do?

What I meant was, it's generally considered impropper to have things like this.



Ultimately, it gets very messy and very hard to manage. It's not really anything as far as how the actual site runs, it's just messier and harder to maintain than having all html and php in different files.

and this has to be saved as a PHP file and not as an html.