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.

#Den nye innleggstypen wp_knowledge og AI-retningslinjer

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: Retningslinjer vises direkte i editoren som en redaksjonell sjekkliste, slik at nye skribenter kommer raskere i gang.
2. For AI-verktøy: Innholdsgeneratorer kan hente reglene via REST-API eller WP-CLI og holde den genererte teksten i tråd med nettstedets stil.

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

#Sammenligning av retningslinjehåndtering i WordPress

Slik endrer lagring av redaksjonelle regler seg:

#Classic-blokken: utfasingen skjedde ikke

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.

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

#AEO-optimalisering (Answer Engine Optimization) med wp_knowledge

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

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

Mer om blokk-deprekering: Classic-blokken (også kjent som core/freeform) var en nøkkelkomponent i overgangen fra TinyMCE til Gutenberg i WordPress 5.0. Over årene ble bakoverkompatibilitet med TinyMCE en ytelsesbrems. Blokkeditorens JS-filer måtte laste hele TinyMCE-biblioteket (over 1 MB) for sikkerhets skyld. Å skjule Classic-blokken ville latt kjernen late-laste disse ressursene. Den skjulingen ble ikke levert i 7.1, så ikke behandle et krav om 40 prosent editorlast som et målt 7.1-resultat.

#Dypdykk: E-E-A-T og rollen til strukturerte redaksjonelle data

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

#Praktisk integrasjon av wp_knowledge i publiseringsflyten

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

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

Mer om blokk-deprekering: Classic-blokken (også kjent som core/freeform) var en nøkkelkomponent i overgangen fra TinyMCE til Gutenberg i WordPress 5.0. Over årene ble bakoverkompatibilitet med TinyMCE en ytelsesbrems. Blokkeditorens JS-filer måtte laste hele TinyMCE-biblioteket (over 1 MB) for sikkerhets skyld. Å skjule Classic-blokken ville latt kjernen late-laste disse ressursene. Den skjulingen ble ikke levert i 7.1, så ikke behandle et krav om 40 prosent editorlast som et målt 7.1-resultat.

#Teknisk guide: Gutenberg blockvaliderings-API og håndtering av deprekert kode i React

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

#Designskisse: et kunnskapsmagasin for flere desker du bygger selv

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.

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

#Ekspertvurdering og B2B-strategi: rollen til wp_knowledge i AEO-tiden

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 i Gutenberg og hos Automattic. 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 wp_knowledge teller for B2B-synlighet:

1. E-E-A-T-verifisering (tillitssignaler): Svarmotorer favoriserer transparente og autoritative kilder. Å lagre redaksjonell policy, ekspertbiografier og verifiseringsflyt i wp_knowledge lar AI-boter knytte disse filene til aktive forfattere.
2. Schema.org-prinsipper: Datapunkter fra wp_knowledge kan SEO-verktøy mappe automatisk til Schema.org-felt (som publishingPrinciples eller editorialGuidelines). 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.

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