WordPress 7.0 «Armstrong»: Vier Features, die mein Block-Theme entschlackt haben

Drei Tage vor diesem Beitrag bin ich mit meinem neuen Theme dieses Blogs auf Basis von WordPress 6.9 online gegangen. Relaunch, Kaffeetasse, fertig. Zwei Tage später erscheint WordPress 7.0 «Armstrong». Erster Reflex: warten, das Major-Update reifen lassen. Zweiter Reflex: trotzdem schauen, was drin ist. Und tatsächlich – vier Features haben mich überzeugt, das Theme direkt nachzuziehen.

Was Armstrong gross bewirbt – Real-Time-Collaboration im Editor und eine generische AI-API – interessiert mich für meinen Einzelblog null. Was mich interessiert, sind die leisen Änderungen, die Theme-Entwicklern Arbeit abnehmen. Davon gibt es genug.

PHP-only Blocks: endlich Editor-UI ohne JavaScript

Bisher hatte ich für eigene Blocks zwei Möglichkeiten: entweder eine schlanke PHP-Datei mit Render-Callback. Die Konsequenz: kein Editor-UI, keine Attribute, aber einfach zu bauen. Oder den vollen Block mit block.json, JavaScript-Komponente und Build-Manifest. Mächtig, aber Setup-Aufwand für jeden kleinen Filter.

Mit 7.0 gibt es einen Mittelweg. Ein Flag im Block-Support, eine Handvoll Attribute, und WordPress baut die Inspector-Controls in der Sidebar selber zusammen. Aus boolean wird eine Checkbox, aus enum ein Dropdown, aus string ein Textfeld. Kein JavaScript, keine Build-Pipeline, nichts.

Mein Kategorie-Filter, der vorher hartcodiert war, hat damit endlich vier richtige Einstellungen bekommen:

register_block_type('blueforce/category-filter', [
    'api_version' => 3,
    'supports'    => [
        'autoRegister' => true,
    ],
    'attributes'  => [
        'showHome'  => ['type' => 'boolean', 'default' => true],
        'homeLabel' => ['type' => 'string',  'default' => 'Alle Artikel'],
        'orderBy'   => [
            'type'    => 'string',
            'enum'    => ['count', 'name', 'term_order'],
            'default' => 'count',
        ],
        'hideEmpty' => ['type' => 'boolean', 'default' => true],
    ],
    'render_callback' => function (array $attributes): string {
        // ...rendert die Filter-Pills...
    },
]);

Die Vorschau im Editor läuft über die REST-API: Jede Attribut-Änderung triggert einen Server-Render. Bei aufwendigen Render-Callbacks merkt man das, bei simplen Blocks ist es egal. Für mich war es der Moment, an dem ich gedacht habe: Endlich brauche ich für solche Sachen kein Webpack mehr.

Breadcrumbs als Core-Block – aber ohne Schema

Eine Breadcrumb-Navigation hat man bisher entweder vom SEO-Plugin geliehen oder selbst gebaut. Jetzt gibt es einen Core-Block, der direkt ins Template eingefügt wird – eine einzige Zeile, fertig:

<!-- wp:breadcrumbs {"separator":"›","showHomeItem":true} /-->

Auf Mobile ist es enger – lange Beitragstitel sprengen die Zeile, wenn man nichts dagegen tut. Ich kappe das letzte Item per CSS-Ellipsis, dann passt es:

Die unangenehme Überraschung kam beim Check des HTML: Der Block rendert ein sauberes <nav><ol> – aber kein BreadcrumbList-JSON-LD. Für strukturierte Daten muss man weiter selber liefern. Bei mir landet das Schema jetzt im functions.php, parallel zum bestehenden BlogPosting-Markup. SEOPress Free kann (zum Zeitpunkt dieses Artikels) noch beides nicht, also bleibt es Theme-Aufgabe.

Endlich konsistente Icons

