Warum das in Ihrer Woche auftaucht
Marketing will einen neuen Abschnitt auf der Pricing-Seite. In einem gesunden Gutenberg-Setup öffnen Redakteure den Editor, fügen ein Pattern ein, tauschen Copy und veröffentlichen. Klare Patterns lassen Marketing diese Arbeit direkt erledigen. Entwickler übernehmen Änderungen am Code.
Klartext
Jeder Block hat eigene Einstellungen (Ausrichtung, Farben innerhalb der Theme-Regeln, Abstände). Patterns gruppieren Blöcke zu wiederverwendbaren Abschnitten wie Hero, Logo-Reihe, Pricing oder FAQ.
Synced Patterns aktualisieren sich an einer Stelle und erscheinen überall, wo sie genutzt werden. So halten Sie Legal-Footer oder CTA-Bänder konsistent, ohne zwanzig Seiten zu durchsuchen.
Gutenberg ist sowohl die Editor-UI als auch die Block-API, mit der Entwickler Custom Blocks registrieren, die zu Ihrem Design System passen.
Classic Editor ist ein Plugin, das die alte Erfahrung zurückbringt. Viele Legacy-Sites hängen noch daran. Migration zu Blöcken ist ein Projekt, kein Toggle.
Wenn Ihr Theme keine Patterns bereitstellt, erfinden Redakteure Einmal-Layouts. Der Editor ist nur so diszipliniert wie Theme und Schulung darum.
Fakten zum Behalten
- Im Core seit
- WordPress 5.0, Dezember 2018
- Ersetzt
- Klassisches Content-Feld als Standard-Editing-Modell
- Bausteine
- Blöcke, Patterns, Template Parts (mit Block-Themes)
- Nicht enthalten
- Elementor, Divi, WPBakery (separate kommerzielle Plugins)
- Editor-Ort
- Beiträge, Seiten und (mit Block-Themes) Site-Editor-Templates
Nicht dasselbe wie
- Elementor / Divi / WPBakerySeparate Page-Builder-Plugins mit eigenem UI und Speicher. Das ist nicht Gutenberg. Beides ohne Migrationsplan erzeugt Doppelsysteme.
- Der Site EditorSite Editor bearbeitet globale Templates und Theme-Parts auf Block-Themes. Gutenberg auf einer Seite bearbeitet deren Inhalt. Verwandt, nicht identisch.
- Nur ACF-FeldgruppenAdvanced Custom Fields kann strukturierte Inhalte liefern. Blöcke können ACF wrappen. Felder ohne klare Editor-UX lassen Redakteure trotzdem hängen.
Wo es wehtut
Gutenberg tut weh, wenn das Theme noch den Classic Editor erwartet oder zwei Editing-Systeme dieselben Templates ohne Migrationsplan teilen.
Redakteure erfinden dann Einmal-Layouts, die beim Update zerbrechen, und jede Kampagne wird wieder ein Entwickler-Ticket.
Was zu prüfen ist
- Sind Schlüssel-Templates aus Blöcken und Patterns gebaut, die die Marke wirklich nutzt?
- Ist für Routine-Landingpages noch ein Page Builder von Drittanbietern nötig?
- Haben Custom Blocks Dokumentation und einen Fallback, wenn ein Plugin deaktiviert wird?
- Können Redakteure ein CTA-Band einmal ändern und überall sehen, wo es synced ist?
- Hat jemand Redakteure zu Patterns geschult, oder nur „Plus-Button klicken"?
Häufige Fragen
Was ist Gutenberg in WordPress?
Gutenberg ist der blockbasierte Editor und das Framework in WordPress seit 5.0. Inhalte und Layouts entstehen aus Blöcken statt aus einem klassischen Editorfeld.
Ist Gutenberg dasselbe wie ein Page Builder?
Nein. Gutenberg ist Core WordPress. Page Builder wie Elementor sind separate Plugins mit eigenem Datenmodell und Lock-in-Profil.
Sollen wir unseren Page Builder entfernen?
Oft ja bei neuen B2B-Builds, wenn das Design System als Blöcke und Patterns ausgedrückt ist. Migrationskosten sind real. Planen Sie es, kein Schalter auf einer Live-Kampagnen-Site.
Was sind Block Patterns?
Vorgefertigte Block-Gruppen für typische Abschnitte. Sie beschleunigen Editing und halten Abstände und Hierarchie on-brand, wenn das Theme eine gute Bibliothek liefert.
Was sollten Sie bei Gutenberg zuerst prüfen?
Patterns, die echte Seiten abbilden, kein konkurrierender Page Builder für Routinearbeit und Custom Blocks, die Redakteure ohne Entwickler neben sich verstehen.