Not that i'm planning to do it right now, but I love Fuel and use it for a good part of my work, so here is a question which crossed my mind :
If I want to developp a web-app which can be use for any number of clients, and I don't want to bother me with dupplicate project for each new installation, I need to have the possibility to keep one fuel dir, with one assets dir in public dir, the only things which are going to change between differents installations are :
- The database access (differents databases, of course config would be stored in db) but with fuel db system (dev, test, prod), I dont see how to do that
- Session of course (I like to use redis, so differents redis db in config)
- A dir which contain uploads (pictures, files...) for each install and which is private (you can't access it from url with another app)
I thought about this for a moment but I question myself if you really can put this together with Fuel design. Thanks for your answer.
An entire list of questions, I'll try to answer them all... ;-)
- One Fuel dir.
Not a problem, we only use one Fuel dir for every server, simply change the COREPATH in the index.php and oil files. And if you use phpunit you'll have to check if that still works after the changes.
- One public dir
Not a problem, you can move the public folder inside your app folder if you want to keep it together. That may main you need to check the other paths in index.php too, as they are relative to the DOCROOT (and that changes when you move the public folder).
- Database access for client
You can do this either via different entries in your db.php, and use some logic to set the 'active' database depending on something external you can identify your clients by (for example hostname). A more structural solution is to use a different environment for every client, and set this using the FUEL_ENV variable in the virtualhost for that client (check the docs).
- Seperate sessions
This is config, so if you use client specific environments, you have a seperate session config too.
- Upload dir
You can create that where you want, that isn't really Fuel dependent. If you choose a location outside the document root, you obviously need a controller method in your application to access them if needed.
In all, not really very complex, our application setup is a lot more complex. We have multiple app folders per application, shared and dedicated modules and packages, lots of composer dependencies, and themes that are installed as composer packages too... ;-)
You answered almost all the questions. Just that when I say one fuel dir, I think at the whole fuel dir (app, core, packages, vendor) which is not planned to be different given that it's the same app. So the idea to put the client-specific dir in app wouldn't work. Beside, if this dir could be the virtualhost root for each app it would be great, but this imply that the assets dir containing all front-end files is not located in the root dir of each app. Maybe this can be solved with a sym link, would it work ? I was thinking at the kind of structure :
- fuel
- app
- core
- packages
- vendor
- assets
- (css, js, fonts and img files)
- app1 (first app virtualhost's root dir)
- .htaccess
- index.php (fuel index.php)
- app specific content (upload dir...)
- assets (which would be a symlink to ../assets)
- app2 (second app virtualhost's root dir)
- .htaccess
- index.php (fuel index.php)
- app specific content (upload dir...)
- assets (which would be a symlink to ../assets)
Also, with differents FUEL_ENV var and this structure, the migrations wouldn't be a problem as they are env specific, right ?
I understood that is was the same app for different clients, and only the config for these clients is different. With a setup like you propose, it might be a bit more complex, since environments are inside your config folder.
Perhaps a different approach, that would also allow you do have version control per client: create a package for each client. Use ./fuel/packages for your standard fuel packages, and add a second package folder in your config pointing to (for example ./fuel/clients.
In there you could have a folder per client, containing: - fuel | - clients | | - clientA | | | - config | | | | - db.php | | | | ... | | | - public | | | | - index.php | | | | - .htaccess | | | | - assets
Then all you have to do, except for making sure the paths in index.php are correct, is add
Package::load('clientA')
to it, before the request gets processed. Then no different environments are needed,. config and lang files in the package gets merged with the ones in app, and you're in business.
The entire "clientA" folder can be a separate git repository so you can manage them easily, a new client is quicky setup by copying a repo and cloning it into the correct position.
Come to think of it., you would have a bit of a challenge with migrations in this scenario, so you might have to combine this with different environments too, so you get:
I understand, it's cleaner as you have one different dir for all but your solution seem a bit complex to me : I don't master the full implication and possibilities of packages for such a system. Beside, there is no necessity to handle each app folder with a git repo, as there is really few files in it. Don't you thinks that the structure i posted with an installation script which take db infos and generate
- an env folder in config
- and the docroot folder with the index.php and assets symlink
Donate
