[ad_1]
[ad_2]
We want to slowly roll out 10+ websites into different servers which all will share same plugins, but have different themes. If possible we would like to avoid having to manage 10+ different github repos.
Would this workflow be valid?
- One Git Repo with wp-content folder with all the plugins and 10+ different themes (one for each site).
- Deploy this repo into all the 10+ servers, each one uses an external database (RDS) and also stores files externally (S3 Bucket).
- In each server we configure which theme I want to use and configure the plugins as needed.
- If we need to make a change to plugins, or theme files, we do it in development and then push the changes to update the wp-content folders of the servers automatically.
My goal is to make the servers themselves stateless, meaning that they could be deleted and recreated at any time without losing any data since all the information is stored in the database, in s3 storage or in the git repo.
I've done this with other stacks before but is my first time using WordPress so im not sure if there is something im missing.
Thanks!
As much as it sucks, I think a different repo for each site is going to be the way to go in the long run.
if the plugins are all off the shelf or otherwise not custom, and you’re not trying to keep DB’s or uploads synced via Git, your approach should work. but the themes can’t be shared at all unless the sites are basically meant to be identical.
This is like… Reverse dependency management. Instead of separating dependencies out, so that they are easier to version and reuse, you will be combining them together, so that any dependency change hard impacts everything. My expectation of this going well would be… Low.
You don’t even want deps in the repo at all, much less hard shared for a dozen of sites.
Had you looked at Composer? Just roll it as Composer-driven projects. Plugins as plugin dependencies, theme as one, actually self-contained projects that won’t all explode together from the first issue.
I’m curious here, why do you want to avoid managing 10 separate repos?
I can’t think of a reason as to why it would become a problem, of course, other than the initial time outlay of creating the repos and pushing the initial code.
Do you also do the site administration, or do your customers have admin accounts that might allow them to switch themes / add plugins?
Are your themes built in the same way, or are you using a bunch of different off-the-shelf premium themes?
Do any of your sites use any super-novel features or complicated plugins like WooCommerce, page builders, etc?
Any of these things might introduce dependency issues. For example, if I’m using plugins A and B on all sites and themes Y and Z on sites 1 & 2, what happens if an upgrade to plugin A breaks something in theme Z? Do you wait to upgrade site 1 until that’s resolved, or do you upgrade site 1 and wait on site 2 until the theme developers (or your engineers) fix the incompatibility?
Imagine this going to 20 plugins and 10 themes, and there are hundreds of dependency issues that can come up.
Do you have a staging environment where you test whether a random change to a plugin to add a feature for site 1 doesn’t break sites 2-9?
There are also risks that expose yourself to by having unused, potentially insecure code deployed in production. If there’s a security problem with theme Q, an attacker would be able to bring down all of your sites, not just the one using theme Q. If
When there are conflicts and problems with dependencies, you could use different branches for each site, so you can keep things at different versions if you need to. You’ll need something really good for managing this, and a very disciplined team of people who know how to do things like git cherry-pick.
I’ve seen the WordPresss monorepo approach go horribly awry due to the things above. Consider whether you’d be impacted or not.