Staged content

Introduction

This module allows a simple way to provide "staged" content to be injected into projects. Providing a basic set during a development cycle.

This is especially usefull for more content first sites, demo's etc since it allows projects to be reïnstalled with a given set of content. Allowing for smoother go live (key content can be generated during the development process). Easier QA cycles (providing basic sets of data instead of having the QA set them up over and over again).
Extra regression and Automated test options.

Usage

Exporting Content

Content is generated as usual via the UI and can then be exported into files. Which can than be commited into a project repository etc. After a project reïnstall these can then be imported again to provide the standard set.

This is powered via Drush (there is no UI provided).

# Export the content based on the data in a config file. 
# Note that the output dir can be selected with the --folder=OUTPUT_DIR option.
# MARKER_NAME is a placeholder (allowing for subfoldering in the set) and can be passed
# as a string. 
# e.g in this example all the prod data is in /path/to/dir/prod 
# and all the acc data is in /path/to/dir/acc
drush staged-content-export /path/to/my/config.yml --folder=/path/to/dir/MARKER_NAME 

The config file would look as follows

# Defines which markes can be detected. Sorting the data over
# various subsets. This makes content sets easier to maintain. 
markers:
  - acc
  - test
  - dev
# Which entity types should be exported.
entity_types:
  node:
    entityType: node
    # Include the original entity id in the exported data. 
    # Defaults to FALSE, if not specified only the uuid is considered relevant.
    includeId: TRUE 
  term:
    entityType: taxonomy_term
  user:
    entityType: user
  block_content:
    entityType: block_content
  menu_link_content:
    entityType: menu_link_content

Importing content

An exported set can be imported into a site again via drush.

# MARKER_NAME is a placeholder (allowing for subfoldering in the set) and can be passed
# as a string. 
# e.g in this example all the prod data is in /path/to/dir/prod 
# and all the acc data is in /path/to/dir/acc (this is done automatically by passing the folder 
# to the export.  
drush staged-content-import /path/to/dir/MARKER_NAME  

Optionally: Markers can be provided to only import a given set of data. See sample setup below for more information.

Features

Chaining of common nested entity types: When exporting an entity all the connected paragraphs, files and media entities are added to the set recursively.

Prevention of duplicate id'sWhen importing data from a set, duplication from id's will be prevented (information about the details will be printed to the CLI). This allows for sets to be extended in different branches.

Option to "soft reset" content: The import can be run several times, resetting the data in the already existing content. Content not in the set will not be touched

Splitting of exported content: To make the set easier to maintain it's possible to "mark" content as part of a set. And only reïmport certain sets. For example the landing page for the news overview (content ready to go live). And 20 example news items (for testing purposes). Importing the "prod" set would only add the landing page. Importing the full sets, would also add the test content. Preventing the need to maintain several sets.

This is done by adding +STAGE_NAME to the label for the entity. For example a node with title "Picknicking +acc" would be added to the acc set. (Note that this detection is subject to change and is a MVP) To prevent this to appear as part of the pathauto, you can add the acc, dev and test keywords to the list of excluded words.

Examples

Carl and Ellen are both devs working in a scrum oriented flow, This the news section, the search and the calender need to get done.

Both Carl and Ellen branch of from the main branch and work their magic. Both their changes require some extra content that should go to production (e.g the news overview page and the calendar overview page, since they work content first). They set up this content and export it to the file system. But for testing purposes they each also add 20 nodes marked for testing. Covering some layout wise test cases and hitting the limit for the pager).

After merging into the master branch a clean build is generated for the QA, which has all the test content already included. Making his work a lot easier.

After the QA rejects everything 3 times it's now ready for a demo build for the client. Which is done by rebuilding with only the production data. This same build can go live later on.

Roadmap

• Improve the input for the various drush commands (currently always absolute paths).
• Provide a better way to handle the detection of project "stages"
• Metatag handling
• Clean up & extending tests
• Support revisions (might work, but would be a coincidence if it does)
• Image property handling (alt texts and titles are currently stripped)

Disclaimer

This is a developer oriented module and it assumes a fair amount of dev knowledge, content is complex and varied so not everything will be supported out of the box. But the module is largely stable. It's meant for automated processes / Dev ops oriented flows. The module has no real use on production environments etc.

Credit

This module is an extension/rewrite of the default content module to since default_content itself did not quite fit the use case.