Was sind WordPress Block Patterns?

Block Patterns sind Layout-Vorlagen, welche sich mit einem Klick in den WordPress-Editor einfügen lassen. Die Block Patterns bestehen dabei einfach aus einer definierten Liste bzw. Ansammlung von Blocks. Die Blocks sind bereits mit Beispiel-Inhalten wie Texte und Bilder ausgestattet und können als Startpunkt verwendet und angepasst werden. Der Vorteil: Statt ein Seiten-Layout mit mehreren Sektionen mühsam Block für Block manuell aufbauen zu müssen, gibt es nun vorgefertigte Module.

Für den Anfang wird WordPress Core einige Block Patterns bereitstellen. In der deutschen Übersetzung werden diese wahrscheinlich Block-Vorlagen genannt. Themes und Plugins können ebenfalls Block Patterns registrieren. Ich gehe davon aus, dass das Angebot an verfügbaren Block-Vorlagen nach dem Release von Version 5.5 am 11. August sehr schnell ansteigen wird.

Einmal eingefügt, verhalten sich die Blocks aus dem Pattern wie ganz normale Blöcke. Das heißt sie können geändert, ergänzt oder gelöscht werden, ohne dass eine Abhängigkeit zum ursprünglichen Pattern besteht. Auch wenn das Pattern entfernt wird, bleiben die Blöcke erhalten.

WordPress Block Patterns verwenden

Die neuen Block Patterns können mit einem Klick auf das Plus-Icon in der linken, oberen Ecke des WordPress-Editors eingefügt werden. Der neue Block Inserter stellt nun zwei Tabs für einzelne Blocks und Patterns bereit. Mit einem Klick auf eine Vorlage werden die Blocks automatisch am Ende vom Editor eingefügt.

Die derzeitige Umsetzung ist auch mein einziger Kritikpunkt an dem neuen Feature. Die Patterns wurden in den recht kleinen Inserter in der Sidebar gequetscht und leiden spürbar unter dem Platzmangel. Die Block-Vorlagen können zwar in unterschiedliche Kategorien eingeordnet werden, diese werden aber trotzdem untereinander in einer Liste angezeigt. Als Resultat ist das alles sehr unübersichtlich und wird mit vielen Patterns garantiert nicht gut funktionieren. Ich hoffe, dass WordPress 5.6 hier noch nachbessert.

Vier Gründe für Block Patterns in WordPress

Kommen wir nun aber auf die zahlreichen Vorteile von Block Patterns zu sprechen und warum diese eine deutliche Verbesserung für das Gutenberg-Projekt darstellen.

1) Gutenberg wird zum vollwertigen Page-Builder

Der neue Block-Editor wurde ja schon häufig als Page-Builder angepriesen, auch von mir. Die Realität ist aber, dass die bisherigen Features und Funktionen im WordPress Core nicht mit bekannten Plugins wie Elementor, Beaver oder Visual Composer mithalten können.

Eine essentielle Funktion ist das Zurückgreifen auf vorgefertige Layouts, wie es beispielsweise Elementor mit seinen Template Kits oder Divi mit seinen Layout Packs anbietet. Es ist wirklich aufwendig, komplexe Layouts mit vielen verschachtelten Elementen oder mehreren Spalten jedes Mal von Hand neu erstellen zu müssen.

Mit den Block Patterns geht der Gutenberg-Editor einen weiteren, sehr wichtigen Schritt in Richtung Page-Builder. Das Erstellen von statischen Seiten mit mehreren Sektionen und aufwendigerem Layout ist für Nutzer mit Block-Vorlagen deutlich schneller und mit wenigen Klicks umsetzbar. Vorlage auswählen, Content anpassen, fertig.

2) Vereinfachtes Setup und Einrichtung von Themes

Als WordPress Theme Entwickler war es schon immer eine Aufgabe, Usern das Erstellen von komplexen Layouts und ein schnelles Nachbauen der Demo-Website zu ermöglichen. Ausgefeilte Page Templates, Layout-Optionen im Customizer, Widgets, Shortcodes, Custom Post Types – ich habe schon so ziemlich jede Methode gesehen oder selbst verwendet. Optimal war nichts davon.

In jüngster Zeit sind viele Themes dazu übergegangen, den Bereich Layout komplett einem Page-Builder zu überlassen, wurden also gezielt für die Verwendung eines Plugins wie z.B. Elementor ausgerichtet. Aus meiner Sicht auch nicht perfekt, weil es eben zusätzliche Plugins erfordert und Page-Builder häufig schon fast eigenständige CMS mit eigener UI sind und mit WordPress nicht mehr viel zu tun haben. Ein Lock-in Effekt und steile Lernkurve sind oftmals die Folge.

Und dieses Dilemma lösen nun Block Patterns:

• Theme Autoren können aufwendige Designs und Layouts für verschiedene Website-Bereiche für den Nutzer bereitstellen, ohne auf Shortcodes, Widgets, Options-Panels oder externe Plugins zurückgreifen zu müssen.
• Nutzer können komplette Seiten-Layouts als Block-Vorlagen mit einem Klick einfügen und den Content nach ihren Wünschen anpassen. Die Theme-Demo ist in wenigen Sekunden in ihrer WordPress Installation nachgebildet.

Für mich als Theme Developer ein Traum und Grund für diesen sehr euphorischen Post.

3) Komplexe Custom Blocks werden unnötiger

Ich glaube, dass mit Block Patterns viele größere, komplexe Blocks von zusätzlichen Plugins oder Block Collections nicht mehr unbedingt notwendig sind. Viele WordPress Entwickler haben für bestimmte Sektionen eigene Blocks erstellt, unter anderem für Hero Images, Portfolios, Services, Features oder Pricing Blocks.

In Zukunft werden sich viele dieser Blocks auch als Patterns umsetzen lassen, weil sie häufig nur aus Grundelementen wie Spalten, Textabsätzen, Überschriften und Bilder bestehen. Aufgrund der Verschachtelung von Core-Blocks werden Layout-Sektionen aus Patterns wesentlich flexibler und einfacher sein als die Entwicklung von komplexen Blocks mit starren Optionen.

Auch wenn Custom Blocks insgesamt mehr Möglichkeiten bieten, könnte die Kombination von Block Styles und Block Patterns für viele Websites in Zukunft mehr als ausreichend sein, weil sich damit viele individuelle Designs realisieren lassen. Vor allem weil die Core-Blocks auch mit jedem Release weitere Design-Optionen und Einstellungen erhalten.

4) Block-Vorlagen sind einfach zu erstellen

Nicht zu unterschätzen sind auch die technischen Hürden und die Einstiegsbarriere für Entwickler. Eigene Blocks zu entwickeln ist aufgrund von JavaScript und React nicht gerade einfach und wird durch die fehlende Dokumentation und sich ständig ändernde Gutenberg API erschwert.

Block Patterns hingegen sind sehr einfach zu erstellen. Für viele Theme Developer und Webdesigner werden Patterns eine große Spielwiese sein, auf der sie sich austoben und kreativ werden können. Durch den simplen Einstieg in Block Patterns werden wir meiner Meinung nach viel mehr Commit und Begeisterung in der WordPress Community sehen als für bisherige Gutenberg-Features.

Mit WordPress 5.5 noch nicht verfügbar, aber durchaus vorstellbar, wäre auch eine Möglichkeit für jeden User, direkt Block Patterns im Gutenberg Editor zu erstellen und wiederverwenden zu können. Dieses Feature wäre alternativ durch zusätzliche Plugins statt im Core machbar.

WordPress Block Patterns – Ein Game Changer?

Das waren meine Gründe, warum ich mich riesig auf die neuen Block Patterns freue.

Was denkt ihr?

Sind Block Patterns ein nützliches Feature für euch?
Glaubt ihr, der neue Gutenberg Editor startet damit erst richtig durch?
Taugt der Block Editor damit endlich als Alternative zu herkömmlichen Page Builder Plugins?

Schreibt mir einen Kommentar!

Restricted Site Access Plugin

Du kannst Restricted Site Access im offiziellen WordPress.org Verzeichnis herunterladen. Das Plugin wird aktiv gepflegt und weiterentwickelt. Auch im Support-Forum wird auf Fragen und Probleme regelmäßig geantwortet.

Restricted Site Access

• Download

