WordPress 7.1: KI-Richtlinien und der neue Inhaltstyp wp_knowledge

#Einführung

Greg Ziółkowskis Merge-Vorschlag, einen Inhaltstyp wp_knowledge und KI-Richtlinien in WordPress 7.1 zu legen, hat eine echte Debatte ausgelöst. Redaktionen wollten einen Standardort für Regeln für Autorinnen, Autoren und KI-Werkzeuge. Kritiker, darunter 9seeds-Inhaber Jon Brown, sagten, das gehöre zuerst in ein Plugin.

Keine der beiden Änderungen ist gelandet. Matt Mullenweg legte im Juli sein Veto gegen den Guidelines-Merge ein. Der Plan, den Classic-Block im Inserter auszublenden, wurde im selben Monat zurückgenommen. WordPress 7.1 Mary Lou erschien am 19. August ohne wp_knowledge, ohne Guidelines und mit dem Classic-Block weiterhin im Inserter. Der Rest dieses Artikels ist der Vorschlag, wie er damals stand, plus was Sie tun, nachdem der Core ihn nicht übernommen hat. Die PHP- und React-Schnipsel unten sind ein Plugin-Entwurf, kein Core-API.

#Was ist der Inhaltstyp wp_knowledge in WordPress

Ziel von Greg Ziółkowskis Vorschlag ist ein eigener Bereich im Core für Website-Richtlinien, Markenstimmen und Inhaltsstrukturen. Diese standardisierten Daten unter wp_knowledge sind gedacht für:

1. Für Autorinnen und Autoren: Die Betreiber der Website schreiben die Standards einmal auf einer Seite Richtlinien unter Einstellungen, und neue Schreibende lesen sie an einem Ort statt in einem PDF.
2. Für KI-Werkzeuge: Jedes Werkzeug mit passenden Rechten kann diese Datensätze über die REST-API lesen und den erzeugten Text an den Stil der Website anpassen. Der Vorschlag bringt keinen eigenen KI-Anbieter, kein Modell und keinen Retrieval-Algorithmus mit.

Einige Entwickler halten die Änderung für verfrüht und wollen zuerst ein Feature-Plugin, bevor ein endgültiger Core-Merge überhaupt zur Debatte steht.

#Wie unterscheidet sich wp_knowledge von klassischen Richtlinien

So ändert sich die Speicherung redaktioneller Regeln:

#Was der Merge-Vorschlag für wp_knowledge festlegte

Der Merge-Vorschlag beschreibt Knowledge als „ein allgemeines Grundelement, um Wissen über die Website für Autorinnen, Autoren und Agenten als normalen WordPress-Inhalt zu speichern“ (Greg Ziółkowski, eigene Übersetzung). Es nutzt Bausteine, die WordPress schon hat: einen eigenen Inhaltstyp, eine Taxonomie, Rollen und Berechtigungen, Revisionen und REST. Der experimentelle Code in Gutenberg entspricht dem Vorschlag:

• Der Inhaltstyp wp_knowledge wird mit public auf false und ohne eigene Admin-Ansichten registriert. Datensätze erscheinen nie in Abfragen im Frontend.
• Die Taxonomie wp_knowledge_type sagt, was ein Datensatz ist. Der Core definiert drei Typen: guideline (ein Standard, der als Quelle der Wahrheit gilt), memory (dauerhafter Kontext, den jemand gespeichert oder freigegeben hat) und note (privater Arbeitstext). Ein Datensatz ohne Typ fällt auf note zurück. Plugins ergänzen Typen über den Filter wp_knowledge_types.
• Die Seite Richtlinien entsteht aus Bereichen: Site, Copy, Images und Blocks. Jeder Bereich ist ein guideline-Datensatz mit reserviertem Slug wie guideline-copy, und Plugins können weitere registrieren.
• REST liegt unter /wp/v2/knowledge, dazu ein schreibgeschütztes Register unter /wp/v2/knowledge/guideline-scopes. Das Lesen von Sammlungen verlangt Authentifizierung.
• Neue Datensätze sind standardmäßig privat (private). Revisionen bleiben erhalten, Autosave ist abgeschaltet, weil es keine Editor-Sitzung gibt.

Die Berechtigungen folgen dem Namensraum *_knowledge_items. Die Zugriffsregeln aus Gutenberg PR 78296, wie der Vorschlag sie auflistet:

Die Seite Richtlinien selbst verlangt weiterhin manage_options. Weil nichts in wp_knowledge öffentlich ist, sieht ein Crawler davon nichts. Ein publishingPrinciples-Link in Ihrem Schema muss auf eine öffentliche Seite zeigen.

