Bevor du kopfüber in all die großen und kleinen Änderungen eintauchst und deine Favoriten auswählst, lies bitte zuerst diese einleitenden Gedanken zu diesem Beitrag und dazu, wie du ihn verwenden kannst. Wenn du Fragen hast, hinterlasse einen Kommentar oder schreibe eine E-Mail an pauli@gutenbergtimes.com.

Ein riesiges „Dankeschön“ an Anne McCarthy, Justin Tadlock, Isabel Brison, Adam Silverstein, Ramon Dodd, Andrew Serong, Hans-Gerd Gerhards, Marin Atanasov, Krupa Nanda, Aaron Robertshaw, Ben Dwyer, Brent MacKinnon, Ashar Fuadi und viele mehr. Es braucht nach wie vor ein ganzes Dorf. Großen Respekt auch an das gesamte Release-Team, das WordPress 7.1 über die Ziellinie bringt.

Geschätzte Lesezeit: 37–55 Minuten bei 8.707 Wörtern (Original)

Changelog

Alle Änderungen werden hier im Verlauf des Release-Zyklus dokumentiert.

30. Juli 2026 – Erste Ausgabe.

31. Juli 2026

• „Global anwenden jetzt mit Überprüfungs-Panel“ hinzugefügt
• „Website-Editor-Ansichten filtern“ hinzugefügt

3. August 2026

• Informationen zur neuen Editor-Einstellung responsiveEditingEnabled hinzugefügt
• Link zu »Iframed Editor Changes in WordPress 7.1« hinzugefügt
• Aktualisierungen zur Abilities API hinzugefügt
• Tags aus den Überschriften entfernt, da sie das Inhaltsverzeichnis beschädigt haben
• Link zur Dev-Note für die barrierefreien Tooltips hinzugefügt
• Abschnitt „Markup der Beitragslisten-Tabellen für Barrierefreiheit geändert“ hinzugefügt

4. August 2026

• Informationen zum Dashboard-Widget „An diesem Tag“ entfernt (siehe Ticket). Auf 7.2 verschoben, bis weiteres Design-Feedback vorliegt.
• Das Codebeispiel "-current": { "color": { "text": "pink" } } korrigiert.

5. August 2026

• „An diesem Tag“ aus dem Überblick entfernt
• Filterung mit wp_get_abilities() im Abschnitt zur Abilities API ergänzt
• Verhaltensänderung des Filters notify_post_author ergänzt
• Änderung zur Weitergabe der Schriftgröße im Abschnitt zum Navigations-Block ergänzt
• Abschnitt „Hosting-Anbieter können jetzt die Standardwerte für spekulatives Laden anpassen“ hinzugefügt
• Dev-Note-Links von Entwurfs-Vorschauen auf die veröffentlichten Versionen aktualisiert (Responsive Stile, Website-Editor-Ansichten filtern)
• Abschnitt „Ressourcen“ aktualisiert: Link zum veröffentlichten WordPress 7.1 Field Guide

Wichtiger Hinweis

Versuche bitte, die Inhalte dieses Beitrags nicht einfach zu kopieren und einzufügen, denn er wird mit sehr vielen Menschen geteilt. Nutze ihn als Inspiration für deine eigenen Inhalte und als Quelle für die besten Informationen zu diesem Release. Wenn du doch kopierst, bedenke, dass andere dasselbe tun könnten – und das kann zu unangenehmen Momenten mit doppelten Inhalten im Netz führen.

Jeder Punkt wurde nach bestem Wissen mit verschiedenen übergeordneten Labels versehen, damit du auf einen Blick erkennst, wer am ehesten betroffen ist. Jeder Punkt enthält eine kurze Beschreibung, gegebenenfalls Bildmaterial und die wichtigsten Ressourcen, falls du mehr erfahren möchtest.

Überblick

WordPress 7.1 rundet die Styling-Steuerelemente des Block-Editors ab und macht die Arbeit mit Medien spürbar geschmeidiger. Lang gewünschte Funktionen erlauben es dir, das Aussehen von Blöcken für drei Bildschirmgrößen und für interaktive Zustände wie Hover und Fokus zu gestalten – ganz ohne individuelles CSS. Auch der Adminbereich wird persönlicher: Dein eigenes Farbschema und deine Werkzeugleiste begleiten dich jetzt auf jeder Ansicht.

Auch der Umgang mit Bildern erhält ein deutliches Upgrade. Das neue Medien-Editor-Dialogfenster vereint freies Zuschneiden, Drehen und das Bearbeiten von Metadaten in einem Arbeitsablauf, und die clientseitige Medienverarbeitung macht Uploads schneller und robuster – mit breiterer Formatunterstützung und besser optimierten Dateien.

Die neuen Blöcke „Playlist“ und „Tabs“ erweitern die von Haus aus verfügbaren Layout-Optionen und ermöglichen eine kreativere Präsentation von Informationen. In dieselbe Richtung gehen die erweiterte Icon-API mit eigenen Icon-Sammlungen, dynamische Galerien und Hintergrund-Verläufe für mehr Blöcke.

Auch die Vereinheitlichung von WP-Admin und den Block-Editoren schreitet voran: Die Editoren respektieren jetzt dein Admin-Farbschema, und die Adminleiste bleibt auf jeder Ansicht bei dir – auch in den Editoren und im Frontend.

Während die Echtzeit-Zusammenarbeit auf eine zukünftige WordPress-Version verschoben wurde, hat die asynchrone Zusammenarbeit mit Notizen echte Fortschritte gemacht: Inline-Notizen an Textauswahlen, @-Erwähnungen, Rich-Text-Formatierung und mehrere Notizen pro Block.

Über die Highlights hinaus erhalten die Core-Blöcke viele Detailverbesserungen und Fehlerkorrekturen, die das Bearbeiten von Inhalten in WordPress schlanker, konsistenter und schneller machen. Und Entwickler*innen bekommen einen wachsenden Satz an APIs, auf denen sie aufbauen können.

Ressourcen

• Help Test WordPress 7.1
• Verfolge die veröffentlichten Dev-Notes.
• WordPress 7.1 Field Guide
• Roadmap to 7.1

Dieses Release umfasst Funktionen aus den Gutenberg-Plugin-Versionen 22.7 bis 23.6. Hier sind die Release-Beiträge dieser Plugin-Versionen: 22.7 | 22.8 | 22.9 | 23.0 | 23.1 | 23.2 | 23.3 | 23.4 | 23.5 | 23.6. Spätere Gutenberg-Versionen enthalten Fehlerkorrekturen, die in die Release-Branches von WordPress 7.1 zurückportiert wurden.

Assets

In diesem Google-Drive-Ordner kannst du alle Assets aus diesem Dokument ansehen.

Tags

Damit du dieses Dokument leichter nach Zielgruppen durchsuchen kannst, werden die folgenden Tags großzügig verwendet:

• [end user]: Fokus auf Endanwender*innen.
• [theme builder]: Autor*innen von Block- oder klassischen Themes.
• [plugin author]: Plugin-Autor*innen, ob Block-Plugin oder nicht.
• [developer]: Sammelbegriff für technisch versierte Personen.
• [site admin]: schließt auch den Typ „Site-Builder“ ein.
• [enterprise]: Punkte, die besonders für den Enterprise-Bereich interessant oder relevant sind.
• [all]: breite Auswirkung auf alle, die mit WordPress arbeiten.

Wie kannst du die Tags nutzen? Verwende die Suchen-Funktion deines Browsers und suche nach der Zeichenfolge inklusive der eckigen Klammern. Mit den Pfeilen springst du dann im Beitrag von einem Treffer zum nächsten.

Prioritäten für WordPress 7.1

WordPress 7.1 bringt bedeutende Verbesserungen für blockbasiertes Design und Bearbeiten. Die Prioritäts-Funktionen konzentrieren sich auf responsive Steuerelemente, interaktive Zustände, Medienverwaltung und eine modernisierte Navigation über die Adminleiste.

Responsive Stile für Blöcke

[theme builders][site admin][end user]

Wahrscheinlich die am häufigsten gewünschte Verbesserung des Block-Editors: Nachdem jahrelang intrinsisches Design für Schriften und Abstände im Vordergrund stand, macht WordPress 7.1 responsives Design zu einem eingebauten, vollwertigen Teil der Bearbeitung. Die Funktion baut auf früheren Schritten in diese Richtung auf – der Möglichkeit, Blöcke je nach Bildschirmgröße ein- oder auszublenden, und dem anpassbaren mobilen Overlay des Navigations-Blocks – und weitet die Idee auf das Styling selbst aus.

Die Funktion ist in allen Block-Editoren verfügbar: für Beiträge, Seiten, Templates, Vorlagen (Patterns), Template-Teile und die Navigation. Das responsive Styling folgt einem Desktop-first-Modell: Stile vererben sich auf kleinere Bildschirme, bis du sie für bestimmte Geräte anpasst.

Viewport-spezifische Werte sind derzeit auf die Einstellungen in der Block-Seitenleiste beschränkt (etwa Typografie, Abstände und Farben). Die Steuerelemente funktionieren in den globalen Stilen (mit Wirkung auf alle Instanzen eines Blocks) und an einzelnen Block-Instanzen – in allen Block-Editoren: Beiträge, Seiten, Templates, Vorlagen, Template-Teile und Navigation.

Steuerelemente aus der Werkzeugleiste, die sich nicht pro Viewport festlegen lassen, werden ausgeblendet, sobald ein Viewport-Zustand aktiviert ist. Zu den wichtigsten Steuerelementen gehören Viewport-spezifische Voreinstellungen für das Seitenverhältnis der Blöcke Bild, Beitragsbild und Cover, sodass sich jeder Block pro Gerät optimieren lässt (78543). Parallel dazu sind die Layout-Steuerelemente vom Tab „Einstellungen“ in den Tab „Stile“ umgezogen – so bleiben alle Styling-Entscheidungen beisammen.

Dank des Community-Feedbacks aus dem Call for Testing wird die Funktion mit einem Ausschalter ausgeliefert: über die neue Editor-Einstellung responsiveEditingEnabled. Ist sie deaktiviert, verschwinden sowohl die Option Responsive Stile im Menü Ansicht als auch die Viewport-Auswahl in den globalen Stilen. Die Einstellung betrifft nur die Bearbeitungsoberfläche: Bereits gespeicherte responsive Stile werden weiterhin wie bisher ausgegeben (80814). Codebeispiele stehen in der Dev-Note zu den responsiven Stilen.

Im »Call for Testing: Responsive Styling« erfährst du, wie du die Funktion aktivierst und worauf du achten solltest. Die technischen Details findest du in der Dev-Note »Responsive block styles and configurable viewports in WordPress 7.1«.

Anpassung der Viewport-Breakpoints

Themes können jetzt eigene Breakpoints in der theme.json definieren, sodass sowohl das responsive Styling als auch die Block-Sichtbarkeit pro Viewport mit den Breakpoints deines Designsystems arbeiten – statt mit den WordPress-Standardwerten. Theme-Entwickler*innen und Designer*innen bekommen damit eine feinkörnige, geräteunabhängige Kontrolle über das responsive Verhalten (79104).

"settings": {
    "viewport": {
        "mobile": "30rem",
        "tablet": "45rem"
    }
}

