krautpress.de
WordPress 7.1 Source of Truth – Deusch
_Birgit Pauli-Haack wohnt in München, arbeitet für Automattic ist seit Jahren als Chronistin der Entwicklung rund um den Block-Editor auf Gutenberg Times aktiv. Dieser Beitrag im Englischen Original findet sich auf_ gutenbergtimes.com
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 Highlight-Raster der wichtigsten Neuerungen (__Entwurf, 5. August 2026_ _)._
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"
}
}Code-Sprache: JavaScript (javascript)
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" }
}
}
}Code-Sprache: JavaScript (javascript)
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).
Screenshot
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
}
}Code-Sprache: JavaScript (javascript)
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"
}
}
}
}
}Code-Sprache: JSON / JSON mit Kommentaren (json)
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"
}
}
}
}
}Code-Sprache: JavaScript (javascript)
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"
}
}
}
}
}Code-Sprache: JSON / JSON mit Kommentaren (json)
#### 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
}
}
}Code-Sprache: JSON / JSON mit Kommentaren (json)
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.