Beschränke den Zugriff auf angemeldete Besucher oder auf einen spezifischen IP-Bereich. Bietet viele Möglichkeiten zur Handhabung von Besuchern ohne Zugriff an.

By 10up

(62)

Last Updated: 2 Monaten ago

20.000+ Active Installs

Compatible up to: 6.9.1

Zugriff auf WordPress Website konfigurieren

Nach Installation des Plugins kannst du den Zugriff auf deine WordPress Installation unter Einstellungen → Lesen in deinem WordPress Backend konfigurieren. Dazu wird die Option für die Sichtbarkeit in Suchmaschinen um eine weitere Checkbox erweitert.

Achtung: Mit Aktivierung des Plugins wird der Zugriff auf die Website für unangemeldete Besucher automatisch limitiert und das Plugin ist aktiv, auch ohne Konfiguration.

In der zweiten Option des Plugins kannst du einstellen, wie sich das Plugin für Besucher ohne Zugriff auf die Website verhalten soll. Du kannst unangemeldete Besucher zum Login-Screen von WordPress senden, auf eine beliebige URL weiterleiten oder eine statische Seite deiner WordPress Installation anzeigen lassen.

Je nach ausgewählter Option öffnen sich weitere Einstellungen, z. B. zur Festlegung der URL und des Statuscodes für die Weiterleitung.

Zugang zu WordPress für bestimmte IP-Adressen oder IP-Bereiche erlauben

Während standardmäßig der Zugriff auf die WordPress Installation nur für angemeldete Besucher erlaubt ist, kannst du auch bestimmte IP-Adressen oder IP-Bereiche für den Zugang freischalten. Nach Angabe einer oder mehrerer IPs können diese Besucher auch ohne Anmeldung die Website ganz normal besuchen.

Damit lassen sich beispielsweise öffentliche Intranets oder Extranets realisieren. Auch für Entwickler kann die Option praktisch sein, um etwa Kunden vorab einen Zugang zum Testen der Website zu geben.

Einschränkungen des Plugins

Wichtig zu beachten ist, dass das Plugin den Zugriff auf die WordPress Installation einschränken kann, aber nicht auf Server-Ebene aktiv ist. Das bedeutet unter anderem, dass hochgeladene Dateien wie Bilder weiterhin über die direkte Datei-URL erreichbar sind, hier wird ja auch WordPress nicht ausgeführt.

Etwas aufpassen muss man auch mit Caching Plugins. Diese speichern häufig die komplette Website als statisches HTML und liefern dieses an ausgeloggte Besucher aus, ohne das WordPress aktiv ist. Hier funktioniert das Plugin demnach nicht, weshalb ich generell kein Caching in Kombination mit dem Plugin verwenden würde.

Auch IP-Adressen können gefälscht werden und somit unbeabsichtigt den Zugang für unerwünschte Personen freigeben. Kurzum: Das Plugin ist ein praktisches Helferlein und nützliches Tool, ich würde damit aber kein Intranet mit hochsensiblen Informationen betreiben.

Falls du deine Website nur temporär für Updates offline schalten willst und keine Feature für den Zugriff von bestimmten IP-Adressen benötigst, empfehle ich stattdessen eines der vielen Plugins, um WordPress in den Wartungsmodus zu setzen.

Social Icons Block

Ein neuer Block für Social Icons erlaubt euch, Links zu all euren sozialen Profilen zu erstellen. Es werden 40 Netzwerke unterstützt und die Icons können nach Belieben angeordnet werden.

Der Block bietet kein Social Sharing Feature. Dafür werden weiterhin zusätzliche Plugins benötigt.

Buttons Block

Der Button-Block wird mit dem Block ButtonS ersetzt. Wie der Name schon sagt, sind damit nun mehrere Buttons möglich. Sehr häufig werden ja zwei Buttons benötigt und bisher ging das nur umständlich mit einem zusätzlichen Spalten-Block. Der neue Buttons-Block schafft hier Abhilfe.

Block Gradients

Ein weiteres neues Feature sind Block Gradients. Damit sind nun als Hintergrund nicht nur einzelne Farben, sondern Farbverläufe (z.B. von grün nach blau) möglich. Theme Entwickler können eine eigene Palette an Gradients bereitstellen.

Im Moment werden Gradients beispielsweise für den Buttons und Cover Block unterstützt. Der Block Gruppe hat das Feature leider noch nicht.

Farbige Wörter im Absatz-Block

Im normalen Textblock können nun auch einzelne Wörter farbig gestaltet werden. Bisher war es nur möglich, die Text- und Hintergrundfarbe des ganzen Absatzes zu ändern. Damit können nun bestimmte Wörter hervorgehoben werden.

Vollbildmodus als Standard

Sehr kontrovers diskutiert wurde die Änderung, den Vollbildmodus (Full Screen Mode) als Standardeinstellung für den neuen Block Editor festzulegen. Beim erstmaligen Aufrufen von Gutenberg wird dieser nun in Full Screen angezeigt, ohne das normale Sidebar-Menü von WordPress.

Die Änderung war vor allem der Wunsch von Matt Mullenweg. Besonders kritisch war, dass diese Neuerung sehr spät und kurz vor dem Release noch mit reingenommen wurde.

Welcome Screen

Bei der erstmaligen Verwendung des Block Editors wird nun ein Willkommens-Popup angezeigt, welche Anwender kurz in alle Features von Gutenberg einführt. Damit soll WordPress Einsteigern das Konzept der Blocks besser nahegebracht werden können.

Sonstige Änderungen in WordPress 5.4

Auch sonst hat sich an vielen anderen Stellen einiges getan:

• Beitragsbilder (Featured Images) können nun per Drag&Drop eingefügt werden
• Tabellen erlauben nun Captions
• Der Embed Block unterstützt nun TikTok
• Der Latest Posts Block kann nun Beitragsbilder anzeigen
• Im Galerie-Block kann nun die Größe für alle Bilder gleichzeitig festgelegt werden
• Die Block Toolbar auf mobilen Geräten wurde verbessert
• Der Spalten-Block enthält nun ebenfalls Farboptionen

Neben neuer Features wurde auch die Performance und Accessibility deutlich verbessert.

Unterschied zwischen Plugin und Core Version

Etwas verwirrend sind die unterschiedlichen Versionen von Gutenberg, welche im Umlauf sind. Sehr häufig liest man nämlich News zu neuen Gutenberg Features des Plugins, welche aber im Core noch gar nicht vorhanden sind. Hier kommt man schnell durcheinander, wenn man das Projekt nicht genauer verfolgt. Deshalb eine kurze Erklärung.

Gutenberg wird auf Github laufend weiterentwickelt. In regelmäßigen Abständen von etwa zwei Wochen wird eine neue Version des Gutenberg Plugins veröffentlicht. Derzeit aktuell ist Version 7.8. Mit dem Plugin erhält man praktisch die neuesten, oft noch experimentiellen Features von Gutenberg. Im Core und ohne Plugin wird eine ältere, stabilere Version verwendet.

In WordPress 5.3 ist momentan Gutenberg Version 6.5 enthalten.

In WordPress 5.4 wird Gutenberg im Core auf Version 7.5 aktualisiert, d.h. es werden die zehn Versionen von 6.6 bis 7.5 nun einfließen. Diese beinhalten alle oben genannten Features.

Fazit

WordPress 5.4 ist ein kleineres Release mit vielen, graduellen Verbesserungen für den Block Editor und bringt Gutenberg auch im Core wieder auf den aktuellen Stand.

Wesentlich spannender beim Thema Gutenberg sind momentan all die Dinge, welche im Hintergrund für Phase 2 passieren. In der nächsten Phase soll Full Site Editing, globale Styles und blockbasierte Themes eingeführt werden. Für diese Themen habe ich aber noch einzelne Beiträge geplant, dass würde an dieser Stelle den Rahmen sprengen. Bis dahin

Ein paar Zahlen zum Blog

Nach einer längeren Schreibpause und vor einem Neustart macht man sich natürlich Gedanken, ob es genauso weitergehen soll oder die Zeit für Veränderungen gekommen ist. Daher erschien es mir ganz sinnvoll, erst einmal den Status Quo zu analysieren.

Hier ein paar Daten und Fakten:

• Launch im September 2016
• 120 veröffentlichte Beiträge
• 558 Kommentare (davon 245 von mir)
• 538 Newsletter Abonnenten
• Derzeit ca. 12.000 Besucher und 18.000 Seitenaufrufe im Monat

