Below is a schema that represents all the logical links between helPHP (the main repository), and its instances (the default instance in this case).

The main repo, is not supposed to undergo any changes (except updates or add-ons), when you create a new project, you install a new instance that will connect to the main and load what it needs via the autoload. 

If you have several instances and one of them has to undergo modifications, you doesn't have to touch anything in the main, it is in the instance itself, through the extendings, that we will support our particular modifications.

As explained previously, everything is done to save server resources with the help of OPcache, both at the memory and processor level, and to do so, some libraries that are dedicated to a "data object" are used in the form of global objects that are shared during the execution of the program, from class to module, such as the $DB object that is created by the DB.php library and is made available to all components of helpPHP through libs/init.php.

It should be remembered that the main is divided mainly into libraries (helphp/libs) and modules (helphp/modules).
Libraries provide basic methods and some of the global objects, all exploited by the modules (whose principles will be detailed later).

To understand this schema, you first need to know the path of the various possible requests, remember that only the instance is exposed to the public by the HTTP server:

- An http query will (most often) be processed by the instance index.php (in orange at the top right of the schema) .
- the index.php will first load the config/main.php file to know the server location of the hand.
- It then loads the autoload...
- then the first library: init.php that will create all the useful global objects...
- then instigate the necessary class(s) ...

A classic example: For a website or webapp, the index.php that is at the root of the instance will call the "core" module, which is responsible for organizing the various modules that are needed in the form of a "disposition". (see how the core admin module works).
All modules without exceptions are all from the HelPHP_module library, and therefore all have the same basic methods in common.

Thanks to the init, they all have access to global objects, and as they are all called by the "core" module can exchange various information during their execution to know:

Each module can also use other modules or libraries via namespaces, and various inclusion methods.
All written in simple PHP! Since it has evolved enormously, helpPHP supports it to speed up development by offering prefabricated elements, but does not replace existing functions in PHP.

As far as Javascript is concerned, it has evolved a lot too, but some libraries do not hurt to save time, this one being in the helphp/js folder are therefore not supposed to be served publicly.
In fact they are, either copied in the proceeding, or a symbolic link is established to load them in the public-side proceeding.

Each PHP module may require specificity at the JS level, and therefore may have a javascript file that will be automatically instilled in the instance when the module is called.
There is other manner to request helPHP (Rest API, ssh etc...), but we'll speak about them later.

All this does not look like a known project standard, and it is quite normal, let us mention in the next chapter the delicate question of standards...