Website Structure

Question

Hey all,

I'm pretty new to php and i'm trying to decide the best way to organize the pages and, using PHP, deliver them. The two (basic) ideas I've had are:

• A bunch of individual pages all with PHP includes to have the header, footer, and menu.

• A single main page that has the menu, header, and footer, along with an include for the main content. The page name comes from a variable in the URL.

Does anyone have any other suggestions or ideas? This is pretty basic stuff, but figured I'd see if anyone has any better ideas.

Thanks

Answer 1

it really depends on the website you are designing. if you want to reutilize your components then the approach using the includes will work. you can try to have a kind of masterpage and just render the page you want in inside it

Answer 2

I like the individual pages with includes for headers and whatnot.

I have to maintain a website where the original developer used a single page with a variable in the URL and it's a pain. It makes it difficult to do any changes other than adding new similar pages. Though he also used frames, so that might be part of the problem as well.

Answer 3

Given those two choices I would go with number 2. If your site grows to a level that you need a proper framework, moving the single pages without all of the include('header.php'); stuff will be a lot easier. For bonus points use model and view folders in which to put db access and display logic respectively and you're half way to a true MVC environment.

edit to add- a single index with conditional includes also gives your app a single point of entry which can be very valuable for security.

Answer 4

It makes your life much easier to have menu and headers in header.php and footer, sopyright etc. in footer.php. Then just include those files into each page you create.

Answer 5

Depends.

Is the content of the page stored in a database? If so, you'd probably be best off by having a template for each content-page that just gets the content, titles and meta-info from the database and inserting it into the template. You can even have different types of pages (news, static content pages, archive-pages etc.), that all can have a different template.

If content is located in more or less flat files, the two suggestions you have do work, and I'd think the latter one is the easisest one to maintain.

Answer 6

The main with PHP is that you need to "KEEP THE PRESENTATION AND PROGRAM LOGIC SEPARATE". Or in other words, make sure that you aren't echoing html to the screen in the middle of the scripts that you do your business or processing logic in.

Your second solution is a fairly common (and not a bad) solution to the problem. It allows you to build a single page with all of your layout information which then includes the specific page content to be rendered. Obviously this won't work so well if you need to swap large portions of the layout template from one page to the next. In that case, your first solution would work better.

Lastly, I would strongly recommend that you take a look at the various PHP frameworks out there like Zend Framework, Symfony, or CakePHP to see how they all handle this problem. If you find one you like, then just use it. Otherwise you're still likely to get some great ideas on how to structure your own site.

Answer 7

Having used with both techniques in the past, I've found the former is more flexible, but that it can encourage poor practices. The latter provides a much more consistent user experience, as it keeps all your site-wide logic in one place and discourages you from making one-off exceptions.

I'm actually in the process of converting a site I wrote a couple of years ago from the included header/footer/menu model to the master-page model. The original system of includes was clean and straightforward and works very well. However, the more additional content I created, the more I realized the project was beginning to violate the DRY principle. Every page on the site began and ended the same way (repetition should always send up warning signals) and I was being tempted to make exceptions to the standard layout by omitting individual includes and writing one-off replacements. (Thankfully, I haven't yielded to that temptation often!)

Refactoring the site is making the pages more consistent, the layout easier to update (you can see the entire thing "at a glance"), and new pages easier to create.

Answer 8

I've gone in both directions before, and though they both have pros and cons I lean toward your second option, the single main page that contains the layout. This is similar to how master pages work in desktop publishing applications, and ASP.NET has a nice implementation of this idea - not that I'm saying you should switch technologies.

However, if you do go this route, use mod_rewrite to get your paths into the PHP master page, rather than querystrings in your URLs. Your .htaccess file should contain something like:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [S=1]
RewriteRule ^(.*)$ /index.php?path=$1 [QSA]

This basically says if the file they ask for didn't exist, instead of giving a 404 error hand off processing to index.php with the URL path in a querystring variable. So "http://example.com/path/to/page" ends up hitting index.php with $_GET['path'] set to "/path/to/page". From there you can pull content from a database, a flat file, or what have you. You can also choose different templates based on the path requested.

Answer 9

Why going only half way the right direction? Use one of existing MVC frameworks. They are powerful tools that structure the code probably much better than any custom solution. Go for MVC, learn how to separate business logic from presentation logic and from data structure, increase your value on the job market as a potential employee, save your time and be happy.

• Zend Framework
• Cake PHP
• Symfony Framework
• Kohana PHP

You should probably start (but not limit yourself to) Kohana PHP as it has mild learning curve.