Insgesamt bin ich mit der Entwicklung von Theme Coder als kleiner Nischenblog sehr zufrieden. Am meisten freuen mich die zahlreichen Kommentare und Konversationen, die hier schon stattgefunden haben und die hohe Anzahl an Newsletter-Abonnenten, welche anscheinend keinen meiner Beiträge verpassen möchten

Mein Ziel war zum einen, nützliche Tutorials zu verfassen und interessante Plugins vorzustellen, quasi als verlängerten Arm für den Support meiner Theme-Nutzer. Und tatsächlich verlinke ich sehr häufig meine eigenen Artikel in meinen Emails. Zum anderen hoffte ich darauf, den Bekanntheitsgrad von mir und meinen WordPress Themes zu steigern, um den ein oder anderen Neukunden zu gewinnen. Diese Ziele lassen sich weniger mit harten Kennzahlen messen, ich würde diese aber als durchaus erfüllt ansehen. Es ist natürlich immer Luft nach oben da.

Rückblick auf über drei Jahre Theme Coder

Der Blog ist ohne große Planung und Vorbereitung entstanden. Im Endeffekt habe ich die Domain registriert, den Webspace bestellt, eins von meinen Themes installiert und einfach zum Schreiben angefangen. Anfangs habe ich dann viel mit Facebook Ads experimentiert, was die ersten Leser auf den Blog gebracht hat.

Rückblickend war es glaube ich gut, sich auf den deutschsprachigen Raum zu beschränken. Gefühlt haben wir hierzulande nach wie vor wenig Content zu WordPress, sodass es etwas leichter ist auch Leser zu erreichen. Und es war auch mit der Hauptgrund, eine separate Website zu starten und nicht auf ThemeZee.com zu bloggen.

Im Laufe der Zeit kam neuer Content und ein paar neue Kategorien hinzu, ansonsten hat sich hier aber wenig geändert. Der Blog hat bis heute kein eigenes Logo. Das Theme basiert auf meinem eigenen Napoli Theme. Meine Shops sind mit mehreren Custom Post Types, Shop-Plugin und Account-Bereich aufwendig genug, weshalb ich den Blog immer sehr einfach gehalten habe.

Was gut lief

Ein Problem als Blogger ist früher oder später, regelmäßig Zeit und Muse für neuen Content zu finden. Bis zu meiner außerplanmäßigen Pause ist mir das gut gelungen und es ist mindestens ein Artikel pro Monat entstanden. Insgesamt waren es 34 Monate ohne Unterbrechung und ich hoffe, diese Serie jetzt wiederholen und dann ausbauen zu können.

Sehr gut funktioniert haben meine Plugin Reviews. Diese waren mit Abstand die beliebtesten Beiträge, sowohl was Zugriffszahlen als auch Kommentare angeht. Das Angebot an Plugins ist schier unüberschaubar und selbst als erfahrener WordPress Nutzer kennt man nur einen Bruchteil, weshalb diese Beiträge wohl für alle Zielgruppen recht nützlich sind.

In letzter Zeit habe ich vor allem wegen Gutenberg auch viel über allgemeine News und Änderungen im WordPress Core berichtet. Diese Artikel kamen ebenfalls sehr gut bei euch an.

Was weniger gut lief

Der größte Fehler war vielleicht, einfach zu schreiben, ohne einen grundlegenden Content-Plan zu haben. Die mangelnde Struktur zeigt sich in angefangenen und nie zu Ende geschriebenen Artikelserien, versprochenen Beiträgen, die nie erschienen sind und mitunter Artikel zu so speziellen Themen, die für 99% der Leser gar nicht interessant waren.

Viele Tutorials für WordPress Entwickler mit detaillierten Code-Snippets haben sehr viel Aufwand benötigt, wurden aber nur wenig gelesen und kommentiert. Ich weiß nicht, ob es an meinen Artikel-Themen oder der viel kleineren Zielgruppe lag, der Content für Developer wurde aber nur wenig nachgefragt.

Auch neu eingeführte Kategorien wie beispielsweise meine WordPress Business Reports waren wenig durchdacht. Ich hatte vor, monatlich einen Artikel zu schreiben. Es stellte sich jedoch schnell heraus, dass das nicht durchzuhalten war und ich gar nicht soviele Themen dafür hatte.

Änderungen hier im Blog

Die angesprochenen Punkte haben mich zu einigen Änderungen für zukünftige Beiträge veranlasst. Der Fokus wird ab jetzt nur noch auf News, Tutorials und Plugin Reviews zu WordPress liegen. Artikel zu Theme Development, Plugin Entwicklung und technische Gutenberg Tutorials fliegen raus. Diese werden an anderer Stelle erscheinen, dazu weiter unten mehr.

Ebenfalls werden keine weiteren Beiträge mehr in der Kategorie Mein WordPress Business erscheinen, das war hiermit der letzte. Zukünftig werde ich direkt in den Blogs von ThemeZee und GermanThemes berichten, woran ich gerade arbeite. Dort passt es auch thematisch besser.

Theme Coder wird damit mehr zu einem Online Magazin für WordPress werden, statt meinem persönlichen Blog. Die Zielgruppe sind alle WordPress Nutzer und Nutzerinnen, die mit dem CMS arbeiten. Das schließt natürlich auch WordPress Developer mit ein.

Persönlicher Blog in Englisch

Zusätzlich dazu habe ich einen neuen, persönlichen Blog unter netzberufler.de gestartet. Die Domain existiert schon ewig. Den Handle @netzberufler verwende ich in den meisten Profilen wie Twitter, Instagram und Github. Es war praktisch mein Firmenname als Freiberufler, bevor ich meinen WordPress Theme Shop gestartet habe.

Es wird dort vor allem um Software Development gehen, insbesondere natürlich um WordPress und Gutenberg. Der Blog ist englischsprachig und erreicht damit hoffentlich die internationale WordPress Community. Das ist mit ein Grund für die Trennung in zwei Blogs.

WordPress wird aber nicht das einzige Thema bleiben. Ich habe die letzten Monate etwas über den Tellerrand geblickt und mich viel mit JavaScript, React, React Native, Python und Machine Learning befasst. Es gibt tatsächlich viele Dinge neben WordPress, die sehr spannend sind.

Gedanken zu Entrepreurship, Business, Remote Work und Marketing kann ich mir auch gut vorstellen. Kurzum: Ich habe Lust, zu allem möglichen Sachen zu schreiben, wenn mir der Sinn danach steht. Dafür ist ein persönlicher Blog als Spielwiese besser geeignet, und Theme Coder konzentriert sich wieder voll auf WordPress.

Auf die nächsten 3 Jahre

Außerplanmäßige Verletzung

Der Grund für meine unvorgesehene Pause ist ein Sturz auf meine Schulter und eine schwere Schultereckgelenkssprengung, welche mich vor zwei Wochen aus dem Arbeitsleben gerissen hat.

Nach Murphys Law ist als Rechtshänder natürlich auch die rechte Schulter betroffen…

Nach Schulter-OP und kurzem Krankenhausaufenthalt bin ich inzwischen daheim und recht zuversichtlich, dass alles vollständig ausheilt. Es wird aber wohl einige Monate und viel Physiotherapie brauchen, bis ich den Arm wieder komplett bewegen kann.

Ich bin deshalb ein wenig eingeschränkt, werde aber relativ bald wieder gut arbeiten können. Das Tippen auf einer Tastatur ist zum Glück nicht sehr belastend für die Schulter. Trotzdem habe ich beschlossen, etwas kürzer zu treten und meine Aufgaben neu zu sortieren.

Theme Coder geht in die Sommerpause

Mit meinen mittlerweile zwei Theme Shops und WordPress Blog ist meine ToDo-List sehr vollgepackt und es blieb auch vor der Verletzung schon fast zu wenig Zeit, alle Projekte gleichermaßen voranzutreiben. Als Invalide wird das natürlich nicht besser.

Momentan befinden wir uns mit Gutenberg in einer Umbruchphase, weshalb mein Theme Business die volle Aufmerksamkeit benötigt. Die Umstellung auf WordPress Blocks hat eine höhere Priorität als das Bloggen und ich möchte mich daher stärker darauf konzentrieren.

