WordPress AI Connectors: какво променя WordPress 7.0 за плъгините и AI моделите

На 20 май 2026 WordPress 7.0 излезе с първата си нативна AI инфраструктура и център на тази инфраструктура е новият екран Settings > Connectors.

Преди тази версия всеки плъгин с AI функционалност изграждаше собствена интеграция: собствена страница за настройки, собствено съхранение на API ключове, собствена логика за HTTP заявки към доставчика. Резултатът беше десетки места, на които администраторът пише един и същи ключ, и нулева преносимост между плъгини. Connectors API събира тази фрагментация на едно място в ядрото. Един ключ, един провайдър, всички съвместими плъгини го виждат автоматично.

Какво представлява connector от гледна точка на кода

Connector е регистрирано отношение между WordPress инсталация и външна услуга, която изисква някаква форма на удостоверяване. В 7.0 поддържаните методи за authentication са api_key и none, като архитектурата е заложена да приема и други в бъдещи версии.

Системата стартира на init hook чрез функцията _wp_connectors_init(), която създава singleton инстанция на WP_Connector_Registry. Този registry първо регистрира трите вградени конектора (Anthropic, Google, OpenAI) с твърдо зададени стойности, а след това обхожда AiClient::defaultRegistry() от PHP AI Client SDK и наслагва метаданните от регистрираните провайдъри върху defaults. Ако plugin-провайдър дефинира собствени икони, описания или поддържани модели, те заменят стандартните без hook битки. За четене от друг код извън callback-а на wp_connectors_init се ползват публичните функции wp_get_connector(), wp_get_connectors() и wp_is_connector_registered(). Достъп директно към registry инстанцията се запазва за самия регистрационен hook.

Трите кутии в Settings > Connectors

Прясно инсталиран WordPress 7.0 показва на страницата Settings > Connectors три провайдъра като placeholder картички: OpenAI, Anthropic и Google.

Картичките не са функциониращи провайдъри сами по себе си. Те са указатели към официалните provider plugins в директорията. Натискането на бутона стартира инсталация на съответния плъгин (например openai-connector), след което се отваря форма за въвеждане на API ключ. Ключът се валидира server-side през самия провайдър преди да бъде записан в wp_options. Резултатът е, че всеки плъгин, който вика wp_ai_client_prompt(), получава достъп до тези креденциали без собствен setup workflow.

Главната входна точка: wp_ai_client_prompt()

Цялата комуникация с AI модели минава през една функция и тя връща fluent builder обект.

$text = wp_ai_client_prompt( 'Напиши кратко резюме на статия за caching в WordPress.' )
    ->using_temperature( 0.4 )
    ->using_model_preference(
        'claude-sonnet-4-6',
        'gemini-3.1-pro-preview',
        'gpt-5.4'
    )
    ->generate_text();

if ( is_wp_error( $text ) ) {
    return $text;
}

echo wp_kses_post( $text );

Истинският PHP SDK под капака е wordpress/php-ai-client, който работи и извън WordPress контекст и използва camelCase методи плюс exceptions. WP_AI_Client_Prompt_Builder го обвива в snake_case методи, хваща exception-ите и ги превръща в WP_Error обекти. Методът using_model_preference() приема списък от желани модели в ред на предпочитание. Builder-ът избира първия наличен от списъка и пада към съвместима алтернатива, ако нито един не е конфигуриран на сайта. Плъгините не зависят от това кой провайдър точно е настроен от собственика – те описват какво искат, не кого да питат.

За структурирани отговори builder-ът поддържа JSON schema валидация на изхода:

$schema = array(
    'type'  => 'array',
    'items' => array(
        'type'       => 'object',
        'properties' => array(
            'title'    => array( 'type' => 'string' ),
            'category' => array( 'type' => 'string' ),
        ),
        'required' => array( 'title', 'category' ),
    ),
);

$json = wp_ai_client_prompt( 'Изброй 5 популярни WordPress плъгина с категория.' )
    ->as_json_response( $schema )
    ->generate_text();

$data = json_decode( $json, true );

Тази възможност е критична за плъгини, които искат да парсират AI отговора като данни вместо като свободен текст.