#Wie Richtlinien von Gutenberg 22.7 zum abgelehnten Core-Merge kamen

Name und Speicherung haben sich vor dem Veto zweimal geändert. Richtlinien kamen als Experiment in Gutenberg 22.7, beschrieben am 23. März 2026 von Aagam Shah. Man schaltete es unter Gutenberg, Experimente ein, und unter Einstellungen erschien eine Seite Richtlinien mit Abschnitten für Site, Copy, Images, Blocks und Additional, dazu Export nach guidelines.json, Import und Revisionsverlauf. Gespeichert wurde in einem Inhaltstyp namens wp_content_guideline, jede Kategorie als Post-Meta, REST unter /wp/v2/content-guidelines. Der Beitrag sagt, Richtlinien „konzentriert sich bewusst auf Erfassen und Abrufen“ (Aagam Shah, eigene Übersetzung) und setzt weder Regeln durch noch erzeugt es Inhalte.

Am 22. Juni veröffentlichte Greg Ziółkowski den Merge-Vorschlag für 7.1, mit dem Core-Patch in wordpress-develop PR 12201 (Trac-Ticket 65476). Gutenberg PR 79149, am 29. Juni gemergt, benannte den Speicher in wp_knowledge um. Am 10. Juli veröffentlichte Anne McCarthy nach einer Abstimmung mit Matt Mullenweg die Entscheidung in den Kommentaren: Die Arbeit kommt nicht in 7.1, und der Core soll nichts aufnehmen, was „nicht bereits von echter Nutzung mit beeindruckendem Wachstum von Woche zu Woche (gemeint ist zweistellig) getragen wird“ (Anne McCarthy, eigene Übersetzung). Beta 1 folgte am 15. Juli.

Wie es weiterging, steht auf GitHub. Ziółkowski eröffnete am 18. August WordPress/ai PR 949, um das Experiment ins KI-Plugin zu übertragen. Er schloss ihn am 1. Oktober ohne Merge, nachdem die Maintainer erklärt hatten, Experimente im KI-Plugin sollten auf Gutenberg-Experimenten aufbauen statt sie zu duplizieren. Stand 14. Oktober 2026 ist PR 12201 weiter offen, und wp-includes/post.php im 7.1-Branch enthält kein wp_knowledge. Die Funktion existiert nur hinter dem Experiment-Schalter in Gutenberg.

#Wird der Classic-Block in WordPress 7.1 entfernt

Ein Plan, den Classic-Block in 7.1 aus dem Inserter auszublenden, wurde zurückgenommen. Marin Atanasov sagte, der ursprüngliche Ansatz habe die Dinge weitgehend falschherum aufgezogen. Der Block ist noch da. Führen Sie keine Massenkonvertierung durch, nur weil Sie denken, 7.1 habe eine Uhr gestartet. Quelle: Beitrag von Marin Atanasov vom 7. Juli.

Wenn Sie Classic-Inhalte (core/freeform) trotzdem in Ihrem eigenen Tempo konvertieren wollen, finden Sie hier ein WP-CLI-Muster und einen Cleanup-Filter. Testen Sie auf einer Kopie der Datenbank. Das Ersetzen des Freeform-Delimiters durch einen Absatz-Delimiter ist ein stumpfes Werkzeug und zerlegt gemischtes HTML.

Führen Sie den folgenden Befehl auf dem Server aus:

# Find and convert classic editor block to paragraph blocks
wp db query "UPDATE wp_posts SET post_content = REPLACE(post_content, '<!-- wp:freeform -->', '<!-- wp:paragraph -->') WHERE post_content LIKE '%<!-- wp:freeform -->%'"

Zusätzlich eine Hilfsfunktion in der functions.php Ihres Themes, um TinyMCE-Reste zu bereinigen:

<?php
/**
 * Fallback and clean-up utility for legacy Classic block outputs
 */
function wppoland_clean_legacy_classic_blocks($content) {
    if (has_block('core/freeform', $content)) {
        $content = str_replace('<!-- wp:freeform -->', '<!-- wp:paragraph -->', $content);
        $content = str_replace('<!-- /wp:freeform -->', '<!-- /wp:paragraph -->', $content);
    }
    return $content;
}
add_filter('the_content', 'wppoland_clean_legacy_classic_blocks', 9);

#Was das Ausblenden des Classic-Blocks im WordPress-Core ersetzt

