Setting aside all those framework advices, your suggested options have these pros&cons.
single php file
- (+) one central point of execution; you can include common parts of app, security checks, env set up, etc... in one place and for all
- (-) one central point of execution; you have to route traffic in one place. this may clutter up code
- (-) basically one url for everything (sure different query parameters); this may be handicap when crawlers/indexers come to your site
separate main php files
- (+) possibly more urls for crawlers and indexers
- (-) you have to explicitly include common parts in every top level script
But there's another way in between these two, read on.
Maybe there is a reason you don't want to use established framework, maybe you want to learn by exploring. I don't want to judge, it's your choice.
Just you may eat the cake and have it too. Gather pros of both solution and eliminate main cons.
I propose two (and half) solutions, both are based on scenario you are using separate main
.php files with their own public urls, let's say:
And want to implicitly include common parts in all scripts.
First of all, you may exploit rewrites in
whatever-your-httpd-is and direct all traffic to single php file. In that file you can do whatever you want to need to initialize application and than require originally requested script.
$script = $_SERVER['SCRIPT_NAME'];
# add mandatory safety checks
Of course, you can do a lot more in
common.php, e.g. set up DB connection, autoloading, configuration options, handle prettier urls, etc...
Basically, this is what all those frameworks do for you.
If you are able to mangle
.htaccess files, you can set up
auto_prepend_file (http://php.net/auto-prepend-file) directive for your project. And possibly
auto-append-file (http://php.net/auto-append-file) too.
auto_prepend_file = prepend.php
auto_append_file = append.php
php_value auto_prepend_file prepend.php
php_value auto_append_file append.php
This has exactly the same effect as adding
require statements on top and bottom of each top-level executed
.php script (i.e. executable with public url).
This solution has added benefit of php interpreter handling execution of top level scripts, not your router. So if it's not supposed to be run from http request,
.htaccess et al come do effect. You have to handle this by hand when using rewrites/router.
This is last option, but I don't recommend it as it effectively destroys anything other than GET requests. But may be useful if you want to use both pretty urls and directly executable scripts.
Instead of rewrites, you may set up 404 handler instead. If httpd couldn't find public resource (be it static file of
.php file), executes your defined handler instead. If it's an
.php file, it's very similar to
router.php from the rewrite solution. But I don't want to go into detail here. You better have to try and play with it yourself.
One more remark maybe useful to you.
PATH_INFO environment variable (accessible as
$_SERVER['PATH_INFO'] from php). And try to play with urls such as
/article.php/123/pretty-name. You do not have to limit yourself to query parameters (a.k.a. $_GET). A lot of individual urls almost instantly.