Skip to content

Content staging

Content staging is building and reviewing DXPR Builder pages before visitors see them. There are two ways to do it: a separate staging site whose content you move to production, or Drupal's revisions and Content Moderation on one site. This page covers both, and states exactly what a builder save does to revisions and moderation states, because that decides which approach works for you.

What a builder save does

Every save from the editor runs these steps:

  1. It loads the page's default revision, in the language being edited.
  2. It checks that the current user may update the page.
  3. It writes the new HTML into the field.
  4. If the entity type has revisions, it creates a new revision and makes it the default revision. The current user becomes its author, with the log message Saved with DXPR builder and the request time.
  5. It removes the editing lock for that page and revision, then saves the page.

The request behind a save is described under API endpoints.

So every save on a node or a Drag and Drop Block creates a new revision, whether or not the content type has Create new revision ticked, and the Revisions tab lists each save with the builder's log message. Drush dxb:page:update also creates a revision, with the log message Updated via dxb:page:update Drush command.

The builder has no control for a moderation state and never sets moderation_state. When Content Moderation is enabled on the content type, the new revision keeps the state of the revision the builder loaded, and Content Moderation applies that state's rules on save:

  • A published page stays published, and the new revision goes live at once.
  • An unpublished page in Draft stays in Draft.
  • A page with a published default revision and a newer pending draft is a problem: the builder loads the published revision, not the draft, so a save creates a new published revision from the published content and leaves the draft's changes aside.

Use the node edit form to change states. For a review process inside one site, keep pages unpublished (Draft) while editors work on them in the builder, and publish through the form when the review is done.

Staging site workflow

A separate staging site avoids the moderation limits above and lets stakeholders review the real page.

  1. Editors build and change pages on the staging site.
  2. Reviewers approve them there.
  3. Move the approved content to production with one of the methods below.
  4. Check the page on production as an anonymous visitor.

Database copy

Copy the whole database from staging to production:

drush sql:sync @staging @production

This replaces all production content, so back up production first and expect to lose changes made on production after the copy. Files are not included; sync them as described below.

Selective content export

To move individual pages, export the node with a module such as Default Content, including the media and files the page references, and import it on production. The builder stores its HTML in the text field, so the field value travels with the node. Image paths in the HTML point into sites/default/files/dxpr_builder_images, so copy those files too.

Configuration-only deployment

If what you built is a reusable layout rather than a specific page:

  1. On staging, save the layout with More > Save as template on the container bar. This creates a user template.
  2. Go to DXPR Studio > DXPR Builder > User Templates and choose Create page template in that template's operations.
  3. Export configuration:

bash drush config:export

  1. Deploy the dxpr_builder.page_template.*.yml file and import it on production:

bash drush config:import

  1. Editors start new pages from the template on production. Page templates appear in empty containers.

File synchronisation

Uploads from the builder go to dxpr_builder_images, dxpr_builder_videos and dxpr_builder_files in the site's default files directory. Sync them with the content:

rsync -avz staging:/path/to/files/ production:/path/to/files/

A shared file store such as S3 mounted on both environments removes this step.

Revisions and rollback

Because every save is a revision, rolling back is a Drupal operation:

  1. Open the page's Revisions tab.
  2. Find the revision before the unwanted save; each builder save shows Saved with DXPR builder.
  3. Click Revert.

Reverting creates another revision, so the history stays intact.

Editing locks

When an editor first clicks into a container, the editor sends a dxpr_toggle_content_lock request to /dxpr_builder/ajax and the dxpr_lock table records the entity, revision, language and user. When another editor opens the page, the editor queries dxpr_content_lock_status, hides the container controls and shows a Locked button with the name of the lock holder. The save deletes the row. Another editor can also click Locked and confirm to override the lock; from then on, the last save wins.

What's next?

Something wrong or missing on this page? Report it or edit the page.