Reputation: 15091
I have an interesting problem that the community might want to bask in and help out. I have a custom forum software. Call it A. Now, I intended to roll out different versions of it, call them B and C. But the caveats are the following.
a) They must remain in sync. A, B and C will naturally be separate repositories.
b) The code is same, but the target market is different. Say gaming and food.
c) My idea is to use 3 different config files, and use environment variables on Laravel Forge.
I am sure someone has a better solution to this. I don't know how this will pan out on localhost and production. I need to hear stories of people who have had experiences before, and what is the recommended way to do it.
To put into perspective my situation, I am trying to create 3 config files in a folder /config/multi-site and naming them a.php, b.php, c.php. Beyond that, I feel dumb, because I don't know how to boot these config files when a specific version of the forum is running. Also, how do I sync repo B and C with A using Github?
Upvotes: 2
Views: 173
Reputation: 1133
I suppose there's no real "perfect" answer, it depends on what you want and where you want to deal with the problems.
If you are using separate repositories, make sure that the databases and the migrations AND some of the content (e.g. specific variables / values that should be available for all the sites) are also synced. That's one point that gave me headaches.
You would set the environment stuff in files in
app/config/
and then through environment detection pick the right one depending on your site? http://laravel.com/docs/4.2/configuration#environment-configuration:
If you need more flexible environment detection, you may pass a Closure to the detectEnvironment method, allowing you to implement environment detection however you wish:
$env = $app->detectEnvironment(function() { return $_SERVER['MY_LARAVEL_ENV']; });
And then based on that you can call the appropriate config file.
Either for each website a different set of files in one repo (local, staging, live) or perhaps all the files in one repo (site1-local, site1-staging, site1-live, site2-local...)
Haven't tested this out yet, though.
Another option would be (which is what I did in the end) to use the same codebase and have one database and then based on the domain visited, the specific data would be shown. So in many database tables you would have to have "site_id" as a column. And when you search for users instead of
User::where('name', 'Jeffrey')->get();
it would be something like
User::where('site_id', Site::GetThisId())->where('name', 'Jeffrey')->get();
Where GetThisId() checks for the environment / domain and returns the correct id.
You can definitely still make it even more efficient and the code less error-prone (e.g. overwrite the User::get() with User::where('site_id', Site::thisId())->get() or so).
This way has worked well for me, since I only have one codebase and one database and one server and I don't need to make sure all the codebases and databases are synced. Perhaps some might see as not so elegant, but it has helped to create new sites fast.
So the actual question is where you want to "separate" the sites. Do you want them on separate repos / servers and everyone has the same set of configs but different content? Or one repo but different configuration file sets for each site? Or everything the same but using id to separate the data on a database level.
Does this help with your question?
Upvotes: 1