View Full Version : Site building with PHP question on comment by missing-score

04-28-2006, 05:33 PM

But for a small portfolio site, I feel his linking method is really inappropriate... IMO, it would have been better to use more than one page or at least use something like: ?page=contact so its human readable.

Hey missing-score quick question (or whom ever else) is this a bad practice?
- some of the sites I've built have a MySQL back end (so clients can update site info) and I set it up so all pages open with a single file index.php
(IE: index.php?page=contact, index.php?page=about us, or index.php?page=about us&subpage=employees, etc).
- Is it a better practice to create a separate page for each section?

If figure since this delt more with PHP and not really a general site question that it should be posted here rather then the General Web Build Form (if not please move).

04-28-2006, 06:13 PM
Is it a better practice to create a separate page for each section?
Nope, if you read/learn the MVC approach you will realize using one page is best .. having multiple pages leads to redundancy and maintenance issues. some may bring up the issue about not being SEO friendly by sending everything through one page but this is where mod_rewrite comes in and allows for SEO friendly URL's.
the purpose of having one page is to have it act as a 'switch board' to the rest of your site, how this is handles varies. from a simplistic approach you are actually using switch() to a more advanced using a framework that takes advantage of OOP/XML/and so on.

04-28-2006, 07:14 PM
Have a search for 'page controller pattern' for more information, having a single point of entry (for a particular use case, having both browsers/users and web-service requests coming to the same place is probably not sensible or necessary) is generally a good idea, but that script should be looking to pass control to something else as quickly as possible- it shoudn't do anything that isn't necessary.

04-28-2006, 07:44 PM
Yeah, I use the MVC pattern for large applications... But for a portfolio I personally hardly see the point, unless it is a very big portfolio.

What I was getting at though, was the resulting URL. Whether he uses one page or many pages, using:


Where x is a number, just doesn't seem appropriate to me for a small site where the content is clearly separated and the creator knows whats going to be on each page.

For example, within a forum or a blog, you will often find entries referenced by their ID's... why? Becuase the person who puts the forum online does not know exactly what will be posted and how many times etc. You can get systems for vB that clean up URL's to make them more friendly (eg: this would become something along the lines of:)


However when you have a low number of pages, and you know exactly what each page contains, I feel:

It is a waste of time to implement an MVC pattern unless you want to for the learning experience It is bad to use page Ids which is probably not helping search rankings or anyone looking at the URL There is nothing wrong with using some good old static XHTML to build the pages

Basically what I was trying to get at was that the result isn't good in any terms... Although I dont see anything wrong with using some static HTML or multiple pages for a something small like this, even those that think MVC should be used for everything should be able to see that this is a bad implementation.