Ich erstelle ein WordPress-Plugin, und es gibt eine geringe Lernkurve, wenn es um dessen Nutzung geht. Ich möchte den Benutzern eine Einführung in die Verwendung des Plugins geben, aber ich möchte vermeiden, Benutzer auf die Dokumentation auf der Website des Plugins umzuleiten, da dies sie aus dem Erlebnis herausreißt.
Es wäre großartig, wenn Benutzer das Plugin sofort nach der Installation nutzen könnten, aber dennoch während der aktiven Nutzung Zugriff auf hilfreiche Tipps hätten. WordPress bietet keine native Funktion dafür, aber wir können etwas machen, da WordPress so flexibel ist.
Hier ist also die Idee. Wir werden die Dokumentation direkt in das Plugin einbacken und sie im Blockeditor leicht zugänglich machen. Auf diese Weise können Benutzer das Plugin sofort nutzen und haben Antworten auf häufig gestellte Fragen direkt dort, wo sie arbeiten.
Mein Plugin arbeitet mit mehreren benutzerdefinierten Beitragstypen (Custom Post Types, CPTs). Was wir bauen werden, ist im Wesentlichen ein Pop-up-Modal, das Benutzer erhalten, wenn sie zu diesen CPTs gehen.
Der WordPress Block Editor ist in React aufgebaut, das Komponenten verwendet, die für verschiedene Situationen angepasst und wiederverwendet werden können. Dies ist auch bei dem, was wir machen, der Fall – nennen wir es die <Guide>-Komponente –, die sich wie ein Modal verhält, aber aus mehreren Seiten besteht, durch die der Benutzer paginieren kann.
WordPress selbst hat eine <Guide>-Komponente, die beim ersten Öffnen des Blockeditors einen Willkommensleitfaden anzeigt.
Der Leitfaden ist ein Container, gefüllt mit Inhalten, die in einzelne Seiten aufgeteilt sind. Mit anderen Worten, es ist ziemlich genau das, was wir wollen. Das bedeutet, dass wir das Rad für dieses Projekt nicht neu erfinden müssen; wir können dieses gleiche Konzept für unser eigenes Plugin wiederverwenden.
Machen wir genau das.
Was wir erreichen wollen
Bevor wir zur Lösung kommen, sprechen wir über das Endziel.
Das Design erfüllt die Anforderungen des Plugins, bei dem es sich um einen GraphQL-Server für WordPress handelt. Das Plugin bietet eine Vielzahl von CPTs, die über benutzerdefinierte Blöcke bearbeitet werden, welche wiederum durch Vorlagen definiert sind. Es gibt insgesamt zwei Blöcke: einen namens „GraphiQL Client“ zur Eingabe der GraphQL-Abfrage und einen namens „Persisted Query Options“ zur Anpassung des Verhaltens der Ausführung.
Da das Erstellen einer Abfrage für GraphQL keine triviale Aufgabe ist, habe ich beschlossen, die Guide-Komponente dem Editorbildschirm für diesen CPT hinzuzufügen. Sie ist in den Dokumenteinstellungen als Panel namens „Willkommensleitfaden“ verfügbar.
Wenn Sie dieses Panel öffnen, erhält der Benutzer einen Link. Dieser Link löst das Modal aus.
Für das Modal selbst habe ich beschlossen, ein Tutorial-Video zur Verwendung des CPT auf der ersten Seite anzuzeigen und dann alle im CPT verfügbaren Optionen auf den nachfolgenden Seiten im Detail zu beschreiben.
Ich glaube, dieses Layout ist eine effektive Möglichkeit, dem Benutzer Dokumentation anzuzeigen. Es ist aus dem Weg, aber dennoch bequem nah am Geschehen. Sicher, wir könnten ein anderes Design verwenden oder den Modal-Trigger mit einer anderen Komponente woanders platzieren, anstatt <Guide> wiederzuverwenden, aber das ist völlig in Ordnung.
Planung der Implementierung
Die Implementierung umfasst folgende Schritte
- Erstellung eines neuen Skripts zur Registrierung des benutzerdefinierten Seitenleisten-Panels
- Anzeige des benutzerdefinierten Seitenleisten-Panels nur im Editor für unseren benutzerdefinierten Beitragstyp
- Erstellung des Leitfadens
- Hinzufügen von Inhalten zum Leitfaden
Legen wir los!
Schritt 1: Erstellung des Skripts
Ab WordPress 5.4 können wir eine Komponente namens <PluginDocumentSettingPanel> verwenden, um ein Panel in den Dokumenteinstellungen des Editors wie folgt hinzuzufügen.
const { registerPlugin } = wp.plugins;
const { PluginDocumentSettingPanel } = wp.editPost;
const PluginDocumentSettingPanelDemo = () => (
<PluginDocumentSettingPanel
name="custom-panel"
title="Custom Panel"
className="custom-panel"
>
Custom Panel Contents
</PluginDocumentSettingPanel>
);
registerPlugin( 'plugin-document-setting-panel-demo', {
render: PluginDocumentSettingPanelDemo,
icon: 'palmtree',
} );Wenn Sie erfahren im Umgang mit dem Blockeditor sind und bereits wissen, wie Sie diesen Code ausführen, können Sie überspringen. Ich arbeite seit weniger als drei Monaten mit dem Blockeditor und React/npm/webpack ist eine neue Welt für mich – dieses Plugin ist mein erstes Projekt, das sie nutzt! Ich habe festgestellt, dass die Dokumentation im Gutenberg-Repo für Anfänger wie mich nicht immer ausreichend ist und manchmal die Dokumentation ganz fehlt, sodass ich tief in den Quellcode eintauchen musste, um Antworten zu finden.
Wenn die Dokumentation für die Komponente besagt, dass sie das obige Codefragment verwenden soll, weiß ich nicht, was als nächstes zu tun ist, denn <PluginDocumentSettingPanel> ist kein Block, und ich kann keinen neuen Block erstellen oder den Code dort hinzufügen. Außerdem arbeiten wir mit JSX, was bedeutet, dass wir einen JavaScript-Build-Schritt benötigen, um den Code zu kompilieren.
Ich habe jedoch den entsprechenden ES5-Code gefunden.
var el = wp.element.createElement;
var __ = wp.i18n.__;
var registerPlugin = wp.plugins.registerPlugin;
var PluginDocumentSettingPanel = wp.editPost.PluginDocumentSettingPanel;
function MyDocumentSettingPlugin() {
return el(
PluginDocumentSettingPanel,
{
className: 'my-document-setting-plugin',
title: 'My Panel',
},
__( 'My Document Setting Panel' )
);
}
registerPlugin( 'my-document-setting-plugin', {
render: MyDocumentSettingPlugin
} );ES5-Code muss nicht kompiliert werden, sodass wir ihn wie jedes andere Skript in WordPress laden können. Aber das möchte ich nicht. Ich möchte die volle, moderne Erfahrung von ESNext und JSX.
Meine Überlegung ist also folgende: Ich kann die Block-Scaffolding-Tools nicht verwenden, da es kein Block ist, und ich weiß nicht, wie ich das Skript kompilieren soll (ich werde auf keinen Fall selbst webpack einrichten). Das bedeutet, ich stecke fest.
Aber warten Sie! Der einzige Unterschied zwischen einem Block und einem regulären Skript ist, wie sie in WordPress registriert werden. Ein Block wird so registriert
wp_register_script($blockScriptName, $blockScriptURL, $dependencies, $version);
register_block_type('my-namespace/my-block', [
'editor_script' => $blockScriptName,
]);Und ein reguläres Skript wird so registriert
wp_register_script($scriptName, $scriptURL, $dependencies, $version);
wp_enqueue_script($scriptName);Wir können jedes der Block-Scaffolding-Tools verwenden, um Dinge zu modifizieren und dann ein reguläres Skript anstelle eines Blocks zu registrieren, wodurch wir Zugriff auf die webpack-Konfiguration zum Kompilieren des ESNext-Codes erhalten. Die verfügbaren Tools sind
- Der WP CLI ‚scaffold‘-Befehl
- Ahmad Awais's create-guten-block Paket
- Das offizielle @wordpress/create-block Paket
Ich habe mich entschieden, das @wordpress/create-block Paket zu verwenden, da es vom Team, das Gutenberg entwickelt, gepflegt wird.
Um den Block zu erstellen, führen wir dies in der Kommandozeile aus.
npm init @wordpress/blockNachdem alle Aufforderungen zur Eingabe von Informationen – einschließlich des Namens, Titels und der Beschreibung des Blocks – abgeschlossen sind, generiert das Tool ein Single-Block-Plugin mit einer PHP-Datei, die Code ähnlich diesem enthält.
/**
* Registers all block assets so that they can be enqueued through the block editor
* in the corresponding context.
*
* @see https://developer.wordpress.org/block-editor/tutorials/block-tutorial/applying-styles-with-stylesheets/
*/
function my_namespace_my_block_block_init() {
$dir = dirname( __FILE__ );
$script_asset_path = "$dir/build/index.asset.php";
if ( ! file_exists( $script_asset_path ) ) {
throw new Error(
'You need to run `npm start` or `npm run build` for the "my-namespace/my-block" block first.'
);
}
$index_js = 'build/index.js';
$script_asset = require( $script_asset_path );
wp_register_script(
'my-namespace-my-block-block-editor',
plugins_url( $index_js, __FILE__ ),
$script_asset['dependencies'],
$script_asset['version']
);
$editor_css = 'editor.css';
wp_register_style(
'my-namespace-my-block-block-editor',
plugins_url( $editor_css, __FILE__ ),
array(),
filemtime( "$dir/$editor_css" )
);
$style_css = 'style.css';
wp_register_style(
'my-namespace-my-block-block',
plugins_url( $style_css, __FILE__ ),
array(),
filemtime( "$dir/$style_css" )
);
register_block_type( 'my-namespace/my-block', array(
'editor_script' => 'my-namespace-my-block-block-editor',
'editor_style' => 'my-namespace-my-block-block-editor',
'style' => 'my-namespace-my-block-block',
) );
}
add_action( 'init', 'my_namespace_my_block_block_init' );Wir können diesen Code in das Plugin kopieren und entsprechend modifizieren, um den Block in ein reguläres Skript umzuwandeln. (Beachten Sie, dass ich auch die CSS-Dateien dabei entferne, aber sie könnte beibehalten werden, falls nötig.)
function my_script_init() {
$dir = dirname( __FILE__ );
$script_asset_path = "$dir/build/index.asset.php";
if ( ! file_exists( $script_asset_path ) ) {
throw new Error(
'You need to run `npm start` or `npm run build` for the "my-script" script first.'
);
}
$index_js = 'build/index.js';
$script_asset = require( $script_asset_path );
wp_register_script(
'my-script',
plugins_url( $index_js, __FILE__ ),
$script_asset['dependencies'],
$script_asset['version']
);
wp_enqueue_script(
'my-script'
);
}
add_action( 'init', 'my_script_init' );Kopieren wir die package.json-Datei.
{
"name": "my-block",
"version": "0.1.0",
"description": "This is my block",
"author": "The WordPress Contributors",
"license": "GPL-2.0-or-later",
"main": "build/index.js",
"scripts": {
"build": "wp-scripts build",
"format:js": "wp-scripts format-js",
"lint:css": "wp-scripts lint-style",
"lint:js": "wp-scripts lint-js",
"start": "wp-scripts start",
"packages-update": "wp-scripts packages-update"
},
"devDependencies": {
"@wordpress/scripts": "^9.1.0"
}
}Nun können wir den Inhalt der Datei src/index.js mit dem ESNext-Code von oben ersetzen, um die <PluginDocumentSettingPanel>-Komponente zu registrieren. Nach dem Ausführen von npm start (oder npm run build für die Produktion) wird der Code in build/index.js kompiliert.
Es gibt noch ein letztes Problem zu lösen: Die <PluginDocumentSettingPanel>-Komponente wird nicht statisch importiert, sondern aus wp.editPost bezogen, und da wp eine globale Variable ist, die von WordPress zur Laufzeit geladen wird, ist diese Abhängigkeit in index.asset.php (die während des Builds automatisch generiert wird) nicht vorhanden. Wir müssen manuell eine Abhängigkeit zum wp-edit-post-Skript hinzufügen, wenn wir das Skript registrieren, um sicherzustellen, dass es vor unserem geladen wird.
$dependencies = array_merge(
$script_asset['dependencies'],
[
'wp-edit-post',
]
);
wp_register_script(
'my-script',
plugins_url( $index_js, __FILE__ ),
$dependencies,
$script_asset['version']
);Jetzt ist die Skript-Einrichtung bereit!
Das Plugin kann mit den unaufhörlichen Entwicklungszyklen von Gutenberg aktualisiert werden. Führen Sie npm run packages-update aus, um die npm-Abhängigkeiten (und damit die webpack-Konfiguration, die im Paket "@wordpress/scripts" definiert ist) auf ihre neuesten unterstützten Versionen zu aktualisieren.
An dieser Stelle fragen Sie sich vielleicht, woher ich wusste, dass ich eine Abhängigkeit zum "wp-edit-post"-Skript vor unserem Skript hinzufügen muss. Nun, ich musste tief in den Quellcode von Gutenberg eintauchen. Die Dokumentation für <PluginDocumentSettingPanel> ist etwas unvollständig, was ein perfektes Beispiel dafür ist, wie Gutenbergs Dokumentation an manchen Stellen mangelhaft ist.
Beim Durchstöbern von Code und Dokumentation habe ich einige erhellende Dinge entdeckt. Zum Beispiel gibt es zwei Möglichkeiten, unsere Skripte zu codieren: entweder mit der ES5- oder der ESNext-Syntax. ES5 benötigt keinen Build-Prozess und referenziert Codeinstanzen aus der Laufzeitumgebung, höchstwahrscheinlich über die globale wp-Variable. Zum Beispiel geht der Code zum Erstellen eines Icons so:
var moreIcon = wp.element.createElement( 'svg' );ESNext verlässt sich auf webpack, um alle Abhängigkeiten aufzulösen, was uns ermöglicht, statische Komponenten zu importieren. Zum Beispiel wäre der Code zum Erstellen eines Icons:
import { more } from '@wordpress/icons';Das gilt so ziemlich überall. Dies ist jedoch nicht der Fall für die <PluginDocumentSettingPanel>-Komponente, die auf die Laufzeitumgebung für ESNext verweist.
const { PluginDocumentSettingPanel } = wp.editPost;Deshalb müssen wir dem „wp-edit-post“-Skript eine Abhängigkeit hinzufügen. Dort ist die Variable wp.editPost definiert.
Wenn <PluginDocumentSettingPanel> direkt importiert werden könnte, dann würde die Abhängigkeit zu „wp-edit-post“ automatisch vom Blockeditor über das Dependency Extraction Webpack Plugin gehandhabt werden. Dieses Plugin baut die Brücke von statisch zu Laufzeit, indem es eine index.asset.php-Datei erstellt, die alle Abhängigkeiten für die Laufzeitumgebungsskripte enthält, die durch Ersetzen von "@wordpress/" im Paketnamen durch "wp-" gewonnen werden. Daher wird das Paket "@wordpress/edit-post" zum Laufzeitskript "wp-edit-post". So habe ich herausgefunden, welchem Skript ich die Abhängigkeit hinzufügen muss.
Schritt 2: Aussperren des benutzerdefinierten Seitenleisten-Panels von allen anderen CPTs
Das Panel zeigt Dokumentation für einen bestimmten CPT an, daher muss es nur für diesen CPT registriert werden. Das bedeutet, wir müssen es von allen anderen Beitragstypen aussperren.
Ryan Welcher (der die <PluginDocumentSettingPanel>-Komponente erstellt hat) beschreibt diesen Prozess bei der Registrierung des Panels.
const { registerPlugin } = wp.plugins;
const { PluginDocumentSettingPanel } = wp.editPost
const { withSelect } = wp.data;
const MyCustomSideBarPanel = ( { postType } ) => {
if ( 'post-type-name' !== postType ) {
return null;
}
return(
<PluginDocumentSettingPanel
name="my-custom-panel"
title="My Custom Panel"
>
Hello, World!
</PluginDocumentSettingPanel>
);
}
const CustomSideBarPanelwithSelect = withSelect( select => {
return {
postType: select( 'core/editor' ).getCurrentPostType(),
};
} )( MyCustomSideBarPanel);
registerPlugin( 'my-custom-panel', { render: CustomSideBarPanelwithSelect } );Er schlägt auch eine alternative Lösung vor, die useSelect anstelle von withSelect verwendet.
Das gesagt, bin ich von dieser Lösung nicht ganz überzeugt, denn die JavaScript-Datei muss trotzdem geladen werden, auch wenn sie nicht benötigt wird, was die Website zu einer Leistungseinbuße zwingt. Macht es nicht mehr Sinn, die JavaScript-Datei *nicht* zu registrieren, als JavaScript auszuführen, nur um JavaScript zu deaktivieren?
Ich habe eine PHP-Lösung erstellt. Ich gebe zu, sie fühlt sich etwas hackelig an, aber sie funktioniert gut. Zuerst ermitteln wir, welcher Beitragstyp zum erstellten oder bearbeiteten Objekt gehört.
function get_editing_post_type(): ?string
{
if (!is_admin()) {
return null;
}
global $pagenow;
$typenow = '';
if ( 'post-new.php' === $pagenow ) {
if ( isset( $_REQUEST['post_type'] ) && post_type_exists( $_REQUEST['post_type'] ) ) {
$typenow = $_REQUEST['post_type'];
};
} elseif ( 'post.php' === $pagenow ) {
if ( isset( $_GET['post'] ) && isset( $_POST['post_ID'] ) && (int) $_GET['post'] !== (int) $_POST['post_ID'] ) {
// Do nothing
} elseif ( isset( $_GET['post'] ) ) {
$post_id = (int) $_GET['post'];
} elseif ( isset( $_POST['post_ID'] ) ) {
$post_id = (int) $_POST['post_ID'];
}
if ( $post_id ) {
$post = get_post( $post_id );
$typenow = $post->post_type;
}
}
return $typenow;
}Dann registrieren wir das Skript nur, wenn es mit unserem CPT übereinstimmt.
add_action('init', 'maybe_register_script');
function maybe_register_script()
{
// Check if this is the intended custom post type
if (get_editing_post_type() != 'my-custom-post-type') {
return;
}
// Only then register the block
wp_register_script(...);
wp_enqueue_script(...);
}Schauen Sie sich diesen Beitrag an für eine tiefere Betrachtung, wie das funktioniert.
Schritt 3: Erstellung des benutzerdefinierten Leitfadens
Ich habe die Funktionalität für den Leitfaden meines Plugins auf der Grundlage der WordPress <Guide>-Komponente entworfen. Das war mir zuerst nicht bewusst, also hier ist, wie ich das herausgefunden habe.
- Durchsuchen Sie den Quellcode, um zu sehen, wie es dort gemacht wurde.
- Erkunden Sie den Katalog aller verfügbaren Komponenten in Gutenbergs Storybook.
Zuerst habe ich Inhalte aus dem Modal des Blockeditors kopiert und eine einfache Suche durchgeführt. Die Ergebnisse führten mich zu dieser Datei. Von dort entdeckte ich, dass die Komponente <Guide> heißt und ich ihren Code einfach in mein Plugin kopieren und als Basis für meinen eigenen Leitfaden verwenden konnte.
Dann habe ich nach der Dokumentation der Komponente gesucht. Ich habe das Paket @wordpress/components durchsucht (das, wie Sie vielleicht erraten haben, der Ort ist, an dem Komponenten implementiert werden) und die README-Datei der Komponente gefunden. Das gab mir alle Informationen, die ich brauchte, um meine eigene benutzerdefinierte Guide-Komponente zu implementieren.
Ich habe auch den Katalog aller verfügbaren Komponenten in Gutenbergs Storybook erkundet (was tatsächlich zeigt, dass diese Komponenten außerhalb des WordPress-Kontexts verwendet werden können). Durch Anklicken aller habe ich schließlich <Guide> entdeckt. Das Storybook liefert den Quellcode für verschiedene Beispiele (oder Stories). Es ist eine praktische Ressource, um zu verstehen, wie man eine Komponente über Props anpasst.
An diesem Punkt wusste ich, dass <Guide> eine solide Basis für meine Komponente sein würde. Es fehlt jedoch noch ein Element: Wie löst man den Leitfaden per Klick aus? Dafür musste ich mir den Kopf zerbrechen!
Dies ist ein Button mit einem Listener, der das Modal beim Klicken öffnet.
import { useState } from '@wordpress/element';
import { Button } from '@wordpress/components';
import { __ } from '@wordpress/i18n';
import MyGuide from './guide';
const MyGuideWithButton = ( props ) => {
const [ isOpen, setOpen ] = useState( false );
return (
<>
<Button onClick={ () => setOpen( true ) }>
{ __('Open Guide: “Creating Persisted Queries”') }
</Button>
{ isOpen && (
<MyGuide
{ ...props }
onFinish={ () => setOpen( false ) }
/>
) }
</>
);
};
export default MyGuideWithButton;Auch wenn der Blockeditor ihn zu verstecken versucht, wir operieren innerhalb von React. Bis jetzt haben wir uns mit JSX und Komponenten beschäftigt. Aber jetzt brauchen wir den useState Hook, der spezifisch für React ist.
Ich würde sagen, dass ein gutes Verständnis von React erforderlich ist, wenn Sie den WordPress Block Editor meistern wollen. Es gibt keinen Weg daran vorbei.
Schritt 4: Hinzufügen von Inhalten zum Leitfaden
Wir sind fast fertig! Erstellen wir die <Guide>-Komponente, die eine <GuidePage>-Komponente für jede Inhaltsseite enthält.
Der Inhalt kann HTML, andere Komponenten und so weiter verwenden. In diesem speziellen Fall habe ich drei <GuidePage>-Instanzen für meinen CPT nur mit HTML hinzugefügt. Die erste Seite enthält ein Video-Tutorial und die nächsten beiden Seiten enthalten detaillierte Anweisungen.
import { Guide, GuidePage } from '@wordpress/components';
import { __ } from '@wordpress/i18n';
const MyGuide = ( props ) => {
return (
<Guide { ...props } >
<GuidePage>
<video width="640" height="400" controls>
<source src="https://d1c2lqfn9an7pb.cloudfront.net/presentations/graphql-api/videos/graphql-api-creating-persisted-query.mov" type="video/mp4" />
{ __('Your browser does not support the video tag.') }
</video>
// etc.
</GuidePage>
<GuidePage>
// ...
</GuidePage>
<GuidePage>
// ...
</GuidePage>
</Guide>
)
}
export default MyGuide;
Nicht schlecht! Es gibt jedoch ein paar Probleme.
- Ich konnte das Video nicht in den
<Guide>einbetten, da das Klicken auf den Play-Button den Leitfaden schließt. Ich vermute, das liegt daran, dass der<iframe>außerhalb der Grenzen des Leitfadens liegt. Ich habe die Videodatei schließlich auf S3 hochgeladen und sie mit<video>serviert. - Der Seitenübergang im Leitfaden ist nicht sehr flüssig. Das Modal des Blockeditors sieht gut aus, da alle Seiten eine ähnliche Höhe haben, aber der Übergang in diesem ist ziemlich abrupt.
- Der Hover-Effekt auf Buttons könnte verbessert werden. Hoffentlich muss das Gutenberg-Team das für seine eigenen Zwecke beheben, denn meine CSS sind nicht vorhanden. Es ist nicht so, dass meine Fähigkeiten schlecht sind; sie sind nichtexistent.
Aber mit diesen Problemen kann ich leben. Funktional gesehen habe ich erreicht, was ich vom Leitfaden brauche.
Bonus: Dokumente separat öffnen
Für unseren <Guide> haben wir den Inhalt jeder <GuidePage>-Komponente direkt mit HTML erstellt. Wenn dieser HTML-Code jedoch über eine autonome Komponente hinzugefügt wird, kann er für andere Benutzerinteraktionen wiederverwendet werden.
Zum Beispiel zeigt die Komponente <CacheControlDescription> eine Beschreibung zur HTTP-Zwischenspeicherung.
const CacheControlDescription = () => {
return (
<p>The Cache-Control header will contain the minimum max-age value from all fields/directives involved in the request, or "no-store" if the max-age is 0</p>
)
}
export default CacheControlDescription;Diese Komponente kann, wie zuvor, innerhalb einer <GuidePage> hinzugefügt werden, aber auch innerhalb einer <Modal>-Komponente.
import { useState } from '@wordpress/element';
import { Button } from '@wordpress/components';
import { __ } from '@wordpress/i18n';
import CacheControlDescription from './cache-control-desc';
const CacheControlModalWithButton = ( props ) => {
const [ isOpen, setOpen ] = useState( false );
return (
<>
<Button
icon="editor-help"
onClick={ () => setOpen( true ) }
/>
{ isOpen && (
<Modal
{ ...props }
onRequestClose={ () => setOpen( false ) }
>
<CacheControlDescription />
</Modal>
) }
</>
);
};
export default CacheControlModalWithButton;Um eine gute Benutzererfahrung zu bieten, können wir anbieten, die Dokumentation nur anzuzeigen, wenn der Benutzer mit dem Block interagiert. Dazu zeigen oder verbergen wir den Button je nach Wert von isSelected.
import { __ } from '@wordpress/i18n';
import CacheControlModalWithButton from './modal-with-btn';
const CacheControlHeader = ( props ) => {
const { isSelected } = props;
return (
<>
{ __('Cache-Control max-age') }
{ isSelected && (
<CacheControlModalWithButton />
) }
</>
);
}
export default CacheControlHeader;Schließlich wird die Komponente <CacheControlHeader> zur entsprechenden Steuerung hinzugefügt.
Tadaaaaaaaa 🎉
Der WordPress Block Editor ist ein ziemliches Stück Software! Ich konnte damit Dinge erreichen, die ich ohne ihn nicht hätte erreichen können. Die Bereitstellung von Dokumentation für den Benutzer ist vielleicht nicht das Glanzvollste aller Beispiele oder Anwendungsfälle, aber es ist ein sehr praktisches und für viele andere Plugins relevantes. Möchten Sie es für Ihr eigenes Plugin verwenden? Nur zu!
Schauen Sie sich dieses Cloudways-Tutorial für weiterführende Informationen zur Einrichtung benutzerdefinierter Seitenvorlagen an.