There is always a direct mapping between a (virtual) hostname (a URL), a public folder (index.php) and an app (defined in index.php).
In all cases, your apps can share the rest: you can have a central fuel/core installation, and change the COREPATH (in index.php, oil and phpunit) to point to it, and you can have central packages and modules by pointing the app config to them.
For packages and modules, multiple paths can be defined, so you can have packages and modules inside the app that are app specific, and a central location for all your apps with generic ones. If you have duplicate names, the first hit wins, allowing you to override central ones in your app.
If I look at our own apps, I see several solutions to this problem.
I see frontend and backend completely separated, using two hostnames and two virtual hosts, using the shared core components as described above.
I see solutions where both hostnames point to the same virtual host, and rewrite rules are used to rewrite them to frontend.php and backend.php (which are copies of index.php, but load a different APPPATH). This is a setup where the app code is also outside the virtualhost, only the "index.php" and all assets are inside the virtualhost docroot.
And I see a solution similar to the last one, but where the rewrite rule rewrites the backend URL to a module, so effectively doing 'backend.domain.org' => 'frontend.domain.org/backend', so only a single app folder structure is used, the backend is completely in a shared and self contained module.
You need integration into the frontend app if you want to do dynamic stuff, for example if the frontend app is modular, and each module comes with an admin extension that needs to be "plugged in" into the backend at runtime (for example using events or HMVC calls).
So it depends a bit on your use-case. Is your backend re-usable or app specific? Do you want to maintain it as a separate app, or does it need to integrate into the frontend?
Donate