Der Beitrag vom 7. Juli sagt, dass das Ausblenden das Projekt nicht näher daran gebracht hat, TinyMCE nicht mehr zu laden, und stellt den Grundsatz auf, „der Classic-Block soll aus freier Wahl überflüssig werden, nicht unter Zwang“ (Marin Atanasov, eigene Übersetzung). Er entfernte außerdem den Deprecation-Hinweis auf Blockebene, brachte die Aktion „In Blöcke umwandeln“ in der Werkzeugleiste zurück und strich den Filter wp_classic_block_supports_inserter, der nie in einer stabilen Version erschienen ist. Das Plugin Enable Classic Block wird geschlossen, Sie können es deaktivieren.

Der Beitrag nennt die Arbeit, die das Ausblenden ersetzt:

• verstehen, warum Leute weiter auf Classic setzen, und diese Lücken schließen,
• „In Blöcke umwandeln“ zuverlässig machen, weil es noch Fehler und Inkonsistenzen hat,
• bessere Werkzeuge für Konvertierung und Migration bauen, auch für Massenmigration,
• die Registrierung der TinyMCE-Assets verbessern und deren Abschalten erlauben,
• Plugins eine Möglichkeit geben, eine ausdrückliche Abhängigkeit von TinyMCE anzumelden,
• TinyMCE bei Bedarf oder asynchron laden, als Option prüfen,
• TinyMCE im Block-Editor nicht laden, wenn der Classic-Block im Block-Manager deaktiviert ist.

Den Stand in 7.1 können Sie im Quelltext prüfen: Die block.json von core/freeform im 7.1-Branch hat kein Flag inserter: false. Der letzte Punkt der Liste ist künftige Arbeit, erwarten Sie also nicht, dass das Deaktivieren des Classic-Blocks im Block-Manager TinyMCE aus dem 7.1-Editor entfernt.

#Wie fügt man wp_knowledge-Daten in das JSON-LD-Schema ein

Einen Knowledge-Inhaltstyp selbst als Plugin umzusetzen, bleibt ein nützliches Werkzeug für Answer Engine Optimization. Es ist keine Core-Funktion von 7.1. In der Ära von Perplexity oder ChatGPT Search müssen Websites Informationen klar ausliefern. Offizielle Unternehmensdaten in einem strukturierten Inhaltstyp zu speichern, vereinfacht die Erzeugung von Schema.org-Metadaten.

Zum Beispiel ein Filter, der Daten aus wp_knowledge als about- oder mentions-Objekte in das JSON-LD der Seite legt:

<?php
// Automatically append wppoland_knowledge metadata to JSON-LD schema
add_action('wp_head', 'wppoland_append_knowledge_schema');
function wppoland_append_knowledge_schema() {
    if (is_single()) {
        $knowledge = get_posts(['post_type' => 'wppoland_knowledge', 'numberposts' => 1]);
        if (!empty($knowledge)) {
            $schema = [
                "@context" => "https://schema.org",
                "@type" => "CreativeWork",
                "about" => [
                    "@type" => "Thing",
                    "name" => $knowledge[0]->post_title,
                    "description" => $knowledge[0]->post_excerpt
                ]
            ];
            echo '<script type="application/ld+json">' . json_encode($schema, JSON_UNESCAPED_SLASHES) . '</script>';
        }
    }
}

Sie können auch eigene Metadaten für wp_knowledge registrieren:

<?php
add_action('init', 'wppoland_register_knowledge_meta');
function wppoland_register_knowledge_meta() {
    register_post_meta('wppoland_knowledge', 'wikidata_qid', [
        'show_in_rest' => true,
        'single' => true,
        'type' => 'string',
        'sanitize_callback' => 'sanitize_text_field'
    ]);
}

Wenn KI-Crawler die Website indexieren, bekommen sie sofort eine strukturierte, autoritative Faktensumme. Das erhöht die Sichtbarkeit der Marke in direkten Suchantworten.

#Wie Redaktionsrichtlinien in Schema.org E-E-A-T stärken

Redaktionelle Richtlinien direkt im WordPress-Core über wp_knowledge waren kein Zufall. 2026 legen Suchmaschinen, vor allem Google, beispiellosen Wert auf E-E-A-T. Vertrauenswürdigkeit des Herausgebers und Transparenz der Inhaltserstellung sind Rankingfaktoren.

Früher wurden Autorenboxen oder Über-uns-Seiten manuell gepflegt. Heute suchen Googles automatisierte Systeme nach tieferen semantischen Verknüpfungen. Sie wollen wissen, ob eine redaktionelle Richtlinie vorliegt und wie Fakten geprüft werden.

