Gutenberging

Es ist über ein Jahr her seit dem großen WordPress-Launch von Gutenberg, dem neuen Editor. Mir scheint, dass die meiste Kontroverse darum herum abgeklungen ist. Es gab genug Zeit, dass die Benutzerfreundlichkeit und Zugänglichkeit davon verbessert wurden, und die Leute sehen das Potenzial viel klarer. Es gibt kein Zurück mehr.

Ich stoße auf Artikel wie den von Haris Zulfiqar, der sagt, er setzt darauf, und Nick Hamze, der sagt, dass Blöcke für die nächste Generation sind.

Obwohl ich denke, dass es noch Ecken und Kanten gibt (wie z. B. warum kann ich keine Liste in ein Blockquote einfügen? Warum kann ich einem Link keine Klasse hinzufügen? Warum kann ich nicht per Pfeiltaste durch den Block-Chooser navigieren?), bin ich insgesamt ein großer Fan. Und das nicht mehr nur konzeptionell. Ich habe es zu einem meiner Ziele für 2020 gemacht, CSS-Tricks auf Gutenberg umzustellen, und so habe ich mich gleich im Januar darum gekümmert.

Wir hatten bereits einen Fuß in der Tür

Wir hatten schon ein wenig Erfahrung mit Gutenberg gesammelt, da wir bereits die Erstellung von Newsletter-Beiträgen auf den neuen Editor umgestellt hatten. Unsere Newsletter sind hier auf CSS-Tricks ein Custom Post Type, die unter öffentlichen URLs veröffentlicht werden, einen eigenen RSS-Feed haben und von MailChimp versendet werden, das diesen RSS-Feed abruft und liest.

Wir konnten Gutenberg für Newsletter einfach über das Plugin Gutenberg Ramp aktivieren. Das funktioniert gut für Custom Post Types und Beiträge mit einzelnen IDs, aber ich wollte Gutenberg *nur für neue Inhalte* aktivieren. Ich habe am Ende das Plugin "monkey-patched". Hier ist ein Pull Request, falls jemand dort der Meinung ist, dass es eine gute Idee ist.

Das war mir wichtig, da wir Zehntausende von alten Beiträgen haben, die mit dem alten Editor erstellt wurden, und auch wenn Gutenberg sie nicht verunstaltet, wenn wir sie zum Bearbeiten öffnen, ist die Editor-Erfahrung, die es für sie bietet, nicht so gut wie die des "klassischen" Editors (z. B. haben wir spezielle Buttons für unsere speziellen Code-Blöcke und Ähnliches).

Umgang mit älteren Inhalten

Was wirklich großartig wäre, ist, wenn Gutenberg alte Beiträge beim Öffnen in richtige Blöcke umwandeln würde, aber das fühlt sich im Moment wie ein Traum an. Es müsste das HTML parsen, identifizieren, welche Chunks wie Blöcke aussehen, identifizieren, *welcher* Block am sinnvollsten ist, einschließlich unserer *benutzerdefinierten* Blöcke, die am wichtigsten sind, und zwar *wirklich korrekt* und auf eine nicht zerbrechliche Weise.

Vorerst werden alte Inhalte einfach mit dem alten Editor bearbeitet. Es gibt nicht einmal eine einfache Möglichkeit, Gutenberg für einen einzelnen Beitrag aus dem Editor heraus zu aktivieren. (Ich könnte Hardcode-Werte in die Gutenberg Ramp-Nutzung einfügen, aber das ist etwas mühsam.)

Ich befürchte ein wenig, dass der alte Editor wirklich verfallen wird. Zum Beispiel ist einer der Hauptgründe, warum ich damit angefangen habe, dass auf dieser Seite der alte Editor zufällig zum Ende der Seite gescrollt hat. Ich kann nicht im Leben herausfinden, warum, aber das macht das Verfassen für mich unangenehm. Nur ein kleiner Papier schnittfehler, der mich dazu veranlasste, auf die Editor-Erfahrung umzusteigen, die aktiv entwickelt wird.

Aber selbst wenn der alte Editor wirklich schlecht wird, ist das einfache Aktivieren von Gutenberg für alles nicht so schlimm. Alle alten Inhalte werden einfach in einem großen "klassischen" Block sein und in Ordnung sein.

Also, kurz gesagt – es funktioniert!

