WordPress 7.1: AI-retningslinjer og den nye innleggstypen wp_knowledge

#Innledning

Greg Ziółkowskis sammenslåingsforslag om å legge innleggstypen wp_knowledge og AI-retningslinjer inn i WordPress 7.1 skapte en reell debatt. Redaksjoner ville ha et standardsted for regler for skribenter og AI-verktøy. Kritikere, blant dem 9seeds-eier Jon Brown, sa at det burde leve som en utvidelse først.

Ingen av endringene landet. Matt Mullenweg nedla veto mot Guidelines-sammenslåingen i juli. Planen om å skjule Classic-blokken fra innsetteren ble reversert samme måned. WordPress 7.1 Mary Lou ble lansert 19. august uten wp_knowledge, uten Guidelines, og med Classic-blokken fortsatt i innsetteren. Resten av artikkelen er forslaget slik det sto, pluss hva du gjør nå som kjernen ikke tok det. PHP- og React-snuttene under er en skisse av en utvidelse, ikke et kjerne-API.

#Hva er innleggstypen wp_knowledge i WordPress

Målet med Greg Ziółkowskis forslag er et eget område i kjernen for nettstedets retningslinjer, merkevarestemme og innholdsstrukturer. Disse standardiserte dataene under wp_knowledge er tenkt for:

1. For skribenter: Nettstedets eier skriver standardene én gang, på siden Guidelines under Innstillinger, og nye skribenter leser dem på ett sted i stedet for i en PDF.
2. For AI-verktøy: Ethvert verktøy med riktige tilganger kan lese disse postene via REST-API-et og holde den genererte teksten i tråd med nettstedets stil. Forslaget tar ikke med egen AI-leverandør, modell eller søkealgoritme.

Noen utviklere mener endringen er for tidlig og vil ha en runde som feature-plugin før en endelig kjerne-sammenslåing.

#Hvordan skiller wp_knowledge seg fra tradisjonelle retningslinjer

Slik endrer lagring av redaksjonelle regler seg:

#Hva sammenslåingsforslaget spesifiserte for wp_knowledge

Sammenslåingsforslaget beskriver Knowledge som «en generell primitiv for å lagre kunnskap om nettstedet, rettet mot forfattere og agenter, som vanlig WordPress-innhold» (Greg Ziółkowski, egen oversettelse). Den bygger på deler WordPress allerede har: en egen innleggstype, en taksonomi, roller og tilganger, revisjoner og REST. Den eksperimentelle koden i Gutenberg samsvarer med forslaget:

• Innleggstypen wp_knowledge registreres med public satt til false og uten egne skjermbilder i admin. Postene dukker aldri opp i spørringer på forsiden.
• Taksonomien wp_knowledge_type sier hva en post er. Kjernen definerer tre typer: guideline (en standard som er sannhetskilden), memory (varig kontekst som en bruker har lagret eller godkjent) og note (privat arbeidstekst). En post som lagres uten type, faller tilbake til note. Utvidelser legger til typer med filteret wp_knowledge_types.
• Guidelines-siden bygges av omfang: Site, Copy, Images og Blocks. Hvert omfang er en guideline-post med en reservert slug, for eksempel guideline-copy, og utvidelser kan registrere flere.
• REST ligger under /wp/v2/knowledge, med et skrivebeskyttet register på /wp/v2/knowledge/guideline-scopes. Lesing av samlinger krever autentisering.
• Nye poster er private (private) som standard. Revisjoner beholdes, og autolagring er slått av fordi postene ikke har noen redigeringsøkt.

Tilgangene følger navnerommet *_knowledge_items. Tilgangspolicyen fra Gutenberg PR 78296, slik forslaget gjengir den:

Selve Guidelines-siden krever fortsatt manage_options. Siden ingenting i wp_knowledge er offentlig, ser en crawler det aldri. En publishingPrinciples-lenke i schemaet ditt må peke til en offentlig side.

#Hvordan Retningslinjer gikk fra Gutenberg 22.7 til en nedstemt sammenslåing

Navnet og lagringen endret seg to ganger før vetoet. Retningslinjer kom som eksperiment i Gutenberg 22.7, beskrevet 23. mars 2026 av Aagam Shah. Du slo det på under Gutenberg, Eksperimenter, og da dukket siden Guidelines opp under Innstillinger med seksjoner for Site, Copy, Images, Blocks og Additional, pluss eksport til guidelines.json, import og revisjonshistorikk. Lagringen var en innleggstype kalt wp_content_guideline, med hver kategori i innleggsmeta og REST på /wp/v2/content-guidelines. Innlegget sier at Retningslinjer «med vilje fokuserer på innsamling og henting» (Aagam Shah, egen oversettelse) og verken håndhever regler eller genererer innhold.

