Pros and cons of using one file for entire webpage?

Question

I'm not sure how I should express this, but I'll give it a try.
I recently started coding my portfolio in object-oriented PHP and I'm wondering if it's according to best practices to use a single page where the content changes depending on SQL data and the $_GET variable?

If so/not, why?

Edit: Take a look at my next post, more in-depth details.

Answer 1

• Not scalable
• Hard to manage code
• Parser has to parse everything
• Perfect example of Code Smell
• One error crashes your whole site

Answer 2

Everything gatekiller mentioned + you also can't utilize late-binding.

Answer 3

• Hard to manage code

If you are using version control it will be a LOT harder to roll back any changes that might have happened to a single "page" of your site. Since you would have to merge back in for anything that might have come after

Answer 4

It's not as search engine friendly unless you use mod rewrite

Answer 5

If you mean a single landing page (e.g. index.php) which then uses session variables etc. to figure out what code needs to be included, then yes, this is an often used technique.

Edit: and by the above I mean what Daniel Papasian explains in detail in his excellent post

If you mean placing all of your HTML, SQL and PHP in a single file, then no, for the reasons pointed out by GateKiller.

Answer 6

Are you asking about using the front controller pattern, where a single file serves all of your requests? Often this is done with an index.php and mod_rewrite getting all of the requests with the rest of the URL being given to it as a parameter in the query string.

http://www.onlamp.com/pub/a/php/2004/07/08/front_controller.html

I would tend to recommend this pattern be used for applications, because it gives you a single place to handle things like authentication, and often you'll need to integrate things at a tighter level where having new features be classes that are registered with the controller via some mechanism makes a lot of sense.

The concerns about the URLs others have mentioned aren't really accurate, because there is no real relationship between URL structure and file structure, unless you're using ancient techniques of building websites. A good chunk of apache functionality is based on the concept that file/directory structure and URL structure are distinct concepts (alias module, rewrite module, content negotiation, so on and so forth)

Answer 7

I tend to disagree with most - if your site is managed by a custom CMS or something similar, there's no reason not to use one page.

I did a similar thing with a CMS I wrote a while back. All clients had a single default.asp page that queried the database for theme, content, attachments, and member permissions. To make a change, I just made the change once, and copied it to my other clients if the change required it.

This of course wouldn't work in most scenarios. If you have a website that does a lot of DIFFERENT things (my cms just repeated certain functions while loading the page), then multiple pages really is the only way to go.

Answer 8

The actaul page file should contain only what is diffrent about that page from a standard "page" on your site(eg the page title, the index page may have code to get the latest news, etc). Everythin which is (or may) be used in more than one place, should be moved to external php files, and included. Examples are:

• Database infomation (password, username, etc)
• Header/Footer
• Login code

This makes the code much easyer to manage. Eg if you change the database password, its only one file that needs updating, or if you decided to add a banner to the header, its again only one page not all the pages that need changing.

It also makes adding new features much less work, eg a new page may simply be:

<?php
require ('config.php')
require ('start.php')
require ('header.php')
//custom page stuff
require ('footer.php')
?>

or adding auto login via cookies, is a simple change to the Login() function (creating a cookie), and start.php (checking for the cookie + calling Login()).

Also you can easyily transfer these files to other projects in the future.

Answer 9

For those of you who are interested, there is a framework that uses this exact model. Originally for ColdFusion. There is still a community for this methodology, version 5.5 was released about a year ago (Dec 2007).

FuseBox Framework site

Wikipedia entry

Answer 10

I often use a php file without the .php extension (ie site) and add

<Files site>
ForceType application/x-httpd-php 
</Files>

to the .htaccess which makes apache interprete the file as a php file.

You can parse vars to the file within the url: http://www.yourdomain.com/site/var1/var2/var3

Use

$var_array = explode("/",$_SERVER['REQUEST_URI']); 
$var1 = $var_array[1];
$var2 = $var_array[2];
$var3 = $var_array[3];

to get the vars. This way you can use a single file with searchengingfriendlyurls without modrewrite.

Answer 11

re: URL and file structure

I converted a site where all the content was in a database and accessed with the index?p=434 model. There was no benefit to using the database, and the site was confusing to the people who had to add content since they had to edit content with the browser and pages were just numbers.

I pulled all the content out and put it in separate files. Each had a sensible name and was organized into folders. Each file looked something like this:

require('sitelib');
do_header('about', 'About Us');
// content here
do_footer();

The client loved it. They were able to use any HTML editor to go in, find the right file and make the change. And they were able to make new pages. All to say: Sometimes, it is useful to have the URL and file structures match.