WordPress 7.1: diretrizes de IA e o novo tipo de conteúdo wp_knowledge

#Introdução

A proposta de fusão de Greg Ziółkowski para meter um tipo de conteúdo wp_knowledge e Diretrizes de IA no WordPress 7.1 gerou um debate real. As redações queriam um sítio padrão para regras de redatores e ferramentas de IA. Críticos, incluindo Jon Brown da 9seeds, disseram que devia viver primeiro como extensão.

Nenhuma das alterações chegou. Matt Mullenweg vetou a fusão das Guidelines em julho. O plano de ocultar o bloco Clássico no inseridor foi revertido no mesmo mês. O WordPress 7.1 Mary Lou saiu a 19 de agosto sem wp_knowledge, sem Guidelines e com o bloco Clássico ainda no inseridor. O resto deste artigo é a proposta tal como estava, mais o que fazer agora que o núcleo não a aceitou. Os trechos PHP e React abaixo são um esboço de extensão, não uma API de núcleo.

#O novo tipo de conteúdo wp_knowledge e diretrizes de IA

O objetivo da proposta de Greg Ziółkowski é uma área dedicada no núcleo para diretrizes do sítio, voz da marca e estruturas de conteúdo. Estes dados padronizados sob wp_knowledge destinam-se a:

1. Para redatores: as diretrizes aparecem diretamente no editor como lista de verificação editorial, para novos autores arrancarem mais depressa.
2. Para ferramentas de IA: geradores de conteúdo podem ir buscar estas regras via REST-API ou WP-CLI e alinhar o texto gerado com o estilo do sítio.

Alguns programadores consideram a mudança prematura e preferem um período de prova como feature plugin antes de qualquer fusão definitiva no núcleo.

#Comparação da gestão de diretrizes no WordPress

Eis como muda o armazenamento das regras editoriais:

#Bloco Clássico: a descontinuação não aconteceu

Um plano para ocultar o bloco Clássico no inseridor na 7.1 foi revertido. Marin Atanasov disse que a abordagem original tinha as coisas em grande parte ao contrário. O bloco continua lá. Não faça uma conversão em massa só porque pensa que a 7.1 arrancou um relógio.

Se mesmo assim quiser converter conteúdo Clássico (core/freeform) no seu próprio ritmo, aqui está um padrão WP-CLI e um filtro de limpeza. Teste numa cópia da base de dados. Substituir o delimitador freeform por um delimitador de parágrafo é um instrumento bruto e estraga HTML misto.

Execute o seguinte comando no servidor:

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

Além disso, uma função auxiliar no functions.php do tema para limpar restos do 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);

#Otimização AEO (Answer Engine Optimization) com wp_knowledge

Implementar um tipo de conteúdo de conhecimento por conta própria, como extensão, continua a ser uma ferramenta útil para Answer Engine Optimization. Não é uma funcionalidade de núcleo da 7.1. Na era do Perplexity ou do ChatGPT Search, os sítios têm de servir informação de forma clara. Guardar dados oficiais da empresa num tipo de conteúdo estruturado simplifica a geração de metadados Schema.org.

Por exemplo, um filtro que acrescenta dados de wp_knowledge como objetos about ou mentions no JSON-LD da página:

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

Também podemos registar metadados personalizados para 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'
    ]);
}

Quando os crawlers de IA indexam o sítio, recebem de imediato um resumo estruturado e autoritativo dos factos. Isso aumenta a visibilidade da marca nas respostas diretas.

Mais sobre a história da descontinuação de blocos: o bloco Clássico (também conhecido como core/freeform) foi uma peça-chave na transição do TinyMCE para o Gutenberg no WordPress 5.0. Ao longo dos anos, manter o TinyMCE compatível tornou-se um travão de desempenho. Os ficheiros JS do editor de blocos tinham de carregar toda a biblioteca TinyMCE (mais de 1 MB) por precaução. Ocultar o bloco Clássico teria permitido ao núcleo carregar esses recursos de forma preguiçosa. Essa ocultação não saiu na 7.1, por isso não trate uma afirmação de 40% no carregamento do editor como um resultado medido da 7.1.

