Sample content

This module makes development easier through the use of sample content. Samples behave exactly like regular content, with the exception that they are restricted to users with permission to view and/or manage those samples.

Use cases

Sample content can be used to create representative pages in a canonical environment without ever exposing them to end users. This is helpful because you can share links to representative pages with a client or designer prior to a site migration, during initial development, or when adding new fields or content types to an existing site.

Sample content can also be used for visual regression testing. For example,

1. A styling bug is found due to unexpected content
2. A contributor creates a new sample which demonstrates the bug
3. A developer syncs their database with the canonical database to obtain a local copy of the new sample
4. Using the sample, the developer quickly fixes the problem
5. After deploying the fix, that sample can be added as a new reference image using a tool like BackstopJS to ensure that the front end for that content won't be accidentally changed

Sample content can be especially useful in decoupled scenarios as well, since front-end developers do not necessarily need to run a local instance of Drupal. Instead, they can point their local front end to the live API (CORS headers must be configured to allow this). This empowers a site builder familiar with Drupal to create content types and test data that a purely front-end focused developer can work from. Then, with minimal training and their own user account, the front-end developer can create new samples with different content variations as needed.

Post installation

After installing this module and configuring permissions, you must rebuild permissions from the status report page (/admin/reports/status). On sites with very large node counts, this may take a long time.

Addressing concerns

Why is unpublished content insufficient for this use case?
Sometimes, unpublished content needs its own styling and it may have slightly different markup than published content. In other words, by creating an unrelated concept of sample vs. regular content in addition to published vs. unpublished content one can have perfectly representative content during development.

One may also want to easily exclude samples from content moderation interfaces or create special interfaces for the samples themselves.

Why put development content into a canonical/production environment?
It is certainly possible to create samples in development or staging environments, but many development workflows often involve overwriting these environment's databases with canonical data from time to time. This means that the samples would be overwritten and lost, which would not be useful for regression testing. It also means that the samples would need to be tediously recreated.

Why not use the Devel module?
Sample content is compatible with the Devel module and devel_generate. However, the Devel module begins from a different philosophy: it creates artificial content that is meant to be thrown away and is rarely, if ever, shared with collaborators. Using devel_generate, you can generate dozens or even hundreds of different content variations using random input, which can be useful for seeing how your front end responds to wildly different content, but it does not typically generate content that's representative of real-world content which may frustrate your stakeholders.