On 5/10/2010 6:39 AM, Alex Major wrote:
Greetings all,

This question basically surrounds how you structure your PHP applications,
whether it changes depending on what you're doing and which you'd favour. I
have a feeling it'll come down to a question of personal taste, but on the
off-chance there's a best practice I'll ask anyways.

 From what I've seen and used, there seem to be three distinct ways of going
about it.

1)      Using a 'core' class which has a request handler in it. All pages in
the site are accessed through that one page, e.g.


This is one that I've personally used most after becoming familiar with a
bulletin board system several years ago. It means that pages are easily
created as all the template/session/database handling is done by the central

2)      Using SE friendly URL's like:


This approach seems to be becoming more common on the sites I frequent,
however by accounts I've read it seems to be more intensive on apache as it
requires a mod-rewrite function.

3)      Using different PHP files for each page:


This would appear to be the least developer friendly option?

Hopefully someone can shed some insight into which is the recommended
approach and why. I've been building bigger and bigger sites so having a
solid foundation is becoming more and more important.

Thanks for any help/feedback, I hope I've been clear.


Here is my take on your 3 options:

1] Basically the approach taken by so-called CMS systems like Joomla. Three major problems. One, everything is in one core and DB; so if there is a major bug, crash, hack, whatever, it is hell to repair. If the site is very active, backups can be a problem trying to recover anything that has changed since the last backup. Also, sometimes bugs and hacks can exist for a relatively long time before they manifest themselves. Finding when such first occurred and then backing up from there can be damn near impossible. Two, any changes to the core can have unforeseen consequences somewhere in the site. Three, if the core breaks the whole site is down.

2] I use essentially this approach. But, don't use mod_rewrite. It is an unnecessary complication. Remember in the PHP world the initial php page "owns" the session. So, the current working dir is where the php file is. I like the fact that all pages are called by a URL name e.g.; www.foo.com/bar/filex.php and I save the pages data in a sub directory or DB just for it. e.g., www.foo.com/bar/data/dataFile.db. All of my application types e.g., simple html pages, sign up registries, etc. each have their own config and functions file, etc. in a separate dir/ Each page can have a custom css, images, etc. in it's dir and for special situations, I can write a php that performs some special functions and then calls the common application script. If the page becomes obsolete, I simply delete the dir and subdir. When I update a application type core code, e.g., Signups, I don't need to worry about affecting regular html page types.

Here is one of my typical "calling files
require_once $_SERVER['DOCUMENT_ROOT'] . '/editPageSR/editPageSR.php'; //do not 

Can't get any simpler.

3} Unless the site is small and has few pages and applications, it is almost impossible to maintain.

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to