wp_knowledge strukturiert diese Informationen auf Systemebene. Ein eigener Inhaltstyp für ethische Standards, Expertenteams und Forschungsmethoden wird Teil des Wissensgraphen der Website. SEO-Plugins können diese Regeln über das Attribut publishingPrinciples in Schema.org mit Autorinnen und Autoren verknüpfen. Da die vorgeschlagenen Datensätze privat sind, muss ein solcher Link auf eine öffentliche Seite zeigen, die dieselbe Richtlinie veröffentlicht. Das signalisiert Suchmaschinen, dass der Inhalt aus einem redaktionellen Prozess stammt und nicht unkontrolliert von einer KI erzeugt wurde.

Answer Engines bauen außerdem direkte Beziehungen zwischen Entitäten. Autoren, Redaktionsprozesse und validierte Inhalte über strukturiertes JSON-LD zu verknüpfen, hebt den Trust-Score der gesamten Site in KI-Suchmodellen.

#Wie prüft man Beiträge vor der Veröffentlichung gegen wp_knowledge

Um die Qualitätskontrolle in einer B2B-Agentur zu automatisieren, können Entwickler den folgenden PHP-Filter nutzen, der Beiträge vor der Veröffentlichung gegen wp_knowledge-Richtlinien prüft:

<?php
add_action('transition_post_status', 'wppoland_enforce_knowledge_rules', 10, 3);
function wppoland_enforce_knowledge_rules($new_status, $old_status, $post) {
    if ($new_status === 'publish' && $post->post_type === 'post') {
        $rules = get_posts(['post_type' => 'wppoland_knowledge', 's' => 'brand-voice']);
        if (!empty($rules)) {
            $excerpt = $rules[0]->post_excerpt;
            if (!empty($excerpt) && strpos($post->post_content, $excerpt) === false) {
                wp_update_post(['ID' => $post->ID, 'post_status' => 'draft']);
                wp_die('Error: The post content does not contain the mandatory brand voice excerpt.');
            }
        }
    }
}

React-Sidebar-Komponente für den Gutenberg-Editor:

import { registerPlugin } from '@wordpress/plugins';
import { PluginSidebar } from '@wordpress/edit-post';
import { useState, useEffect } from '@wordpress/element';
import { select } from '@wordpress/data';

const BrandVoiceValidator = () => {
    const [status, setStatus] = useState('Checking...');
    useEffect(() => {
        const unsubscribe = select('core/editor').subscribe(() => {
            const content = select('core/editor').getEditedPostContent();
            if (content.includes('beste') || content.includes('garantie')) {
                setStatus('Warning: Violates brand guidelines.');
            } else {
                setStatus('Compliant: Tone of voice matches guidelines.');
            }
        });
        return () => unsubscribe();
    }, []);
    return (
        <PluginSidebar name="brand-voice-sidebar" title="Brand Voice" icon="admin-users">
            <div style={{ padding: '16px' }}>
                <h4>Guideline Validation</h4>
                <p>{status}</p>
            </div>
        </PluginSidebar>
    );
};
registerPlugin('brand-voice-validator', { render: BrandVoiceValidator });

Und die vollständige PHP-Plugin-Dateistruktur zur Registrierung des Inhaltstyps:

<?php
/**
 * Plugin Name: WPPoland Custom Knowledge Base and AI Guidelines
 * Description: Registers the wppoland_knowledge custom post type
 * Version: 1.0.0
 */

namespace WPPoland\Knowledge;

class KnowledgeBasePlugin {
    private static $instance = null;
    public static function get_instance() { 
        if (null === self::$instance) { self::$instance = new self(); }
        return self::$instance;
    }
    private function __construct() {
        add_action('init', [$this, 'register_post_type']);
    }
    public function register_post_type() {
        register_post_type('wppoland_knowledge', [
            'public' => true,
            'label'  => 'Knowledge',
            'show_in_rest' => true,
            'supports' => ['title', 'editor', 'excerpt']
        ]);
    }
}
add_action('plugins_loaded', function() { KnowledgeBasePlugin::get_instance(); });

#Wie funktionieren Blockvalidierung und Deprecations in Gutenberg

Der Classic-Block wird in 7.2 nicht auf der Grundlage dieses Zyklus entfernt. Block-Deprecation-Schemas bleiben für Ihre eigenen Blöcke relevant. So gleicht Gutenberg gespeichertes HTML mit einer save()-Funktion ab, unabhängig davon, ob der Core core/freeform jemals ausblendet.

