Install the module as you normally would. Since I am using the module for creating content for recipes, I install it in the dev section of my composer requirements as I do not need it in production.
You can also apply a recipe multiple times, or install and uninstall a module and add that default content again. There are issues in the module’s queue to address some of these situations, but work still needs to be done to improve the processes.
The argument is required.
How did we get here?
Alias:
We keep our recipes in the recommended folder above the webroot.
The Default Content contrib module
mkdir recipes/recipe-name
mkdir recipes/recipe-name/content
touch recipes/recipe-name/recipe.yml
Until the recent interest from the Recipes Initiative team, the Default Content module has always been used for creating default content configuration files for custom modules and install profiles. You could create content on a local site, export it to your module or a module in an install profile, and when that module was enabled (or a site was started from the install profile), and you installed the default content module as a dependency, you would get your content imported. This all still works exactly as it always has, and now it can also be used with recipes.
Options:
Using the Default Content module
I’d love to hear your thoughts and feedback on how you are using Default Content, or how you plan on using it! Please reach out to me in the Drupal Slack or on LinkedIn.
Getting set up
Instead, it can be a great tool in our toolkit for creating demos and test content, while freeing developers and testers from the drudgery of repetitive content creation.
There are plenty of issues in the module’s issue queue to improve the quality and functionality of Default content, and the eleven year old Support default content entities core issue that has recently won some success thanks to the Recipes initiative.
Both of these arguments are required.
What can we export?
# Exports node 123 and all its dependencies.
# To a module:
drush dcer node 123 module_name
# To a recipe:
drush dcer node 123 --folder=recipes/recipe_name/content
# Export all nodes and all their dependencies.
drush dcer node --folder=modules/custom/my_custom_module/content
default-content-export
Alias:
In Drupal 10.3, the DefaultContent API was added to Drupal core as part of the experimental Recipes APIs. These APIs allow Drupal to create content from files that are part of a recipe.
Default content drush commands
default-content-export-references
We can now uninstall the Default Content module from our local environment.
Out of the box, we can export the following entity types:
Out of the box, we can export the following entity types:
Out of the box, we can export the following entity types:
One of the biggest reasons is that we don’t know what the IDs will be on the destination site. You may have started out with the same database, but there is a good chance that the IDs have been increased on the production site by content editors adding new articles or pages.
- module – The machine name of the module
# Exports node 123 only. You are responsible to export dependencies.
drush dce node 123 module_name
default-content-export-module
Arguments:
drush en -y default_content
Once your deployment has finished, you can use Drupal core’s recipe script to apply the recipe. If you have cli access to your server, from the webroot you can run:
Commit and deploy your new recipe along with your code changes as you normally would.
Arguments:
Drupal Recipes are a framework and set of tools for automating the configuration of a site. They allow developers to rapidly configure entities, fields, and other settings. A recipe can be applied to any number of different sites. This means creating multiple sites can be achieved faster and with a greater degree of consistency in how they are configured. A great deal of human error and forgetfulness can be avoided by using Recipes, particularly for repetitive config. (Check out my comprehensive guide to Drupal recipes.)
drush recipe ../recipes/recipe-name -v
One of these arguments is required.
This content that we programmatically create isn’t intended for deploying or migrating content, we have the Workspaces and other modules for that.
Exports an entity and all its referenced entities. This is my go to command as it helps you export referenced media, files, taxonomy terms, and users from the parent node.
Applying the recipe
# PHP script
terminus drush site.env -- ev "passthru('php core/scripts/drupal recipe ../recipes/recipe-name -v');"
# Drush 13+
terminus drush site.env -- recipe ../recipes/recipe-name -v
The export process is the same for modules and recipes. Let’s review that now.
You can manually create a recipe folder, the content folder, and a recipe.yml file or use the command line:
Once deployed and applied on your site, you’ll probably want to remove your recipe in a subsequent pull request as you don’t need it in production.
Default content is not meant to be a replacement for content deployment solutions. It can be a good starting point on new sites. It’s great for demo sites, and quality assurance and user acceptance testing, but there are better solutions like the Workspaces module in Drupal core that allow for you to stage content and deploy it later.
What Default content isn’t made for
Let’s take a look at the three commands that the module provides to export content.
Normally we just use recipes in our local development environments and deploy the resulting config, but when leveraging the Default Content module in your recipes, you will deploy them to your server.
name: 'Recipe name'
description: 'Demo content for ticket xyz'
type: 'Content'
Export your content
While we added a way in core to consume content config files from recipes, we are still at the start of what core can do, and mid-journey of what the contrib module aims to do.
Starting back in 2011, a group of open-source Drupal developers started working on a new install profile for Drupal called Snowman. Instead of having a generic and unopinionated starting point, the idea behind Snowman was that it wanted to provide a ready-to-use Drupal site tailored for a specific use case.