Ich habe deshalb entschieden, den Blog komplett auf Eis zu legen. Die nächsten Monate werden daher keine neuen Beiträge erscheinen. Irgendwann hoffe ich natürlich auf einen Neustart.

Zum Start der Serie und ersten Teil geht es hier.

Die RichText-Komponente im Überblick

Im derzeitigen Stand unseres WordPress Blocks wird Titel und Beschreibung statisch ausgegeben:

<h2>Titel des Blocks</h2>
<p>Beschreibung des Blocks.</p>

Diese zwei Felder wollen wir in Teil 4 für den Nutzer editierbar machen, sodass Titel und Beschreibung direkt im Block eingegeben werden können. Eingabe- bzw Textfelder im Block können wir mit der RichText-Komponente des Gutenberg Editors realisieren, welche wir vom Package wp.editor erhalten.

const { RichText } = wp.editor;

Die RichText-Komponente kann im JSX-Code des Return-Statements der Edit-Funktion gerendert werden und gibt dann ein editierbares Feld mit dem HTML-Attribut contenteditable aus.

<RichText
	tagName="p"
	value={ variable }
	className="css-class"
	onChange={ changeFunction }
	placeholder={ __( 'Placeholder Text', 'themecoder-block' ) }
/>

Die Komponente nimmt mehrere Properties entgegen. Zwingend erforderlich ist value für den aktuellen Wert bzw. Inhalt des Textfelds und onChange, mit der eine Funktion übergeben wird, welche bei Änderung des Texts im Eingabefeld für die Speicherung des Inhalts zuständig ist.

Optional können eine Reihe weiterer Properties definiert werden, unter anderem HTML-Tag (p, h2, div), CSS-Klasse und Platzhalter. Eine komplette Liste der Props findest du im Github-Repo.

Block-Attribute für Textfelder hinzufügen

Bevor wir die RichText-Komponente im Block einbauen, legen wir zuerst zwei neue Attribute für Titel und Beschreibung an. Diese werden im Objekt attributes in den Block Settings definiert.

/**
 * Register block
 */
registerBlockType(
	'themecoder-block/image-card',
	{
		title: __( 'Image Card', 'themecoder-block' ),

		category: 'layout',

		attributes: {
			title: {
				type: 'string',
				source: 'html',
				selector: '.tc-title',
			},
			description: {
				type: 'string',
				source: 'html',
				selector: '.tc-description',
			},
		},

		// Edit-Function + Save Function
	}
);

Unsere Textfelder werden direkt im HTML-Markup des Blocks gespeichert. Wir geben daher für die dazugehörigen Attribute den Typ type als string und die Quelle source als html an. Mit selector legen wir fest, wo genau im HTML-Markup unsere Attribute zu finden sind.

Wichtig zu wissen: Grundlagen zu Block-Attributen

1) Block-Attribute sind ein zentraler Bestandteil jedes WordPress Blocks und repräsentieren und strukturieren alle Daten (Inhalt, Optionen, Styling) im Block.

2) Blocks werden nicht einzeln in der WordPress Datenbank gespeichert, sondern landen als HTML-Markup mit allen anderen Blöcken eines Posts als post_content in der Tabelle wp_posts.

3) Blocks werden anhand HTML-Kommentare voneinander abgegrenzt. Beim Aufruf des Gutenberg Editors werden so aus dem ganzen HTML wieder einzelne Blocks generiert.

4) Der Gutenberg Editor extrahiert mit Hilfe der definierten Block-Attribute und deren Selektoren die Variablen wieder aus dem HTML-Code und speichert sie in einem Object-Tree.

5) Falls Attribute keinen Selektor aufweisen, werden sie statt im Markup im HTML-Kommentar des jeweiligen Blocks gespeichert.

Beispiel:

<!-- wp:paragraph {"align":"center"} -->
<p style="text-align:center">Beispiel-Text</p>
<!-- /wp:paragraph -->

Mit obigen HTML-Code wird ein Absatz-Block dargestellt, erkennbar an dem Block-Kommentar <!-- wp:paragraph -->. Es sind ebenfalls zwei Attribute gespeichert. Als Erstes der Inhalt mit dem Selektor p im Markup, als Zweites die Textausrichtung align: center im Kommentar.

RichText-Komponente in Edit-Funktion einbauen

Nach Registrierung der Attribute können wir die RichText-Komponente nun in der Edit-Funktion des Blocks einbauen. Wir ändern dazu den bisherigen Code wie folgt ab:

edit( props ) {
	const {
		attributes,
		className,
		setAttributes,
	} = props;

	function changeTitle( newTitle ) {
		setAttributes( { title: newTitle } );
	}

	function changeDescription( newDescription ) {
		setAttributes( { description: newDescription } );
	}

	return (
		<div className={ className }>
			<div className="tc-columns">

				<div className="tc-image">

				</div>

				<div className="tc-card">

					<RichText
						tagName="h2"
						value={ attributes.title }
						className="tc-title"
						onChange={ changeTitle }
						placeholder={ __( 'Add a title…', 'gt-blocks' ) }
						keepPlaceholderOnFocus
					/>

					<RichText
						tagName="p"
						value={ attributes.description }
						className="tc-description"
						onChange={ changeDescription }
						placeholder={ __( 'Write a description…', 'gt-blocks' ) }
						keepPlaceholderOnFocus
					/>

				</div>

			</div>
		</div>
	);
},

Okay, schauen wir uns die Funktion Zeile für Zeile genauer an.

Am Anfang nutzen wir wieder Object Destructuring zur Extraktion einiger Variablen aus den props unseres Blocks. Für unsere Eingabefelder benötigen wir nun zusätzlich das Objekt attributes und die Funktion setAttributes, mit der Attribute geändert werden können.

Anschließend definieren wir zwei Funktionen changeTitle() und changeDescription(), welche für die Änderung der jeweiligen Block-Attribute title und description zuständig sind, sobald der Nutzer den Inhalt im Eingabefeld manipuliert.

Als letzte Änderung ersetzen wir unseren statischen Titel und Beschreibung mit zwei RichText-Komponenten. Als value übergeben wir unsere Block-Attribute, mit onChange unsere Funktionen. Für den Titel nutzen wir h2 als tagName, für die Beschreibung p.

Der obige Code funktioniert, mit etwas ES6-Magie können wir die Syntax aber noch etwas reduzieren. Statt für jedes Textfeld umständlich eine eigene Funktion anzulegen, nutzen wir eine Arrow-Function direkt in der RichText-Komponente, um setAttributes aufzurufen.

<RichText
	tagName="h2"
	value={ title }
	className="tc-title"
	onChange={ ( value ) => setAttributes( { title: value } ) }
	placeholder={ __( 'Add a title…', 'gt-blocks' ) }
	keepPlaceholderOnFocus
/>

<RichText
	tagName="p"
	value={ description }
	className="tc-description"
	onChange={ ( value ) => setAttributes( { description: value } ) }
	placeholder={ __( 'Write a description…', 'gt-blocks' ) }
	keepPlaceholderOnFocus
/>

Die Funktionen changeTitle() und changeDescription() sind damit nicht mehr notwendig.

Anpassung der Save-Funktion mit RichText.Content

Schlussendlich muss der Inhalt unserer Eingabefelder auch noch im Frontend mit der Save-Funktion ausgegeben werden. Wir nutzen dafür ebenfalls die RichText-Komponente; die Ausgabe erfolgt hier aber mit RichText.Content. Das Attribut wird wie vorhin als value übergeben.

save( { attributes } ) {
	const {
		title,
		description,
	} = attributes;

	return (
		<div>
			<div className="tc-columns">

				<div className="tc-image">

				</div>

				<div className="tc-card">

					<RichText.Content
						tagName="h2"
						className="tc-title"
						value={ title }
					/>

					<RichText.Content
						tagName="p"
						className="tc-description"
						value={ description }
					/>

				</div>

			</div>
		</div>
	);
},

Sehr wichtig ist die Angabe der CSS-Klasse mit className, welcher mit dem selector-Wert des Attributs übereinstimmen muss. Passen die CSS-Klassen nicht zu den definierten Selektoren der Block-Attribute, können die Attribute nicht mehr aus dem HTML-Code herausgefiltert werden.

Invalidation Error im Gutenberg Editor

Nach Änderung der Save-Funktion werdet ihr diesen Fehler im Gutenberg Editor sehen:

Der Invalidation Error tritt immer dann auf, wenn das gespeicherte HTML-Markup des Blocks nicht zum definierten Markup in der Save-Funktion passt. Diese Fehlermeldung wirst du bei der Entwicklung von Custom Blocks deshalb häufig sehen, nämlich immer dann wenn du die Save-Funktion modifiziert.

Für den Nutzer sollte dieser Fehler natürlich nie auftauchen, weshalb bei Updates des Block-Markups extra Vorkehrungen getroffen werden müssen, um Blocks ohne Fehler zu aktualisieren. Das ist aber genug Thema für einen eigenständigen Artikel.

Ergebnis und Ausblick auf Teil 5

Und das wars auch schon mit dem vierten Teil. Der Block sieht nahezu gleich aus, Titel und Beschreibung lassen sich nun aber vom Nutzer selbst eingeben. Nach dem Hinzufügen des Blocks werden die Platzhalter angezeigt:

Du findest den kompletten Beispiel-Code für unseren Block in diesem Github-Repo: https://github.com/Netzberufler/themecoder-block

Im nächsten Teil werden wir uns mit der Erstellung von Toolbar- und Sidebar-Optionen beschäftigen, um das Styling und Layout des Blocks anpassen zu können.

Überblick über alle Beiträge dieser Serie

Site Health Check / Website-Zustand

WordPress 5.2 wird ein neues Tool namens Site Health Check enthalten. In der deutschen Lokalisierung von WordPress wird es mit Zustand der Website übersetzt und ist fortan im WordPress Backend unter Werkzeuge → Website-Zustand zu finden.

Das neue Tool soll vor allem Endnutzern dabei helfen, häufig auftretende Konfigurationsfehler leichter aufzuspüren und die eigene Website auf allgemeine Probleme analysieren zu können. Für Entwickler schafft es eine standardisierte Methode, um Debugging-Information hinzuzufügen.

Im ersten Tab Status werden eine Reihe von Tests für die WordPress Installation durchlaufen, welche dann je nach Ergebnis als bestandener Test, kritisches Problem oder empfohlene Verbesserung kategorisiert werden. Jeder Test kann ausgeklappt werden und gibt so weitere Informationen, warum etwas wichtig ist und wie das Problem behoben werden kann.

WordPress Entwickler können mit neuen Filter Hooks eigene Tests hinzufügen und entfernen, sodass der Statusbericht flexibel angepasst werden kann. Der Ankündigungs-Post auf make.wordpress.org liefert dafür einige Code-Beispiele.

Ganz oben wird auch eine Prozentzahl angezeigt, welche den Zustand der Website auf einer Skala von 0 bis 100% wiedergibt. Kritische Probleme werden strenger gewichtet als Empfehlungen. Einige Entwickler kritisieren diese Skala bereits, weil diese wenig aussagekräftig ist und bei Nutzern sowohl zu Panik als auch falscher Sicherheit führen kann. Du kannst die Diskussion darüber in den Kommentaren im oben verlinkten Beitrag sehen.

Im zweiten Tab Info / Bericht werden ganz klassisch Debugging-Informationen angezeigt. Der Bericht enthält zahlreiche Infos über Website- und Serverkonfiguration unterteilt in mehrere Sektionen und kann mit einem Klick in die Zwischenablage kopiert werden.

Themes und Plugins können auch hier eigene Einträge hinzufügen.

Recovery Mode zum Schutz vor White Screen of Death

Mit WordPress 5.2 wird ebenfalls ein Recovery Mode für Fatal Errors in PHP eingeführt. Damit können Website-Administratoren nun selbständig einen PHP Fehlermeldung reparieren oder abstellen, ohne dass ein Webentwickler eingreifen und der Code geändert werden muss.

Ein Syntaxfehler in einem Theme oder Plugin führte häufig zu einem komplett weißen Screen (White Screen of Death), ohne Anhaltspunkte für den Nutzer, was schief gelaufen ist. Ist auch das WordPress Backend betroffen, blieb oft nur der umständliche Weg über FTP, um das fehlerhaften Code von der Website zu entfernen.

WordPress 5.2 wird die Wiederherstellung der Website nun wesentlich einfacher machen. Falls ein PHP Fehler auftaucht, wird der Administrator per E-Mail informiert. In der E-Mail befindet sich ein Link, mit dem der Nutzer den neuen Recovery Mode starten kann.

Im Recovery Mode werden die Themes und Plugins mit PHP Fehlern automatisch ausgeschaltet. Der Nutzer kann so den Code reparieren oder die Plugins dauerhaft deaktivieren.

Der Recovery Mode wird nur für den jeweiligen Nutzer aktiviert und betrifft nicht den Rest der Website. Dort sind weiterhin alle Plugins aktiv. Besucher der Website sehen bei einem PHP Fehler jetzt aber einen Hinweistext über technische Schwierigkeiten, statt einen weißen Screen.

WordPress 5.2 beinhaltet Gutenberg Version 5.4

Die Entwicklung des Block Editors schreitet stetig voran. Etwa alle zwei Wochen wird eine neue Version des Gutenberg Plugins mit neuen Features und Bugfixes veröffentlicht.

In der aktuellen Version 5.1 von WordPress ist Gutenberg 4.8 enthalten. Das Update von WordPress 5.2 wird Gutenberg zur Version 5.4 bringen, also bekommen wir nun Features aus sechs Gutenberg Releases im Core hinzu. Alle Gutenberg Versionen ab 5.5 inklusive dem neuen Group-Block werden erst mit WordPress 5.3 im Core verfügbar sein.

Mit WordPress 5.2 erhalten wir neue Blocks für RSS und Amazon Kindle Embeds. Bestehende Blocks, unter anderem Cover, Spalten und Tabellen, wurden mit zusätzlichen Optionen und Block Styles verbessert. Außerdem können nicht benötigte Blocks nun mit einem neuen Block-Manager deaktiviert werden, ohne dass zusätzliche Plugins dafür notwendig wären.

Neben zahlreichen Bugfixes wurde auch ordentlich an der Performance geschraubt. Mit WordPress 5.2 sollte sich der Block Editor nun deutlich schneller und flüssiger anfühlen.

Sonstiges in WordPress 5.2

Die neue WordPress Version enthält natürlich auch einige neue Funktionen für Entwickler, unter anderem den neuen wp_body_open Theme Hook. Ebenfalls wurden etliche Updates für Verbesserungen in Accessibility und Privacy vorgenommen.

Eine komplette Übersicht aller Änderungen liefert der WordPress 5.2 Field Guide.

Meiner Meinung nach bringt die neue Version von WordPress einige sehr sinnvolle neue Features mit sich. Insgesamt ein sehr gelungenes Update.

Was haltet ihr von den Neuerungen in WordPress 5.2?

Zum Start der Serie und ersten Teil geht es hier.

Dateien für neuen WordPress Block anlegen

Nachdem wir im zweiten Teil unser Plugin mit dem Create Guten Block Toolkit erstellt haben, können wir nun mit der Entwicklung unseres Beispiels – einem Image Card Block – starten.

Wir legen dazu einen neuen Ordner /image-card im Source-Verzeichnis an. Darin erstellen wir zwei neue und leere Dateien: index.js und style.css. Wir fangen praktisch bei Null an, weshalb du den bestehenden Example-Block des CGB-Toolkits löschen kannst.

Das src-Verzeichnis sollte nun folgende Struktur aufweisen:

├── src
|   ├── image-card
|   |   ├── index.js
|   |   └── style.scss
|   |
|   ├── blocks.js
|   ├── common.scss
|   └── init.php

Anschließend öffnen wir die Datei /src/blocks.js und importieren unseren neuen Block:

import './image-card/index.js';

Damit wird die neu erstellte index.js von Webpack eingelesen und wir können dort unseren neuen WordPress Block registrieren und entwickeln. Falls dein Plugin weitere Blocks enthalten soll, kannst du im src-Verzeichnis auch einfach weitere Ordner für zusätzliche Blocks erstellen.

Die Funktion registerBlockType im Überblick

Jeder Block wird mit der Funktion registerBlockType() im Editor registriert. Die Funktion wird uns vom Package wp-blocks bereitgestellt und nimmt zwei Parameter entgegen:

• name string: Block Name.
• settings Object: Block Settings.

