If you're going to set up a framework for a website (particularly one which hosts a variety of applications), the following is a suggested framework for the directory structure.

First let's look at the context of our creation. I built a suite of applications (a "package"?, a "suite"?) for the internal use of my company. Most important of those components was the "jobs" component. Everything we did was linked to a "job". But within a job, there were customers, inventory, invoices, cash receipts, prices, reports and various administrivia. Each one of those components could be considered an "application", with its own screens for adding, listing, deleting and updating records within that application. Then there were other things that went along with these components but were not part of the jobs "suite", like Accounts Payable, Payroll, Statistics, Mailing Lists (we handled those for customer jobs), Hosting (website hosting, which we also did), etc.

All of these were hosted on an internal server behind our firewall, not advertised on the internet and otherwise cut off from the outside world. So if you wanted to work with invoices, for example, you logged into the internal server and launched the invoices app from a link on all our webpages. Since this was a business run from our home, we did not have a VPN or anything. Just an internal server. Not that it matters, but just as a point of reference.

Now what I'm going to detail is not how we set it up. It was set up years ago. What I'm going to detail is how I would have set it up if I'd had the benefit when I set it up of what I know now.

Second, let's handle terminology so we do not get all confused about what's what. Let's call the whole of this creation a "suite". And then let's call each of what I've called an "application" above an "app". Let's also acknowledge that we are going to be adhering to an MVC ("model", "view" and "controller" framework). I'm going to assume you know how an MVC framework goes together, and what each part is supposed to be doing.

Third, I'm going to make a point which may be unpopular with a lot of people. I don't like, nor will I use "front controllers". If you object too much, I'll refer you to the creator of PHP, Rasmus Lerdorf. He's with me on this one, for what it's worth. If you want to see the arguments, look his blog up. My reasoning is largely the same as his.

Okay, so let's look at the root of all this code. This is a "suite" of "apps", and there will be some things they all share, like our date library, our database library, our security infrastructure, etc. So, on our host, "bullwinkle" (one of the various names for that computer over the years), we have a web directory for the suite called "pss". Why was it called that? Long story. Just trust me. So on the bullwinkle server, there's a web directory called /var/www/pss. This is the "root" of all the other stuff. This directory will contain subdirectories for libraries, include files, configuration, etc. Like this:

/var/www/pss
/config/
/libraries/
/models/
/includes/
/templates/
/views/

The "models" and "views" for PSS might be pretty sparsely populated, since the /pss/ directory would mainly serve as a gateway for the other applications, if that directery was needed for something like that. Probably doubtful, in which case you could omit them.

Now, we have applications we want to add, which will likely have their own similarly named subdirectories. Like this:

/var/www/pss
/cust/   /* customers */
/invc/   /* invoices */
/invt/   /* inventory */
/stats/  /* statistics */
/cash/   /* cash receipts */
/fjobs/  /* future jobs */
/disb/   /* disbursements or Accounts Payable, A/P */
/payr/   /* payroll */
/price/  /* pricing */
/mlists/ /* mailing lists */
/host/   /* web hosting */
/admin/  /* administrivia */

Each of these new "app" directories would hold the "page controllers" for the app, in addition to containing directories for configuration, libraries, includes, models, views, etc. So an individual's application "tree" might look like the following:

/var/www/pss
/cust
/config/
/includes/
/libraries/
/models/
/views/

This would be more or less repeated for each application.

If you don't want to use a "front controller", then you'll have a file called "init.php" (or similar) in each app root directory for things which would be common to all the other files in that directory. For example, if you wanted to turn on the session infrastructure for every page in an app, then high up in the init.php page, you'd issue a call to session_start(). Page controllers would also go in this directory. Like this:

/var/www/pss
/cust/
cust-add.php
cust-del.php
cust-upd.php
cust-list.php
cust-search.php
init.php
index.php -- soft linked to --> cust-search.php

So if you were in the host app and wanted to now use the customer app, you'd probably click on a link like /var/www/pss/cust/index.php, which would make this type of call:

include('./init.php');

You'd have an init.php file in each app's root directory (to define constants and such for that app) and an init.php in the suite's root directory (to define stuff for all apps).

In each app's init.php, insert (at the top) the following:

$app_root = '/var/www/pss/cust/';

And in the main init.php, insert a line like:

$suite_root = '/var/www/pss/';

Now you can use those values to define the absolute locations of all the other files in the main system and your particular app. Make sure your app's init.php file jumps back to include the main init.php. Your init.php files will be the only ones you'll call relatively.

What does the init file do?

These kinds of apps will have entry points like this:

localhost/pss/cust/cust-add.php

or

localhost/pss/cust/index.php

which would be equivalent to (in the cust app's case)

localhost/pss/cust/cust-search.php

This makes the four or five files in this directory page controllers. We go directly to them instead of using a front controller.

That's how I'd do it, and how I will be doing it in the future. You can do it as you like. This is just advice from someone who's been doing this for a long time.