Das Aktivieren von Gutenberg für neue Beiträge war eine kleine Herausforderung für sich, aber es ist für uns eingeschaltet und wir erstellen alle neuen Inhalte darin. Ich spreche hier nur für mich, aber OMG, ich liebe es so sehr. Es ist ein so massives Upgrade für das Schreiben von Inhalten, dass ich ein wenig davon besessen bin. Das Team ist auch glücklich.

Erstellen von benutzerdefinierten Blöcken

Schauen Sie sich diesen schicken Textblock an, den wir haben

Man könnte denken, oh cool, eine Gelegenheit für einen benutzerdefinierten Block. Heck, wir haben sogar das Erlernen und Erstellen von Gutenberg-Blöcken in einer ganzen großen Serie behandelt. Aber das bringt eine ziemlich relevante Situation mit sich: wann man *keinen* Block bauen sollte. Das Einzige, was an *diesem* Block einzigartig ist, ist, dass er einen speziellen Klassennamen hat, den unser CSS zur Formatierung dieses Blocks verwendet. Das ist alles. Das Hinzufügen eines Klassennamens ist eine integrierte Funktion jedes Blocks, daher ist ein benutzerdefinierter Block hier wirklich nicht notwendig.

Tatsächlich können wir noch einen Schritt weiter gehen und einen Textblock mit dieser genauen Klasse zu einem "wiederverwendbaren Block" machen, damit wir uns diesen Klassennamen nicht einmal merken oder eingeben müssen. Nachdem ich einen Textblock mit dieser Klasse erstellt habe, wähle ich im Kebab-Menü "In wiederverwendbaren Block konvertieren" und nun ist er für immer als wiederverwendbarer Block gespeichert.

Wir nutzen ihn bereits für einige andere Dinge, wie unseren "Artikelserien"-Block (ein <h4> und <ol> mit einem speziellen <div>-mit-Klasse-Wrapper) und Fußnotenblöcke und dergleichen.

Aber wir brauchen tatsächlich auch einige benutzerdefinierte Blöcke, und dafür habe ich create-guten-block verwendet, um ein spezielles Plugin¹ zu erstellen. Einer, der für uns megawichtig ist, sind Codeblöcke. Es gibt bereits einen nativen Block für Codeblöcke. Er setzt den Code im Wesentlichen in ein <pre>-Tag, und der Inhalt von Gutenberg wird standardmäßig bereits escaped.

Unser schicker Codeblock ermöglicht es uns, die Sprache auszuwählen, bestimmte Zeilen hervorzuheben und benutzerdefinierte Labels bereitzustellen. Dies war in unserem alten Editor über HTML-Attribute möglich, sodass dieser Block lediglich eine schöne Benutzeroberfläche für all das ist.

Dieser Block ist so spezifisch für CSS-Tricks, dass es keinen Sinn ergibt, ihn als Open Source zu veröffentlichen. Aber es gibt einen anderen Block, den ich erstellt habe und der Open Source ist, und das ist der CodePen Embed Block. Ich habe darüber geschrieben auf dem CodePen-Blog.

Er ermöglicht es Ihnen, eine CodePen-URL einzufügen, und sie verwandelt sich in einen CodePen-Embed. oEmbed macht das standardmäßig bereits, aber mit diesem Plugin können Sie alles steuern, wie Höhe, Thema und Standard-Tabs.

Es ist ziemlich genial, die eingebetteten Pens tatsächlich während der Erstellung zu sehen!

Ungelöste Herausforderungen

Die größte Herausforderung ist derzeit die Handhabung von Bildern. Im alten Editor hatten wir ein sehr, sehr schickes Setup mit Cloudinary integriert. Die Bilder werden automatisch nach Cloudinary hochgeladen, Breakpoints werden programmatisch festgelegt, mehrere Größen werden erstellt, eine responsive Bildsyntax wird erstellt, und was im HTML landet, ist eine perfekte responsive Bildsyntax mit den von Cloudinary gehosteten Bildern. Dies hat uns den Vorteil verschafft, auf einem CDN zu sein und die Bilder im bestmöglichen Format zu liefern.

Nichts davon geschieht bei Beiträgen, die mit Gutenberg erstellt wurden. 😭

Ich muss ein neues System finden oder entwickeln, das überall auf der Website gut mit Bildern umgeht und idealerweise ein weniger maßgeschneidertes System ist, das einfacher zu warten ist. Möglicherweise finde ich das mit Cloudinary heraus, vielleicht probiere ich einen anderen Dienst aus, vielleicht lasse ich WordPress es direkt abwickeln, unterstützt vom Jetpack Site Accelerator. Noch nicht sicher. Immer gibt es etwas zu tun.