registerBlockType( 'my-plugin/block-name', {} );

Als Erstes muss ein eindeutiger String übergeben werden, welcher den Block identifiziert. Dazu wird der Name üblicherweise mit namespace/block-name strukturiert und als Namespace der Slug des WordPress Plugins verwendet. In unserem Fall folglich themecoder-block/image-card.

Wesentlich interessanter ist das Configuration bzw. Settings Object, welches als zweites Argument übergeben wird. In diesem Objekt definieren wir alle Eigenschaften und Funktionen, welche unseren Block auszeichnen und funktionsfähig machen.

Die wichtigsten Properties für die Block Settings sind:

• title string: Der angezeigte Name des Blocks im Editor.
• category string: Zu welcher Kategorie im Block Inserter gehört der Block.
• attributes Object: Deklarierung aller Daten bzw. Variablen des Blocks.
• edit function: Beschreibt, wie der Block im Editor gerendert und dargestellt wird.
• save function: Beschreibt, wie der Block im Frontend dargestellt wird.

Für das Settings Object bestehen natürlich noch eine Menge anderer Properties, mit denen wir uns noch eingehender beschäftigen werden.

Wichtig an dieser Stelle ist zu wissen, dass mit dem Settings Object unser kompletter Block definiert wird. Das Objekt enthält alle Eigenschaften, Attribute und Funktionen des Blocks und wird als zweiter Parameter an registerBlockType() übergeben.

Image Card WordPress Block registrieren

Genug der Theorie. Es ist an der Zeit, etwas Code zu schreiben und unseren Block zu erstellen.

Du kannst dazu folgenden Code in der Datei /src/image-card/index.js einfügen:

/**
 * Register block
 */
wp.blocks.registerBlockType( 'themecoder-block/image-card',
	{
		title: wp.i18n.__( 'Image Card', 'themecoder-block' ),

		category: 'layout',

		edit() {
			return (
				<div>Block Content im Editor</div>
			);
		},

		save() {
			return (
				<div>Block Content im Frontend</div>
			);
		},
	}
);

Wir registrieren unseren Block mit wp.blocks.registerBlockType() und definieren in unseren Settings einen Titel, eine Kategorie und die Edit- und Save-Funktionen. Diese geben kein HTML, sondern JSX zurück, weshalb hier keine Anführungszeichen für Strings notwendig sind.

Und das wars auch schon.

Du solltest nun im Block Inserter den Image Card Block finden und einfügen können:

Tipp: Stelle sicher, dass du Webpack mit npm start angestoßen hast, falls der Block fehlt.

Die WordPress Packages im Gutenberg Editor

WordPress Core stellt uns seit Version 5.0 eine Reihe von Packages zur Entwicklung von Blocks zur Verfügung. Diese sind inzwischen auch als NPM-Packages verfügbar, z.B. @wordpress/blocks.

Für die Entwicklung von Blocks müssen wir diese aber nicht als externe Node-Module installieren. Der Gutenberg Editor stellt uns nämlich freundlicherweise (fast) alle Packages in der globalen Variable wp bereit, welche als riesiges Objekt alle Komponenten und Funktionen enthält.

Die wichtigsten Packages für unsere Zwecke sind:

• wp.element – Abstraction Layer von WordPress für React und ReactDOM.
• wp.blocks – Hauptsächlich Funktionen zum Erstellen und Manipulieren von Blocks.
• wp.components – Allgemeine Komponenten für häufig vorkommende UI-Elemente.
• wp.editor – Spezifischere Komponenten für UI-Elemente im Gutenberg Editor.
• wp.i18n – Enthält alle Lokalisierungsfunktionen für die Übersetzung von Textstrings.
• wp.data – Funktionen, um mit den Redux Data Stores von WordPress zu interagieren.

Das Tippen des kompletten Pfads zu einer Funktion (z.B. wp.blocks.registerBlockType) wäre auf Dauer etwas mühsam, weshalb wir uns ein ES6-Feature names Destructuring zu Nutze machen. Mit dem Object Destructuring der WP Packages extrahieren wir nur die gerade benötigten Funktionen aus dem globalen wp-Objekt und machen diese als Variablen zugänglich.

Wir können unseren obigen Code dementsprechend etwas anpassen und klarer gestalten:

/**
 * WordPress dependencies
 */
const { registerBlockType } = wp.blocks;
const { __ } = wp.i18n;

/**
 * Register block
 */
registerBlockType( 'themecoder-block/image-card',
	{
		title: __( 'Image Card', 'themecoder-block' ),

		category: 'layout',

		edit() {
			return (
				<div>Block Content im Editor</div>
			);
		},

		save() {
			return (
				<div>Block Content im Frontend</div>
			);
		},
	}
);

Destructuring begegnet uns sehr häufig bei der Entwicklung mit React und Gutenberg Blocks. Falls du mit modernen JavaScript noch nicht vertraut bist, empfehle ich, den Begriff zu googeln und einige Tutorials zu lesen, beispielsweise dem Destructuring Guide von codeburst.

HTML-Markup für Image Card Block erstellen

Nachdem wir unseren Block im Editor registriert haben, können wir nun das HTML-Grundgerüst für unsere Image Card erstellen. Der Block soll später Bild und Text in zwei Spalten anzeigen, weshalb wir einige div-Elemente für diese Struktur erstellen.

Dabei solltest du beachten, dass wir hier weiterhin JSX und nicht HTML schreiben, was zu einigen Unterschieden führt. Der Begriff class ist in JavaScript registriert für Klassen, weshalb in JSX auf className zurückgegriffen wird, um das Klassen-Attribut in HTML-Elementen auszuweisen.

Wir beginnen mit der Änderung der Save-Funktion unseres WordPress Blocks:

save() {
	return (
		<div>
			<div className="tc-columns">

				<div className="tc-image">

				</div>

				<div className="tc-card">

					<h2>Titel des Blocks</h2>
					<p>Beschreibung des Blocks.</p>

				</div>

			</div>
		</div>
	);
},

Das erste Div-Element ist unser Block-Wrapper. Für die Save-Funktion wird automatisch die CSS-Klasse des Blocks eingefügt, sodass wir als Entwickler darauf verzichten können. Die Klasse wird aus dem Prefix wp-block, dem Namespace und Name des Blocks generiert. In unserem Fall lautet der vollständige Name also wp-block-themecoder-block-image-card.

In der Edit-Funktion für das Rendern des Blocks im Editor wird die CSS Klasse nicht automatisch hinzugefügt. Aus diesem Grund fügen wir diese manuell ein. Wir bekommen die Klasse mit der Variable className aus dem props-Argument. Wir nutzen dafür wieder Destructuring.

edit( props ) {
	const { className } = props;

	return (
		<div className={ className }>
			<div className="tc-columns">

				<div className="tc-image">

				</div>

				<div className="tc-card">

					<h2>Titel des Blocks</h2>
					<p>Beschreibung des Blocks.</p>

				</div>

			</div>
		</div>
	);
},

Wie in Teil 1 bereits kurz erwähnt, setzt React auf Komponenten, welche ineinander verschachtelt werden. Dabei können Input-Variablen von der Parent Component zu Child Komponenten in Form des props-Arguments übergeben werden. Props steht für Properties und ist ein Objekt, dass beliebig viele Variablen enthalten kann.

Auch WordPress Blocks weisen ein props-Objekt auf, welches als Parameter für die Save- und Edit-Funktion eines Blocks zur Verfügung steht. Du kannst zum Test in der Edit-Funktion die props mit console.log( props ) in der Browser-Konsole ausgeben lassen, um einen Überblick über alle props des Blocks zu erhalten. Du solltest ein Objekt mit ähnlichen Variablen erhalten:

props: {
	attributes: {},
	className: "wp-block-themecoder-block-image-card",
	clientId: "6b0366da-11af-45f2-9af0-4080415e5eed",
	isSelected: false,
	name: "themecoder-block/image-card",
	[...]
}

Für die Entwicklung von Custom Blocks werden wir später sehr häufig die Property attributes benötigen, in der alle Daten und Optionen des Blocks gespeichert werden. Momentan ist das Objekt noch leer, weil wir noch keine Block Attribute definiert haben.

Styling für WordPress Block hinzufügen

