1

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:

Client A:

  • site 1, clienta.ourdomain.com/someslug
  • site 2, clienta.ourdomain.com/anotherslug

Client B:

  • site 1, clientb.ourdomain.com/customslug
  • site 2, clientb.ourdomain.com/orangeslug
  • site 3, clientb.ourdomain.com/frenchslug

Client C:

  • site 1, clientc.ourdomain.com/potatoes

...etc

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.

Improve this question
4
  • Appreciate the red pen to my English @Brad, it had been a long day...
    – Wallace
    Commented Oct 12, 2020 at 20:23
  • Just trying to satisfy my OCD. :)
    – Brad Bell ♦
    Commented Oct 12, 2020 at 22:37
  • I'm not ruling out using project-config for this, I'd rather not go down the road of maintaining future updates through migrations. I am instead considering <editing> project-config between dev and staging deployments, but the question is whether that's done directly to the YAML config files before sync, or by using the project-config Service
    – Wallace
    Commented Oct 28, 2020 at 9:12
  • @Wallace found your post, because I have nearly the same question. How did you eventually solve your problem? Any hints and information very appreciated. Thanks!
    – Henrik
    Commented Nov 16, 2023 at 9:07

1 Answer 1

Reset to default
1

Craft's Project config is really made for updating changes from staging to production.

When it comes to making changes across a fleet of (different) sites, you're somewhat on your own there. You might think of all of your sites as the same but Craft is thinking of each site independently because that's how it's designed.

It sounds to me that one way to handle this might be to try to automate migrations between installs? You change one site, test it, and then move the migration to the next client site/grouping.

After all, if you're changing or adding fields, for example, you're most likely going to be changing the (GraphQL) code that also queries those fields as well or everything is going to fall down pretty quick.

Something like Migration Assistant could useful here?

Also, I'm not sure how your devops is setup but theoretically you could share code between installs (same templates, plugins, etc.) The vendor, migrations, templates, and other code directories could be symlinked in from a central spot so when they get updated, the rest of the sites get updated as well. Once the build process is complete you could fire off a craft migrate/up command line that propagates across each install to make sure everything updates.

Improve this answer
1
  • Thanks for your input, it's welcome. As far as similarity between each site goes - from a fields, sections, entry types perspective - they're all identical. The only real difference is the content, users and number/naming of sites so the GraphQL queries made by the front end can be the same across installations. Since they're otherwise tightly coupled, it's one BitBucket repo containing ReactJS front end and the Craft back end.
    – Wallace
    Commented Oct 12, 2020 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.