#1. Gutenberg-Blockvalidierungs-API unter der Haube

Wenn ein Beitrag im Block-Editor lädt, parst die JS-Engine die gespeicherten HTML-Kommentare in wp_posts.post_content. Sie führt die aktuelle save()-Funktion des Blocks aus und vergleicht die Ausgabe mit dem Roh-HTML in der Datenbank.

Wenn die Datenbank enthält:

<!-- wp:wppoland/custom-block -->
<div class="wp-block-wppoland-custom-block legacy-class">Content</div>
<!-- /wp:wppoland/custom-block -->

die aktuelle Implementierung aber new-class ausgibt, entsteht ein Validierungsfehler. Gutenberg warnt vor Blockkorruption und bietet Konvertierungsschaltflächen.

#2. Alte Blockstrukturen in React neu registrieren (Deprecations)

Um Validierungsfehler zu verhindern, registrieren Sie frühere Blockversionen im Array deprecated. Gutenberg versucht diese Schemas der Reihe nach, wenn die primäre Validierung scheitert:

import { registerBlockType } from '@wordpress/blocks';

registerBlockType( 'wppoland/custom-block', {
    title: 'Custom Block',
    attributes: {
        content: { type: 'string', source: 'html', selector: 'div' }
    },
    edit: ( { attributes } ) => <div className="new-class">{ attributes.content }</div>,
    save: ( { attributes } ) => <div className="new-class">{ attributes.content }</div>,
    deprecated: [
        {
            attributes: {
                content: { type: 'string', source: 'html', selector: 'div' }
            },
            save( { attributes } ) {
                return <div className="legacy-class">{ attributes.content }</div>;
            }
        }
    ]
} );

#3. Programmatisches Block-Parsing in PHP (parse_blocks)

Auf dem Server deserialisiert WordPress den Beitragsinhalt mit parse_blocks() in ein strukturiertes Array von Blockobjekten. Der Parser liest Delimiter, dekodiert Attribut-JSON und gibt einen Baum zurück:

<?php
$blocks = parse_blocks( get_post( 123 )->post_content );
foreach ( $blocks as $block ) {
    if ( $block['blockName'] === 'wppoland/custom-block' ) {
        $content = $block['attrs']['content'] ?? "";
    }
}

Diese Architektur hält B2B-Kundenseiten performant, stabil und wartbar, wenn Sie große Migrationen auf Blockebene fahren.

#Wie baut man ein wp_knowledge-Plugin für mehrere Redaktionen

wp_knowledge ist nicht in 7.1. Wenn Sie strukturierte Redaktionsregeln für Menschen und Agenten brauchen, registrieren Sie Ihren eigenen Inhaltstyp in einem Plugin. Die Skizze unten ist genau diese Plugin-Form. Das ist keine Kunden-Fallstudie und kein Core-API.

Das Präfix zählt. Das Plugin-Handbuch zu eigenen Inhaltstypen sagt: „Um die Zukunftskompatibilität zu sichern, verwenden Sie wp_ nicht als Bezeichner“ (WordPress Plugin Handbook, eigene Übersetzung). Das Gutenberg-Experiment registriert wp_knowledge nur, wenn der Inhaltstyp noch nicht existiert. Ein Plugin, das den Namen zuerst belegt, ersetzt den privaten Speicher durch seine eigenen Einstellungen, bis hin zu public auf true. Der Entwurf unten verwendet deshalb wppoland_knowledge.

Redaktionen, die Stilregeln schon in PDFs halten, haben dasselbe Problem wie vor 7.1: Redakteurinnen und Redakteure prüfen Entwürfe von Hand, und externe Generatoren haben keinen offiziellen Ort, an dem sie die Regeln lesen.

#Ein Workflow in Plugin-Form

1. Strukturierte Wissensknoten: Wir definierten konkrete wppoland_knowledge-Beiträge mit redaktionellen Richtlinien für verschiedene Ressorts (Nachrichten, Finanzen, Sport). Die Regeln lagen als strukturierte JSON-Schema-Payloads.
2. REST-API-Verteilung für KI-Werkzeuge: Wir stellten einen abgesicherten REST-Endpunkt bereit, damit externe Content-Pipelines lokalisierte Formatvorgaben dynamisch holen können:

   curl -H "Authorization: Bearer [TOKEN]" https://portal.wppoland.dev/wp-json/wp/v2/wppoland_knowledge?category=brand-voice