Als letzten Schritt für heute fügen wir nun noch etwas Styling für unseren WordPress Block hinzu. Dazu importieren wir erst einmal unsere style.scss, und zwar ausgehend von der index.js unseres Blocks. Du kannst den Code über der Funktion registerBlockType() einfügen:

/**
 * Internal dependencies
 */
import './style.scss';

In der style.scss können wir unseren WordPress Block nun stylen. Für unsere Zwecke reichen ein paar Abstände und etwas Schlagschatten. Das zweispaltige Layout realisieren wir mit Flexbox.

.wp-block-themecoder-block-image-card {
	margin-bottom: 1.5em;
	box-shadow: 0 0 10px #ccc;

	.tc-columns {
		display: flex;

		.tc-image {
			width: 50%;
			background: #eee;
		}

		.tc-card {
			width: 50%;
			padding: 4em 2em;

			h2 {
				margin-top: 0;
			}

			p {
				margin-bottom: 0;
			}
		}
	}
}

Damit es überschaubar für das Tutorial bleibt, verzichten wir auf Responsive Design, d.h. der Block bleibt auch auf kleineren Screens zweispaltig.

Ergebnis und Ausblick auf Teil 4

Als Ergebnis solltest du nun diesen Block erhalten, der natürlich noch vollkommen statisch ist.

Du findest den kompletten Code unseres WordPress Blocks auf Github und kannst das Repo auch von dort klonen und installieren. Ich werde für jeden Teil des Tutorials den aktuellen Stand als neuen Block veröffentlichen, sodass du alle Schritte jederzeit nachverfolgen kannst.

Repo: https://github.com/Netzberufler/themecoder-block

Im nächsten Teil werden wir mit der RichText-Komponente Eingabefelder hinzufügen, um den  Titel und die Beschreibung des Blocks editierbar zu machen. Danach geht es weiter mit Medien-Upload sowie Toolbar- und Sidebar-Optionen für den Block.

Überblick über alle Beiträge dieser Serie

WP Migrate DB exportiert deine Datenbank als MySQL-Dump, findet und ersetzt alle URLs und Dateipfade und ermöglicht dann, die Datenbank als SQL-Datei auf dem Computer zu speichern. Um die Migration abzuschließen, kannst du anschließend die SQL-Datei mit z.B. phpMyAdmin auf der Ziel-Website importieren, um dort die bestehende Datenbank zu ersetzen.

WP Migrate DB

Du findest die Basis-Version des Plugins kostenlos im WordPress Plugin Verzeichnis. Es existiert auch eine Pro-Version mit mehr Features, dazu aber später mehr. WP Migrate DB stammt vom Entwickler-Studio Delicious Brains und ist derzeit auf 300.000 Websites aktiv.

WP Migrate Lite – Migration Made Easy

• Download

Migrate your database. Export full sites including media, themes, and plugins. Find and replace content with support for serialized data.

By WP Engine

(311)

Last Updated: 3 Monaten ago

200.000+ Active Installs

Compatible up to: 6.9.1

Im Gegensatz zu dem im Core enthaltenen WordPress Importer erlaubt es die Migration der kompletten WordPress Datenbank, d.h. es werden nicht nur deine Inhalte wie Beiträge und statische Seiten, sondern auch alle Core-, Theme- und Plugin-Optionen mit eingeschlossen.

WordPress Datenbank exportieren

Du findest die Einstellungen des Plugins unter Werkzeuge → Migrate DB in deinem WordPress Backend. Die Hauptfunktion Export File ist bereits ausgewählt und erlaubt dir den Download einer komprimierten gzip-Datei deiner Datenbank.

Neben dem Exportieren einer SQL-Datei kannst du mit der kostenlosen Version auch Inhalte in der Datenbank der Website suchen und ersetzen. Für diese Aufgabe würde ich wegen des besseren Feature-Sets aber das Plugin Search & Replace empfehlen.

In den Optionen für Find & Replace kannst du die URL deiner Website und falls notwendig den Dateipfad des wp-content-Verzeichnisses beim Exportieren automatisch ersetzen lassen. Meistens reicht die URL für die Ziel-Website. In den Advanced Options kannst du bestimmte Inhalte wie Spam-Kommentare, Revisionen und Transients vom Export ausschließen.

Schlussendlich besteht noch die Option, deine Einstellungen als Migrations-Profil zu speichern. Damit kannst du die gleiche Migration ohne erneute Konfiguration zu einem späteren Zeitpunkt erneut durchführen. Mit einem Klick auf Export & Save wird der Export ausgeführt und die SQL-Datei nach Fertigstellung zum Download angeboten.

Im Gegensatz zu einem Datenbank-Backup mit einem WordPress Backup Plugin oder einem MySQL-Dump mit phpMyAdmin ist die exportierte SQL-Datei von WP Migrate DB direkt für einen Import vorbereitet, weil alle URLs und Dateipfade bereits für die Ziel-Website angepasst und geändert wurden.

WordPress Datenbank umziehen mit SQL-Import

Als finalen Schritt kannst du die exportierte SQL-Datei nun auf der Ziel-Website importieren. In den meisten Fällen solltest du Zugang zu einem Datenbank-Management-Tool haben, mit dem du den Import der Datenbank mit einer Weboberfläche durchführen kannst.

Webhosting-Anbieter geben dir in der Regel einen Zugang zur Datenbank mit Tools wie Adminer oder phpMyAdmin. Von dort ist ein Import der SQL-Datei möglich.

Die SQL-Datei von WP Migrate DB enthält DROP TABLE Befehle, d.h. deine bestehenden WordPress Tabellen werden komplett gelöscht und durch die neu importierten Tabellen ersetzt. Wie immer bei solch kritischen Tätigkeiten empfehle ich unbedingt, im Vorfeld für ausreichende Backups aller Daten zu sorgen – just in case.

Mehr Features mit WP Migrate DB Pro

Für das kostenlose WordPress Plugin gibt es auch eine Pro-Version, welche eine Reihe von Add-ons und zusätzlicher Features bietet.

Unter anderem ist damit auch der Import von exportierten SQL-Dateien möglich, sodass externe Werkzeuge wie phpMyAdmin überflüssig sind und du alles direkt im WordPress Backend erledigen kannst. Mit den Funktionen für Push und Pull ist auch eine einfache Synchronisation von Staging- und Live-Server möglich, ohne dass mit SQL-Dateien hantiert werden muss.

Die Add-ons von WP Migrate DB Pro ermöglichen den Abgleich von Theme-, Plugin- und Media-Dateien zwischen zwei WordPress Installationen, besseren Support für WordPress Multisites und eine Integration mit WP-CLI, dem Kommandozeilen-Tool von WordPress.

Fazit

Ich verwende WP Migrate DB eher selten, aber es hat immer hervorragend funktioniert, wenn ich Bedarf für eine Migration der Datenbank hatte. Das Plugin zeichnet sich durch seinen Fokus auf einen bestimmten Zweck und sehr gute Usability aus. Und das Wichtigste: Es läuft zuverlässig ohne zu crashen und hat keine Probleme mit komplexen und großen Datenbanken.

Zum Start der Serie und ersten Teil geht es hier.

WordPress Block entwickeln mit create-guten-block

Die Konfiguration von Webpack, Babel und Co. ist anfangs ziemlich verwirrend und kompliziert. Für Entwickler lohnt es sich aber, sich etwas damit zu beschäftigen. Wer sich näher damit auseinandersetzen möchte, dem kann ich folgende zwei Tutorials ans Herz legen:

• KrautPress: Einrichtung von Webpack für die Gutenberg-Entwicklung
• Getting Started with Block Development in ES.Next

Für dieses Tutorial wählen wir den einfachen und schnellen Weg und setzen Create Guten Block von Ahmad Awais ein. Dabei handelt es sich um ein Zero Configuration Dev-Toolkit für WordPress Gutenberg Blocks, sodass wir React, Webpack und Babel nicht selbst konfigurieren müssen.

WordPress Block Plugin erstellen

Für die Verwendung des Tools solltest du Node.js installiert haben und bereits mit NPM vertraut sein. Außerdem brauchst du einen lokalen Server mit einer WordPress Installation.

Die Installation erfolgt über die Kommandozeile. Begebe dich dazu als Erstes in das Plugin-Verzeichnis deiner lokalen WordPress Website.

cd wp-content/plugins