Meine Alert-Boxen – die kleinen blauen, orangen, grünen und roten Hinweiskästen – hatten bisher Emoji als Icons. Ein Pseudo-Element im CSS, das je nach Variante ℹ️, ⚠️, ✅ oder ⛔ ausgegeben hat. Funktional okay, aber: Emojis sehen auf macOS anders aus als auf Windows. Die Farbe greift nur halb, weil das Rendering ans OS abgegeben wird. Pixelig auf manchen Linux-Distros. Ein Kompromiss.

Der neue core/icon-Block holt SVGs aus einer Core-Registry mit rund 200 Symbolen. Das ist genug für Alerts, Buttons, dezente Akzente. Eigene Icons gehen in 7.0 noch nicht – das soll mit 7.1 kommen. Für meine vier Varianten reichen die Core-Icons aber locker: core/info, core/caution, core/check, core/error.

Damit alte Posts mit den Emoji-Alerts weiter funktionieren, habe ich den CSS-Selektor mit :has() erweitert: Ist im Alert ein Icon-Block drin, greift das neue Styling; ist keiner drin, bleibt das Emoji-Fallback. Niemand muss alte Beiträge nochmal anfassen.

Block-Visibility nach Bildschirmgrösse

Jeder Block lässt sich jetzt direkt im Editor pro Viewport ein- oder ausblenden. Drei Grössen sind hartcodiert: Mobile bis 480 Pixel, Tablet bis 782 Pixel, Desktop alles darüber. Konfigurierbar wird das erst mit 7.1.

Versteckt liegt die Funktion hinter dem Drei-Punkte-Menü der Block-Toolbar – Eintrag «Ausblenden», Shortcut ⇧⌘H. Was sich öffnet, ist kein Inspector-Panel, sondern ein Modal mit Checkboxen:

Mein Testfall: das orange «KATEGORIE»-Label, das in meinem Archiv über dem Kategorienamen sitzt. Auf Desktop ein nettes Detail, auf Mobile schluckt es Platz, der dem Titel besser steht. Eine Checkbox später ist es auf Smartphones weg:

Ein kleines, aber feines Extra im Modal: die Option «Von veröffentlichten Inhalten ausschliessen». Der Block bleibt im Editor sichtbar, im Frontend wird er gar nicht ausgegeben. Perfekt für Redaktions-Notizen, die nur ich sehen soll – ein Reminder an mich selbst, der nie auf der Live-Seite landet.

Was beim Live-Update wichtig war

Ich habe das Theme lokal gebaut und dann auf live geschoben. Reihenfolge war entscheidend: zuerst WordPress 7.0 auf dem Server, dann das Theme hinterher. Hätte ich es umgekehrt gemacht, wären core/breadcrumbs und core/icon auf Live nicht verfügbar gewesen – Templates und Patterns hätten reihenweise gebrochen.

Was noch geholfen hat: nach jedem Theme-Update den LiteSpeed-Cache leeren. Sonst sieht man die Änderungen nicht im Frontend und beginnt, an seinem CSS zu zweifeln, wo eigentlich alles richtig ist. Klassische Stunde im Sand verbrannt – ich habe das schmerzlich gelernt.

Fazit

WordPress 7.0 ist kein Feuerwerk, sondern ein Reinigungsupdate. Die Themen, die die Pressemitteilungen prägen – Collaboration und KI – sind für mich Marketing. Was wirklich zählt, sind die kleinen Schritte: PHP-only Blocks reduzieren Build-Pipelines, native Breadcrumbs und Icons reduzieren Plugin-Abhängigkeit, Block-Visibility ersetzt für simple Fälle ein eigenes Plugin.

Drei Tage nach dem Release schwirren überall die «WP 7.0 hat alles geändert»-Posts herum. Hat es nicht. Aber es hat ein paar Sachen einfacher gemacht, die ich vorher umständlich gelöst habe. Und für ein selbstgebautes Block-Theme zählt genau das.

Was mich an 7.0 am meisten freut, ist nicht ein einzelnes Feature, sondern die Richtung: WordPress investiert weiter konsequent in Block-Themes und macht ihnen das Leben leichter. Für 7.1 stehen schon konfigurierbare Breakpoints und eigene Icon-Sets auf der Roadmap – beides Sachen, die ich aktuell noch im Theme selber baue. Ich freue mich drauf.