WordPress 7.0 AI-klienten ur en utvecklares perspektiv

WordPress 7.0 har en inbyggd AI-klient. Inte som ett plugin, inte som en experimentell funktionsflagga, utan som en del av kärnan. Det är ett uttalande.

Jag har utvecklat WordPress-plugins sedan 2009 och har arbetat med Citadellagret® Jag har själv byggt ett AI-plugin som påverkas direkt av detta arkitektoniska beslut. Här är min tekniska analys: Vad kan API:et göra, vilka är dess styrkor och vad behöver plugin-utvecklare veta?

Ingångspunkten: wp_ai_client_prompt()

Allt börjar med en enda funktion:

$builder = wp_ai_client_prompt();

Detta ger en WP_AI_Klient_Prompt_Builder-Objekt tillbaka – en Fluent Builder där prompt, konfiguration och genereringsmetod kopplas samman. Grundprincipen: Utvecklaren beskriver, vad han behöver. WordPress tar hand om som.

Ett enkelt exempel på textgenerering:

// Fråga direkt som en parameter - bekvämt för enkla fall
$text = wp_ai_client_prompt( 'Sammanfatta fördelarna med cachelagring i WordPress.' )
    ->använda_temperatur( 0.7 )
    ->generate_text();

// Felhantering som överallt i WordPress: Kontrollera WP_Error
if ( is_wp_error( $text ) ) {
    returnera;
}

echo wp_kses_post( $text );

Frågetexten kan ställas in som en parameter eller via med_text() Det senare är användbart om prompten sätts samman dynamiskt.

Mer än text: Bild, språk, video

API:et är multimodalt. Bildgenereringen fungerar enligt samma mönster:

använda WordPress\AiClient\Files\DTO\File;

$image = wp_ai_client_prompt( 'En futuristisk WordPress-logotyp i neonstil' )
    ->generera_bild();

if ( is_wp_error( $image ) ) {
    returnera;
}

// Fil-DTO med data-URI - direkt användbar
echo '<img src="' . esc_url( $image->getDataUri() ) . '" data-no-translation="" data-no-auto-translation="">';

För variationer finns det generera_bilder( 4 ) och generera_texter( 4 ). Dessutom convert_text_to_speech_result(), generate_speech_result() och generera_video_resultat(). WordPress täcker alla vanliga modaliteter.

Särskilt spännande: multimodala resultat i en enda undersökning:

använda WordPress\AiClient\Messages\Enums\ModalityEnum;

// Text och bilder i ett svar - resultatet innehåller båda
$result = wp_ai_client_prompt( 'Skapa ett recept med foton för varje steg.' )
    ->as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
    ->generera_resultat();

Detta öppnar dörren för plugins som genererar innehåll som går längre än ren text.

Feature Detection: Gör inga antaganden

Inte alla WordPress-installationer kommer att ha en AI-leverantör konfigurerad. Och inte alla leverantörer stöder alla modaliteter. API:et erbjuder deterministiska kontroller:

$builder = wp_ai_client_prompt( 'test' )
    ->använder_temperatur( 0.7 );

// Inget API-anrop - rent logisk kontroll mot tillgängliga leverantörer
if ( $builder->is_supported_for_text_generation() ) {
    // Visa användargränssnitt för textgenerering
}

if ( $builder->is_supported_for_image_generation() ) {
    // Visa knapp för bildgenerering
}

Det är en snygg lösning. Kontrollerna kostar ingenting – inga API-anrop, ingen fördröjning. Plugin-utvecklare kan ladda sitt användargränssnitt villkorligt och visa ett hjälpsamt meddelande om ingen AI är tillgänglig. Regeln: Utgå aldrig från att AI-funktioner kommer att fungera bara för att WordPress 7.0 är installerat.

Tillgängliga kontroller: is_supported_for_text_generation(), is_supported_for_image_generation(), is_supported_for_text_to_speech_conversion(), is_supported_for_speech_generation(), is_supported_for_video_generation().

Modellera preferenser istället för krav

Här blir designfilosofin tydlig:

$result = wp_ai_client_prompt( 'Förklara tryckningens historia.' )
    ->använda_temperatur( 0.1 )
    ->använda_modell_preferens(
        'claude-sonnet-4-6',
        'gemini-3.1-pro-preview',
        'gpt-5.4'
    )
    ->generera_text_resultat();

använda_modell_preferens() är en Företräde, inget krav. AI-klienten tar den första tillgängliga modellen från listan - eller någon kompatibel modell om ingen av dem är konfigurerad. Plugin-koden fungerar alltid, oavsett leverantör.

Detta är rätt beslut. Plugin-utvecklare bör aldrig vara beroende av att en viss modell är tillgänglig. Den officiella rekommendationen är att sortera dina modeller så att nyare kommer före äldre. De tre officiella leverantörspluginsen för lanseringen gör redan detta.

Strukturerade svar med JSON-schema

Detta är en höjdpunkt för plugins som kräver strukturerad data - och det finns många av dem:

$schema = array(
    'type' => 'array',
    'items' => matris(
        'typ' => 'objekt',
        'properties' => array(
            'plugin_name' => array( 'type' => 'string' ),
            'category' => array( 'type' => 'string' ),
        ),
        'required' => array( 'plugin_name', 'category' ),
    ),
);

$json = wp_ai_client_prompt( 'Lista 5 populära WordPress-insticksprogram med kategori.' )
    ->as_json_response( $schema )
    ->generera_text();

// Strukturerad data direkt som en array - ingen manuell parsning krävs
$data = json_decode( $json, true );

Detta är guld värt för SEO-plugins, formulärplugins och verktyg för innehållsanalys. I stället för att analysera ostrukturerad text får du direkt användbara data.

Arkitektur med två lager

Under motorhuven består AI Client av två nivåer:

1. PHP AI-klient (wordpress/php-ai-klient) - en leverantörs-agnostisk PHP SDK, buntad som ett externt bibliotek i Core. CamelCase-metoder, undantag, tekniskt WordPress-oberoende.
2. WordPress Omslag — WP_AI_Klient_Prompt_Builder utvecklar SDK i WordPress-konventioner: snake_case-metoder, WP_Fel istället för undantag, integration med WordPress HTTP Transport, Abilities API, Connectors-infrastruktur och hook-systemet.

Detta är en elegant separation. PHP SDK kan teoretiskt sett också användas utanför WordPress. WordPress-omslaget gör det idiomatiskt. Och det GenerativAiResultat-objektet kan serialiseras och kan anslutas direkt till rest_ensure_response() REST API-integration direkt från start:

function my_rest_callback( WP_REST_Request $request ) {
    $result = wp_ai_client_prompt( $request->get_param( 'prompt' ) )
        ->generate_text_result();

    // WP_Error oder GenerativeAiResult — beides funktioniert
    return rest_ensure_response( $result );
}

Granulär kontroll: Filtret

För säkerhet och efterlevnad finns det wp_ai_client_prevent_prompt:

add_filter(
    'wp_ai_client_prevent_prompt',
    function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
        // Exempel: AI endast för administratörer
        if ( ! current_user_can( 'manage_options' ) ) {
            return true;
        }
        return $prevent;
    },
    10,
    2
);

Om en prompt är blockerad: inget API-anrop, is_supported_*() ger falska tillbaka, generera_*() Förnödenheter WP_Fel. Ren, förutsägbar, inga tävlingsförhållanden.

Styrkor och svagheter

Vilket är en bra lösning:

• Abstraktion av leverantör. Plugin-utvecklare behöver aldrig hantera API-nycklar, prisgränser eller leverantörens egenheter.
• Funktionsdetektering utan API-anrop. Inget gissande om något fungerar.
• WordPress-konventionerna. WP_Fel, krokar, REST-kompatibilitet - det känns naturligt.
• Stöd för JSON-schema. Strukturerade svar stöds i första klass.
• Den tvådelade arkitekturen. Ren separation mellan SDK och WordPress-integration.

Vad jag observerar kritiskt:

• Webbplatsägaren är ansvarig för konfigurationen av anslutningen. Plugins har inget inflytande på detta, om en leverantör är konfigurerad. Feature Detection fångar upp detta, men UX-utmaningen kvarstår.
• Modellandskapet rör sig snabbt. Det återstår att se hur väl preferenslistan kommer att åldras när nya modeller dyker upp var tredje månad.
• Konsekvenserna för prestandan är fortfarande oklara. Hur beter sig systemet under belastning när 10 plugins skickar uppmaningar samtidigt?

Vad detta innebär för befintliga plugins

Varje plugin som för närvarande har sina egna AI-integrationer står inför ett beslut: Behåll din egen API-anslutning eller migrera till AI-klienten?

För SEO-tillägg svaret är tydligt - strukturerad data, innehållsanalys och generering av metabeskrivningar körs mycket renare via AI-klienten. För Plugins för formulär öppnar upp intelligent fältvalidering och automatisk ifyllning. För Plugins för e-handel AI-genererade produktbeskrivningar blir plötsligt triviala.

För ett insticksprogram som citelayer® – AI-synlighet för WordPress, som arbetar i gränssnittet mellan WordPress och AI-system, är AI-klienten en naturlig förlängning. Citelayer gör innehållet läsbart för AI - genom llms.txt, schemainjektion, botspårning och protokoll som UCP och WebMCP. AI-klienten skulle kunna komplettera dessa analyslager med mer intelligenta, AI-stödda analyser. Jag har förklarat vad detta innebär för AI Visibility i konkreta termer. mer i detalj i Citelayer-bloggen.

Inte en pryl utan infrastruktur

WordPress 7.0 AI Client är inte en pryl. Det är en infrastruktur. Väl genomtänkt, WordPress-idiomatisk och med en tydlig designfilosofi: utvecklaren beskriver avsikten, systemet tar hand om utförandet.

Alla som utvecklar WordPress-plugins idag bör bekanta sig med detta API. Inte för att du måste - utan för att det är grunden för nästa generation av WordPress-plugins.

Den fullständiga API-dokumentationen finns tillgänglig på WordPress Skapa blogg.