15

I am taking over an existing PHP project. I noticed that the previous developer uses a one index.php page for the entire site, currently 10+ pages. This is the second project that I have seen done like this. I don't see the advantage with this approach. In fact it seems like it over complicates everything because now you can't just add a new page to the site and link to it. You also have to make sure you update the main index page with a if clause to check for that page type and then load the page. It seems if they are just trying to reuse a template it would be easier to just use includes for the header and footer and then create each new page with those files referenced.

Can someone explain why this approach would be used? Is this some form of an MVC pattern that I am not familiar with? PHP is a second language so I am not as familiar with best practices.

I have tried doing some searches in Google for "single index page with php" and things like that but I can not find any good articles explaining why this approach is being used. I really want to kick this old stuff to the curb and not continue down that path but I want to have some sound reasoning before making the suggestion.

spinon
  • 10,760
  • 5
  • 41
  • 59
  • Similar to http://stackoverflow.com/questions/604046/having-a-single-entry-point-to-a-website-bad-good-non-issue – zerkms Nov 03 '10 at 04:22
  • @zerkms Thanks for the point to the similar article. I was having the hardest time finding anything like I was looking for. I will take a look at it. – spinon Nov 03 '10 at 04:27
  • 'php front controller' would probably bring more results. Seo-friendly links is the main reason in my opinion – Your Common Sense Nov 03 '10 at 06:10
  • @Col Yeah see I can understand that. The implementation that I am using though has just raw urls so every page is index.php?Module=&params= etc... So that just doesn't make sense to me. But if you were hiding that behind pretty urls then sure. – spinon Nov 03 '10 at 06:38

6 Answers6

19

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.

kijin
  • 8,702
  • 2
  • 26
  • 32
  • Thanks for the in depth answer. I can see some value in this and I think it's probably just more of the implementation that was done here that is bugging me. – spinon Nov 03 '10 at 05:26
1

Having a single index.php file in the public directory can also protect against in the case of the php interpreter going down. A lot of frameworks use the index.php file to include the bootstrap file outside of the doc root. If this happens, the user will be able to see your sourcecode of this single file instead of the entire codebase.

Mike B
  • 31,886
  • 13
  • 87
  • 111
0

Well, if the only thing that changes is the URL, It doesn't seem like it's done for any reason besides aesthetic purposes...

JustcallmeDrago
  • 1,885
  • 1
  • 13
  • 23
  • Not sure I follow. The pages do all change as each one has a php page that is being created. It is just being loaded into the index page so the URL stays the same and just the parameters change. – spinon Nov 03 '10 at 04:30
  • Meaning an "aesthetically pleasing" `mysite.com/?page=about` vs `mysite.com/about.php` – JustcallmeDrago Nov 03 '10 at 04:33
0

As for me - single entry point can help you to have better control of your application: it helps to handle errors easily, route requests, debug application.

zerkms
  • 249,484
  • 69
  • 436
  • 539
  • Why route requests through a single file? Web server will already route requests to the individual pages. Errors generally would be handled by the individual php pages that contain the content. Just not really seeing the big value here. – spinon Nov 03 '10 at 04:32
  • @spinon: it is an important for me at least ;-) That is how I like to develop applications, based on my 7+ years experience ;-) – zerkms Nov 03 '10 at 04:35
  • @spinon: let's suppose during the page generation your database fall down. So you get an exception in the middle of your separated page. Where will you catch this exception? ;-) – zerkms Nov 03 '10 at 04:36
0

A single "index.php" is an easy way to make sure all requests to your application flow through the same gate. This way when you add a second page you don't have to make sure bootstrapping, authentication, authorization, logging, etc are all configured--you get it for free by merit of the framework.

In modern web frameworks this could be using a front controller but it is impossible to tell since a lot of PHP code/developers suffer from NIH syndrome.

Eric Butera
  • 638
  • 4
  • 6
  • but can't you also just put all this into a single include file and then have the same functionality is there. But it is a custom implementation and not a framework. – spinon Nov 03 '10 at 04:35
  • Yes, you could, but if you forget you could be in for big trouble. I don't know the context of your site or anything about that. I am answering based on the experiences I've had in working on various sites. – Eric Butera Nov 03 '10 at 04:41
-1

Typically such approaches are used when the contents of the pages are determined by database contents. Thus all the work would get done in a single file. This is seen often in CMS systems.

Philip
  • 3,689
  • 3
  • 24
  • 35
  • Yes I could see that. But these all have separate content pages that are loaded with an if clause in the index page. Just can't see the value in having one page redirect all requests. I mean so it reuses a template but that can easily be accomplished with an include. – spinon Nov 03 '10 at 04:29