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

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

Ostatnio zweryfikowano: 20 sierpnia 2026
11 min czytania
Opinia
500+ projektów WP

#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.

#Nowy typ wpisu wp_knowledge i wytyczne AI

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: wytyczne w edytorze jako checklista redakcyjna, żeby nowi autorzy szybciej weszli w standard.
  2. Dla narzędzi AI: generatory treści mogłyby pobierać reguły przez REST API albo WP-CLI i trzymać styl tekstu przy witrynie.

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

#Porównanie zarządzania wytycznymi w WordPressie

Tak zmienia się przechowywanie reguł redakcyjnych:

CechaPodejście tradycyjne (nadal aktualne po 7.1)Proponowany model wp_knowledge (nie wszedł)
Miejsce przechowywaniaZewnętrzne PDF-y, strony statyczneDedykowany własny typ wpisu wp_knowledge
Wsparcie APIBrak albo własnePełne wsparcie REST API i WP-CLI
Integracja z edytoremRęczna weryfikacja przez autoraAutomatyczne wskazówki w sidebarze Gutenberga
Przetwarzanie przez AITrudne (wymaga scrapowania)Ustandaryzowany obiekt JSON z rdzenia
Brand voiceWtyczki firm trzecichNatywne reguły walidacji stylu i tonu

#Blok klasyczny: wycofanie nie nastąpiło

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.

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

#Optymalizacja AEO (Answer Engine Optimization) przy użyciu wp_knowledge

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 wp_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' => 'wp_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('wp_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.

Więcej o historii deprecjacji bloków: blok klasyczny (też core/freeform) był kluczowym elementem przejścia z TinyMCE na Gutenberg w WordPress 5.0. Przez lata utrzymywanie kompatybilności wstecznej TinyMCE stało się hamulcem wydajności. Pliki JS edytora blokowego musiały ładować całą bibliotekę TinyMCE (ponad 1 MB) na wszelki wypadek. Ukrycie bloku klasycznego pozwoliłoby rdzeniowi leniwie ładować te zasoby. To ukrycie nie weszło w 7.1, więc nie traktuj twierdzenia o 40% szybszym ładowaniu edytora jako zmierzonego wyniku 7.1.

#Głębsze spojrzenie: E-E-A-T i rola ustrukturyzowanych danych redakcyjnych

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. 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.

#Praktyczna integracja wp_knowledge z procesem publikacji

Ż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' => 'wp_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 wp_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('wp_knowledge', [
            'public' => true,
            'label'  => 'Knowledge',
            'show_in_rest' => true,
            'supports' => ['title', 'editor', 'excerpt']
        ]);
    }
}
add_action('plugins_loaded', function() { KnowledgeBasePlugin::get_instance(); });

Więcej o historii deprecjacji bloków: blok klasyczny (też core/freeform) był kluczowym elementem przejścia z TinyMCE na Gutenberg w WordPress 5.0. Przez lata utrzymywanie kompatybilności wstecznej TinyMCE stało się hamulcem wydajności. Pliki JS edytora blokowego musiały ładować całą bibliotekę TinyMCE (ponad 1 MB) na wszelki wypadek. Ukrycie bloku klasycznego pozwoliłoby rdzeniowi leniwie ładować te zasoby. To ukrycie nie weszło w 7.1, więc nie traktuj twierdzenia o 40% szybszym ładowaniu edytora jako zmierzonego wyniku 7.1.

#Przewodnik techniczny: API walidacji bloków Gutenberga i deprecjacje w React

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.

#Szkic projektu: wieloredakcyjny magazyn wiedzy, który zbudujesz sam

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.

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: zdefiniowaliśmy konkretne wpisy wp_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: wystawiliśmy 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/wp_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.

#Opinia ekspercka i strategia B2B: rola wp_knowledge w erze AEO

Natywny typ wpisu wp_knowledge w rdzeniu byłby przydatnym krokiem w erze AI. W 7.1 go nie ma. Veto zostawiło pracę w Gutenbergu i u Automattic. 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 wp_knowledge ma znaczenie dla widoczności B2B:

  1. Weryfikacja E-E-A-T (sygnały zaufania): answer engines faworyzują źródła przezroczyste i autorytatywne. Przechowywanie polityk redakcyjnych, biogramów ekspertów i workflow weryfikacji w wp_knowledge pozwala botom AI powiązać te pliki z aktywnymi autorami.
  2. Integracja zasad Schema.org: punkty danych z wp_knowledge wtyczki SEO mogą mapować na pola Schema.org (np. publishingPrinciples albo editorialGuidelines). 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.

#Checklista po 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ął.

Następny krok

Przekuj artykuł w realne wdrożenie

Pod tym wpisem dokładam linki, które domykają intencję użytkownika i prowadzą dalej w strukturze serwisu.

Chcesz wdrożyć ten temat na swojej stronie?

Jeśli zależy Ci na widoczności w Google i systemach AI, mogę przygotować architekturę treści, FAQ, schema i linkowanie pod GEO, AEO i SEO.

Powiązany klaster

Sprawdź inne usługi WordPress i bazę wiedzy

Wzmocnij swój biznes dzięki profesjonalnemu wsparciu technicznemu w kluczowych obszarach ekosystemu WordPress.

FAQ do artykułu

Często zadawane pytania

Najważniejsze odpowiedzi, które pomagają wdrożyć temat w praktyce.

SEO-readyGEO-readyAEO-ready3 Q&A
Czy wp_knowledge trafił do WordPress 7.1?#
Nie. Greg Ziółkowski zaproponował go jako warstwę przechowywania pod Guidelines. Matt Mullenweg zawetował merge w lipcu 2026. WordPress 7.1 Mary Lou ukazał się 19 sierpnia bez tego typu wpisu. Eksperyment zostaje w Gutenbergu i u Automattic.
Dlaczego propozycja merge została odrzucona?#
Mullenweg nie chciał funkcji AI w rdzeniu, które nie mają już realnej adopcji i wyraźnego wzrostu tydzień do tygodnia. David Levine uznał propozycję za przedwczesną. Jon Brown z 9seeds argumentował, że powinna żyć jako wtyczka przez rok albo dwa. Anne McCarthy opublikowała decyzję przy propozycji merge pięć dni przed Betą 1.
Co stało się z blokiem klasycznym w WordPress 7.1?#
Plan ukrycia go w inserterze cofnięto w lipcu. Marin Atanasov stwierdził, że pierwotne podejście miało rzeczy w dużej mierze na odwrót. Blok klasyczny nadal jest w 7.1. Istniejące treści z blokiem klasycznym się nie psują, a to wydanie nie wymusza migracji.

Potrzebujesz FAQ dopasowanego do branży i rynku? Przygotujemy wersję pod Twoje cele biznesowe.

Porozmawiajmy

Polecane artykuły

Mapa drogowa WordPress 7.1

Mapa drogowa WordPress 7.1 autorstwa Anne McCarthy była zbudowana wokół współpracy, a jednak współpraca w czasie rzeczywistym znów nie weszła. WordPress 7.1 Mary Lou ukazał się 19 sierpnia 2026. Co naprawdę weszło, co wypadło i co debata o wdrożeniach canary nadal mówi o tym, jak buduje się WordPressa.