Anschließend kannst du dein Block Plugin mit dem Befehl npx create-guten-block erstellen. Dem Kommando wird außerdem der Name für das WordPress Plugin übergeben. Du kannst einen beliebigen Namen wählen. Für unser Tutorial verwenden wir themecoder-block.

npx create-guten-block themecoder-block

Das Tool legt für uns den Plugin-Ordner an und installiert alle benötigten Node Module.

Die Installation kann deshalb einige Minuten in Anspruch nehmen.

WordPress Block Plugin aktivieren

Nach Abschluss der Installation kannst du das Plugin in deinem WordPress Backend aktivieren.

Das Toolkit beinhaltet einen Dummy-Block als Boilerplate. Im Gutenberg Editor kannst du nach CGB Block suchen, um diesen einzufügen. Der Block zeigt nur etwas Text, ohne Eingabefelder oder Optionen. Wir werden später den Namen ändern und den Block editierbar machen.

Fürs Erste wissen wir nun, dass die Installation ordnungsgemäß funktioniert hat.

Struktur des WordPress Block Plugins

Für die nächsten Schritte benötigst du einen Editor, z.B. VS Code.

Wir sehen uns damit die Dateien des Block Plugins genauer an. Wenn du den Plugin-Ordner themecoder-block öffnest, findest du dort folgende Ordner und Dateien:

├── dist
|   ├── blocks.build.js
|   ├── blocks.editor.build.css
|   └── blocks.style.build.css
|
├── node_modules
|
├── src
|   ├── block
|   |   ├── block.js
|   |   ├── editor.scss
|   |   └── style.scss
|   |
|   ├── blocks.js
|   ├── common.scss
|   └── init.php
|
├── .eslintignore
├── .eslintrc.json
├── .gitignore
├── plugin.php
├── package.json
├── README.md

Das sieht auf den ersten Blick komplex aus. In Teil 1 habe ich noch davon gesprochen, dass ein einfaches Block Plugin aus nur vier Dateien besteht. Auch wenn wir nun etwas mehr Dateien haben, lässt sich die grundlegende Block Architektur darin wiederfinden.

Aber der Reihe nach:

JavaScript Tooling

Im Root-Verzeichnis des Plugins findest du eine Reihe von Dateien für die Konfiguration von Git, ESLint und der NPM Packages (.gitignore, package.json, etc). Diese sind für das ganze Tooling notwendig, nicht aber für die eigentliche Funktionsweise des Plugins.

Das Gleiche gilt für den Ordner /node_modules/, in dem alle Tools wie Webpack, Babel und ESLint installiert sind.

PHP Dateien

Wichtig für die Initialisierung des Plugins sind die zwei PHP-Dateien plugin.php und src/init.php. Die erste Datei enthält nur den Plugin Header und bindet die zweite Datei ein.

Die init.php beinhaltet zwei Funktionen, welche das Block-Skript und die Block-Stylesheets im Theme und im WordPress Editor laden. Dazu werden die zwei neuen Action Hooks enqueue_block_assets und enqueue_block_editor_assets verwendet.

/**
 * Enqueue Gutenberg block assets for both frontend + backend.
 */
function themecoder_block_cgb_block_assets() {
	// Styles.
	wp_enqueue_style(
		'themecoder_block-cgb-style-css',
		plugins_url( 'dist/blocks.style.build.css', dirname( __FILE__ ) ),
		array( 'wp-editor' )
	);
}
add_action( 'enqueue_block_assets', 'themecoder_block_cgb_block_assets' );

/**
 * Enqueue Gutenberg block assets for backend editor.
 *
 */
function themecoder_block_cgb_editor_assets() {
	// Scripts.
	wp_enqueue_script(
		'themecoder_block-cgb-block-js',
		plugins_url( '/dist/blocks.build.js', dirname( __FILE__ ) ),
		array( 'wp-blocks', 'wp-i18n', 'wp-element', 'wp-editor' )
	);

	// Styles.
	wp_enqueue_style(
		'themecoder_block-cgb-block-editor-css',
		plugins_url( 'dist/blocks.editor.build.css', dirname( __FILE__ ) ),
		array( 'wp-edit-blocks', 'themecoder_block-cgb-style-css' )
	);
}
add_action( 'enqueue_block_editor_assets', 'themecoder_block_cgb_editor_assets' );

Aus Gründen der Übersichtlichkeit habe ich den Code und die Kommentare etwas gekürzt.

*UPDATE*
In der neuesten Version von Create-Guten-Block werden die Skripte inzwischen nur noch registriert und mit register_block_type() eingebunden:

register_block_type(
	'cgb/block-themecoder-block', array(
		'style'         => 'themecoder_block-cgb-style-css',
		'editor_script' => 'themecoder_block-cgb-block-js',
		'editor_style'  => 'themecoder_block-cgb-block-editor-css',
	)
);

Auch wenn sich die Implementierung geändert hat, ist der Zweck der Datei immer noch der Gleiche. Ich empfehle, die init.php selbst im Editor zu öffnen und den Code nachzuvollziehen.

Ordner dist/

dist steht für Distribution und enthält deshalb die gebündelten Files mit kompiliertem Code, also das Ergebnis unseres Build-Prozesses mit Webpack. Falls du die zwei PHP-Funktionen aufmerksam studiert hast, dann hast du bereits bemerkt, dass damit die drei Dateien vom Ordner dist/ geladen werden:

• blocks.build.js
• blocks.editor.build.css
• blocks.style.build.css

Kommt dir das bekannt vor? Es handelt es sich um die Block-JS, Block-Stylesheet und Editor-Stylesheet, welche ich im ersten Teil als die zentralen Bestandteile eines Blocks vorgestellt habe.

Ordner src/

src steht für Source und damit für die Quelldateien. Hier findet die Entwicklung der Blocks statt.

Du kannst hier beliebig viele JS- und Sass-Dateien erstellen und von Webpack bündeln lassen. Auch die Ordnerstruktur bleibt dir überlassen. Nach dem Build-Prozess erhalten wir immer die drei kompilierten Dateien in /dist/, egal ob du einen oder zwei dutzend Blocks programmierst.

Mit Create-Guten-Block ist die Datei src/blocks.js als sogenannter Entry Point festgelegt. Das bedeutet, dass Webpack diese Datei einliest und alle Dateien bündelt, welche von dort importiert werden. Es ist praktisch der Start von unserem Trichter, in den wir unsere Source-Dateien und Code (ES6, JSX, SCSS) kippen, um bei der Metapher aus dem ersten Teil zu bleiben.

Block Development mit create-guten-block

Wer nun eine JavaScript-Datei aus dem Source-Ordner verändert und beispielsweise den Namen des Blocks anpasst, wird feststellen, dass die Änderung in WordPress erst einmal keine Auswirkung hat. Das liegt daran, dass im Gutenberg Editor nur die kompilierten Skripte aus dem Distribution-Ordner eingebunden werden, nicht die Source-Files.

Bevor wir deshalb mit der Entwicklung von Gutenberg Blocks loslegen können, müssen wir unseren Webpack-Prozess anstoßen, damit unser Code auch kompiliert wird. Wir gehen dafür zurück in die Kommandozeile und wechseln direk in unseren neuen Plugin-Ordner.

cd themecoder-block
npm start

Mit dem Befehl npm start kannst du den Build-Prozess starten.

Webpack überwacht nun den src-Ordner automatisch und kompiliert den Code jedes Mal neu, wenn du eine Änderung durchführst. Bei Syntax-Fehlern in deinem Code wird dir ein Kompilierungsfehler in deinem Terminal angezeigt.

Neben dem Development Mode kannst du mit npm run build auch Production Code erzeugen:

npm run build

Dabei wird der Code kompiliert, minifiziert und alle Kommentare entfernt. Die Dateigröße wird damit soweit wie möglich reduziert, um ein möglichst performantes Einbinden unserer Blocks zu gewährleisten. Der Build-Prozess läuft einmalig und ist nicht für die laufende Entwicklung geeignet, sondern zur Bereitstellung deines Plugins für den Endnutzer.

Ausblick auf Teil 3

Nach dem Setup und Einrichtung unseres Plugins und dem Tooling können wir in Teil 3 endlich damit beginnen, unseren eigenen Block zu entwickeln. Fragen zum Block Setup oder Tooling können sehr gerne in den Kommentaren gestellt werden

Überblick über alle Beiträge dieser Serie