#Análise detalhada: E-E-A-T e o papel dos dados editoriais estruturados

Integrar diretrizes editoriais diretamente no núcleo do WordPress via wp_knowledge não é coincidência. Em 2026, os motores de pesquisa, sobretudo o Google, dão um peso sem precedentes aos critérios E-E-A-T. A credibilidade do editor e a transparência na criação de conteúdos são fatores de posicionamento.

Antes atualizavam-se à mão as caixas de autor ou as páginas «Sobre nós». Hoje os sistemas automatizados do Google procuram ligações semânticas mais profundas. Querem saber se existe uma política editorial e como se verificam os factos.

O wp_knowledge estrutura esta informação ao nível do sistema. Um tipo de conteúdo dedicado a normas éticas, equipas de especialistas e metodologias de investigação passa a fazer parte do grafo de conhecimento do sítio. Extensões de SEO podem ligar estas regras aos autores através do atributo publishingPrinciples no Schema.org. Isso sinaliza aos motores que o conteúdo resulta de um processo editorial, e não de geração cega por IA.

Os motores de resposta constroem também relações diretas entre entidades. Ligar autores, processos editoriais e conteúdo validado via JSON-LD estruturado sobe o trust score de todo o sítio nos modelos de pesquisa por IA.

#Integração prática do wp_knowledge no fluxo de publicação

Para automatizar o controlo de qualidade numa agência B2B, os programadores podem usar o seguinte filtro PHP para validar artigos contra as diretrizes wp_knowledge antes da publicação:

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

Componente React da barra lateral no editor 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('melhor') || content.includes('garantia')) {
                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 });

E a estrutura completa do ficheiro PHP da extensão para registar o tipo de conteúdo:

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

Mais sobre a história da descontinuação de blocos: o bloco Clássico (também conhecido como core/freeform) foi uma peça-chave na transição do TinyMCE para o Gutenberg no WordPress 5.0. Ao longo dos anos, manter o TinyMCE compatível tornou-se um travão de desempenho. Os ficheiros JS do editor de blocos tinham de carregar toda a biblioteca TinyMCE (mais de 1 MB) por precaução. Ocultar o bloco Clássico teria permitido ao núcleo carregar esses recursos de forma preguiçosa. Essa ocultação não saiu na 7.1, por isso não trate uma afirmação de 40% no carregamento do editor como um resultado medido da 7.1.

#Guia técnico: API de validação de blocos do Gutenberg e depreciações em React

O bloco Clássico não é removido na 7.2 com base neste ciclo. Os esquemas de depreciação de blocos continuam a importar para os seus próprios blocos. Eis como o Gutenberg compara o HTML guardado com uma função save(), quer o núcleo venha ou não a ocultar core/freeform.

#1. API de validação de blocos do Gutenberg por baixo

Quando um artigo carrega no editor de blocos, o motor JS analisa os comentários HTML guardados em wp_posts.post_content. Executa a função save() atual do bloco e compara o resultado gerado com o HTML em bruto na base de dados.

Se a base de dados contém:

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

mas a implementação atual do bloco devolve new-class, ocorre um erro de validação. O Gutenberg avisa sobre corrupção do bloco e oferece botões de conversão.

#2. Voltar a registar estruturas antigas do bloco em React (deprecations)

Para evitar erros de validação, registe versões anteriores do bloco no array deprecated. O Gutenberg tenta corresponder a estes esquemas por ordem se a validação principal falhar:

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. Análise programática de blocos em PHP (parse_blocks)

No servidor, o WordPress usa parse_blocks() para desserializar o conteúdo do artigo de volta a um array estruturado de objetos de bloco. O analisador lê delimitadores, descodifica JSON de atributos e devolve uma árvore:

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

Esta arquitetura mantém sítios de clientes B2B performantes, estáveis e fáceis de manter em migrações grandes ao nível dos blocos.

#Esboço de desenho: um repositório de conhecimento de várias mesas que constrói por si

O wp_knowledge não está na 7.1. Se precisa de regras editoriais estruturadas para humanos e agentes, regista o seu próprio tipo de conteúdo numa extensão. O esboço abaixo é essa forma de extensão. Não é um caso de cliente e não é uma API de núcleo.