22. juni publiserte Greg Ziółkowski sammenslåingsforslaget for 7.1, med kjerneoppdateringen i wordpress-develop PR 12201 (Trac-sak 65476). Gutenberg PR 79149, slått sammen 29. juni, ga lageret navnet wp_knowledge. 10. juli la Anne McCarthy ut beslutningen i kommentarene etter en gjennomgang med Matt Mullenweg: arbeidet skulle ikke videre i 7.1, og kjernen skulle ikke ta inn ting som «ikke allerede drives av reell bruk med imponerende vekst fra uke til uke (tenk tosifret)» (Anne McCarthy, egen oversettelse). Beta 1 kom 15. juli.

Resten kan du se på GitHub. Ziółkowski åpnet WordPress/ai PR 949 18. august for å flytte eksperimentet inn i AI-utvidelsen. Han lukket den uten sammenslåing 1. oktober, etter at vedlikeholderne sa at eksperimenter i AI-utvidelsen skal bygge på Gutenberg-eksperimentene i stedet for å duplisere dem. Per 14. oktober 2026 er PR 12201 fortsatt åpen, og wp-includes/post.php i 7.1-grenen inneholder ingen wp_knowledge. Funksjonen finnes bare bak eksperimentflagget i Gutenberg.

#Fjerner WordPress 7.1 Classic-blokken

En plan om å skjule Classic-blokken fra innsetteren i 7.1 ble reversert. Marin Atanasov sa at den opprinnelige tilnærmingen i stor grad hadde ting bakvendt. Blokken er der fortsatt. Ikke kjør en massekovertering fordi du tror 7.1 startet en klokke. Kilde: innlegget fra Marin Atanasov 7. juli.

Hvis du likevel vil konvertere Classic-innhold (core/freeform) i ditt eget tempo, er her et WP-CLI-mønster og et oppryddingsfilter. Test på en kopi av databasen. Å bytte freeform-delimiter med avsnittsdelimiter er et stump verktøy og ødelegger blandet HTML.

Kjør følgende kommando på serveren:

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

I tillegg en hjelpefunksjon i temaets functions.php som rydder TinyMCE-rester:

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

#Hva erstatter skjulingen av Classic-blokken i WordPress-kjernen

Innlegget fra 7. juli sier at skjulingen ikke brakte prosjektet nærmere å slutte å laste TinyMCE, og slår fast prinsippet om at «Classic-blokken skal bli foreldet fordi folk velger det, ikke med tvang» (Marin Atanasov, egen oversettelse). Det fjernet også varselet om utfasing på blokknivå, tok tilbake handlingen «Konverter til blokker» i verktøylinjen og droppet filteret wp_classic_block_supports_inserter, som aldri kom i en stabil utgivelse. Utvidelsen Enable Classic Block legges ned, så du kan deaktivere den.

Innlegget lister opp arbeidet som erstatter skjulingen:

• finne ut hvorfor folk fortsatt bruker Classic, og tette de hullene,
• gjøre «Konverter til blokker» pålitelig, siden den fortsatt har feil og inkonsekvenser,
• bygge bedre verktøy for konvertering og migrering, også massemigrering,
• forbedre hvordan TinyMCE-ressurser registreres, og la dem slås av,
• gi utvidelser en måte å oppgi en eksplisitt avhengighet til TinyMCE på,
• utforske lasting av TinyMCE ved behov eller asynkront,
• slutte å laste TinyMCE i blokkeditoren når Classic-blokken er slått av i blokkbehandleren.

Du kan sjekke tilstanden i 7.1 i kildekoden: block.json for core/freeform i 7.1-grenen har ikke flagget inserter: false. Det siste punktet på listen er fremtidig arbeid, så ikke regn med at det å slå av Classic-blokken i blokkbehandleren fjerner TinyMCE fra editoren i 7.1.

#Slik legger du wp_knowledge-data inn i JSON-LD-schema

Å implementere en knowledge-innleggstype selv, som utvidelse, er fortsatt et nyttig verktøy for Answer Engine Optimization. Det er ikke en kjernefunksjon i 7.1. I en tid med Perplexity eller ChatGPT Search må nettsteder servere informasjon tydelig. Å lagre offisielle bedriftsopplysninger i en strukturert innleggstype forenkler generering av Schema.org-metadata.

For eksempel et filter som legger data fra wp_knowledge inn som about- eller mentions-objekter i sidens JSON-LD:

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

