We're developing an application that uses a multi-site Craft back-end with a JS front-end, making use of GraphQL. The intention is to maintain a single codebase that can be used to deploy new and update existing instances of the application.
Each client has their own installation of Craft (currently Craft 3.5), with multiple sites in each. To illustrate:
- site 1, clienta.ourdomain.com/someslug
- site 2, clienta.ourdomain.com/anotherslug
- site 1, clientb.ourdomain.com/customslug
- site 2, clientb.ourdomain.com/orangeslug
- site 3, clientb.ourdomain.com/frenchslug
- site 1, clientc.ourdomain.com/potatoes
The underlying Craft components (i.e. fields, sections, entry types, plugins, etc.) are identical across clients. Initially, I thought that project-config would be all over this until I realised that site data is held in Project Config. With each client having a different number of sites with different slugs etc., that rules out keeping project config in a single git repository.
This, therefore, presents a maintenance and deployment nightmare. As it stands, the only (terrible) option as I see it is:
- Create some kind of baseline config and store a matching SQL dump with it
- Remove project config from the repo
- Manually create migrations for any subsequent modifications.
I had considered forks of the main repo for each Client but again, if there's any project config in those, there's the potential to hose a client's site by modifying site-related data.
The ideal solution would be the ability to configure (!) project config, such that it ignores anything to do with sites. As far as I can see from the generated yaml, sites are only referenced in defining the site itself, and sections' site settings. Configuring the latter programmatically when a site is created is fairly straightforward.
If anyone has any experience of a similar setup, I'd very much appreciate the benefit of their experience.