Self service for Site Factory and Content Hub

Maintenance of multisite platforms on Acquia Site Factory (ASF) and Content Hub (ACH) generally requires developers.

This article describes our solution to remove the dependency of developers:

1. Within the application:
   1. ASF and ACH are not integrated out of the box and require developers to connect sites, manage configuration, deploy updates, and perform common maintenance tasks.
   2. We model the client's org structure with a taxonomy hierarchy in 1 place and API integrate it with ASF and ACH to create ASF sites, structure them in ASF groups, connect ACH subscribers, and syndicate content to the right places.
   3. We're using no code Acquia CMS and Site Studio, allowing the client to configure the changes they need within Drupal.
2. Around the application:
   1. We've extended Acquia Code Studio and ASF hooks with a workflow that does not require a local environment or understanding of the codebase.
   2. Client is able to manage configuration for all sites in 1 place, export it in Code Studio, update Drupal core and contrib code, and deploy to their ASF sites using Acquia managed UIs and without touching code.
   3. Client can also run drush and common maintenance tasks against any or all sites in bulk using pre-configured scheduled jobs in Code Studio.

Within the application (APIs and stuff)

Taxonomy organization structure

We use an organization taxonomy to model their org structure:

1. Terms at the bottom of the hierarchy are ASF sites and ACH subscribers.

2. Every organization above these child terms in the hierarchy live on the publisher site.

    

 

Acquia Site Factory (ASF) API integration

When organization terms are saved:

1. Create ASF groups for levels 1 - 4 of organization taxonomy structure.
   1. These organizations live on the main site and are not themselves sites.
2. Create ASF sites in the right ASF groups for level 5.
3. When new site is created with ASF API:
   1. Clean install on minimal install profile.
   2. Config import.
   3. Site Studio package import.
   4. Connect site and UID 1 to Acquia DAM.
   5. Connect to ACH through API and subscribe to the right filters.

Acquia Content Hub (ACH) API integration

When organization terms are saved:

1. Create ACH client and webhook per ASF site.
2. Create ACH filter per organization and attach to the right sites.
   1. Subscriber sites are at the bottom of the hierarchy and subscribe to ACH filters for all parent organizations.
   2. So tagging content with an organization or any of its parents in the org structure will syndicate it to the right site(s).
3. So from client perspective:
   1. They just model their organization taxonomy.
   2. Tag content with the right organizations.
   3. Content is syndicated to the right places.

Content model and organization references

All syndicated content entities have 5 fields used to determine syndication behaviors:

Field name	Field type	Purpose
Site access and syndication	Taxonomy reference	Prevents content from showing in the wrong places after it syndicates to sites.
Organization	Taxonomy reference	Determines which sites content syndicates to.
Promotion Type	Taxonomy reference	Determines which pages and where on them content shows. These values are used as views filters.
Content Source	Taxonomy reference	Tracks the origin of all content entities, including from ACH but also Feeds and other API integrations.
Prevent API Updates	Boolean	Allows client to bulk push changes to sites that prevents content from receiving further updates from ACH. This can also be toggled from subscriber sites.

Image

 

ACH often syndicates content to sites unexpectedly as a dependency or a recursive dependency of content that is expected to syndicate. In our case, 50%+ of syndicated content shouldn't show on the site.

We use a "Site access and syndication field" to ensure content shows when expected. Options:

Option	Description	Behaviors
Publisher only	Content can only be accessed on publisher site.	Unpublishes on subscriber sites. Hides from sitemap on subscriber sites. Hides from search on subscriber sites.
Subscriber sites only	Content can only be accessed on subscriber sites.	Unpublishes on publisher site. Hides from sitemap on publisher site. Hides from search on publisher site.
Link to publisher	Content is shown on all sites, but subscriber sites link to the publisher site for detail pages so the content does not exist in 160+ sites.	Does not unpublish anywhere. On subscriber sites, uses absolute link to publisher site. So content exists in 1 site instead of 160+. Sets meta tags to noindex and nofollow on subscriber sites.

Acquia CMS, Site Studio, and no code

Acquia CMS is a managed set of open source Drupal modules and Acquia products that provides the best available out of the box platform for no code applications.

No code means that solutions are configured in the UI instead of coded. This allows non-developers to do many of the tasks that historically required developers to custom code. And it opens doors for new products and automation.

Our implementation extends Acquia CMS with additional no code automation projects like eca, or a configurable framework of events, conditions, and actions. It covers the rest of no code.