As redações que já guardam regras de estilo em PDF continuam com o mesmo problema de antes da 7.1: os editores revêem rascunhos à mão, e os geradores externos não têm um sítio oficial de onde ler as regras.

#Um fluxo em forma de extensão:

1. Nós de conhecimento estruturados: definimos publicações wp_knowledge concretas com diretrizes editoriais para diferentes mesas (notícias, finanças, desporto). As regras estavam como payloads de JSON schema.
2. Distribuição REST API para ferramentas de IA: expusemos um endpoint REST seguro, para pipelines externos de geração de conteúdo irem buscar restrições de formatação localizadas de forma dinâmica:

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

3. Auditor em tempo real na barra lateral do Gutenberg: um componente React na barra lateral do editor subscrevia alterações do documento e destacava vocabulário ou frases que violavam as diretrizes ativas da mesa.
4. Controlos de qualidade programáticos via WP-CLI: um script cron com WP-CLI auditava artigos publicados contra as diretrizes e sinalizava exceções para revisão de editores seniores.

Nada disto exige um tipo de conteúdo no núcleo. Exige uma extensão sua, com permissões e uma superfície REST que possa versionar. Foi esse o resultado para o qual o veto apontou: prove adoção fora do núcleo primeiro.

#Opinião de especialistas e estratégia B2B: o papel do wp_knowledge na era AEO

Um tipo de conteúdo nativo wp_knowledge no núcleo teria sido um passo útil para a era da IA. Não está na 7.1. O veto deixou o trabalho no Gutenberg e na Automattic. À medida que o comportamento de pesquisa passa de ligações clássicas para motores de resposta (Perplexity, Claude, Gemini), a disciplina de SEO evolui para Answer Engine Optimisation (AEO).

Programadores e editores B2B já não podem escrever só para legibilidade humana ou indexadores básicos de palavras-chave. Têm de entregar payloads estruturados, verificáveis e legíveis por máquina, para os modelos de IA construírem respostas precisas.

#Porque o wp_knowledge conta para a visibilidade B2B:

1. Verificação E-E-A-T (sinais de confiança): os motores de resposta favorecem fontes transparentes e autoritativas. Guardar políticas editoriais, biografias de especialistas e fluxos de verificação em wp_knowledge permite aos bots de IA ligar estes ficheiros a autores ativos.
2. Integração de princípios Schema.org: pontos de dados de wp_knowledge podem ser mapeados automaticamente por ferramentas de SEO para campos Schema.org (como publishingPrinciples ou editorialGuidelines). Isso sinaliza um pipeline editorial controlado aos crawlers de IA.
3. Não conte com um ganho de Core Web Vitals pela descontinuação do bloco Clássico. Essa ocultação não saiu. Se quiser o TinyMCE fora do caminho do editor, isso continua a ser trabalho seu na extensão e no tema, não um almoço grátis da 7.1.

Se precisa de diretrizes estruturadas num sítio de cliente, registe o seu próprio tipo de conteúdo. Não espere que o núcleo inverta o veto.

#Lista de verificação depois do WordPress 7.1

1. Não converta em massa blocos Clássicos por causa desta versão. O inseridor continua a oferecê-los.
2. Audite o uso do Clássico só quando voltar a tocar nesse conteúdo, para conhecer a dívida.
3. Não procure wp_knowledge num sítio 7.1. Não está lá. Se precisa do armazenamento, lance uma extensão.
4. Teste o editor de artigos em iframe, que de facto saiu. Blocos próprios que assumem um document global vão partir. Veja a nota sobre o editor em iframe.
5. Mantenha as Guidelines no Gutenberg se já usa a experiência. Não prometa aos clientes um ecrã de definições no núcleo.

#Resumo

O WordPress 7.1 Mary Lou saiu sem wp_knowledge e sem Guidelines. A fusão foi vetada. O bloco Clássico continua no inseridor. O trabalho útil da 7.1 para agências está noutro sítio: estilos responsivos, media no cliente e o editor sempre em iframe. Se ainda quiser regras editoriais estruturadas para agentes, construa a extensão. Não a escreva num plano de atualização 7.1 como se o núcleo a tivesse aceite.