WordPress 7.1: wytyczne AI i własny typ wpisu wp_knowledge

#Wprowadzenie

Propozycja merge Grega Ziółkowskiego, żeby wstawić własny typ wpisu wp_knowledge i wytyczne AI do WordPress 7.1, wywołała prawdziwą debatę. Twórcy chcieli standardowego miejsca na reguły dla redaktorów i narzędzi AI. Krytycy, w tym Jon Brown z 9seeds, mówili: najpierw wtyczka.

Żadna z tych zmian nie weszła. Matt Mullenweg zawetował merge Guidelines w lipcu. Plan ukrycia bloku klasycznego w inserterze cofnięto w tym samym miesiącu. WordPress 7.1 Mary Lou ukazał się 19 sierpnia bez wp_knowledge, bez Guidelines i z blokiem klasycznym nadal w inserterze. Reszta artykułu to propozycja taka, jaka wtedy stała, plus co robić teraz, skoro rdzeń jej nie wziął. Fragmenty PHP i React poniżej to szkic wtyczki, nie API rdzenia.

#Czym jest typ wpisu wp_knowledge w WordPressie

Cel propozycji Grega Ziółkowskiego to dedykowany obszar w rdzeniu na wytyczne witryny, brand voice i struktury treści. Te ustandaryzowane dane pod wp_knowledge miały służyć:

1. Dla autorów: właściciel witryny spisuje standardy raz, na stronie Wytyczne w Ustawieniach, a nowi autorzy czytają je w jednym miejscu zamiast w PDF-ie.
2. Dla narzędzi AI: każde narzędzie z odpowiednimi uprawnieniami może czytać te rekordy przez REST API i trzymać styl tekstu przy witrynie. Propozycja nie wnosi własnego dostawcy AI, modelu ani algorytmu wyszukiwania.

Część deweloperów uznała to za przedwczesne i wolała najpierw feature plugin, zanim ktokolwiek mówi o merge do rdzenia.

#Czym wp_knowledge różni się od tradycyjnych wytycznych

Tak zmienia się przechowywanie reguł redakcyjnych:

#Co propozycja merge określała dla wp_knowledge

Propozycja merge opisuje Knowledge jako „ogólny prymityw do przechowywania wiedzy o witrynie dla autorów i agentów jako standardowej treści WordPressa” (Greg Ziółkowski, tłumaczenie własne). Składa się z części, które WordPress już ma: własnego typu wpisu, taksonomii, ról i uprawnień, rewizji i REST. Eksperymentalny kod w Gutenbergu zgadza się z propozycją:

• Typ wpisu wp_knowledge jest rejestrowany z public ustawionym na false i bez natywnych ekranów w panelu. Rekordy nie pojawiają się w zapytaniach na froncie.
• Taksonomia wp_knowledge_type mówi, czym jest rekord. Rdzeń definiuje trzy typy: guideline (standard, który jest źródłem prawdy), memory (trwały kontekst zapisany albo zatwierdzony przez użytkownika) i note (prywatny tekst roboczy). Rekord zapisany bez typu dostaje note. Wtyczki dodają typy filtrem wp_knowledge_types.
• Ekran Wytyczne buduje się z zakresów: Site, Copy, Images i Blocks. Każdy zakres to rekord guideline z zarezerwowanym slugiem, na przykład guideline-copy, a wtyczki mogą rejestrować kolejne.
• REST działa pod /wp/v2/knowledge, a rejestr tylko do odczytu pod /wp/v2/knowledge/guideline-scopes. Odczyt kolekcji wymaga uwierzytelnienia.
• Nowe rekordy domyślnie są prywatne (private). Rewizje zostają, autosave jest wyłączony, bo rekordy nie mają sesji edytora.

Uprawnienia żyją w przestrzeni *_knowledge_items. Polityka dostępu z PR 78296 w Gutenbergu, w wersji z propozycji:

Sam ekran Wytyczne nadal wymaga manage_options. Ponieważ nic w wp_knowledge nie jest publiczne, crawler tego nie zobaczy. Link publishingPrinciples w schemacie musi prowadzić do publicznej strony.

#Jak Wytyczne przeszły z Gutenberga 22.7 do zawetowanego merge

Nazwa i sposób zapisu zmieniły się dwa razy przed wetem. Wytyczne weszły jako eksperyment w Gutenbergu 22.7, co 23 marca 2026 opisał Aagam Shah. Włączało się je w Gutenberg, Eksperymenty, a w Ustawieniach pojawiała się strona Wytyczne z sekcjami Site, Copy, Images, Blocks i Additional, eksportem do guidelines.json, importem i historią rewizji. Zapis szedł do typu wpisu wp_content_guideline, każda kategoria w meta wpisu, a REST pod /wp/v2/content-guidelines. Ten wpis mówi wprost, że Wytyczne „celowo skupiają się na zapisie i odczycie” (Aagam Shah, tłumaczenie własne) i nie egzekwują reguł ani nie generują treści.

22 czerwca Greg Ziółkowski opublikował propozycję merge do 7.1, z łatką rdzenia w PR 12201 w wordpress-develop (zgłoszenie Trac 65476). PR 79149 w Gutenbergu, scalony 29 czerwca, zmienił nazwę magazynu na wp_knowledge. 10 lipca Anne McCarthy, po przeglądzie z Mattem Mullenwegiem, opublikowała w komentarzach decyzję: praca nie wejdzie do 7.1, a rdzeń nie powinien przyjmować rzeczy „jeszcze nienapędzanych realnym użyciem z imponującym wzrostem z tygodnia na tydzień (mowa o dwucyfrowym)” (Anne McCarthy, tłumaczenie własne). Beta 1 wyszła 15 lipca.

Dalszy ciąg widać na GitHubie. Ziółkowski otworzył 18 sierpnia PR 949 w WordPress/ai, żeby przenieść eksperyment do wtyczki AI. Zamknął go bez scalenia 1 października, gdy opiekunowie uznali, że eksperymenty wtyczki AI powinny opierać się na eksperymentach Gutenberga zamiast je powielać. Na 14 października 2026 PR 12201 jest nadal otwarty, a wp-includes/post.php w gałęzi 7.1 nie zawiera wp_knowledge. Funkcja istnieje tylko za flagą eksperymentu Gutenberga.

#Czy WordPress 7.1 usuwa blok klasyczny

Plan ukrycia bloku klasycznego w inserterze w 7.1 został cofnięty. Marin Atanasov napisał, że pierwotne podejście miało rzeczy w dużej mierze na odwrót. Blok nadal tam jest. Nie rób masowej konwersji tylko dlatego, że myślisz, iż 7.1 uruchomił zegar. Źródło: wpis Marina Atanasova z 7 lipca.

Jeśli i tak chcesz konwertować treści Classic (core/freeform) we własnym tempie, poniżej jest wzorzec WP-CLI i filtr czyszczący. Testuj na kopii bazy. Zamiana delimitera freeform na delimiter akapitu to tępe narzędzie i psuje mieszany HTML.

Uruchom na serwerze:

# 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 -->%'"

Dodatkowo funkcja pomocnicza w functions.php motywu, która czyści resztki TinyMCE:

<?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);

#Co zastępuje ukrycie bloku klasycznego w rdzeniu WordPressa

Wpis z 7 lipca mówi, że ukrycie nie przybliżało projektu do niewczytywania TinyMCE, i stawia zasadę: „blok klasyczny powinien stać się przestarzały z wyboru, a nie pod przymusem” (Marin Atanasov, tłumaczenie własne). Usunął też komunikat o deprecjacji na poziomie bloku, przywrócił akcję „Przekształć na bloki” na pasku narzędzi i wycofał filtr wp_classic_block_supports_inserter, który nigdy nie trafił do stabilnego wydania. Wtyczka Enable Classic Block jest zamykana, więc możesz ją dezaktywować.