No code is the keystone to supporting a multisite platform without developers. It allows the client to configure the changes they need in Drupal and use the rest of the solution documented here to deploy their configuration to sites.

In 9 months, our client has been able to learn the field of no code and Acquia CMS without any prior experience in Drupal:

1. New entity types, bundles, and fields.
2. Components, templates, and all UX through Site Studio.
3. Lists of entities using views.
4. Advanced search and faceting on Solr and Acquia Search.
5. API integrations through feeds and tamper.
6. Access control.
7. Any custom business logic using eca.

Around the application

Workflow summary

The client is able to manage their workflows without getting in to code:

1. We gave them a solution to prepare all config on their publisher site by treating it like any subscriber site.
2. Code Studio exports config from publisher site to merge request.
   1. Code Studio jobs also run any set of drush tasks against any or all sites.
   2. And runs composer updates to Drupal core and contrib stuff.
3. Merge changes and cut release tag.
4. Deploy release tag to ASF environment.
5. For each site, ASF hooks run:
   1. Config import.
   2. Site Studio package sync.
   3. Module database updates.
   4. Other required updates.
   5. Drupal and Varnish cache clear.

Config mangement

Managing and merging configuration across sites is a common challenge in ASF or any multisite platform. You can prepare and export your configuration from 1 site, but some configuration is dependent on specific sites and needs to be prepared on those sites.

Our solution was to allow any user to access the publisher site while mocking any other site using an organization reference field on the user entity. This allows them to prepare and export configuration for all sites in 1 place, removing issues around merging configuration across sites.

Image

 

Code Studio jobs

Code Studio is Acquia managed GitLab and tailored for Drupal. GitLab is both a code management service and a CI/CD automation service. CI/CD involves machines that boot on certain events and run any set of tasks you tell them to do.

Image

 

Typically, CI/CD machines deploy code to cloud environments or run tests. But in our case, we've extended Code Studio with pre-configured jobs to let the client run common tasks against their 160+ sites. They don't need to fully understand Drupal infrastructure to click a button to clear caches on all their sites.

Image

 

Drush and acsf-tools

Drush is a command line application used to control Drupal and is the most common maintenance tool for developers. Common maintenance tasks with Drush:

1. Clear all caches.
2. Rebuild Solr index.
3. Regenerate sitemap.
4. Resave a bunch of entities.

We've extended Code Studio to support running any drush tasks against any or all sites. Drush does require some technical context, but we've pre-configured common examples and pointed the client to documentation for all command options.

We also use the acquia/acsf-tools project to run drush commands with configurable concurrency against all 160 sites. By default, commands are run against 8 sites at a time. We configure these jobs in .gitlab-ci.yml with environment variables passed from the Code Studio scheduled jobs configuration.

Image

 

Composer updates to Drupal core and contrib

Code Studio provides a scheduled job that automates composer update and creates a merge request to your default branch with the outcome. We've removed all patches possible to reduce likelihood of future composer issues, but this could break at some point.

Image

 

Config export from publisher

Similar to the composer update scheduled job, we created a job configuration that syncs the publisher site in to the Code Studio build and exports configuration to a merge request. Client can simply merge it, create a tag, and deploy the tag to ASF to update their sites.

Image

 

Summary

There are many components to making Acquia Site Factory (ASF) and Content Hub (ACH) a solution that doesn't require developer support:

1. Acquia CMS, Site Studio, and no code open source allows the client to configure in Drupal what historically required developers to custom code.
   1. Components, templates, and UX through Acquia Site Studio.
   2. Grids, accordions, and entity lists through views.
   3. Advanced search and facets through Acquia Search.
   4. API integrations through feeds and tamper.
   5. Any custom business logic through eca.
2. Client is able to deploy their configuration and Drupal updates to sites using Acquia managed UIs:
   1. In Code Studio, export configuration from publisher site and run composer update for open source code.
   2. Merge the generated merge request, cut tag, and deploy tag to an ASF environment.
   3. For each site, ASF imports configuration, runs module updates, and other required updates.
   4. No local environment or understanding of codebase is required.
3. ASF and ACH are API integrated through a central taxonomy structure in Drupal.
   1. ASF sites and groups are created based on the taxonomy hierarchy.
   2. ACH clients, webhooks, and filters are created and attached to the right sites.
   3. From client perspective, they just model their taxonomy structure and tag content with organizations to syndicate to the right places.
   4. This also limits the amount they need to learn about the products and focuses their learning on no code configuration.