Hiya all,

I've been thinking about how I'm going to structure my website and am trying to decide the best method for doing so. In this I figured I'd see if anyone here has any suggestions.

More specifically, 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. I'm avoiding frames and iframes for seemingly obvious reasons.

Thanks

I have two comments/suggestions:

1. I've used both the methods you mentioned above, and I strongly prefer the first one. The URLs aren't nearly as messy, it's slightly more secure (because you don't give your users any clue as to how your website is structured), and it's more robust because if content on one page requires that the navigation, header, etc. work slightly differently, you can make those changes on just the one page rather than hack up your code to accomodate both situations.

Also, I found that passing those files around in URLs gets to be cumbersome once the site grows in complexity and you have a large folder structure. You end up having to write a fair amount of code to find out which directory you're in, adjust the links on the page accordingly, etc. It was a big pain.

2. On a related but different topic, I've really benefited from writing several generic class files that have formed the code base of every website I've done. Whatever you do, make as much as you can generic so you can use it again in the next site you do. PHP's classes aren't winning any beauty contests, but they really are pretty powerful.

I wrote a dbObject class that, kind of like phpmyadmin, automates inserting, editing, validating, and viewing mysql database information. I have other classes for each kind of information I store in the db (numbers, texts, filenames, categories, enumerations, etc.), so each field knows how it should be displayed, edited, validated, etc. Then I wrote a dbObjectCollection class that handles many-to-many and many-to-one relationships. Since most of my sites are heavily data-centric and my clients really value being able to edit all the content themselves, these classes have become invaluable in cranking out seemingly complex sites in a small amount of time.

Good luck,
-SNa

Thanks for the suggestions. I was leaning towards the first one I suggested, primarily because of the problems you mention. I already started having problems because of relative vs absolute paths using the second method. It was aggravated even more because my site isn't in the root of the site. Because of this I had to try to figure out where I was in the tree (not so simple it seems) then fix all the paths to other pages and images.

Good idea with the classes too. My plan right now is to use an XML-based database (a *very* small database) for a few things. Doing up some editing classes for that certainly wouldn't hurt.

Thanks.

Or, depending on the structure of your site a combination of the two approaches might be a viable option.

For instance if you have an FAQ section that will have different headers/footers from other pages in your site, you could have an index FAQ page at yoursite.com/faq/. That page then could utilize a switch to show the default (no value) or various pages depending on the particular FAQ page to be displayed.

I like this approach as it makes it easier to have file names that don't have to be big in order to know what they are for. Taking the FAQ example you could have your FAQ folder with index.php, sales.php, service.php, etc. instead of faqsales.php, faqservice.php, etc. Of course for other sections, the names would ahve to be much longer to be fully descriptive.

Good suggestion Michael.

Thanks.