Tracking: WordPress 7.1: Block visibility configurable breakpoints and theme.json integration (#75707)

Das macht interaktives Design für Menschen ohne Programmierkenntnisse und für Theme-Autor*innen zugänglich. Individuelle CSS-Schnipsel für gängige Interaktionen sind damit nicht mehr nötig.

Styling interaktiver Zustände (Hover, Fokus)

Du kannst jetzt interaktive Pseudo-Zustände (:hover, :focus oder :active) für zwei Blöcke gestalten: Button und Navigations-Link. Das Styling lässt sich global und pro Instanz anwenden – ohne eine Zeile CSS zu schreiben. Du kannst zum Beispiel die Farbe eines Buttons beim Überfahren mit der Maus direkt im Editor ändern (76491).

Der zugrundeliegende Mechanismus erlaubt außerdem das Styling des aktuellen Menüpunkts in einem Navigations-Block über die theme.json (75736).

"core/navigation-link": {
    "-current": {
        "color": { "text": "#ff0000" },
        "typography": { "fontWeight": "700" },
        ":hover": {
            "color": { "text": "#0000ff" }
        },
        ":focus": {
            "color": { "text": "#00aa00" }
        },
        ":active": {
            "color": { "text": "#ff6600" }
        }
    }
}

Mehr Details und weitere Codebeispiele liefert die Dev-Note »Pseudo and custom style states in WordPress 7.1«.

Medien-Editor-Dialogfenster und freies Zuschneiden von Bildern

[end user][site admin]

Das neue Medien-Editor-Dialogfenster ersetzt das bisherige Inline-Zuschneidewerkzeug. Es wird über den vertrauten Button Zuschneiden geöffnet und vereint freies Zuschneiden und Zuschneiden nach Seitenverhältnis, Spiegeln, feinstufiges Drehen mit Einrast-Hilfslinien und das Bearbeiten von Metadaten in einem einheitlichen Arbeitsablauf (78653, 78935, 78792).

Das verbessert die Bearbeitung im WordPress-Block-Editor erheblich. Das Ziel: Für grundlegende Bildbearbeitung soll kein externes Werkzeug mehr nötig sein. Du kannst deine Bilder jetzt schneller und präziser steuern – Bildausschnitt feinjustieren, Ausrichtung korrigieren oder ein Bild spiegeln, damit es besser ins Layout passt – mit wenigen Klicks und ohne deinen Arbeitsfluss zu unterbrechen.

Beim Cover-Block ist das neue Medien-Editor-Dialogfenster mit dem Button Hintergrundbild zuschneiden verknüpft. Die Option erscheint immer dann, wenn der Cover-Block ein bearbeitbares Bild verwendet. Nach einer Bearbeitung berechnet der Block seine Overlay-Farbe und den Kontrast automatisch neu, damit Text lesbar bleibt – auch wenn der Zuschnitt die hellsten oder dunkelsten Bildbereiche entfernt hat (79258).

Tracking: Media Editor Modal task tracking (#73771)

Verbesserungen bei der clientseitigen Medienverarbeitung

[developer][site admin][enterprise]

Wenn du ein Bild im Block-Editor hochlädst, übernimmt jetzt dein Browser die Erstellung aller Zwischengrößen – nicht mehr dein Server. Dazu kommt eine WebAssembly-Version (WASM) von libvips (wasm-vips) zum Einsatz, einer leistungsstarken Bibliothek zur Bildverarbeitung. Das auf dem Server gespeicherte Ergebnis ist besser als das, was die serverseitige Verarbeitung bisher lieferte: kleinere Dateien, direkt auf deinem Gerät erzeugt. Die CPU-Last der serverseitigen Bildverarbeitung könnte auf leistungsfähigen Geräten um mehr als 80 % sinken (79188).

Das Update bringt außerdem breitere Unterstützung moderner Bildformate mit: HEIC (das Standardformat für iPhone-Fotos), JPEGs mit HDR-Gain-Maps (verwendet von UltraHDR und Adaptive HDR) sowie eingebaute AVIF- und WebP-Unterstützung. Eine große Performance-Verbesserung ist die Umwandlung von GIFs in Videos – für leichtere, effizientere Dateien, die im Frontend schneller laden. Diese Funktion ist derzeit optional aktivierbar. Uploads sind zudem robuster: mit Fortschrittsanzeige und automatischen Wiederholungsversuchen, falls die Datenverbindung abbricht (76765, 79307).

Für alle, die Medien hochladen, bedeutet das Update: bessere Unterstützung für HDR-Bilder, schnellere und zuverlässigere Uploads, breitere Formatunterstützung und besser optimierte Dateien – ohne manuelles Eingreifen.

Eine wichtige Einschränkung gibt es: Einige serverseitige Hooks – darunter wp_generate_attachment_metadata, image_resize_dimensions und wp_handle_upload – werden möglicherweise nicht mehr wie bisher ausgelöst. Plugin-Entwickler*innen sollten das im Blick behalten. Das Team arbeitet an Dokumentation und Migrationsstrategien (74333).

Ausführlichere Informationen enthält die Dev-Note »Client-Side Media Processing in WordPress 7.1«.

Icons erben jetzt Farben, und die Icons-API nimmt Gestalt an

[theme builder][plugin author][developer][enterprise]

WordPress 7.0 lieferte einen eingebauten Satz von SVG-Icons für den Block-Editor und den Icon-Block. Mit WordPress 7.1 wächst daraus eine richtige, öffentliche API: Plugins und Themes können eigene Icons registrieren, sie in Sammlungen gruppieren, serverseitig rendern und über die REST-API auslesen.

Für alle, die Inhalte erstellen, ist die sichtbarste Änderung die Icon-Auswahl des Icon-Blocks: Sie gruppiert Icons jetzt nach Sammlung – mit einem Tab pro Sammlung plus einem Tab „Alle“ – und deine Suchanfrage bleibt beim Wechsel zwischen den Tabs erhalten. Individuelle Icons aus Plugins und Themes erscheinen direkt neben dem Core-Satz. Auch der Block selbst wurde verfeinert: Er fügt ein Standard-Icon ein, damit du nie auf einen leeren Platzhalter starrst, bietet Steuerelemente zum Spiegeln und Drehen in der Werkzeugleiste und zeigt Steuerelemente für Text- und Hintergrundfarbe standardmäßig an.

Für Entwickler*innen: weitere Sammlungen registrieren

Auf der PHP-Seite fügen sich die Teile zusammen: Registriere eine Sammlung mit wp_register_icon_collection(), füge Icons mit wp_register_icon() hinzu – aus einer Inline-SVG-Zeichenfolge oder einer .svg-Datei – und gib jedes registrierte Icon aus mit wp_get_icon(), inklusive Größe, CSS-Klasse und barrierefreier Beschriftung. Icon-Namen werden streng validiert, die register-Methode der Registry ist jetzt öffentlich, und REST-API-Endpunkte stellen Sammlungen und Icons für deinen eigenen Code bereit. Eine Dev-Note mit vollständigen Codebeispielen ist für den Make-Core-Blog in Arbeit.

Eine Breaking Change zum Vormerken: Alle 330 Icons in @wordpress/icons v15 deklarieren jetzt fill="currentColor" – Icons erben damit standardmäßig die umgebende Textfarbe. Wenn du Icons bisher über die CSS-Eigenschaft fill eingefärbt hast, wechsle zu color. Das ist zuverlässiger, denn ein Icon kann intern fill, stroke oder beides verwenden. Wenn du eigene Icons registrierst, füge ihrem <svg>-Element fill="currentColor" hinzu, um dasselbe Verhalten zu erhalten.

Die Dev-Note »Registering and rendering SVG icons in WordPress 7.1« enthält alle Details.

Tracking: SVG Icon API: Iteration for WordPress 7.1 (#75715)

Adminleiste überall

[all]

Mit WordPress 7.1 wird die WordPress-Adminleiste, die oben im Frontend deiner Website und auf anderen Admin-Seiten sitzt, jetzt standardmäßig auch im Block-Editor angezeigt. Sie bleibt nur verborgen, wenn Vollbildmodus und ablenkungsfreier Modus gleichzeitig aktiviert sind.

Bisher bedeutete der Wechsel in den standardmäßigen Vollbildmodus des Editors, dass die Adminleiste verschwand – und damit die Verbindung zum Rest von wp-admin. Da die Adminleiste jetzt den Website-Kontext liefert, ersetzt das Update außerdem das W-/Website-Icon oben links im Website-Editor durch einen expliziten Zurück-Button und macht die Navigation damit offensichtlicher (79197).

Mit dem Update kommt auch eine Design-Auffrischung:

• Dein Website-Icon ersetzt das Haus-Symbol,
• der Profil-Avatar wird rund, und
• der Tastatur-Shortcut für die Befehlspalette wandert in die Adminleiste, um visuelle Unruhe zu beseitigen und Shortcut-Konflikte aufzulösen (79060).

So bleibt die vertraute Navigation wieder auf allen Ansichten bei dir.

Die Dev-Note mit allen Details für Anwender*innen und Entwickler*innen: »Consistent navigation in WordPress 7.1 with persistent toolbar«.

Neue Blöcke

[all]

Dieses Release erweitert die Block-Bibliothek um vielseitige neue Werkzeuge. Die Neuzugänge geben dir bessere Möglichkeiten, interaktive Medien darzustellen und Informationen zu organisieren.

Playlist-Block

Mit dem neuen Playlist-Block erstellst du Audio-Playlists mit Wellenform-Visualisierung – ideal, um mehrere Titel oder Podcast-Episoden in einem einzigen interaktiven Player zu präsentieren. Besucher*innen können deine Audio-Inhalte durchstöbern und abspielen, ohne die Seite zu verlassen. Damit bekommst du ein modernes, ansprechendes Hörerlebnis direkt in WordPress – für Podcast-Episoden, Musiktitel oder Vorträge.

Jeder Titel bringt seine Metadaten mit: Artwork, Interpret, Titelnummer und Titellänge. Die Titelliste ist konfigurierbar – du legst die Abspielreihenfolge fest und kannst Artwork, Interpreten, Titelnummern und Titellänge einzeln ein- oder ausblenden, passend zum Design deiner Seite.

Die WaveformPlayer-Visualisierung kommt mit einer Auswahl für den Visualisierungsstil. Du kannst Farben für die Wellenform und ihren Hintergrund festlegen und das Titel-Artwork auf dem Abspiel-Button anzeigen – zugänglich für alle Besucher*innen. Die Blöcke „Playlist“ und „Playlist-Titel“ sind in der Standard-Block-Bibliothek verfügbar.

Das ist die erste Version. Und die Mitwirkenden arbeiten bereits an Verbesserungen für die nächste WordPress-Version: mehr Wellenform-Stile, Buttons für Zufallswiedergabe und Überspringen, ein Hover-Overlay für intuitiveres Spulen sowie Performance-Verbesserungen.

Tracking: Playlist Block: Iteration issue for 7.1 (#77421)

Tabs-Block

Der neue Tabs-Block organisiert Inhalte in getrennten Tab-Bereichen, durch die sich Besucher*innen klicken. Dieses Gestaltungsmuster präsentiert Informationen kompakt, ohne die Leserschaft mit einer Textwand zu erschlagen. Es ist ein gängiges Layout für FAQs, Produktmerkmale oder alle Inhalte, bei denen du Optionen nebeneinander zeigen möchtest. Für Redakteur*innen ist es ein vertrautes, flexibles Layout-Muster – jetzt nativ in WordPress verfügbar.

Die Block-Familie besteht aus einer Tab-Liste für die Navigation und Tab-Panels für die Inhalte. Jedes Panel nimmt beliebige Blöcke auf, und die Tab-Buttons bringen eigene Steuerelemente für Farbe, Typografie, Rahmen und Abstände mit, sodass sich die Navigation ans Theme anpassen lässt. Über die Buttons in der Werkzeugleiste ordnest du die Tabs schnell neu an.

Unter der Haube folgen Markup und Tastaturverhalten den Best Practices aus dem Tabs-Muster des W3C ARIA Authoring Practices Guide.

Tracking: Stabilize Tabs Blocks (#73230)

Verbesserte Blöcke und Block-Handling

Die Core-Blöcke erhalten in 7.1 zahlreiche Detailverbesserungen. Diese Updates verfeinern bestehende Bearbeitungsabläufe, vereinfachen den Umgang mit Medien und ermöglichen eine tiefere Anpassung von Layouts und Design.

Block-Umwandlungen: erst Vorschau, dann schneller umwandeln

[end user][site admin]

Das Ändern von Aussehen oder Typ eines Blocks lässt sich jetzt viel leichter beurteilen, bevor du dich festlegst. Wenn du den Block-Umschalter in der Werkzeugleiste öffnest, zeigen die vom Theme bereitgestellten Stil-Optionen – etwa der „Outline“-Stil eines Buttons – beim Überfahren mit der Maus eine Live-Vorschau. So siehst du genau, wie dein Block mit dem Stil aussehen wird (75889). Dieselben Vorschauen im Stile-Panel des Inspectors entsprechen jetzt der Darstellung in der Werkzeugleiste – es spielt also keine Rolle mehr, wo du den Wechsel vornimmst (75989). Eine kleine Politur zentriert außerdem die Vorschau des Navigations-Blocks in seinem Vorschaufenster (75741).

Auch die Umwandlungen selbst können mehr: Ein Block kann sich jetzt direkt in eine Variante eines anderen Blocks umwandeln. Statt erst in eine Gruppe umzuwandeln und danach „Reihe“ auszuwählen, bietet das Umwandlungsmenü „Reihe“ oder „Stapel“ als direkte Ziele an – ein Schritt statt zwei (78713).

Derselbe Gedanke – ein Schritt statt zwei – gilt auch für Alt-Inhalte. Das Einfügen oder Umwandeln eines Embed-Shortcodes erzeugt jetzt einen richtigen Embed-Block, statt rohen Shortcode-Text zu hinterlassen. Einbettungen von YouTube und anderen Diensten werden so sofort korrekt angezeigt (77937). Und wenn du es dir anders überlegst, stellt „Rückgängig“ einen Absatz mit der URL wieder her, statt sie zu löschen (77551).

Der Shortcode-Block zieht ebenfalls mit: Wenn sein Inhalt einem registrierten Shortcode entspricht, bietet er jetzt blockspezifische Umwandlungen in den entsprechenden Block an (77944).

Für alle, die eine Website mit jahrelang gewachsenen Shortcode-Beiträgen pflegen, entfällt damit ein mühsamer Aufräumschritt auf dem Weg zur blockbasierten Bearbeitung.

Verläufe und Hintergrundbilder kombinieren

[end user][theme builder][site admin]

Mehr Blöcke unterstützen jetzt Hintergrund-Verläufe über den neuen Block-Support background.gradient, der einen Verlauf über ein Hintergrundbild legt, statt dass eines das andere überschreibt – zum Beispiel ein durchscheinender Farbschleier über einem Foto, ohne individuelles CSS.

Bisher lebten Verläufe nur im Farben-Panel, gespeichert als CSS-Hintergrund-Kurzschreibweise, die mit jedem Bild auf dem Block kollidierte. Der neue Support fügt dem Hintergrund-Panel ein Verlauf-Steuerelement neben dem bestehenden Bild-Steuerelement hinzu, und die Style-Engine kombiniert beide zu einem einzigen, geschichteten background-image-Wert – an einzelnen Blöcken, in den globalen Stilen und über die theme.json. Eine Folgeänderung erlaubt moderne Farbfunktionen in eigenständigen Verläufen, und die Steuerelemente für Text- und Hintergrundfarbe sind passend dazu in die Panels Typografie und Hintergrund umgezogen.

WordPress 7.1 wird mit sechs Blöcken ausgeliefert, die die neuen Verläufe unterstützen: Gruppe, Vers, Akkordeon, Pullquote, Beitragsinhalt und Zitat. Weitere folgen – langfristig soll das ältere color.gradient bei allen Blöcken auf das neue System migriert werden. Einen eingebauten Migrationspfad gibt es in 7.1 zumindest aktuell noch nicht.

Für Erweiterungs-Entwickler*innen folgt das Aktivieren dem vertrauten Block-Supports-Muster. Individuelle Blöcke deklarieren es in ihrer block.json:

"supports": {
    "background": {
        "gradient": true
    }
}

Themes steuern die Einstellung über die theme.json unter settings.background.gradient (sie ist auch in appearanceTools enthalten) und können Verlauf-Werte in styles definieren – auf Root-Ebene, pro Block oder in Stil-Varianten:

{
    "styles": {
        "background": {
            "gradient": "linear-gradient( 135deg, #000 0%, #fff 100% )"
        },
        "blocks": {
            "core/group": {
                "background": {
                    "gradient": "var:preset|gradient|vivid-cyan-blue"
                }
            }
        }
    }
}

Alle wesentlichen Details in dieser Dev-Note: »New Block Support in WordPress 7.1: Background Gradient (background.gradient)«

Cover-Block: Video-Embed-Anbieter steuern

[theme builder][plugin author][enterprise][developer]

Neben dem neuen Medien-Editor-Dialogfenster für Hintergrundbilder greift der Cover-Block einen Wunsch aus dem Community-Feedback auf. Als die Funktion „Video per URL einbetten“ in WordPress 7.0 erschien, baten Site-Builder um eine Möglichkeit, sie zu kuratieren oder zu deaktivieren. WordPress 7.1 fügt ein neues Attribut allowedVideoProviders hinzu, mit dem sich die angebotenen Video-Anbieter einschränken lassen – oder die URL-Einbettung ganz entfernen lässt, indem keiner erlaubt wird (80092). Bestehende Einbettungen funktionieren weiter; nur die neue URL-Eingabe im Editor wird eingeschränkt.

Die Details stehen bereits in der Dokumentation des Cover-Blocks.

Galerie und der Workflow mit angehängten Bildern in der Mediathek

[end user][site admin]

Bilder, die du beim Schreiben eines Beitrags hochlädst, waren schon immer an diesen Beitrag „angehängt“. Das gilt besonders für ältere Websites aus der Zeit vor dem Block-Editor. Angehängte Bilder waren bisher nicht als Gruppe zugänglich und mussten einzeln in den Block-Editor eingefügt werden. WordPress 7.1 macht diese Beziehung endlich im Editor nutzbar – über einen zusätzlichen Filter-Eintrag Zu diesem Beitrag hochgeladen im Mediathek-Dialogfenster des Inserters. Fotos und andere Medien, die du hochgeladen hast, bleiben für die Wiederverwendung in Reichweite, statt in der Mediathek zu verschwinden.

Der Galerie-Block ist das Schaufenster: Statt jedes Bild von Hand auszuwählen, füllt ein einziger Button Angehängte Bilder verwenden eine dynamische Galerie mit allen Medien, die am aktuellen Beitrag hängen (78796). So stellst du Bildergalerien schneller und flexibler zusammen. Das hilft auch beim Neuordnen von Bildern in älteren Beiträgen. Das Panel „Quelle“ bietet Optionen zum Sortieren der Bilder. Damit zieht die Handhabung von Galerien im Block-Editor mit einigen Funktionen des Galerie-Shortcodes gleich.

Für volle Kontrolle über den Galerie-Block gibt es die Funktion „Lösen“: Ein Lösen-Button in der Werkzeugleiste und im Panel Quelle der Seitenleiste macht daraus eine eigenständige Galerie ohne die dynamische Verbindung zu den Bildern des Beitrags. So lässt sich der Galerie-Block anschließend frei bearbeiten und aktualisieren.

Das Video im Originalbeitrag veranschaulicht die Verbindung zwischen der Liste der an einen Beitrag angehängten Bilder in der Mediathek und dem Galerie-Block mit der neuen Funktion.

Tracking: WordPress 7.1: dynamic galleries and post-attached media iteration issue (#77117)

Es ist ein Schritt zurück zur Einfachheit, Fotos in einen Beitrag zu werfen und WordPress das Anordnen zu überlassen. Und es ist das erste sichtbare Stück einer größeren Initiative rund um dynamische Galerien und beitragsgebundene Medien – mit dynamischen Abfragen nach Datum und später auch nach Kategorien oder Schlagwörtern.

Bild-Block: Schalter „Als dekorativ markieren“

[end user][site admin]

Screenreader kündigen ihren Nutzer*innen jedes Bild an. Aber manche Bilder, etwa Trennlinien und Zierelemente, enthalten keine Information, die es anzukündigen lohnt. Die neue Checkbox „Als dekorativ markieren“ im Bild-Block weist assistive Technologien an, ein solches Bild im Frontend komplett zu überspringen – es wird im veröffentlichten Beitrag mit role="none" ausgegeben. Damit erübrigt sich die Frage: Wurde der Alt-Text vergessen, oder war das leere Feld eine bewusste Entscheidung?

Mit dem Setzen des Häkchens passiert noch mehr: Das Markieren als dekorativ leert den Alt-Text und deaktiviert Beschriftungen und Links. Denn ein Bild, das irgendwohin verlinkt oder etwas erklärt, ist per Definition nicht dekorativ. Bisher bestand der barrierefreie Weg darin, die Konvention mit dem leeren Alt-Text zu kennen; die Checkbox macht die Absicht explizit, maschinenlesbar und für alle verfügbar, die Inhalte pflegen (78064).

Verbesserungen am Anmelden/Abmelden-Block

[theme builder][site admin][developer]

Der Anmelden/Abmelden-Block hat eine Option, statt eines einfachen Links ein vollständiges Anmeldeformular anzuzeigen. Bisher ignorierte der Absende-Button dieses Formulars dein Theme allerdings vollständig und erschien mit schlichten Browser-Standardstilen, die neben allen anderen Buttons der Website aus dem Rahmen fielen. Mit einem aktiven Block-Theme trägt der Absende-Button jetzt die Standard-Button-Klassen (wp-block-button__link und wp-element-button) und übernimmt damit automatisch das Button-Styling, das dein Theme in der theme.json definiert – Farben, Eckenradius und alles Weitere, ganz ohne individuelles CSS. Der Block folgt demselben Ansatz, den das Kommentarformular bereits verwendet, und behebt damit eine Unstimmigkeit, die erstmals 2023 gemeldet wurde (76746).

Navigations-Block und das Anlegen von Links

[theme builder][site admin][end user]

Der Navigations-Block erhält mehrere Verbesserungen, die Site-Buildern mehr Freiheit geben, was ein Menü enthalten kann und wo es sich bearbeiten lässt. Der Anmelden/Abmelden-Block kann jetzt in Untermenüs verschachtelt werden (#75497) – praktisch, um Konto-Aktionen in einem „Mein Konto“-Dropdown unterzubringen, statt dafür einen Platz auf oberster Ebene zu opfern. Neue Links lassen sich direkt aus der Listenansicht in der Seitenleiste des Website-Editors anlegen (#75918) – für den Menüaufbau musst du also nicht mehr jeden Eintrag einzeln auf der Arbeitsfläche anklicken. Und der Startseiten-Link-Block erhält bisher fehlende Steuerelemente (#76672) und zieht damit mit seinen Navigations-Geschwistern gleich.

Eine Verhaltensänderung sollten sich Theme-Autor*innen vormerken: Der Navigations-Block gibt seine Schriftgröße nicht mehr zwangsweise an die einzelnen Menüpunkte weiter (77419). Bisher erhielt jeder Navigations-Link, jedes Untermenü und jeder Seitenlisten-Eintrag das Schriftgrößen-Markup des Eltern-Elements. Und weil sich relative Einheiten multiplizieren, schaukelten sich verschachtelte Dropdowns dramatisch auf: aus 1.5em wurden 2.25em, dann 3.375em.

Der Block setzt jetzt stattdessen auf die normale CSS-Vererbung, was zugleich abweichende Typografie zwischen der Editor-Arbeitsfläche und dem Frontend behebt. Die meisten Themes müssen nichts ändern. Themes, die has-{slug}-font-size-Klassen direkt an Navigationselementen ansprechen, sollten ihre Menüs aber prüfen – die Dev-Note »Miscellaneous Editor Changes« enthält einen Filter, der bei Bedarf das alte Markup wiederherstellt.

Styling des Suche-Blocks

[theme builder][site admin][end user]

Das Release schließt eine Styling-Lücke beim Suche-Block: Farbeinstellungen wirken jetzt auch dann auf das Sucheingabefeld, wenn der Such-Button deaktiviert ist (77219) – deine Suchfelder passen also unabhängig von den gewählten Anzeigeoptionen zu deinem Designsystem.

Der Block setzt außerdem auf modernes HTML: Er kann jetzt innerhalb des nativen <search>-Landmark-Elements gerendert werden, das Such-Semantik für Browser und assistive Technologien mitbringt – ohne das manuelle role="search"-Attribut. Weil das Weglassen dieses Attributs bestehendes Theme-CSS brechen könnte, ist die Funktion optional aktivierbar: pro Block über eine neue HTML-Element-Auswahl im Panel „Erweitert“ oder websiteweit mit add_theme_support( 'search-element' ). Die Standardausgabe bleibt unverändert, mit der Aussicht, das moderne Markup in einem zukünftigen Release zum Standard zu machen (78485).

Query-Block

[theme builder][site admin][end user]

Der Query-Block hat einen zusätzlichen Filter zur Steuerung der Beitragsliste erhalten: Du kannst jetzt den aktuellen Beitrag aus einer Beitragsliste ausschließen. Das ist nützlich, wenn du eine Liste mit ähnlichen Beiträgen anzeigen möchtest (64916).

Allgemeine Detailverbesserungen

Verbesserungen beim Bearbeiten von Vorlagen

[theme builder][site admin][developer]

WordPress 7.0 hat die Vorlagen-Bearbeitung auf Inhaltsänderungen fokussiert, statt jedes Werkzeug offenzulegen – Vorlagen verhalten sich seither eher wie einzelne Blöcke. In 7.1 konzentriert sich die Arbeit auf UX-Verfeinerungen auf Basis von Feedback, Fehlerkorrekturen und allgemeine Pflege. Wer Vorlagen einfügt und anpasst, bekommt ein runderes, vorhersehbareres Erlebnis mit weniger Ecken und Kanten.

Tracking: WordPress 7.1: Pattern Editing Iteration (#75717)

• Vorlagen-Bearbeitung und Block-Felder: ausgewählten Block hervorheben (74841)
• Vorlagen-Bearbeitung: Identität des Root-Blocks beim Bearbeiten von Vorlagen-Abschnitten anzeigen (79417)

Steuerelemente für Blockbreite und Layout

[theme builder][site admin][developer]

Die Abstands- und Layout-Werkzeuge werden intuitiver. Der Spalten-Block zeigt in seiner Layout-Auswahl keine verwirrende „Überspringen“-Option mehr, der Button-Block verwendet jetzt das Standard-System für die Breitensteuerung, und die Abstands-Steuerelemente erscheinen in einer logischeren Reihenfolge, wenn sie entkoppelt sind. Diese Änderungen beseitigen Stolpersteine beim Bau komplexer Layouts.

• Button: auf den Block-Support „width“ migriert (74242)
• Spalten: überflüssige „Überspringen“-Option aus der Layout-Auswahl entfernt (78405)
• Abstands-Steuerelemente bei entkoppelten Seiten neu angeordnet (66317)

Verbesserungen an Link-Steuerung und Vorschau

[theme builder][site admin][developer]

Beim Verlinken auf Seiten oder Beiträge zeigt die Link-Auswahl für die Startseite deiner Website jetzt „Homepage“ statt nur „Seite“ an und verwendet den tatsächlichen Link-Titel des Elements für die Vorschau. Diese kleinen Verbesserungen machen das Anlegen von Links schlauer und helfen Redakteur*innen zu verstehen, worauf sie verlinken, bevor sie veröffentlichen.

• Link-Titel des Elements für die Vorschau der Link-Steuerung verwenden (77155)
• Link-Auswahl: Badge „Homepage“ statt „Seite“ für die Startseite (75929)

Validierung für zusätzliches CSS

[theme builder][site admin][developer][end user]

Zusätzliches CSS wird jetzt sowohl beim Laden als auch über einen neuen Validierungs-Endpunkt für nachgeladene Stile geprüft. Diese Prüfungen verhindern, dass fehlerhaftes oder unsicheres CSS das Erscheinungsbild deiner Website zerstört oder Sicherheitsrisiken einführt – und geben dir mehr Vertrauen beim Hinzufügen eigener Stile.

• Zusätzliches CSS beim Laden validieren (78682)
• Dimensions-Validierung für den Sideload-Endpunkt (74903)

Attribut-Handling im Block-Editor

[theme builder][developer]

Der Block-Editor wählt beim Kopieren von Direct-Insert-Block-Attributen jetzt den richtigen Ziel-Block aus und behebt damit Grenzfälle, in denen Attribute auf den falschen Block angewendet wurden. Kopieren, Einfügen und Duplizieren verhalten sich damit wie erwartet.

• Block-Editor: Ziel-Block beim Kopieren von Direct-Insert-Block-Attributen korrigiert (77877)
• Block-Editor: Überschreiben der Einstellung disableContentOnlyForTemplateParts erlaubt (79191)

Verbesserter Umgang mit Bildern

[end user][site admin]

Eine Reihe kleiner Korrekturen macht die Arbeit mit Bildern berechenbarer. Verweist ein Bild auf ein inzwischen gelöschtes Mediathek-Element, behandelt der Editor es nicht mehr als lokalen Anhang und verhindert damit verwirrende Fehlermeldungen. Der Zuschneiden-Button erscheint nur, wenn das Zuschneiden für deine Benutzerrolle und deinen Bildtyp tatsächlich verfügbar ist – dir wird also nie ein Werkzeug angeboten, das nicht funktionieren kann.

Und das Beitragsbild-Feld zeigt jetzt einen Platzhaltertext, der auf einen Blick klar macht, was dort hingehört.

• Bild-Block: prüfen, ob die Anhang-ID existiert, bevor ein Bild als lokal behandelt wird (77178)
• Bild/Website-Logo: Zuschneiden-Werkzeugleiste ausblenden, wenn editMediaEntity nicht verfügbar ist (76626)
• Platzhalter für das Beitragsbild-Feld gesetzt (76342)

Layout-Verbesserungen beim Beitrags-Template

[theme builder][site admin]

Die Fallback-Stile des Beitrags-Template-Blocks greifen jetzt nur noch, wenn es angemessen ist. Das verhindert Layout-Konflikte, wenn individuelle minimale Spaltenbreiten definiert sind. Diese Korrektur gibt Redakteur*innen eine berechenbarere Kontrolle über Query-Loop-Layouts ohne unerwartete Stil-Überschreibungen.

• Sicherstellen, dass die Fallback-Stile des Beitrags-Templates nicht greifen, wenn minimumColumnWidth definiert ist (77411)

Verbesserungen am Beitragstitel-Block

[site admin][end user]

Der Titel-Block erhält ein Platzhalter-Attribut, mit dem sich ein Hinweistext anzeigen lässt, solange noch kein Titel eingegeben wurde. Diese kleine Ergänzung verbessert die Bearbeitung bei individuellen Inhaltstypen und führt dich zu den auszufüllenden Feldern.

• Beitragstitel: Platzhalter-Attribut hinzugefügt (76016)

Verbesserungen am Block-Inserter

[site admin][end user]

Das Entdecken und Hinzufügen von Blöcken wird durch visuellen Feinschliff am Inserter leichter. Das Suchfeld bleibt beim Scrollen durch die Block-Optionen sichtbar, und der Inserter-Button zeigt mit einer Animation deutlich an, wann das Panel geöffnet ist. Diese kleinen Details verringern die Reibung beim Seitenbau und helfen dir, beim Erkunden der Block-Optionen die Orientierung zu behalten.

• Block-Inserter: Icon des Inserter-Buttons animiert, um den geöffneten Zustand zu signalisieren (78306)
• Suchfeld des Block-Inserters bleibt beim Scrollen fixiert (77698)

Verbesserungen am Editor

Über die Block-Verbesserungen hinaus wird auch das Bearbeiten selbst auf ganzer Linie verfeinert. Die Notizen reifen zu einem vollwertigeren Kommentar-Workflow heran. Die visuellen Revisionen erhalten eine detailliertere Zeitleiste. Und die Markenidentität deiner Website bekommt ein eigenes Zuhause im Website-Editor.

Eine Dev-Note listet die verschiedenen weiteren Änderungen am Editor auf.

Notizen auf dem Weg zu einem vollständigen Kommentar-Workflow

[end user][site admin][developer][enterprise]

Die Notizen – redaktionelle Anmerkungen direkt im Editor – reifen weiter. Mehrere Neuerungen in diesem Release machen die asynchrone Zusammenarbeit reicher und leichter umsetzbar, ohne WordPress zu verlassen.

Die wichtigste Neuerung: Inline-Notizen. Du kannst eine Notiz jetzt an eine bestimmte Textauswahl anhängen statt an einen ganzen Block. Markiere einen Teil eines Absatzes, füge eine Notiz hinzu – und die Hervorhebung bleibt an diesem Text verankert, während du drumherum weiter bearbeitest. Ein einzelner Block kann mehrere Inline-Notizen tragen, sortiert nach ihrer Reihenfolge im Text, und nichts von der Hervorhebung erscheint im veröffentlichten Beitrag. Blöcke sind auch nicht mehr auf eine einzige Unterhaltung beschränkt: Du kannst mehrere Notiz-Threads am selben Block beginnen.

Auch die Unterhaltungen selbst wurden ausdrucksstärker. Notizen unterstützen jetzt Rich-Text-Formatierung – fett, kursiv, Links und Code. Die @-Erwähnung mit Autovervollständigung holt Kolleg*innen schnell in einen Thread. Längere Notizen klappen hinter einem „Mehr anzeigen“-Schalter zusammen, und ein „Erledigt“-Trenner in der Seitenleiste trennt abgeschlossene Diskussionen von offenen. So siehst du leicht, was noch Aufmerksamkeit braucht.

Tracking: Notes iteration for WordPress 7.1 (#76316)

Eigener Bereich „Identität“

[site admin][theme builder][end user]

Eine neue Ansicht Design > Editor > Identität bündelt Logo, Favicon, Titel und Untertitel deiner Website an einem leicht auffindbaren Ort – mit Inline-Bearbeitung, sodass du Bilder direkt dort zuschneiden und anpassen kannst. Das erspart die Suche in den Einstellungen oder das Wühlen in Templates, nur um grundlegendes Branding zu aktualisieren. Besonders wenn du gerade erst anfängst, eine Website zu bauen, ist das Einrichten der Website-Identität damit schnell und unkompliziert. Und wer schon länger eine Website betreibt, hat einen intuitiven Ort, um die Daten zu aktualisieren (76264, 76116).

Verbesserungen an den visuellen Revisionen

[site admin][end user][theme builder]

Aufbauend auf den in 7.0 eingeführten visuellen Revisionen erhält die Revisionsansicht eine seitenweise Zeitleiste im Inspector mit detaillierteren Informationen zu jeder Revision. So lässt sich beim Durchblättern der Versionen leichter nachvollziehen, was sich geändert hat (77333).

Änderungen durch die automatische Speicherung werden in der Revisions-Zeitleiste jetzt gekennzeichnet, und der Hinweis zur automatischen Speicherung funktioniert mit der Oberfläche der visuellen Revisionen zusammen (79950, 79947).

„Global anwenden“ jetzt mit Überprüfungs-Panel

Die Aktion Global anwenden im Block-Inspector – bisher ein Ein-Klick-Push der lokalen Stiländerungen eines Blocks in die globalen Stile – hat in WordPress 7.1 ein Upgrade erhalten: Designer*innen können jetzt feiner steuern, welcher Teil der Stile in die globalen Stile übernommen wird.

Der Button öffnet nun ein Überprüfungs-Dialogfenster, das jeden geänderten Stil mit aktuellem und neuem Wert auflistet. Alle Änderungen sind vorausgewählt; wähle die ab, die du als lokale Überschreibungen behalten möchtest – nur die markierten Stile werden angewendet. „Rückgängig“ stellt den vorherigen Zustand weiterhin in einem Schritt wieder her. Was bisher eine etwas riskante Aktion war, ist jetzt eine bewusste Entscheidung: Du siehst genau, was sich auf deiner Website ändern wird, bevor du es bestätigst (79839).

Admin-/Workflow-Updates

Die Updates an Admin- und Workflow-Werkzeugen in 7.1 verbessern Navigation, Inhaltsverwaltung und Website-Administration. Sie sollen Reibung verringern und dir helfen, im WordPress-Dashboard effizienter zu arbeiten.

Aufgeräumte Befehlspalette

[all]

Die Befehlspalette – das Schnellzugriffsmenü, das du per Tastatur-Shortcut öffnest – gruppiert Ergebnisse jetzt in die Bereiche „Zuletzt verwendet“, „Vorgeschlagen“ und „Treffer“ und merkt sich deine zuletzt verwendeten Befehle über Sitzungen hinweg. Auch das visuelle Design wurde aufgefrischt, damit sich die Ergebnisse leichter überfliegen lassen. So navigierst du schneller durch WordPress, weil die am häufigsten genutzten Werkzeuge ganz oben erscheinen (75691).

Übergeordneten Kommentar direkt in der Kommentar-Bearbeitung ändern

[end user][site admin][enterprise]

Musstest du je einen Kommentar reparieren, der im falschen Thread gelandet ist? Die Ansicht „Kommentar bearbeiten“ hat jetzt ein Steuerelement „Antwort auf“ in der Speichern-Box: Ein Klick auf „Bearbeiten“ öffnet ein Dropdown mit den anderen Kommentaren des Beitrags, aufgelistet nach Autor*in mit einem kurzen Textauszug. Kommentare auf oberster Ebene zeigen einfach „Keine“.

Kaputte Threads kannst du damit nicht erzeugen: Das Dropdown blendet den Kommentar selbst und alles darunter Verschachtelte aus, und der Server prüft beim Speichern noch einmal – der neue übergeordnete Kommentar muss zum selben Beitrag gehören und darf weder der Kommentar selbst noch eine seiner eigenen Antworten sein (Ungültiges wird mit einem WP_Error abgewiesen). Wenn der aktuelle übergeordnete Eintrag normalerweise nicht in der Liste erscheinen würde (etwa ein Pingback), bleibt er als ausgewählte Option erhalten – Speichern ohne Anfassen des Feldes ändert also nichts. Funktioniert auch ohne JavaScript, und die Validierung ist mit Tests abgedeckt (65570).

Textauszug bei Beiträgen ohne Titel sehen

[end user][site admin]

Wenn du Beiträge ohne Titel veröffentlichst – etwa für schnelle Status-Updates – war die Beitragsliste bisher ziemlich nutzlos, um sie auseinanderzuhalten: nur eine Spalte identischer „(Kein Titel)“-Links.

In der kompakten Ansicht zeigen Beiträge ohne Titel jetzt die ersten 15 Wörter des Textauszugs direkt hinter „(Kein Titel)“. So siehst du auf einen Blick, worum es in jedem Beitrag geht.

Die Screenreader-Beschriftung der Checkbox erhält denselben Text, passwortgeschützte Beiträge halten ihren Inhalt weiterhin verborgen, und die erweiterte Ansicht bleibt unverändert, da sie bereits Textauszüge anzeigt (65022).

Mediathek: endloses Scrollen ist standardmäßig zurück – mit Abschaltmöglichkeit pro Benutzer*in

[end user][site admin]

Die Rasteransicht der Mediathek verwendet jetzt standardmäßig endloses Scrollen: Anhänge laden fortlaufend beim Scrollen, statt hinter einem „Mehr laden“-Button. Wer das bisherige Verhalten bevorzugt, hat eine neue persönliche Option: die Checkbox „Endloses Scrollen in der Rasteransicht der Mediathek deaktivieren“ im Profil. Die Einstellung erscheint nur bei Benutzer*innen, die Dateien hochladen dürfen – alle anderen sehen das Anhang-Raster ohnehin nie.

Für Entwickler*innen funktioniert der bestehende Filter media_library_infinite_scrolling weiterhin und hat jetzt oberste Priorität: Ein eingehängter Filter gewinnt immer, danach folgt die Profil-Einstellung, und wenn beides fehlt, ist das endlose Scrollen aktiviert. Beachte, dass der Standardwert des Filters mit 7.1.0 von false auf true gewechselt ist – Code, der sich auf den alten Standard verlässt, sollte überprüft werden. Die Änderung wird mit Unit-Tests für die neue Benutzer-Option und die vollständige Prioritätskette ausgeliefert (65564).

Lies die Dev-Note »Media Library infinite scrolling is now enabled by default, with a per-user opt-out«.

Hosting-Anbieter können jetzt die Standardwerte für spekulatives Laden anpassen

Seit WordPress 6.8 können Browser dank spekulativem Laden Seiten vorab laden oder vorab rendern, die Besucher*innen wahrscheinlich als Nächstes öffnen. Die Navigation fühlt sich damit nahezu verzögerungsfrei an. WordPress liefert bewusst vorsichtige Standardwerte aus, und bisher war für deren Änderung ein mu-Plugin nötig. Mit WordPress 7.1 können Hosting-Anbieter und Website-Betreiber*innen den Standard-Modus und die Eagerness-Stufe über Umgebungsvariablen oder Konstanten in der wp-config.php anpassen. Ein gut konfigurierter Host mit Seiten- und Objekt-Caching kann seine Websites für aggressiveres spekulatives Laden freischalten und den Geschwindigkeitsgewinn an die Besucher*innen weitergeben. Die Praxisdaten, die Hosts auf diesem Weg sammeln, helfen außerdem bei der Entscheidung, ob der Core die Standardwerte in einem zukünftigen Release für alle ändert. Die technischen Details stehen im Core-Ticket (65624).

Developer Goodies

[developer][theme builder][plugin author][enterprise]

WordPress 7.1 bietet Entwickler*innen erweiterte APIs, neue theme.json-Fähigkeiten und Systemverbesserungen. Diese Werkzeuge geben mehr Kontrolle über Website-Design, Block-Verhalten und System-Integrationen.

Beitrags-Editor jetzt immer im Iframe

Die anderen Editoren in WordPress – der Website-Editor, der Template-Editor sowie Block-, Template- und Geräte-Vorschauen – laufen schon lange bedingungslos in einem Iframe, zurückgehend auf die Einführung des Template-Editors in 5.8. Der Beitrags-Editor war der Nachzügler: Seit 7.0 hing die Isolation von den tatsächlich vorhandenen Blöcken eines Beitrags ab. Ein Beitrag nur mit Blöcken der Block-API v3+ bekam die isolierte Arbeitsfläche; ein Beitrag mit auch nur einem älteren Block (API v1 oder v2) fiel komplett heraus. Dieselbe Website – sogar dieselbe Autorin – konnte den Editor also von Beitrag zu Beitrag unterschiedlich erleben. In 7.1 entfällt diese Bedingung: Jeder Beitrags-Editor läuft jetzt immer im Iframe, unabhängig vom Theme-Typ oder der Block-API-Version.

Für die meisten, die Inhalte schreiben und bearbeiten, ist das eine gute Nachricht – kein wechselndes Verhalten mehr, je nachdem, welche Blöcke gerade eingefügt sind. Block-Entwickler*innen haben allerdings etwas Hausaufgaben: Das Iframe hat ein eigenes document und window, getrennt von der Admin-Seite, auf der die Editor-Skripte laufen. Jeder Code, der über das globale document oder window auf die Arbeitsfläche zugreift, schaut jetzt also an die falsche Stelle. Die übliche Lösung: das document der Arbeitsfläche über ein Element darin ermitteln (via ownerDocument und dessen defaultView) statt über das globale Objekt – und useRefEffect verwenden, um Event-Listener auf der Arbeitsfläche anzuhängen und wieder aufzuräumen.

Lies die Dev-Note zu den Änderungen in 7.1 und den Migrationsleitfaden für Blöcke für mehr Details.

Ryan Welcher hat einen Leitfaden und ein Demo-Plugin veröffentlicht: »The post editor is going full iframe: what block developers need to know before WordPress 7.1« – mit Codebeispielen und Anleitungen, wie sich Probleme bei Bedarf beheben lassen.

Die Abilities API öffnet ihre Ausführungs-Pipeline

Die Abilities API kam mit WordPress 6.9, und 7.1 gibt Erweiterungs-Entwickler*innen echte Kontrolle darüber. Vier neue Lifecycle-Filter lassen Plugins in die Ausführung von Abilities eingreifen: Sie können sie komplett abkürzen (etwa für Caching, Rate-Limiting oder Wartungsmodus), Eingaben transformieren, zusätzliche Autorisierungsregeln aufsetzen oder Ergebnisse umformen und sogar retten. Zwei weitere Filter ergänzen eine eigene Ein- und Ausgabe-Validierung zusätzlich zum JSON-Schema, und eine neue Action wp_ability_invoked feuert bei jedem Aufruf – auch bei fehlgeschlagenen – praktisch für Logging und Auditing. Die Core-Info-Abilities liefern mehr Benutzerdetails, Eingaben über die REST-API kommen jetzt korrekt typisiert an, und wp_prepare_json_schema_for_client() entfernt PHP-Callbacks und WordPress-eigene Konventionen, bevor ein Schema an REST-Clients, MCP-Integrationen oder KI-Werkzeuge herausgeht.

Ein neues Metadaten-Flag public rundet das Ganze ab: Einmal deklarieren, dass eine Ability für externe Clients gedacht ist – und REST, MCP-Adapter und zukünftige Integrationen verwenden das als Standard. Kanalspezifische Flags können es weiterhin überschreiben, und Berechtigungs-Callbacks sichern nach wie vor die eigentliche Ausführung ab.

Auch das Auffinden der passenden Abilities wird leichter: wp_get_abilities() akzeptiert jetzt Argumente, um registrierte Abilities nach Kategorie, Namespace oder Meta zu filtern – dieselbe Filterung steht auch am REST-Endpunkt zur Verfügung.

Details und Codebeispiele in diesen Dev-Notes:

• New execution lifecycle filters for the Abilities API
• Abilities API improvements
• JSON Schema preparation for client compatibility
• A unified public exposure flag for Abilities
• Filtering registered abilities with wp_get_abilities() in WordPress 7.1

Globale Stile und theme.json

Text-Shadow-Unterstützung in der theme.json

Theme-Autor*innen können jetzt Textschatten direkt in der theme.json definieren – über eine neue Eigenschaft textShadow unter styles.typography. Sie funktioniert überall, wo man es erwartet: auf Root-Ebene, pro Block (etwa ein Schatten nur für Absätze), über Stil-Varianten und an Elementen, einschließlich Pseudo-Selektoren wie dem :hover-Zustand eines Links. Jeder gültige CSS-text-shadow-Wert wird akzeptiert, auch gestapelte Mehrfach-Schatten. Platzhaltertext von Blöcken setzt den Schatten im Editor zurück, damit er unabhängig von den Theme-Einstellungen lesbar bleibt.

"styles": {
    "typography": {
        "textShadow": "1px 1px 2px red, 0 0 1em blue, 0 0 0.2em blue"
    },
    "blocks": {
        "core/paragraph": {
            "typography": {
                "textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
            }
        }
    },
    "elements": {
        "link": {
            ":hover": {
                "typography": {
                    "textShadow": "none"
                }
            }
        }
    }
}

Mehr Details in der Dev-Note »Text Shadow Support in Global Styles«

Migration auf den Block-Support „text-align“

Neun weitere Core-Blöcke (Beitragsdatum, Beitrags-Textauszug, Beitrags-Navigations-Link, Beitragstitel, Query-Titel, Website-Untertitel, Website-Titel, Pullquote und Begriffs-Name) verwenden jetzt das standardisierte text-align-System von WordPress. Als Teil einer größeren Migrations-Initiative sorgt dieses Update für konsistente Ausrichtungs-Steuerelemente im gesamten Editor und dafür, dass sich diese Blöcke neben neueren Blöcken vorhersehbar verhalten.

Als Endanwender*in solltest du keine Änderungen bemerken, und bestehende Blöcke funktionieren weiter. Theme-Designer*innen können die Textausrichtung dieser Blöcke jetzt über eine theme.json-Eigenschaft gestalten. Das Codebeispiel zeigt, wie sich „zentriert“ websiteweit als Standard für die Textausrichtung setzen lässt. Und mit "textAlign": false deaktivierst du die Funktion für den jeweiligen Block.

{
    "version": 3,
    "styles": {
        "blocks": {
            "core/pullquote": {
                "typography": {
                    "textAlign": "center"
                }
            }
        }
    }
}

Block-Sichtbarkeit

Die theme.json erhält settings.blockVisibility.allowEditing, womit Themes die Funktion zur Block-Sichtbarkeit komplett deaktivieren können.

{
    "settings": {
        "blockVisibility": {
            "allowEditing": false
        }
    }
}

Steht der Wert auf false, werden der Button in der Werkzeugleiste und der Eintrag im Block-Optionen-Menü ausgeblendet. Damit verhält sich dieser Block-Support konsistent zu Farbe, Typografie und Co.

blockVisibility.allowEditing folgt dem Layout-Flag. Der Grund ist die Doppelnatur von blockVisibility auf Block-Supports-Ebene: Ein Boolean bedeutet „Block gar nicht rendern“, während die Viewport-Einstellungen dir die Sichtbarkeit pro Viewport überlassen.

Die Objekt-Form lässt außerdem die Tür offen, die Block-Sichtbarkeit später um weitere Auslöser zu erweitern – nicht nur blockVisibility.viewports, sondern etwa auch den Inhaltstyp oder anderes (76559).

Block-Supports: CSS-Variablen pro Feature-Selektor

Block-Supports erzeugen CSS-Custom-Properties jetzt auf Basis der Feature-spezifischen Selektoren eines Blocks – nicht mehr nur seines Root-Selektors. Manche Blöcke, der Button-Block ist das genannte Beispiel, definieren ihren äußeren Wrapper und ein inneres Styling-Ziel als verschiedene Elemente. Und bisher gab es keine Möglichkeit, eine Preset-Variable (etwa eine Größen-Dimension) gezielt auf dieses innere Element auszugeben. Theme- und Plugin-Autor*innen, die Designsysteme bauen, können jetzt pro Feature das richtige Element ansprechen – ohne individuelles CSS als Notlösung.

Eine Mindestbreiten-Option für Block-Dimensionen

Blöcke unterstützten bereits height, minHeight und width. Was fehlte, war eine Möglichkeit zu verhindern, dass etwas zu stark schrumpft – damit ein Layout-Element auf schmalen Bildschirmen nicht zu einem unbrauchbaren Streifen zusammenfällt. Die Mindestbreite schließt diese Lücke und spiegelt die Funktionsweise der Mindesthöhe.

Auf Block-Ebene ist sie optional aktivierbar: Das Steuerelement bleibt im Inspector verborgen, bis ein Block es explizit aktiviert; im Panel der globalen Stile wird es standardmäßig angezeigt. Vom Theme definierte Dimensions-Voreinstellungen werden automatisch übernommen – bestehende Größenskalen funktionieren also einfach. Der Gruppen-Block ist der erste, der die Funktion übernimmt.

Mehr Details in der Dev-Note »New Block Support in WordPress 7.1: Minimum Width«

Theme-Provider des Designsystems

Die erste Version der Theme-Komponente des Designsystems kommt mit WordPress 7.1. Sie besteht aus standardisierten CSS-Custom-Properties, die der W3C-Spezifikation für Design-Tokens folgen. Du wirst den Unterschied vermutlich nicht sofort bemerken – das Standard-Theme wurde bewusst passend zu den bestehenden Stilen gebaut. Aber das ist die Maschinerie, die künftig das Admin-Farbschema im Website-Editor antreiben wird. Mehr zur zukünftigen Richtung liest du im »Merge Proposal: Design System Theming«.

Die Dev-Note hat mehr: »Design System Theming in WordPress 7.1«

Admin-Farbschemata im Website-Editor

Seitenleiste und Oberfläche des Website-Editors respektieren jetzt dein gewähltes WordPress-Admin-Farbschema, statt immer einen dunklen Hintergrund zu zeigen. Das bringt visuelle Konsistenz über Beitrags-Editor, Website-Editor und Admin-Dashboard hinweg. Wenn du WordPress mit einem bevorzugten Farbschema personalisiert hast, begleitet dich diese Wahl jetzt überall, wo du arbeitest (78397).

Statisches HTML mit bearbeitbaren Blöcken mischen

Ein neuer Block-Support innerContent erlaubt es einem Block, statische HTML-Fragmente mit bearbeitbaren inneren Blöcken verschränkt als maßgebliche Quelle seines eigenen Markups zu führen. In der Praxis heißt das: In einer handgeschriebenen HTML-Struktur kann genau ein Teil – ein Absatz, ein Bild – direkt bearbeitbar sein, während der Rest fixiert bleibt und sich weder verschieben noch entfernen oder neu anordnen lässt.

Der Individuelles-HTML-Block ist der erste Anwendungsfall: Wird HTML mit einem eingebetteten Block-Kommentar-Delimiter eingefügt (zum Beispiel ein <!-- wp:paragraph -->-Block innerhalb eines größeren statischen <div>), wird dieser innere Teil direkt auf der Arbeitsfläche bearbeitbar, während das umgebende Markup an Ort und Stelle gesperrt bleibt. Vorerst ist das eine schmale, entwicklerorientierte Fähigkeit – der HTML-Block ist der einzige Ort, an dem sie verdrahtet ist. Aber sie öffnet die Tür dafür, dass individuelle Blöcke künftig dasselbe „größtenteils statisch, teilweise bearbeitbar“-Erlebnis anbieten können (79115).

Die Dev-Note steht im Make-Core-Blog: »Editable blocks inside the Custom HTML block«

Block Bindings für Listenelemente und innere Blöcke

Der Listenelement-Block unterstützt jetzt Block Bindings. Der Inhalt eines Listenelements kann mit einer Datenquelle verbunden werden – einem individuellen Feld, einem Pattern Override oder einer anderen registrierten Quelle –, sodass sich einzelne Einträge einer Liste dynamisch befüllen lassen, statt von Hand getippt zu werden. Die Änderung registriert content als bindbares Attribut für core/list-item.

Eine ergänzende Korrektur rundet die Funktion ab: Enthielt ein gebundenes Listenelement bisher zusätzlich eine verschachtelte Unterliste, ging diese beim Rendern der Bindung verloren. Jetzt kann ein Listenelement gleichzeitig einen gebundenen Wert und eine verschachtelte Liste darunter tragen. In der Praxis lassen sich damit mehrstufige Listen vollständig dynamisch aufbauen, ohne die Struktur zu verlieren – etwa der Name eines Teammitglieds aus einem individuellen Feld, mit einer verschachtelten Liste seiner aktuellen Projekte darunter.

Tracking: Block Bindings in WordPress 7.1 (#77199)

Verbesserungen bei der Connectors-Authentifizierung

Das Connectors-Framework, das die Verbindungen von WordPress zu externen Diensten wie KI-Anbietern verwaltet, unterstützt jetzt die Authentifizierung mit Benutzername und Anwendungspasswort als Alternative zu API-Schlüsseln. Ein zusammengeführter Pull Request ergänzt ein Standard-Connector-Formular für diese Methode samt dem zugrundeliegenden Authentifizierungstyp und spiegelt damit die entsprechende, bereits in WordPress Core verfügbare API.

Die Änderung kümmert sich auch um die praktischen Details: Gespeicherte Passwörter werden in der Oberfläche und über REST maskiert, Zugangsdaten lassen sich statt in der Datenbank über Konstanten oder Umgebungsvariablen setzen, und ein begleitender Core-Patch hält beides synchron. Für Connectors, die eine Konto-Anmeldung statt eines bloßen API-Schlüssels benötigen, entfällt damit die Notwendigkeit einer eigenen Einstellungsansicht.

Das landet neben einem breiteren offenen Vorschlag für eine PHP-seitige Feld-Registry, mit der Connector-Autor*innen beliebige Einstellungen deklarieren könnten – Modellwahl, Temperature, individuelle URLs und mehr – so, wie register_setting() an anderer Stelle in WordPress funktioniert. Diese Registry ist noch nicht gebaut. Die Arbeit an den Anwendungspasswörtern ist ein erster, konkreter Schritt (eine neue Authentifizierungsmethode, keine neuen Feldtypen) und adressiert eine der beiden im Vorschlag benannten Lücken – noch nicht die volle Vision.

Tracking: Connectors: proposal for a PHP-side field registry for connector configuration (#78647)

Das Blocks-Paket stabilisiert zwei experimentelle Funktionen

Das Blocks-Paket stabilisiert cloneSanitizedBlock und sanitizeBlockAttributes und legt ihre __experimental-Präfixe ab, nachdem die Funktionen in der Praxis schon länger stabil sind. Die alten Namen mit __experimental-Präfix funktionieren weiterhin, protokollieren aber einen Deprecation-Hinweis. Plugins oder Themes, die sie direkt importieren, sollten auf die neuen Namen wechseln.

Benachrichtigungen an Beitragsautor*innen: der Filter entscheidet

Der Filter notify_post_author hat jetzt das letzte Wort: Der Freigabestatus wird geprüft, bevor der Filter läuft. Er erhält dadurch einen korrekten Standardwert, und die Rückgabe von true verschickt zuverlässig eine Benachrichtigung – auch bei nicht freigegebenen Kommentaren. Websites, die Benachrichtigungen mit __return_true erzwingen, sollten auf einen Callback wechseln, der die Freigabe prüft. Sonst erhalten sie künftig auch E-Mails für Spam und Kommentare in der Moderation (64217). Mehr Details in der Dev-Note »The notify_post_author filter now has the final say on post author notifications«.

API für barrierefreie Tooltips und Toggle-Tips

WordPress erhält einen Core-Mechanismus für barrierefreie Tooltips (51006) – eine Alternative zum title-Attribut, das für Tastatur- und Touch-Nutzer*innen nicht zugänglich ist. Zwei neue Funktionen decken unterschiedliche Anwendungsfälle ab: wp_get_tooltip() stellt einen barrierefreien Namen bereit, wenn ein Steuerelement Fokus oder Hover hat – etwa bei Buttons, die nur ein Icon zeigen – und wp_get_toggletip() implementiert eine Popover-Auskunft mit erweiterten Hilfe-Informationen, die geöffnet bleibt, bis sie geschlossen wird. Beide erzeugen barrierefreies Markup, das übermäßige Geschwätzigkeit für Screenreader vermeidet und Best Practices für Nutzer*innen von Sprachsteuerung folgt.

Der erste Toggle-Tip im Core erklärt die Option „Angemeldet bleiben“ auf der Anmeldeseite (55343). Plugin-Entwickler*innen können die Funktionen für ihre eigenen Einstellungsansichten und Metaboxen verwenden (62741).

Die Dev-Note mit allen Details ist jetzt verfügbar: »Introducing name and informational tool tips in WordPress 7.1«

Website-Editor-Ansichten filtern

Plugin-Entwickler*innen können die Ansichten Seiten, Templates, Template-Teile und Vorlagen des Website-Editors jetzt über vier neue PHP-Filter konfigurieren – einen pro Ansicht. Jeder Filter justiert die DataViews- und DataForm-Komponenten hinter diesen Ansichten: die Standardansicht (Layout, Sortierreihenfolge, sichtbare Felder), die verfügbaren Layouts, die vorkonfigurierten Ansichten in der Seitenleiste wie „Alle“ oder „Entwürfe“ und die im Quick-Edit-Formular angezeigten Felder.

So entsteht ein zentraler Konfigurationsort pro Entität. Weitere Ansichten, darunter der Editor-Inspector, sollen in zukünftigen Releases aus derselben Quelle gespeist werden (76544). Codebeispiele stehen in der Dev-Note »Filtering Site Editor Screens in WordPress 7.1«.

Markup der Beitragslisten-Tabellen für Barrierefreiheit geändert

Ein elf Jahre altes Barrierefreiheits-Ticket ist gelöst: In den Beitragslisten-Tabellen wandert die Zeilenüberschrift (th scope="row") von der Checkbox-Spalte in die Titel-Spalte. Screenreader identifizieren jede Zeile damit über den Namen des Beitrags – und nicht mehr über eine Checkbox, die unter Umständen gar nicht vorhanden ist (32892).

Erweiterungs-Entwickler*innen sollten ihr CSS und JavaScript prüfen: Selektoren wie th.check-column oder solche, die Titel und Zeilen-Aktionen in einem td erwarten, müssen angepasst werden. Die Dev-Note »Post list tables row headers changed« listet die betroffenen Muster auf. Wer sowohl td– als auch th-Selektoren beibehält, bleibt mit älteren WordPress-Versionen kompatibel.

Eine Liste aller Dev-Notes findest du im Make-Core-Blog.

Quelle

Málaga klingt nicht nur nach Sonne, Tapas und Meer. Ende Mai werden wir mit Temperaturen zwischen 25 und 30 Grad rechnen dürfen.

WordCamp Europe unter der Sonne Andalusiens

Málaga ist weit mehr als nur Strand und Pablo Picasso. Die Stadt hat in den letzten Jahren eine beeindruckende kulturelle Entwicklung durchgemacht und gilt heute als eine der lebendigsten Städte Südspaniens, mit einer gut vernetzten Tech-Community und einer starken spanischen WordPress-Community im Rücken, die sich sehen lassen kann.

Und wer nach den Sessions noch Energie hat: Die Altstadt von Málaga, die Alcazaba und der Hafen sind zu Fuß gut erreichbar. Ein Abendspaziergang entlang der Küstenpromenade mit einer Tapa in der Hand — das gehört dann einfach dazu.

Ein Gespräch mit einer Organisatorin

Ich habe mich mit Delia Carballo unterhalten, die als Local Lead einen wichtige Rolle im Orga-Team des nächsten WordCamp Europe spielen wird. Die passende Podcast-Folge gibt’s im englischen Feed des KrautPress-Podcast.

Quelle

Ein WordCamp zum Verlieben

Erst Jahre später habe ich es dann zum ersten Mal auf das richtige WordCamp Vienna geschafft. Und was soll ich sagen, ich war direkt wieder verliebt – in die Stadt und die lokale Community. Auf wenigen anderen WordCamps wurde ich (und sicherlich liegt es nicht an mir) immer wieder so herzlich empfangen, wie in Wien.

Dazu kommt, dass das Orga-Team in Wien das geschafft hat, was ich jeder lokalen Community nur wünschen kann: Beständigkeit. Seit Jahren findet das WordCamp Wien nach einem bewährten Rezept statt. Die Handgriffe sind eingespielt und das Konzept von Jahr zu Jahr durch kleine Änderungen optimiert.

Der Plan in diesem Jahr

Dieses Jahr rufen die Wiener*innen uns am 10. und 11. April 2026 zu sich ins Hörsaalzentrum auf den Campus der Uni Wien. Wie in den vergangenen Jahren findet am Freitag ein Workshop-Tag statt, an dem verschiedene Vortragende tiefer in Themen einsteigen. Samstag ist dann Zeit für 21 Vorträge.

Das WordCamp in Wien ist, zumindest so lange ich es kenne, durchweg international aufgestellt. Entsprechend findet sich im Vortragsprogramm eine bunte Mischung aus deutsch- und englischsprachigen Vorträgen. Und im Publikum eine mindestens ebenso bunte Zusammenstellung internationaler Teilnehmender.

Die Vorbereitungen laufen

Für ein WordCamp im April laufen jetzt im Frühjahr die Vorbereitungen natürlich auf Hochtouren.

Noch bis zum 14. Februar nimmt das Orga-Team Bewerbungen für Vorträge an.

So lange der Vorrat reicht, laufen der Call for Volunteers, die Suche nach Sponsoren und natürlich der Ticketverkauf.

Quelle

Doch auch für alle, denen die Community-theoretischen Überlegungen herzlich egal sind, ist ein Besuch in Leipzig eine Empfehlung wert. Dieses Camp findet an einem Samstag statt. Dem 9. Mai 2026, um genau zu sein.

Wie in den letzten Jahren wird es auch dieses Jahr nur einen einzigen Track geben. Das schränkt die Auswahl an Vorträgen deutlich ein, gleichzeitig macht es die ganze Veranstaltung aber auch sehr angenehm überschaubar.

Eine wichtige Einschränkung gibt es: Das alte Theater, das seit Jahren als Austragungsort dient, ist nicht barrierefrei und nur über eine Treppe zugänglich. Ist die Treppe aber einmal überwunden, gibt es alle Annehmlichkeiten – von der Bühne über eine kleine Bar bis hin zu den Toiletten auf einem Stockwerk.

Eine charmante Community bräuchte keine anderen Argumente (hat sie aber)

Als Teilnehmer der ersten Stunde, plane ich auch in diesem Jahr wieder dabei zu sein. Tatsächlich hat sich Leipzig für mich in den letzten Jahren zu einem der jährlichen Pflicht-Events entwickelt. Durch den schon angesprochenen sehr fokussierten Ansatz und eine wahnsinnig coole Location hat die charmante Community aus Leipzig ein mindestens genauso charmantes Event geschaffen.

Quelle

In einschlägigen Kreisen ist Sim für das einzigartige (aber leider auch einzigartig teure) Newsletter-Plugin Newsletter Glue bekannt. Das Plugin, das sie inzwischen verkauft hat, ist, was den WP Letter antreibt und verbindet seit Jahren erfolgreich Funktionalität und Design zu einem sehr stimmigen Gesamtpaket. Ich hatte also wirklich hohe Erwartungen an das neue Plugin.

Das Plugin selbst kommt mit einem liebevoll gestalteten Interface und unterstützt alle Funktionen, die wir von einem herkömmlichen Terminverwaltungs-Plugin erwarten würden. Mehrtägige Termine, Terminwiederholungen, Online- und Präsenztermine – alles kein Problem. Das Verwalten mehrerer Kalender ist ebenso vorhanden, wie die nahtlose Unterstützung für Zeitzonen.

Wer allerdings auf Ticketverkäufe, Platzauswahl oder das Generieren von eTickets für den Einlass setzt, ist bei Event Koi zumindest aktuell (noch) nicht richtig aufgehoben.

Block- und Shortcode-Support

Das ganze Plugin fühlt sich ganz an, als wäre es im Block-Editor zuhause. Es bringt eine Reihe liebevoll gestalteter Blöcke zum Einbinden von Terminen als Listen oder Kalender mit und sieht die mögliche Nutzung der Block-Bindings-API vor. Aber hinter einem kleinen Schalter versteckt bietet es auch die Möglichkeit, pro Event generierte Shortcodes zu kopieren.

Verfügbarkeit und Preise

Dieser Artikel ist auf Basis einer Vorabversion des Plugins entstanden, die noch eine Hand voll kleiner Bugs hatte, die aber alle nicht weltbewegend waren und hoffentlich schnell behoben werden können.

Das Plugin ist auf eventkoi.com erhältlich.

Quelle

Das WordCamp Europe 2025 in Basel ist vorbei! Es war wie jedes Jahr ein tolles Event. Ganz abgesehen von den super interessanten Talks ist das Highlight eindeutig der persönliche Austausch. Der WordPress Alltag ist im Normalfall sehr digital, und die meisten Leute sieht man nur auf dem Bildschirm. Aber auf den WordCamps trifft man die Leute live und dadurch entstehen noch bessere Beziehungen.

Aber alles, was einen Anfang hat, hat auch ein Ende … und das gilt auch für das WordCamp Europe 2025. Wie jedes Jahr wurde am Ende des WordCamps die Stadt angekündigt, in der das WordCamp Europe im kommenden Jahr stattfinden wird. Und 2026 fahren wir nach Krakau!

Das freut mich persönlich extrem 😁 Denn ich war im letzten Jahr bei den WordCamps in Krakau und in Gdynia dabei, und die WordPress Community in Polen ist wirklich toll! Das Team ist sehr motiviert, das kommende WordCamp Europe zu einem ganz besonderen Event zu machen.

Das bedeutet, dass wir im kommenden Jahr auf dem WordCamp Europe ganz viel Żurek und Pierogi (saure Mehlsuppe und Teigtaschen) essen werden 🙌

Von der Location des WordCamps werden wir auch einen wunderschönen Ausblick auf die Burg Wawel haben. Da lohnt sich ein kleiner Ausflug in die Altstadt (15 bis 20 Minuten) ganz besonders. Denn ein Großteil der Architektur in Krakau ist noch immer in einem Top Zustand, und es gibt sehr viele interessante Geschichten zu erkunden, wie zum Beispiel die Drachenlegende. Deswegen ist Krakau die erste Stadt, die 1978 in die Liste des UNESCO Weltkulturerbes aufgenommen wurde.

Im englischsprachigen KrautPress-Podcast hat Simon mit Sebastian Miśniakiewicz gesprochen, der in Krakau Teil des lokalen Orga-Teams sein wird.

Quelle

Dezentrale Infrastruktur mit FAIR

An diesem Beispiel wird deutlich, dass eine zentrale Infrastruktur zum Hosten der Plugins, die aus dem WordPress-Backend heraus installiert werden können, aber auch von WordPress-Updates und anderen Services keine gute Idee ist. Daher hat Joost in seinem Beitrag »Breaking the Status Quo« das Konzept von Federated And Independent Repositories (FAIR) vorgestellt, bei dem theoretisch jede*r eine eigene Instanz der WordPress.org-Infrasturktur hosten kann. Diese Repositorys können aber auch untereinander kommunizieren, um beispielsweise Installations-Zahlen auszutauschen. Karim hat in seinem Beitrag »Breaking the Status Quo: A Vision For a New WordPress Business Roadmap« dazu noch die Idee eingebracht, dass auch Plugins aus anderen Quellen als dem WordPress.org-Repo in diesen FAIR gehostet werden können.

Nach einigen Monaten Arbeit von über 200 Menschen und von Unternehmen aus dem WordPress-Ökosystem wurde auf dem Alt Ctrl Org Event die erste Version von FAIR vorgestellt. Das Projekt soll ein Ersatz für die WordPress.org-Infrastruktur sein, um diesen zentralen Teil kritischer Infrastruktur dem Zugriff einer einzelnen Person oder Organisation zu vermeiden.

Nicht nur ein Mirror des WordPress.org-Repos

Der für die Anwendung wichtige Aspekt von FAIR besteht aus zwei Teilen: einem Plugin, mit dem die Quelle für Plugin-Installationen einer WordPress-Instanz ausgetauscht werden kann, und einer Server-Lösung, mit der ein Plugin-Repository gehostet werden kann. Das Plugin-Repository spiegelt standardmäßig die Plugins von WordPress.org, und kann um weitere Quellen erweitert werden. So ist es zum Beispiel möglich, Kauf-Plugins mit in ein Verzeichnis aufzunehmen. Das Spiegeln der WordPress.org-Plugins kann auch deaktiviert oder die Auswahl eingeschränkt werden, um etwa nur Plugins zur Installation anzubieten, die eine bestimmte PHP-Version unterstützen.

Des Weiteren wäre beispielsweise denkbar, dass ein Unternehmen, das Managed Hosting von WordPress anbietet, nicht sicherheitsrelevante Plugin-Updates vor der Auslieferung an seine Kund*innen erst testet. Darüber hinaus bietet das Plugin Datenschutzvorteile gegenüber der Update-Lösung im WordPress Core, da keine unnötigen Requests von WordPress-Admin-Usern an die Update-Server gemacht werden, und auch im Bereich Sicherheit gibt es Verbesserungen gegenüber der WordPress.org-Infrastruktur.

All diese Punkte könnten das Projekt sehr interessant etwa für Hosting-Unternehmen machen, die teilweise nach den Vorfällen der letzten Zeit bereits angefangen haben, eigene Mirror für das WordPress.org-Repo aufzubauen.

Governance bei FAIR: durch die Linux-Foundation geregelt

Der wichtigste Teil des Projekts ist aber wohl das Thema Governance, also wie das Projekt geleitet wird. Es sollte natürlich nicht so laufen, wie es aktuell (noch 🤞🏻) beim WordPress-Projekt der Fall ist, dass es eine Person gibt, die letztlich alles entscheiden kann. Da der Aufbau von Governance ein komplexes Thema ist, wurde entschieden, das Projekt unter dem Dach der Linux-Foundation zu platzieren. Dadurch profitiert es von den gewachsenen und erprobten Strukturen und Abläufen der Linux-Foundation, so gibt es ein von der Community ernanntes Gremium zur Leitung des Projekts, ein Technical Steering Committee (TSC). Die ersten drei Co-Vorsitzenden des TSC sind der Erfinder der WordPress-REST-API Ryan McCue, die langjährige Plugin-Verantwortliche Mika Epstein und die, in der Community hoch angesehene Carrie Dils.

Joost und Karim sehen die Lösung nicht als heiligen Gral, der alle Probleme mit der Governance des WordPress-Projekts regelt. Aber als Schritt in die richtige Richtung und als Beispiel, wie es gelingen könnte. Es soll auch kein Wettbewerb sein, sondern bestenfalls alle mitnehmen, inklusive Automattic und WP Engine. Im Idealfall, so Joost, steht am Ende eine Integration in den WordPress Core.

Unter fair.pm wird es später eine Website geben, aktuell leitet sie auf die GitHub-Organisation des Projekts weiter, in der die Repositorys mit dem Code des Projekts zu finden sind, und Simon hat sich im Rahmen des WordCamp Europe mit Joost und Karim über das FAIR-Projekt für den englischsprachigen KrautPress-Podcast unterhalten.

Auf GitHub gibt es im Moment Repositories für das FAIR-Protokoll, das FAIR-Plugin, das mini-FAIR-repo und einen Fork des WP Planet.

Quelle

Wir starten Ende Februar eine neue kleine Veranstaltungsreihe: den KrautPress Website Club. Gemeinsam mit Matthias Pfefferle werden wir uns einmal im Monat treffen und ganz im Sinne des WordPress-Mottos „democratize publishing“ zusammen über persönliche Websites sprechen.

Matthias ist im deutschsprachigen Raum, aber vor allem in der WordPress-Welt, eine der Instanzen zum Thema IndieWeb. Mit ihm über kleine Ideen für Websites zu sprechen oder einen unerwarteten Deepdive zu Themen wie Webfinger, .well-known oder Webmentions zu machen, motiviert mich persönlich immer an meinem eigenen Blog zu arbeiten. Und genau diese Aspekte wollen wir zukünftig regelmäßiger gemeinsam anschauen. Das erste Treffen wird am 26. Februar von 17:30-18:30 Uhr stattfinden und hat kein fixes Thema. Es wird aber definitiv um das Open Web, WordPress und persönliche Websites gehen. 🙂

Wir wollen das Ganze als eine Art Online-Meetup durchführen und für den Start dafür auf Zoom setzen. Die Teilnahme ist offen für alle Interessierten und natürlich kostenfrei. Zur Anmeldung haben wir im Moment noch kein schickes System aufgesetzt, stattdessen gibt’s den Zoom-Link per E-Mail einfach für alle, die hier in den Kommentaren Interesse bekunden.

Quelle

Lass uns vielleicht damit anfangen, was Post Status so besonders macht.

Joost: Ich denke, was Post Status historisch besonders gemacht hat, waren unterschiedliche Dinge zu unterschiedlichen Zeiten. Als es gegründet wurde, war es Brian Krogsgard, der es ins Leben rief und sehr tiefgründige, analytische Artikel darüber schrieb, wie es bei WordPress läuft, und einige ziemlich ernste Fragen zum Ökosystem stellte. Er schuf eine Community auf Slack, in der viele dieser Diskussionen stattfanden, hauptsächlich unter Menschen, die mit WordPress ihr Geld verdienen. Das funktionierte gut, und die Community wuchs weiter. Als Brian ging und es an Cory und Lindsey übergab, wurde der Community-Aspekt immer wichtiger. Immer mehr Menschen begannen, miteinander zu sprechen, und die Gruppe wurde immer größer, während auch WordPress wuchs.

Es gibt vieles, das WordPress heute besonders macht. Das meiste davon sind keine Dinge, sondern Menschen. Menschen mit sehr unterschiedlichen Hintergründen im WordPress-Ökosystem, die sehr gute und offene Diskussionen führen, die relativ leicht moderiert werden.

Also, wir bemühen uns, sicherzustellen, dass alle respektvoll miteinander umgehen. Es gibt viele große Besitzer*innen großer Plugins und viele Leute von Hosting-Unternehmen, mit denen wir diskutieren. Diese Vielfalt an Meinungen bringt wertvolles Feedback.

Du hast bereits die Geschichte von Brian und Cory erwähnt. Jetzt wird es Zeit für das nächste Kapitel für Post Status, das ist der Grund, warum wir heute sprechen. Es ist eine große Neuigkeit und etwas, das schon längere Zeit in Arbeit war, oder?

Joost: Ja, es hat ziemlich lange gedauert. Ich hatte längere Zeit mit Cory diskutiert, was wir mit Post Status machen sollen. Soll es ein tatsächlich profitables Unternehmen werden? Oder würde das die Community zerstören? Ich kam zu dem Schluss, dass es schwer wäre, viel Geld zu verdienen, ohne die Community zu gefährden. Und in den letzten Monaten wurde mir klar, dass es wichtig ist, einen Ort zu haben, an dem Menschen frei sprechen können. Also haben wir die Anteile von Cory und Lindsey gekauft und sie direkt an eine neu gegründete Stiftung in den Niederlanden gespendet.

Die Stiftung ist gemeinnützig, und ich bin der Vorsitzende. Post Status soll für alle zugänglich bleiben und der Community dienen. Michelle Frechette bleibt als Geschäftsführerin und wir suchen Sponsoren, um langfristige Nachhaltigkeit zu gewährleisten.

Das klingt nach einem Plan. Was sind die nächsten Schritte?

Joost: Wir werden die Infrastruktur umstellen und den Slack-Workspace auf eine Non-Profit-Version upgraden. Michelle startet einen neuen Podcast „Get Hired“, um Menschen beim Einstieg ins WordPress-Ökosystem zu helfen.

Und bei den Post-Status-Mitgliedschaften, die nach wie vor kostenpflichtig sind, habt ihr auch Änderungen vorgenommen, richtig?

Joost: Ja, wir senken die Kosten erheblich. Früher war es recht teuer, aber wir reduzieren den Preis auf 50 USD pro Jahr. Und intern waren wir uns schon einig: Falls sich jemand das nicht leisten kann, finden wir dennoch einen Weg, den Zugang zu ermöglichen.

Das war vorher schon Corys Politik, richtig?

Joost: Ja genau, Cory war da sehr großzügig. Und genau, das ist auch unser Ziel. Wir möchten alle in der WordPress-Community einbinden und hoffen auf freiwillige Beiträge.

Danke dir.

Joost: Gerne.

Quelle

Anders als die meisten anderen Kontaktformular-Plugins landet Form Block nach der Installation direkt im Block-Editor und verzichtet komplett auf einen komplizierten Überbau. Es gibt keine gesonderte Einstellungsseite, auf der Formulare zusammengesetzt werden müssen. Stattdessen werden alle Kontaktformulare direkt im Block-Editor gebaut.

Im Editor präsentieren sich neue Formulare mit einigen vorgefertigten Vorlagen. Die können übernommen und angepasst werden.

Ein kleines bisschen Einstellungen bringt Form Block dann aber doch mit. Unter Einstellungen / Schreiben im Admin-Menü fügt es zwei Optionen hinzu, die aber auch nur relevant sind, wenn ein Kontaktformular zum Hochladen von Dateien verwendet wird.

In einer kostenpflichtigen Version gibt es einige zusätzliche Funktionen, wie die Möglichkeit, Uploads nur in WordPress zu speichern, aber nicht per E-Mail zu versenden. Damit sammeln wir für den PressWerk-Podcast zum Beispiel die lokalen Aufnahmen unserer Interviewpartner*innen ein. Zusätzlich bringt die Pro-Version noch individuelle Formular-Actions, eine erweiterte Validierung von Formularen und mehr.

Quelle