As you'd expect with Drupal, there are several ways to get content into a new site.
You’ve just deployed your latest and greatest feature to your Drupal site, but something's wrong. The content you’ve been testing on your staging site isn't on your production site. Now, things are looking a little barren. So, rather than spend your weekend copying and pasting content from one site to another, what can you do? As it happens, the Drupal community has both asked and answered this very question about Drupal content deployment.
Here, I’ll look at some techniques to help. But, this won’t be a look at deploying features. Because it’s assumed you're already using some kind of workflow using the Drupal configuration system. More, this will be about getting content from one place to another so you can launch your new feature-filled with content.
Modules
A few modules exist that can help you deploy content.
Workspaces
First and foremost is the Workspaces module, which was included in Drupal core version 8.6.0 as an experimental module. This module allows you to create content, menus, taxonomy terms and other entities without them appearing on your live site. Once you are happy that everything is in place then you can hit a button and publish everything at once.
It works by creating one or more spaces where content can be curated before being pushed live. This might be a workspace for an upcoming event, or perhaps the launch of a new feature. Here, all new content can be seen in situ within your site. So you can ensure any content problems are resolved before lunch.
Clicking the “deploy content” button for the Workspace will effectively publish all necessary content at the same time. In fact, this is a big deal if you've ever launched something in Drupal. Because it generally means spending time publishing everything at once, then ensuring you haven’t missed anything.
Ready-to-go content
To add, it's possible to create a Drupal site containing all of the content ready-to-go. More, you can only publish it fully once all of your new features are in place. Granted, you still have to be careful of how you integrate your new features into the site. However, the Workspaces module is a powerful tool in this regard.
Unfortunately, this module is still marked as experimental in Drupal 9. So whilst it’s a wonderful tool I don't recommend using it right now. Unless you're prepared for the API to change. Though, I have heard reports of it being used on production sites. So if you're happy with a couple of edge case bugs the this might be for you for your Drupal content deployment.
Deploy
If you like the sound of using Workspaces, the Deploy module will interest you. Because it worked with the previous version of Workspaces before it became a part of Drupal core.
The Deploy module can be used to deploy one workspace to another. Also, it can be used in conjunction with the RELAXed module to deploy a workspace from one site to another. The RELAXed module creates a RESTful API for all content entries and so can be used to pull content. The Deploy module plugs neatly into the RELAXed module and allows workspaces to be deployed across sites.
Setting up these modules together can be fiddly. Because you need to have Deploy and RELAXed installed and configured correctly on both sites. And that isn’t an easy task. Whilst testing it, I needed to install a couple of patches to get things working properly. Also, the instructions on doing these site-to-site workspace deployments were (and still are) dated.
However, once it’s all in place it works seamlessly. As such, your workspace can easily be deployed from one site to another. If you're already using Workspaces in core, you can’t use the Deploy module. This is because it's incompatible with the Workspaces setup.
Default Content
Moving into the common “content as code", the Default Content module can be used to deploy your features and content. This can be done at the same time by packaging content as bits of configuration. The content is stored as YAML, in the same way the core Drupal configuration is stored.
The process involves setting up a module that you package your default content into. Then, you export content from the site into this module. Following this, you set up the module so when it installs the content is created automatically. Finally, when you deploy your code you can install this module, which will create the default content within the site.
This module is really useful for packaging content. Additionally, for ensuring all of your sites (including local development environments) have the same taxonomy terms.
Furthermore, you can use this module to create test content you only need when running behavioural tests on your continuous integration environment. So this allows you to install and run a copy of your site without needing a copy of the database.
Word of advice
Default content is a powerful module, but it’s a one-shot deal. You install the module containing your default content and that’s it. Job done. Things can get interesting when you update that content. Because you need to build in update hooks to re-import the content. The module is smart enough to figure out what content has already been created so you won’t get duplicate content.
Content Sync
Content Sync works in a similar way to default content. As it allows you to export some (or all) of your content as configuration files. Rather than package your content in a module, you export it into a directory that lives next door to your configuration directory.
The module acts like the existing configuration modules. So anyone familiar with the existing configuration workflows will pick this up quickly. Not only can you import content but you can keep it up-to-date as well, all through a familiar interface.
The Content Sync module can work with all of the content on your site or a few pages. It works with linked entities so things like taxonomy terms and paragraphs are covered. Though, be careful if you're looking to export thousands of pages of content. Because this will probably take a lot of system resources to export and import. There are some features being worked on currently that will help towards splitting content by sub-directory. So if you're interested, get involved in the issue queue for the module.
Entity Share
The Entity Share module uses the built-in Drupal JSON API to create a link between one site and another. Here, the idea is to install a server module on one side and a client module on the other site. Then get that to subscribe to the content feed from the server site. When content is created on the server the client will pick it up and import the content.
This sharing works with all forms of content including content types, taxonomy terms, menu items, indeed anything that can feed through the JSON API system. And because Entity Share is built upon the foundations of JSON API, it has a solid security system with authentication and permissions. As you're exposing a detailed API to the world, ensure your authentication has a user with a complex password and the right permissions to only access necessary content.
This type of content syndication has many uses. More, allowing content to be copied between your staging and production is only one part of this module's use. Also, you can do things like share a menu system between your sites. Or ensure a standard list of taxonomy terms is maintained throughout all your sites.
Prod sites
For content deployment to your production sites, there are a couple of things you might need to be aware of. By default, Entity Share will allow you to push all types of an entity type to your client sites. Meaning, if you're testing your server site all your testing content will automatically feed to the other site. For that reason, it’s best to create a channel using a filter so you can, for example, only deploy items with a particular tag or author. Also, the content is only shared on a cron run on the client site. So if you need to prep your content before sharing, it’s wise to temporarily disable cron whilst you get things ready.
Entity Share is a powerful tool and works well, but don’t expect everything to work seamlessly the first time. The module is currently in beta and is undergoing active development. So there are likely teething problems. Also, be careful about the link between the sites and what content is shared or you'll share more than you intended.
Feeds
A long time fan favourite of the Drupal community is the Feeds module. If your requirements are simple and you want to copy simple pages or taxonomy terms between sites, the Feeds module is a good option.
Set up an RSS feed on your staging site. Then use the Feeds module to pull the content from that feed and create the content on your production site. The Views module is a great way to set up an RSS feed on your staging site. Because you can apply filters or other requirements to it and only expose the desired content.
There are other plugins available for the Feeds module, so you aren’t limited to using RSS. You can install the Feeds extensible parsers module and consume XML or JSON feeds from your staging site.
I've seen the Feeds module used for some impressive things in the past. So there's no reason why you can’t use it for content deployment.
Third-Party Services
As well as installing a module and managing your own content there are a number of services that will manage your content deployment for you. As these are third-party services they have a cost associated. Some also have dedicated content staging features, but all will allow you to copy content from your staging site and deploy it to your production site with minimal fuss.
CMS Content Sync
Using this module, you have the ability to link your site with the CMS Content Sync service. This looks like a pretty comprehensive service that can accept lots of different types of content from your Drupal sites. The product looks like it can deploy content from one site to another within seconds, including updates to that content. There is also a content deployment feature that might be worth looking at if you want to push a section of content live at the same time.
The whole thing is built around Drupal. So you can push content out to different export pools, which allows you to separate the content between sites. They have a free trial so you can try it before taking the plunge.
Entity Pilot
This module is a wrapper around the Entity Pilot service and was built with content staging and deployment in mind. By installing this module on both of your sites you can push from one site into the Entity Pilot service, then pull from that service into another site. That pull operation can be manual or automatic. Either way, you can control when the content is pulled through.
The content you push to Entity Pilot is completely encrypted in transit so you don’t have to worry about your content being viewable before you pull it down onto your live site. The prices of the service look reasonable and they have a free trial.
Acquia Content Hub
I have used Acquia Content Hub extensively and it’s a robust system. The idea is to install the Content Hub module on your Drupal site and this will send content to a central system.
You can select what sort of content gets pushed to Content Hub, even down to individual Paragraph entities within your content. Then, you can push that content onto one or more sites via the Content Hub service.
Content Hub comes with some built-in hooks so you can filter and tweak the content as it is sent to the Content Hub service.
In addition to standard content syndication, you can use Acquia’s Lift tool to create a personalised content experience for your users. This uses analytics to pull in content that might be relevant to your users whilst they are navigating the site. In fact, it goes beyond the scope of content deployment, but I thought I would mention it as an added benefit to the system.
Conclusion
There are a lot of options for Drupal content deployment from one site to another. Some of these techniques can be used for content staging at the start then allow you to use them long-term to deploy content as you like.
Starting from scratch
If you're getting started I recommend Default Content or Content Sync. You won’t need to think about automatically pulling in content, the content import is baked into the modules. Although possible, I wouldn’t recommend using them long-term to deploy content. But they can be useful if you want to get some content live and don’t want to mess around with migrating content.
Longer-term
Longer-term solutions you should look at for Drupal content deployment involve using API interfaces like Entity Share or third-party services. This will help you get your new feature up and running quickly and can be used longer-term to deploy content for your next feature. Or even deploy on a regular basis.
The Workspace module is the next step in enterprise-level content management and will be a valued addition to the Drupal ecosystem. It means that publishing those 15 pages, with menu items and taxonomy terms can be done at the same time, without doing it manually and missing something. Although it’s not quite ready, I can see it being installed as a matter of course on sites in the future so you should have a look if you haven't already.