Wpis wymienia pracę, która zastępuje ukrycie:

• zrozumieć, dlaczego ludzie nadal polegają na bloku klasycznym, i zamknąć te luki,
• dopracować „Przekształć na bloki”, bo nadal ma błędy i niespójności,
• zbudować lepsze narzędzia konwersji i migracji, także masowej,
• poprawić rejestrację zasobów TinyMCE i pozwolić je wyłączać,
• dać wtyczkom sposób na jawne zadeklarowanie zależności od TinyMCE,
• zbadać wczytywanie TinyMCE na żądanie albo asynchronicznie,
• nie wczytywać TinyMCE w edytorze blokowym, gdy blok klasyczny jest wyłączony w menedżerze bloków.

Stan 7.1 sprawdzisz w źródle: block.json bloku core/freeform w gałęzi 7.1 nie ma flagi inserter: false. Ostatni punkt listy to plan na przyszłość, więc nie zakładaj, że wyłączenie bloku klasycznego w menedżerze bloków usuwa TinyMCE z edytora 7.1.

#Jak dodać dane z wp_knowledge do schematu JSON-LD

Własny typ wpisu wiedzy, zrobiony jako wtyczka, nadal jest użytecznym narzędziem pod Answer Engine Optimization. To nie jest funkcja rdzenia 7.1. W erze Perplexity czy ChatGPT Search witryny muszą podawać informacje wprost. Przechowywanie oficjalnych danych firmy w ustrukturyzowanym typie wpisu upraszcza generowanie bogatego Schema.org.

Przykład: filtr, który dokłada dane z wp_knowledge jako obiekty about albo mentions w JSON-LD strony:

<?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>';
        }
    }
}

Można też zarejestrować własne metadane dla wp_knowledge:

<?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'
    ]);
}

Gdy crawler AI indeksuje witrynę, od razu dostaje ustrukturyzowane, autorytatywne streszczenie faktów. To podnosi szansę marki w bezpośrednich odpowiedziach.

#Jak polityka redakcyjna w Schema.org wspiera E-E-A-T

Włączenie wytycznych redakcyjnych bezpośrednio do rdzenia WordPressa przez wp_knowledge nie było przypadkiem. W 2026 wyszukiwarki, zwłaszcza Google, kładą bezprecedensowy nacisk na E-E-A-T. Wiarygodność wydawcy i przejrzystość procesu tworzenia treści to dziś czynniki rankingowe.

Wcześniej aktualizowało się ręcznie boksy autorów albo strony „O nas”. Dziś zautomatyzowane systemy Google szukają głębszych powiązań semantycznych. Chcą wiedzieć, czy jest polityka redakcyjna i jak weryfikuje się fakty.

wp_knowledge strukturyzuje te informacje na poziomie systemu. Dedykowany typ wpisu na standardy etyczne, zespoły eksperckie i metodologię badań wchodzi w graf wiedzy witryny. Wtyczki SEO mogą łączyć te reguły z autorami przez atrybut publishingPrinciples w Schema.org. Proponowane rekordy są prywatne, więc taki link musi prowadzić do publicznej strony, która publikuje tę samą politykę. To sygnał dla wyszukiwarek, że treść wynika z procesu redakcyjnego, a nie z bezrefleksyjnej generacji AI.

Answer engines budują też bezpośrednie relacje między encjami. Powiązanie autorów, procesu redakcyjnego i zweryfikowanej treści przez ustrukturyzowany JSON-LD podnosi trust score całej witryny w modelach wyszukiwania AI.

#Jak sprawdzać wpisy z regułami wp_knowledge przed publikacją

Żeby zautomatyzować kontrolę jakości w agencji B2B, deweloperzy mogą użyć filtra PHP, który przed publikacją sprawdza wpis względem wytycznych wp_knowledge:

<?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.');
            }
        }
    }
}

Komponent React sidebara w edytorze Gutenberg:

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('najlepszy') || content.includes('gwarancja')) {
                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 });

I kompletna struktura pliku wtyczki PHP rejestrującej typ wpisu:

<?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(); });

#Jak działa walidacja bloków i deprecjacje w Gutenbergu

Blok klasyczny nie znika w 7.2 na mocy tego cyklu. Schematy deprecjacji bloków nadal mają znaczenie dla własnych bloków. Poniżej Gutenberg dopasowuje zapisany HTML do funkcji save(), niezależnie od tego, czy rdzeń kiedykolwiek ukryje core/freeform.

#1. API walidacji bloków Gutenberga od środka

Gdy wpis ładuje się w edytorze, silnik JS parsuje zapisane komentarze HTML w wp_posts.post_content. Wykonuje bieżącą funkcję save() bloku i porównuje wygenerowany wynik z surowym HTML w bazie.

Jeśli baza zawiera:

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

a obecna implementacja bloku oddaje new-class, pojawia się błąd walidacji. Gutenberg pokazuje ostrzeżenie o uszkodzeniu bloku i przyciski konwersji.

#2. Ponowna rejestracja starych struktur bloku w React (deprecations)

Żeby uniknąć błędów walidacji, zarejestruj poprzednie wersje bloku w tablicy deprecated. Gutenberg spróbuje dopasować te schematy po kolei, gdy główna walidacja padnie:

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. Programistyczne parsowanie bloków w PHP (parse_blocks)

Na serwerze WordPress używa parse_blocks(), żeby zdeserializować treść wpisu do tablicy obiektów bloków. Parser czyta delimitery, dekoduje JSON atrybutów i zwraca drzewo:

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

Ta architektura utrzymuje witryny klientów B2B wydajne, stabilne i łatwe w utrzymaniu przy większych migracjach na poziomie bloków.

#Jak zbudować wtyczkę wp_knowledge dla kilku redakcji

wp_knowledge nie ma w 7.1. Jeśli potrzebujesz ustrukturyzowanych reguł redakcyjnych dla ludzi i agentów, rejestrujesz własny typ wpisu we wtyczce. Szkic poniżej to właśnie kształt takiej wtyczki. To nie jest case study klienta i to nie jest API rdzenia.

Prefiks ma znaczenie. Podręcznik wtyczek o własnych typach wpisów mówi: „Dla zgodności w przyszłości nie używaj wp_ jako identyfikatora” (WordPress Plugin Handbook, tłumaczenie własne). Eksperyment w Gutenbergu rejestruje wp_knowledge tylko wtedy, gdy taki typ wpisu jeszcze nie istnieje. Wtyczka, która zajmie tę nazwę pierwsza, zamienia prywatny magazyn na ustawienia wybrane przez siebie, łącznie z public ustawionym na true. Dlatego szkic poniżej używa wppoland_knowledge.

Redakcje, które trzymają zasady stylu w PDF-ach, mają ten sam problem co przed 7.1: redaktorzy sprawdzają szkice ręcznie, a zewnętrzne generatory nie mają oficjalnego miejsca, skąd odczytać reguły.

#Przepływ w kształcie wtyczki

1. Ustrukturyzowane węzły wiedzy: zdefiniowałem konkretne wpisy wppoland_knowledge z wytycznymi redakcyjnymi dla działów (wiadomości, finanse, sport). Reguły siedziały jako ładunki JSON schema.
2. Dystrybucja REST API dla narzędzi AI: wystawiłem zabezpieczony endpoint REST, żeby zewnętrzne potoki generowania treści mogły dynamicznie pobierać lokalne ograniczenia formatowania:

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

