In Gutenberg kann der Button zum Veröffentlichen und Aktualisieren deaktiviert werden. So wäre es beispielsweise möglich, vor dem Veröffentlichen eines Custom-Post-Type-Inhalts das Ausfüllen eines Blocks zu erzwingen, mit dem Metadaten für den Inhalt gespeichert werden, die bei der Ausgabe benötigt werden. Hier zeige ich, wie das funktioniert.
lockPostSaving
und unlockPostSaving
Mit den Funktionen lockPostSaving()
und unlockPostSaving()
des data
-Moduls lässt sich ein Gutenberg-Inhalt sperren oder entsperren. Als Parameter wird ein Name für das lock
übergeben, sodass ein Inhalt auch durch mehrere verschiedene Bedingungen gesperrt werden kann. Solange eine von den Sperren noch nicht mit unlockPostSaving()
entfernt wurde, kann nicht veröffentlicht oder aktualisiert werden.
In der Praxis sieht das Sperren des Buttons zum Veröffentlichen oder Aktualisieren so aus:
wp.data.dispatch( 'core/editor' ).lockPostSaving( 'requiredValueLock' );
Code-Sprache: JavaScript (javascript)
Und so kann die Sperre wieder aufgehoben werden:
wp.data.dispatch( 'core/editor' ).unlockPostSaving( 'requiredValueLock' );
Code-Sprache: JavaScript (javascript)
In Verbindung mit der subscribe()
-Funktion aus dem data
-Modul, die bei Änderungen des Status im Editor abgefeuert wird, können wir eine Bedingung überwachen und je nachdem, ob die Bedingung gerade nicht erfüllt oder erfüllt ist, den Button sperren oder entsperren.
Hier ein Beispiel dafür, bei dem der Button gesperrt wird, wenn der Metakey required_value
einen leeren Wert hat:
const {
subscribe,
select,
dispatch,
} = wp.data;
wp.domReady( () => {
const postType = select( 'core/editor' ).getCurrentPostType();
if ( postType === 'portfolio' ) {
let locked = false;
// Subscribe to editor state changes.
let checkRequiredField = subscribe( () => {
// Get meta values of post.
const meta = select( 'core/editor' ).getEditedPostAttribute( 'meta' );
if ( meta.required_value !== undefined && meta.required_value === '' ) {
// Lock post, if not already locked.
if ( ! locked ) {
locked = true;
dispatch( 'core/editor' ).lockPostSaving( 'requiredValueLock' );
}
} else {
// Unlock post if locked.
if ( locked ) {
locked = false;
dispatch( 'core/editor' ).unlockPostSaving( 'requiredValueLock' );
}
}
} );
}
} );
Code-Sprache: JavaScript (javascript)
Zunächst speichern wir die Funktionen subscribe
, select
und dispatch
aus dem wp.data
-Modul in gleichnamige Variablen, um uns später etwas Schreibarbeit zu sparen.
Mit wp.domReady()
warten wir darauf, bis der Editor fertig geladen ist und prüfen im Anschluss, ob der aktuelle Inhalt dem Post-Type portfolio
entspricht. Nur in diesem Fall wollen wir unsere Bedingungen überprüfen.
Mit subscribe()
hängen wir uns an Änderungen des Editor-Status, sodass der Code innerhalb der Funktion bei jeder Änderung ausgeführt wird. Bei einer Änderung holen wir uns zunächst die Metawerte für den Post. Wenn ein Block einen Metawert verändert, wird immer der aktuelle Wert zurückgegeben, nicht der, der in der Datenbank gespeichert ist.
Danach prüfen wir, ob meta.required_value
existiert (also ob es einen Wert für den Metakey required_value
gibt) und ob dieser Wert ein leerer String ist. In diesem Fall sperren wir den Post, sofern er nicht bereits gesperrt ist.
Wenn der Key nicht existiert oder er nicht leer ist, entsperren wir den Post wieder.
Wenn ihr noch keinen Code für den Block-Editor geschrieben habt: Bei KrautPress habe ich in zwei Beiträgen beschrieben, wie man Webpack für die Blockentwicklung einrichtet und wie man ein kleines Plugin damit erstellt. In dem Plugin könnt ihr den Code in die JavaScript-Datei einfügen.
Wo und wie bindet man diesen Code denn ein? Kannst du das noch etwas näher ausführen? Das wäre toll. 🙂
Hi Torsten,
ups, ja, gute Frage. Ich habe einen entsprechenden Absatz ans Ende des Beitrags eingefügt 🙂
Viele Grüße
Florian
Ein Nachtrag: da in dem Code-Beispiel nichts von JSX genutzt wird, sondern eigentlich nur normales modernes JavaScript, sollte es für moderne Browser im Backend auch reichen, wenn du den Code einfach unverändert einbindest und den ganzen Babel- und Webpack-Kram weglässt. Ich habe es gerade testweise mal direkt in die Browser-Konsole eingegeben und das hat funktioniert.
Falls von Interesse: Altis (schamlose Werbung für meinen Arbeitgeber, sorry…) hat dieses Publication Checklist Framework, das auch als eigenständiges Plugin ohne Altis drumherum funktionieren sollte. 😊
Hi Caspar,
uh, cool, danke für den Hinweis, sehr von Interesse! Schaue ich mir mal an.
Viele Grüße
Florian
Danke für den Tipp.
Ich habe diese Funktion ein wenig umgebaut und nutze sie um abhängig vom gewählten Seitentemplate individuelles Styles auf den Editor anzuwenden.
Ich habe ein separates Seitentemplate mit Dunklem Hintergrund während mein Standard Seitentemplate einen weißen Hintergrund besitzt. Mit Hilfe des abgewandelten Snippets konnte ich das jetzt auch auf den Editor übertragen.
https://gist.github.com/derweili/6c5b32f414a4895f34eff515b2b24d42
Danke fürs Teilen des Codes! Das Seiten-Template-Select wollte ich auch mal überwachen, dadurch bin ich auf die
subscribe()
-Funktion aufmerksam gemacht worden 🙂