In September 2021 Cumbria County Council launched a new website using the LocalGov Drupal distribution. This was effectively a single-service site, migrating the council’s Births, Deaths, Marriages and Ceremonies service information to a new home at new.cumbria.gov.uk
After a period of assessment and evaluation (largely very favourable) the decision was taken to extend the site to encompass at least one other service, and Highways (Parking, streets and transport) was selected.
The challenge
One of the challenges when building any site is how to make content available to the owners and stakeholders so they can provide feedback and engage with the content and development team during the build. We had two basic options:
- Build the new service on the production environment, employing some method of hiding the entire body of content from public users while making it available to Highways;
- Build on a non-public staging environment, and migrate the content to the production environment on sign-off.
A couple of other factors influenced our approach:
- This would be a one-off migration of the service content – the business-as-usual process of reviewing and updating content would be handled using LocalGov Workflow within the production environment.
- The experience for reviewers should be as live-like as possible, so no login required, and no difference to the ultimate production version when viewing the site.
We considered several Drupal modules including Workspaces, Content Synchronization, and Replication, eventually settling on Entity Share.
It was the best documented option, as well as meeting our needs exactly on paper. I canvassed the LGD #technical-group Slack channel, and proving the power of the LocalGov Drupal network, Mark Conroy at Annertech generously shared his experience of the module, which confirmed our assessment.
Entity Share explained
The Entity Share module works on a simple client/server model. In our case our staging environment where the Highways service content was being built would be the server (or source), with our production environment the client (or destination).
An environment can be both a client and a server, not something we required but a valuable option if you need to synchronise content in both directions.
Server configuration
The server configuration is centered around the concept of channels. A channel is a mapping to a single entity type, for example a content type or taxonomy, and can be further refined by defining filters, searches, sorts, and access control, each of which influence the options at the client when importing content.
For Cumbria this meant one channel per content type, with additional channels for Alert banners, Directory facets, Files, and Media.
Access control is configured per-channel, with options to grant access to users with the module’s Access channels list permission, specific roles, specific users, or any combination of the above.
Client configuration
The two elements to client config are:
Remote websites
A name, URL, and authorisation method for each server the client needs to access.
The ability to define multiple remotes for a client makes it easy to pull in content from more than one source (not a requirement we had in Cumbria).
Import config
This defines a set of rules for importing content from the server including the handling of:
- embedded entities
- content timestamps
- internal content from link fields
- entities that have already been imported
It also allows for the recursive import of entities from entity reference fields.
This is especially useful for LocalGov Drupal Guides and Step-by-steps, where importing a Guide Overview or Step-by-step Overview can also automatically import all of their child Guide and Step-by-step pages.
Pulling entities
This is where the magic finally happens. On the client site, Content > Pull entities prompts you for an import config, a remote site, and a channel:
Select a channel, and a list of entities from the server will be displayed, with links to the remote and local (if it exists) versions, and their status, including a Diff link if the entity exists on both sites but isn’t synchronised:
This makes it easy to assess the differences between remote and local versions of content, and make a decision on how it’s best handled.
For this post I synchronised the Step-by-step Overview entity Apply for a dropped kerb – step by step, marked as a New Entity in the table above.
After synchronisation, the Entity Share log shows that it also automatically imported the four child step-by-step pages which were missing on the client, since the import config had entity reference processing switched on:
The Entity Share module fits our use at Cumbria perfectly, and will save a lot of time and effort as additional services are added to the site.
(As a bonus, I’ve also found it useful for quickly pulling down specific content from remote sites to a local installation for testing and development.)