3. Audytor sidebara Gutenberga w czasie rzeczywistym: komponent React w sidebarze edytora subskrybował zmiany dokumentu i podświetlał słownictwo albo frazy łamiące aktywne wytyczne działu.
4. Programistyczne kontrole jakości WP-CLI: skrypt crona przez WP-CLI audytował opublikowane wpisy względem wytycznych i flagował wyjątki do przeglądu seniora.

Nic z tego nie wymaga typu wpisu w rdzeniu. Wymaga wtyczki, którą masz, z uprawnieniami i powierzchnią REST, którą możesz wersjonować. Taki był wniosek z veta: najpierw udowodnij adopcję poza rdzeniem.

#Czy wp_knowledge pomaga w AEO na stronach B2B

Natywny typ wpisu wp_knowledge w rdzeniu byłby przydatnym krokiem w erze AI. W 7.1 go nie ma. Veto zostawiło pracę jako eksperyment w Gutenbergu. Gdy zachowanie wyszukiwania przesuwa się z klasycznych linków do answer engines (Perplexity, Claude, Gemini), dyscyplina SEO ewoluuje w Answer Engine Optimisation (AEO).

Deweloperzy i wydawcy B2B nie mogą już pisać wyłącznie pod czytelność dla ludzi albo pod podstawowe indeksery słów kluczowych. Muszą dostarczać ustrukturyzowane, weryfikowalne, maszynowo czytelne ładunki, z których modele AI złożą dokładną odpowiedź.

#Dlaczego ustrukturyzowane wytyczne mają znaczenie dla widoczności B2B

1. Weryfikacja E-E-A-T (sygnały zaufania): answer engines faworyzują źródła przezroczyste i autorytatywne. Polityki redakcyjne, biogramy ekspertów i workflow weryfikacji pomagają tylko wtedy, gdy stoją na publicznych stronach, które boty AI mogą powiązać z aktywnymi autorami. Rekordy w proponowanym magazynie wp_knowledge są prywatne, więc zasilałyby Twoje własne narzędzia, a nie crawlery.
2. Integracja zasad Schema.org: punkty danych z wp_knowledge wtyczki SEO mogą mapować na pola Schema.org (właściwość publishingPrinciples). To sygnał wysokiej jakości pipeline redakcyjnego dla crawlerów AI.
3. Nie licz na wygraną Core Web Vitals z deprecjacji bloku klasycznego. To ukrycie nie weszło. Jeśli chcesz TinyMCE poza ścieżką edytora, to nadal Twoja praca we wtyczce i motywie, nie darmowy prezent z 7.1.

Jeśli na stronie klienta potrzebujesz ustrukturyzowanych wytycznych, zarejestruj własny typ wpisu. Nie czekaj, aż rdzeń odwróci veto.

#Co zrobić po aktualizacji do WordPress 7.1

1. Nie konwertuj masowo bloków klasycznych z powodu tego wydania. Inserter nadal je oferuje.
2. Audytuj użycie Classic dopiero przy kolejnym kontakcie z tą treścią, żeby znać dług.
3. Nie szukaj wp_knowledge na witrynie 7.1. Tam go nie ma. Jeśli potrzebujesz magazynu, wypuść wtyczkę.
4. Przetestuj edytor wpisów w iframe, który faktycznie wszedł. Własne bloki zakładające globalny document się wyłożą. Zobacz notatkę o edytorze w iframe.
5. Zostaw Guidelines w Gutenbergu, jeśli już używasz eksperymentu. Nie obiecuj klientom ekranu ustawień w rdzeniu.

#Podsumowanie

WordPress 7.1 Mary Lou ukazał się bez wp_knowledge i bez Guidelines. Merge zawetowano. Blok klasyczny nadal jest w inserterze. Użyteczna praca 7.1 dla agencji leży gdzie indziej: style responsywne, media po stronie klienta i zawsze iframowany edytor. Jeśli nadal chcesz ustrukturyzowanych reguł redakcyjnych dla agentów, zbuduj wtyczkę. Nie wpisuj tego w plan upgrade’u 7.1 tak, jakby rdzeń to wziął.