3. Echtzeit-Auditor in der Gutenberg-Sidebar: Eine React-Komponente in der Editor-Sidebar abonnierte Dokumentänderungen und markierte Vokabular oder Formulierungen, die gegen die aktiven Ressortregeln verstießen.
4. Programmatische WP-CLI-Qualitätsprüfungen: Ein Cron-Skript per WP-CLI prüfte veröffentlichte Beiträge gegen die Richtlinien und flaggte Ausnahmen für die Chefredaktion.

Nichts davon braucht einen Core-Inhaltstyp. Es braucht ein Plugin, das Ihnen gehört, mit Rechten und einer REST-Oberfläche, die Sie versionieren können. Darauf zielte das Veto: Adoption zuerst außerhalb des Cores beweisen.

#Hilft wp_knowledge bei AEO für B2B-Websites

Ein nativer Inhaltstyp wp_knowledge im Core wäre ein nützlicher Schritt für die KI-Ära gewesen. In 7.1 ist er nicht. Das Veto hat die Arbeit als Experiment in Gutenberg gelassen. Wenn Suchverhalten von klassischen Trefferlisten zu Answer Engines (Perplexity, Claude, Gemini) wandert, wird aus SEO Answer Engine Optimisation (AEO).

Enterprise-B2B-Entwickler und Verlage können nicht mehr nur für menschliche Lesbarkeit oder einfache Keyword-Indexer schreiben. Sie müssen strukturierte, prüfbare, maschinenlesbare Payloads liefern, aus denen KI-Modelle genaue Antworten bauen.

#Warum strukturierte Richtlinien für B2B-Sichtbarkeit zählen

1. E-E-A-T-Verifikation (Vertrauenssignale): Answer Engines bevorzugen transparente, autoritative Quellen. Redaktionsrichtlinien, Expertenbios und Prüfworkflows helfen nur, wenn sie auf öffentlichen Seiten stehen, die KI-Bots mit aktiven Autorinnen und Autoren verknüpfen können. Datensätze im vorgeschlagenen Speicher wp_knowledge sind privat, sie würden also Ihre eigenen Werkzeuge speisen, nicht die Crawler.
2. Schema.org-Prinzipien: Datenpunkte aus wp_knowledge können SEO-Tools automatisch auf Schema.org-Felder mappen (die Eigenschaft publishingPrinciples). Das signalisiert KI-Crawlern eine kontrollierte Redaktionspipeline.
3. Bauen Sie keinen Core-Web-Vitals-Gewinn auf Classic-Block-Deprecation. Das Ausblenden ist nicht ausgeliefert. Wenn Sie TinyMCE vom Editor-Pfad haben wollen, bleibt das Ihre Plugin- und Theme-Arbeit, kein Gratisgeschenk von 7.1.

Wenn Sie auf einer Kundenseite strukturierte Richtlinien brauchen, registrieren Sie Ihren eigenen Inhaltstyp. Warten Sie nicht darauf, dass der Core das Veto zurücknimmt.

#Was tun nach dem Update auf WordPress 7.1

1. Konvertieren Sie Classic-Blöcke nicht massenhaft wegen dieses Releases. Der Inserter bietet sie weiterhin an.
2. Prüfen Sie Classic-Nutzung erst, wenn Sie diese Inhalte ohnehin anfassen, damit Sie die Schulden kennen.
3. Suchen Sie nicht nach wp_knowledge auf einer 7.1-Site. Es ist nicht da. Wenn Sie den Speicher brauchen, liefern Sie ein Plugin.
4. Testen Sie den iframed Beitragseditor, der tatsächlich ausgeliefert wurde. Eigene Blöcke, die ein globales document annehmen, brechen. Siehe den Hinweis zum iframed Editor.
5. Lassen Sie Guidelines in Gutenberg, wenn Sie das Experiment schon nutzen. Versprechen Sie Kunden keinen Core-Einstellungsbildschirm.

#Zusammenfassung

WordPress 7.1 Mary Lou erschien ohne wp_knowledge und ohne Guidelines. Der Merge wurde per Veto gestoppt. Der Classic-Block steht weiterhin im Inserter. Die nützliche 7.1-Arbeit für Agenturen liegt woanders: responsives Styling, clientseitige Medien und der dauerhaft iframed Editor. Wenn Sie weiterhin strukturierte Redaktionsregeln für Agenten wollen, bauen Sie das Plugin. Schreiben Sie es nicht in einen 7.1-Upgrade-Plan, als hätte der Core es übernommen.