Достъп, права и prompt_ai capability

Извикването на AI заявка не е безплатна операция за никой сайт, който плаща токени към провайдър.

Затова WP AI Client въвежда нова capability на име prompt_ai, която по подразбиране е дадена само на администраторите. Това решава два проблема едновременно: ограничава кой може да хаби бюджета на сайта чрез плъгини, експониращи AI функция към ниско привилегировани роли, и дава точка за контрол на администратора, ако иска например да даде право на редакторите да генерират текст. Capability-то се проверява в builder-а преди реален API call – ако правото липсва, връща се WP_Error без HTTP заявка към провайдъра. Защитата на WordPress инсталация вече трябва да включва и преглед на това кои роли имат prompt_ai и колко често го викат. Логване на token usage през getTokenUsage() метода на result обекта позволява откриване на anomaly преди фактурата да удари.

Връзката с Abilities API и MCP Adapter

Connectors API не съществува в изолация – той е третият слой от стек, който започна с Abilities API в WordPress 6.9.

Abilities API регистрира конкретни действия в WordPress (publish_post, update_product, get_orders) като дискретни capabilities с описание на параметри и резултати. MCP Adapter превръща тези abilities в Model Context Protocol инструменти, които външни агенти като Claude Desktop или Cursor могат да открият и извикат. WP AI Client пък върви в обратна посока – дава на самите плъгини възможност да правят AI заявки от вътре в WordPress. Двупосочна комуникация: AI може да чете и пише в сайта чрез MCP, а сайтът може да генерира съдържание чрез AI Client. WooCommerce вече има MCP сървър, който позволява AI асистент да управлява поръчки и продукти през абилитите на магазина.

Какво още не работи в 7.0

Третите страни нямат начин да регистрират собствен connector на екрана Settings > Connectors в 7.0.

Тази extensibility е планирана за 7.1 и към момента само трите официални провайдъра (OpenAI, Anthropic, Google) се показват на picker екрана. Ако плъгин ползва Mistral, Cohere или локален Ollama модел, той трябва да регистрира собствен провайдър директно в PHP AI Client registry, а UI за ключа да поддържа сам. Ядрото също не идва с готови AI feature-и за крайни потребители. Очаквате ли тулбар бутон „Напиши alt текст“ или auto генериране на meta description от кутията, ще трябва да инсталирате плъгин, който ползва новия API. Логиката на „какво AI прави“ е умишлено отделена от логиката на „как AI се свързва“. Чат плъгините за WordPress вече започват да мигрират към новия SDK, което означава, че смяна на провайдъра ще става от едно място.

Кеширане и производителност на AI заявките

AI отговорите са най-скъпият тип външна заявка, която WordPress сайт прави.

Една заявка към GPT-5 или Claude Sonnet 4.6 може да добави между 2 и 8 секунди latency и да струва от $0.003 до $0.05 на повикване в зависимост от размера на input и output. На сайт с трафик това бързо се натрупва без layer от кеш отгоре. Builder-ът няма вграден persistent cache, но resultите имат стабилен hash на входните параметри и могат да се кешират в transients или object cache. Page cache плъгините няма да кешират AI заявките автоматично, защото това става в PHP layer-а, не на HTML output ниво. Custom кеш в wp_cache_get / wp_cache_set или transient API остава отговорност на плъгина, който вика SDK-то.

Какво да направите днес

Тестова инсталация на 7.0 на staging среда с активиран Anthropic или OpenAI connector отнема под 5 минути.

Конфигурацията изисква PHP 7.4 или по-високо, като 8.3+ е препоръчително заради по-добрата производителност на JIT компилатора. Версията на PHP на хостинга е първото нещо за проверка преди миграция. API ключ от избрания провайдър се пише веднъж в Settings > Connectors и веднага става достъпен за всеки плъгин, който вика SDK-то. За продукционни сайтове изчакване от 1 до 2 месеца преди миграция е разумно, докато екосистемата от плъгини догони и популярните теми също интегрират новия API.

Connector-ите не превръщат WordPress в AI платформа, но премахват най-болезнения tax от integration работата.

Често задавани въпроси