Project structure for PHP

With the invention of Composer, people now have a central place to register their projects for the world to consume, and other people now can look at that code base and see similarities.

The result is this: https://github.com/php-pds/skeleton

In short:

This standard does not make any further recommendations about which directories have to exist below src or public.

The task to organize your PHP source files inside any of these directories is still up to you, but there are suggestions outlined in this article that I'd agree on: Either sort by type (controller, entity, service), or sort by feature (user, login, cart, catalog, article, comment) - the latter keeping all the code that belongs to one feature in on directory (or few sub directories), which often seems to be the better file organisation.

When organizing by type, you'll find yourself jumping between directories quite often, and also you do not get a good overview about what the code is about - you'd always have "Controller", but you rarely have "StampCollection".

Nope. PHP is what you make of it. It can be very simple flat files, or however you want it.

That being said, there are a few agreed upon coding standards, but there is no "enforcement" of said standards. They are called PSR (PHP Standards Recommendation). There is a background on it here: http://net.tutsplus.com/tutorials/php/psr-huh/
You can view the standards one by one here: http://www.php-fig.org/psr/

Most major frameworks follow these standards, and if you are going to use one, it may be easier to go with the flow.

Again, every framework, project, plugin, program, etc, have different layouts with different project structures. A common structure is something like this:

-framework_dir
-public_html
    -js
    -img
    -css
    -index.php
    -protected/private
        -controllers
        -models
        -views
        -etc

They then use the .htaccess file to block access to the protected directories. Again, this is just the common representation I have seen in several frameworks. If you are doing a personal project, just use something that is comfortable to you. Every framework is going to give you a different library or way to access the data. There are no "layers", but again every framework has objects that handle different areas (email, database, cache, http, logs, etc). Because there are dozens of popular ones, it is just up to you to find what fits with your philosophy or project. Watch a few of the 5 minute blog videos, see what jives, and then give it a test run for a couple days. If you don't like it, switch to another.

I tend to use a Feature-based folder structure for my backend projects. Every feature-folder has his own controller, manager and routes file. This works well for api-backends. It looks in a way like https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/

For example, we have a Customer feature with a CustomerController, CustomerRepository, CustomerRoutes,..

My folder structure looks like this:

- build/
-- phpdox.xml
-- phpmd.xml
-- phpunit.dist.xml
- config/
- public/
-- .htaccess
-- index.php
-- assets/
- src/
-- Customer/
--- CustomerController.php
--- CustomerRepository.php
--- Customer.php
--- customer.routes.php
- tests/
- vendor/
composer.json
.gitignore