Content-Staging.

Learn DXPR BuilderManage the siteNaar productie

Content-Staging heißt, DXPR-Builder-Seiten zu bauen und zu prüfen, bevor Besucher sie sehen. Dafür gibt es zwei Wege: eine eigene Staging-Website, deren Inhalte Sie in die Produktion übernehmen, oder Drupals Revisionen und Content-Moderation auf einer Website. Diese Seite behandelt beide und hält genau fest, was ein Builder-Speichern mit Revisionen und Moderationszuständen tut, denn davon hängt ab, welcher Weg für Sie funktioniert.

Was ein Builder-Speichern tut

Jeder Speichervorgang aus dem Editor läuft in diesen Schritten:

  1. Er lädt die Standardrevision der Seite, in der bearbeiteten Sprache.
  2. Er prüft, ob die aktuelle bearbeitende Person die Seite aktualisieren darf.
  3. Er schreibt das neue HTML in das Feld.
  4. Wenn der Entitätstyp Revisionen hat, erzeugt er eine neue Revision und macht sie zur Standardrevision. Die neue Revision gehört der aktuellen bearbeitenden Person, mit der Protokollmeldung Saved with DXPR builder und der Anfragezeit.
  5. Er entfernt die Bearbeitungssperre für diese Seite und Revision und speichert dann die Seite.

Die Anfrage hinter einem Speichern ist unter API-Endpunkte beschrieben.

Jeder Speichervorgang auf einer Node oder einem Drag-and-drop-Block erzeugt also eine neue Revision, ob der Inhaltstyp Create new revision aktiviert hat oder nicht, und der Tab Revisions listet jeden Speichervorgang mit der Protokollmeldung des Builders. Drush dxb:page:update erzeugt ebenfalls eine Revision, mit der Protokollmeldung Updated via dxb:page:update Drush command.

Der Builder hat keine Steuerung für einen Moderationszustand und setzt moderation_state nie. Wenn Content-Moderation auf dem Inhaltstyp aktiviert ist, behält die neue Revision den Zustand der Revision, die der Builder geladen hat, und Content-Moderation wendet die Regeln dieses Zustands beim Speichern an:

  • Eine veröffentlichte Seite bleibt veröffentlicht, und die neue Revision geht sofort live.
  • Eine unveröffentlichte Seite in Draft bleibt in Draft.
  • Eine Seite mit veröffentlichter Standardrevision und neuerem ausstehendem Entwurf ist ein Problem: Der Builder lädt die veröffentlichte Revision, nicht den Entwurf, daher erzeugt ein Speichern eine neue veröffentlichte Revision aus dem veröffentlichten Inhalt und lässt die Änderungen des Entwurfs beiseite.

Nutzen Sie das Node-Bearbeitungsformular, um Zustände zu ändern. Für einen Prüfprozess auf einer Website halten Sie Seiten unveröffentlicht (Draft), während Bearbeitende sie im Builder bearbeiten, und veröffentlichen Sie über das Formular, wenn die Prüfung fertig ist.

Staging-Website-Workflow

Eine eigene Staging-Website umgeht die Moderationsgrenzen oben und lässt Beteiligte die echte Seite prüfen.

  1. Bearbeitende bauen und ändern Seiten auf der Staging-Website.
  2. Prüfende geben sie dort frei.
  3. Übernehmen Sie die freigegebenen Inhalte mit einer der Methoden unten in die Produktion.
  4. Prüfen Sie die Seite in der Produktion in einem privaten Browserfenster.

Datenbankkopie

Kopieren Sie die ganze Datenbank von Staging in die Produktion:

drush sql:sync @staging @production

Dies ersetzt alle Produktionsinhalte, sichern Sie daher zuerst die Produktion und rechnen Sie damit, Änderungen zu verlieren, die nach der Kopie in der Produktion gemacht wurden. Dateien sind nicht enthalten; synchronisieren Sie sie wie unten beschrieben.

Gezielter Inhaltsexport

Um einzelne Seiten zu übernehmen, exportieren Sie die Node mit einem Modul wie Default Content, einschließlich der Medien und Dateien, die die Seite referenziert, und importieren Sie sie in der Produktion. Der Builder speichert sein HTML im Textfeld, daher wandert der Feldwert mit der Node. Bildpfade im HTML zeigen in sites/default/files/dxpr_builder_images, kopieren Sie daher auch diese Dateien.

Reines Konfigurations-Deployment

Wenn das Gebaute ein wiederverwendbares Layout statt einer konkreten Seite ist:

  1. Speichern Sie auf Staging das Layout mit More > Save as template an der Container-Leiste. Dies erzeugt eine Benutzervorlage.

  2. Gehen Sie zu DXPR Studio > DXPR Builder > User Templates und wählen Sie Create page template in den Aktionen dieser Vorlage.

  3. Exportieren Sie die Konfiguration:

    drush config:export

  4. Bringen Sie die Datei dxpr_builder.page_template.*.yml aus und importieren Sie sie in der Produktion:

    drush config:import

  5. Bearbeitende beginnen in der Produktion neue Seiten aus der Vorlage. Seitenvorlagen erscheinen in leeren Containern.

Dateisynchronisation

Uploads aus dem Builder landen in dxpr_builder_images, dxpr_builder_videos und dxpr_builder_files im Standard-Dateiverzeichnis der Website. Synchronisieren Sie sie mit den Inhalten:

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

Ein geteilter Dateispeicher wie S3, der in beiden Umgebungen eingehängt ist, erübrigt diesen Schritt.

Revisionen und Zurücksetzen

Weil jeder Speichervorgang eine Revision ist, ist Zurücksetzen ein Drupal-Vorgang:

  1. Öffnen Sie den Tab Revisions der Seite.
  2. Finden Sie die Revision vor dem unerwünschten Speichern; jeder Builder-Speichervorgang zeigt Saved with DXPR builder.
  3. Klicken Sie auf Revert.

Zurücksetzen erzeugt eine weitere Revision, daher bleibt der Verlauf intakt.

Bearbeitungssperren

Wenn eine bearbeitende Person zuerst in einen Container klickt, sendet der Editor eine dxpr_toggle_content_lock-Anfrage an /dxpr_builder/ajax, und die Tabelle dxpr_lock vermerkt Entität, Revision, Sprache und Konto. Wenn eine weitere bearbeitende Person die Seite öffnet, fragt der Editor dxpr_content_lock_status ab, verbirgt die Container-Steuerung und zeigt eine Locked-Schaltfläche mit dem Namen der sperrenden Person. Das Speichern löscht die Zeile. Eine weitere bearbeitende Person kann auch auf Locked klicken und bestätigen, um die Sperre zu übersteuern; von da an gewinnt der letzte Speichervorgang.

Wie geht es weiter?