Website Structure

Question

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 o

Answer 1

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 2

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 3

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 4

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

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.