Vi kan også registrere tilpassede metadata for 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'
    ]);
}

Når AI-crawlere indekserer nettstedet, får de straks et strukturert, autoritativt sammendrag av fakta. Det øker merkevarens synlighet i direkte søkesvar.

#Hvordan redaksjonell policy i Schema.org styrker E-E-A-T

Å legge redaksjonelle retningslinjer rett inn i WordPress-kjernen via wp_knowledge er ikke tilfeldig. I 2026 legger søkemotorer, særlig Google, enestående vekt på E-E-A-T. Utgiverens troverdighet og åpenhet i innholdsproduksjonen er rangeringsfaktorer.

Tidligere ble forfatterbokser eller om-oss-sider oppdatert for hånd. I dag leter Googles automatiserte systemer etter dypere semantiske koblinger. De vil vite om det finnes en redaksjonell policy, og hvordan fakta blir verifisert.

wp_knowledge strukturerer denne informasjonen på systemnivå. En egen innleggstype for etiske standarder, ekspertteam og forskningsmetodikk blir del av nettstedets kunnskapsgraf. SEO-utvidelser kan knytte disse reglene til forfattere via attributtet publishingPrinciples i Schema.org. Siden de foreslåtte postene er private, må en slik lenke peke til en offentlig side som publiserer den samme policyen. Det signaliserer til søkemotorene at innholdet er resultatet av en redaksjonell prosess, ikke blindt generert av AI.

Svarmotorer bygger også direkte relasjoner mellom entiteter. Å knytte forfattere, redaksjonelle prosesser og validert innhold via strukturert JSON-LD løfter tillitsscoren til hele nettstedet i AI-søkemodeller.

#Slik sjekker du innlegg mot wp_knowledge-regler før publisering

For å automatisere kvalitetskontroll i et B2B-byrå kan utviklere bruke dette PHP-filteret, som sjekker innlegg mot wp_knowledge-retningslinjer før publisering:

<?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-sidelinjekomponent for Gutenberg-editoren:

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('garanti')) {
                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 });

Og den fulle PHP-utvidelsesstrukturen for registrering av innleggstypen:

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

#Hvordan fungerer blokkvalidering og deprecations i Gutenberg

Classic-blokken fjernes ikke i 7.2 på grunn av denne syklusen. Deprekeringsskjemaer for blokker er fortsatt viktige for dine egne blokker. Slik matcher Gutenberg lagret HTML mot en save()-funksjon, enten kjernen noen gang skjuler core/freeform eller ikke.

#1. Gutenberg Block Validation API under panseret

Når et innlegg lastes i blokkeditoren, parser JS-motoren de lagrede HTML-kommentarene i wp_posts.post_content. Den kjører blokkens gjeldende save()-funksjon og sammenligner den genererte utdataen med rå HTML i databasen.

Hvis databasen inneholder:

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

men blokkens nåværende implementasjon gir new-class, oppstår en valideringsfeil. Gutenberg advarer om ødelagt blokk og tilbyr konverteringsknapper.

#2. Nyregistrering av eldre blokkstrukturer i React (deprecations)

For å unngå valideringsfeil, registrer tidligere versjoner av blokken i deprecated-arrayet. Gutenberg prøver å matche disse skjemaene i rekkefølge hvis primærvalideringen feiler:

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. Programmatisk blokkparsing i PHP (parse_blocks)

På servernivå bruker WordPress parse_blocks() til å deserialisere innleggsinnholdet tilbake til et strukturert array av blokkobjekter. Parseren leser delimiterne, dekoder attributt-JSON og returnerer et tre:

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

Denne arkitekturen holder B2B-kundenettsteder ytelsessterke, stabile og enkle å vedlikeholde ved store migreringer på blokknivå.

#Slik bygger du en wp_knowledge-utvidelse for flere desker

wp_knowledge er ikke i 7.1. Hvis du trenger strukturerte redaksjonelle regler for mennesker og agenter, registrerer du din egen innleggstype i en utvidelse. Skissen under er den utvidelsesformen. Det er ikke et kundeforløp, og det er ikke et kjerne-API.

Prefikset betyr noe. Utvidelseshåndboken om egne innleggstyper sier: «For fremtidig kompatibilitet, ikke bruk wp_ som identifikator» (WordPress Plugin Handbook, egen oversettelse). Gutenberg-eksperimentet registrerer wp_knowledge bare hvis innleggstypen ikke finnes fra før. En utvidelse som tar navnet først, bytter ut et privat lager med de innstillingene utvidelsen valgte, inkludert public satt til true. Skissen nedenfor bruker derfor wppoland_knowledge.

