Full website pages in just one page!

Question

hi I am working on a great website (social network with php) and I've decided to create only one php page, (index.php), but this php page will contain php if conditions and statments of the $_GET value,and will display the page requered (but in the same page index.php).

This means that the code(javascript+xhtml+php) will be very huge (nearly all the project in one page).

I will also use the Htaccess to rewrite the urls of those pages to avoid any malicious requests (so it will appear just like a normal website).

But, before doing so, I just want to know about the advantages and downsides of this technique, seeing it from all other sides (security, server resources, etc...)

thank you

Answer 1

I think what you're trying to do is organize your code properly and effectively, which I commend.

However if I understand correctly, you're going to put all of your javascript, html, and PHP in one file, which is really bad. You want your code to be modular, not lumped together in a single file.

I think you should look into using a framework (eg Zend) - PHP frameworks are specifically designed to help your code remain organized, modular, and secure. Your intent (organizing your code effectively) is great, but your idea for how to organize your code isn't very good. If you're absolutely adament about not using a framework (for example if this is a learning/school project), you should at least make sure you're following best practices.

Answer 2

Came by this question searching so since the best answer is old, here is more modern one, from this question

Why use a single index.php page for entire site?

A front controller (index.php) ensures that everything that is common to the whole site (e.g. authentication) is always correctly handled, regardless of which page you request. If you have 50 different PHP files scattered all over the place, it's difficult to manage that. And what if you decide to change the order in which the common library files get loaded? If you have just one file, you can change it in one place. If you have 50 different entry points, you need to change all of them.

Someone might say that loading all the common stuff all the time is a waste of resources and you should only load the files that are needed for this particular page. True. But today's PHP frameworks make heavy use of OOP and autoloading, so this "waste" doesn't exist anymore.

A front controller also makes it very easy for you to have pretty URLs in your site, because you are absolutely free to use whatever URL you feel like and send it to whatever controller/method you need. Otherwise you're stuck with every URL ending in .php followed by an ugly list of query strings, and the only way to avoid this is to use even uglier rewrite rules in your .htaccess file. Even WordPress, which has dozens of different entry points (especially in the admin section), forces most common requests to go through index.php so that you can have a flexible permalink format.

Almost all web frameworks in other languages use single points of entry -- or more accurately, a single script is called to bootstrap a process which then communicates with the web server. Django works like that. CherryPy works like that. It's very natural to do it this way in Python. The only widely used language that allows web applications to be written any other way (except when used as an old-style CGI script) is PHP. In PHP, you can give any file a .php extension and it'll be executed by the web server. This is very powerful, and it makes PHP easy to learn. But once you go past a certain level of complexity, the single-point-of-entry approach begins to look a lot more attractive.

Answer 3

This approach is not good because of server resource usage. In order to get access to say jQuery.js your web server is going to:

1. Determine that jQuery.js actually passes through index.php
2. Pass index.php through the php parser
3. Wait for php to generate a response.
4. Serve that response.

Or, you could serve it this:

1. Determine jQuery.js exists in /var/www/mysite/jQuery.js
2. Serve it as the response.

Likewise for anything that's "static" i.e. isn't generated from PHP directly. The bigger the number of ifs in the PHP script, the more tests will need be done to find your file.

You do not need to pass your static content through some form of url routing; only your dynamic content. For real speed, its better to generate responses ready as well, called caching, particularly if the dynamic content is expensive in terms of cpu cycles to generate. Other caching techniques include leaving frequently accessed database data in memory, which is what memcached does.

If you're developing a social network, these things really do matter. Heck, facebook wrote a PHP-to-C++ compiler to save clock cycles.

I second the framework recommendation because it really will make code organisation easier and might integrate with a caching-based solution.

In terms of PHP frameworks, there are many. Here's a list of many web application frameworks in many languages and from the same page, the PHP ones. Take a look and decide which you like best. That's what I did and I ended up learning Python to use Django.

Answer 4

It will be a hell of a mess.

You also wont be able to upgrade parts of the website or work on them without messing with the whole thing.

You will not be able to apply some programming architecture like MVC.

It could theoretically be faster, because you have only one file that needs to be fetched from disk, but only under the assumption that all or at least almost all the code is going to be executed.

So you will have to load and compile the whole file for every single request, also the parts that are not needed. so it will slow you down.

What you however CAN do is have a single point of entry where all requests originate from. That helps controlling a lot and is called a bootstrap file.

But most importantly:

Answer 5

Why would you want that?

From what I know most CMSes (and probably all modern ones) are made so that the requested page is the same index.php, but that file is just a dispatcher to other sections. The code is written properly in different files that are built together with includes.

Edit: If you're afraid your included scripts are vulnerable the solutions is trivial. Put them outside of the web root.

Simplistic example:

<?php

/* This folder shouldn't even be in the site root, 
it should be in a totally different place on the server 
so there is no way someone could request something from it */
$safeRoot = '/path/to/safe/folder/';

include $safeRoot.'all_pages_need_this.php'; // aka The Bootstrap //

switch($_GET['page']){
    case 'home':
        include $safeRoot.'home.module.php';
        break;
   case 'blog':
        include $safeRoot.'blog.module.php';
        break;
   case 'store':
        include $safeRoot.'store.module.php';
        break;
   default:
       include $safeRoot.'404.module.php';
}

Answer 6

What you are referring to is called single point of entry and is something many web applications (most notably the ones built following the MVC pattern) use.

The code of your point of entry file doesn't have to be huge as you can simply include() other files as needed. For example:

<?php 

if ($_GET['module'] == 'messages') {
  include('inbox.php');
} 

if ($_GET['module'] == 'profile') {
  include('profile.php');
} etc..

Answer 7

This means that the code(javascript+xhtml+php) will be very huge (nearly all the project in one page). Yes and it'll be slow.

So you're not going to have any HTML cacheing?
It's all purely in one file, hard to update and slow to interpret? geesh, good luck.