Redaksjoner som allerede holder stilregler i PDF-er, har samme problem som før 7.1: redaktører sjekker utkast for hånd, og eksterne generatorer har ingen offisiell plass å lese reglene fra.

#En arbeidsflyt formet som utvidelse

1. Strukturerte kunnskapsnoder: Vi definerte konkrete wppoland_knowledge-innlegg med redaksjonelle retningslinjer for ulike desker (nyheter, finans, sport). Reglene lå som strukturerte JSON-schema-payloads.
2. REST-API-distribusjon for AI-verktøy: Vi eksponerte et sikret REST-endepunkt, slik at eksterne innholdspipelines kan hente lokaliserte formatkrav dynamisk:

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

3. Gutenberg-sidelinje som revisor i sanntid: En React-komponent i editorsidelinjen abonnerte på dokumentendringer og markerte vokabular eller formuleringer som brøt gjeldende desk-retningslinjer.
4. Programmatiske WP-CLI-kvalitetssjekker: Et cron-skript med WP-CLI reviderte publiserte innlegg mot retningslinjene og flagget unntak for seniorredaktør.

Ingenting av dette krever en kjerne-innleggstype. Det krever en utvidelse du eier, med rettigheter og en REST-flate du kan versjonere. Det var utfallet vetoet pekte mot: vis adopsjon utenfor kjernen først.

#Hjelper wp_knowledge med AEO for B2B-nettsteder

En native wp_knowledge-innleggstype i kjernen ville vært et nyttig steg for AI-tiden. Den er ikke i 7.1. Vetoet lot arbeidet ligge som et eksperiment i Gutenberg. Når søkeatferd skifter fra klassiske trefflenker til svarmotorer (Perplexity, Claude, Gemini), utvikler SEO seg til Answer Engine Optimisation (AEO).

B2B-utviklere og utgivere kan ikke lenger skrive bare for menneskelig lesbarhet eller enkle nøkkelordindeksere. De må levere strukturerte, verifiserbare, maskinlesbare payloads som AI-modeller kan bruke til å bygge nøyaktige svar.

#Hvorfor strukturerte retningslinjer teller for B2B-synlighet

1. E-E-A-T-verifisering (tillitssignaler): Svarmotorer favoriserer transparente og autoritative kilder. Redaksjonell policy, ekspertbiografier og verifiseringsflyt hjelper bare når de ligger på offentlige sider som AI-boter kan knytte til aktive forfattere. Poster i det foreslåtte wp_knowledge-lageret er private, så de ville matet dine egne verktøy, ikke crawlerne.
2. Schema.org-prinsipper: Datapunkter fra wp_knowledge kan SEO-verktøy mappe automatisk til Schema.org-felt (egenskapen publishingPrinciples). Det signaliserer en kontrollert redaksjonell pipeline til AI-crawlere.
3. Ikke bank på en Core Web Vitals-gevinst fra Classic-blokk-deprekering. Den skjulingen ble ikke levert. Vil du ha TinyMCE av editorstien, er det fortsatt din utvidelse og ditt tema, ikke en gratis lunsj fra 7.1.

Trenger du strukturerte retningslinjer på et kundenettsted, registrer din egen innleggstype. Ikke vent på at kjernen reverserer vetoet.

#Hva du bør gjøre etter oppdatering til WordPress 7.1

1. Ikke massekonverter Classic-blokker på grunn av denne utgivelsen. Innsetteren tilbyr dem fortsatt.
2. Revider Classic-bruk først når du likevel tar i det innholdet, slik at du kjenner gjelden.
3. Ikke se etter wp_knowledge på et 7.1-nettsted. Den er ikke der. Trenger du lagringen, lever en utvidelse.
4. Test innleggseditoren i iframe, som faktisk ble levert. Egne blokker som antar et globalt document vil knekke. Se notatet om iframe-editoren.
5. Behold Guidelines i Gutenberg hvis du allerede bruker eksperimentet. Ikke lov kundene en kjerne-innstillingsflate.

#Oppsummering

WordPress 7.1 Mary Lou ble lansert uten wp_knowledge og uten Guidelines. Sammenslåingen ble stanset med veto. Classic-blokken står fortsatt i innsetteren. Den nyttige 7.1-jobben for byråer ligger et annet sted: responsiv styling, klientside-media og den alltid iframede editoren. Vil du fortsatt ha strukturerte redaksjonelle regler for agenter, bygg utvidelsen. Ikke skriv den inn i en 7.1-oppgraderingsplan som om kjernen tok den.