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 que é o tipo de conteúdo wp_knowledge no WordPress

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: o proprietário do sítio escreve as normas uma vez, na página Guidelines em Opções, e os novos redatores leem-nas num só sítio em vez de num PDF.
2. Para ferramentas de IA: qualquer ferramenta com as permissões certas pode ler estes registos através da REST API e alinhar o texto gerado com o estilo do sítio. A proposta não traz fornecedor de IA, modelo nem algoritmo de pesquisa próprios.

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.

#Em que difere o wp_knowledge das diretrizes tradicionais

Eis como muda o armazenamento das regras editoriais:

#O que a proposta de fusão definia para o wp_knowledge

A proposta de fusão descreve o Knowledge como «uma primitiva geral para guardar conhecimento do sítio, dirigido a autores e a agentes, como conteúdo normal do WordPress» (Greg Ziółkowski, tradução própria). Usa peças que o WordPress já tem: um tipo de conteúdo personalizado, uma taxonomia, funções e permissões, revisões e REST. O código experimental no Gutenberg corresponde à proposta:

• O tipo de conteúdo wp_knowledge é registado com public a false e sem ecrãs próprios no painel. Os registos nunca aparecem em consultas no front-end.
• A taxonomia wp_knowledge_type diz o que é um registo. O núcleo define três tipos: guideline (uma norma que é a fonte de verdade), memory (contexto duradouro que um utilizador guardou ou aprovou) e note (texto de trabalho privado). Um registo guardado sem tipo passa a note. As extensões acrescentam tipos com o filtro wp_knowledge_types.
• O ecrã Guidelines é construído a partir de âmbitos: Site, Copy, Images e Blocks. Cada âmbito é um registo guideline com um slug reservado, por exemplo guideline-copy, e as extensões podem registar mais.
• A REST fica em /wp/v2/knowledge, com um registo só de leitura em /wp/v2/knowledge/guideline-scopes. A leitura de coleções exige autenticação.
• Os registos novos são privados (private) por omissão. As revisões mantêm-se e o guardar automático está desligado, porque os registos não têm sessão de editor.

As permissões seguem o espaço de nomes *_knowledge_items. A política de acesso do PR 78296 do Gutenberg, tal como a proposta a apresenta:

O próprio ecrã Guidelines continua a exigir manage_options. Como nada no wp_knowledge é público, um crawler nunca o vê. Uma ligação publishingPrinciples no seu schema tem de apontar para uma página pública.

#Como as Guidelines passaram do Gutenberg 22.7 a uma fusão vetada

O nome e o armazenamento mudaram duas vezes antes do veto. As Guidelines chegaram como experiência no Gutenberg 22.7, descritas a 23 de março de 2026 por Aagam Shah. Ativava-se em Gutenberg, Experiências, e aparecia em Opções uma página Guidelines com secções Site, Copy, Images, Blocks e Additional, mais exportação para guidelines.json, importação e histórico de revisões. O armazenamento era um tipo de conteúdo chamado wp_content_guideline, com cada categoria em meta do artigo e REST em /wp/v2/content-guidelines. A publicação diz que as Guidelines «se concentram de propósito na recolha e na consulta» (Aagam Shah, tradução própria) e não aplicam regras nem geram conteúdo.

A 22 de junho, Greg Ziółkowski publicou a proposta de fusão para a 7.1, com o patch do núcleo no PR 12201 do wordpress-develop (ticket Trac 65476). O PR 79149 do Gutenberg, integrado a 29 de junho, mudou o nome do armazenamento para wp_knowledge. A 10 de julho, Anne McCarthy publicou a decisão nos comentários depois de uma revisão com Matt Mullenweg: o trabalho não avançaria na 7.1, e o núcleo não deve receber coisas «que não sejam já impulsionadas por adoção real com um crescimento impressionante de semana para semana (pense em dois dígitos)» (Anne McCarthy, tradução própria). A Beta 1 saiu a 15 de julho.

O que veio a seguir está no GitHub. Ziółkowski abriu o PR 949 do WordPress/ai a 18 de agosto para levar a experiência para a extensão de IA. Fechou-o sem integração a 1 de outubro, depois de os responsáveis dizerem que as experiências da extensão de IA devem assentar nas experiências do Gutenberg em vez de as duplicar. A 14 de outubro de 2026, o PR 12201 continua aberto e o wp-includes/post.php do ramo 7.1 não contém wp_knowledge. A funcionalidade só existe atrás da opção de experiência do Gutenberg.

#O WordPress 7.1 remove o bloco Clássico

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. Fonte: publicação de Marin Atanasov de 7 de julho.

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

#O que substitui a ocultação do bloco Clássico no núcleo do WordPress

A publicação de 7 de julho diz que a ocultação não aproximou o projeto de deixar de carregar o TinyMCE e fixa o princípio de que «o bloco Clássico deve tornar-se obsoleto por escolha, não à força» (Marin Atanasov, tradução própria). Também retirou o aviso de descontinuação ao nível do bloco, devolveu a ação «Converter para blocos» à barra de ferramentas e eliminou o filtro wp_classic_block_supports_inserter, que nunca saiu numa versão estável. A extensão Enable Classic Block vai ser fechada, por isso pode desativá-la.

A publicação enumera o trabalho que substitui a ocultação:

• perceber porque é que as pessoas ainda dependem do Clássico e fechar essas lacunas,
• tornar fiável o «Converter para blocos», que ainda tem falhas e incoerências,
• criar melhores ferramentas de conversão e migração, incluindo migração em massa,
• melhorar o registo dos recursos do TinyMCE e permitir desativá-los,
• dar às extensões uma forma de declarar uma dependência explícita do TinyMCE,
• explorar o carregamento do TinyMCE a pedido ou de forma assíncrona,
• deixar de carregar o TinyMCE no editor de blocos quando o bloco Clássico está desativado no gestor de blocos.

Pode confirmar o estado da 7.1 no código: o block.json do core/freeform no ramo 7.1 não tem a opção inserter: false. O último ponto da lista é trabalho futuro, por isso não conte que desativar o bloco Clássico no gestor de blocos retire o TinyMCE do editor da 7.1.

#Como adicionar dados do wp_knowledge ao schema JSON-LD

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

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

#Como a política editorial no Schema.org reforça o E-E-A-T

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. Como os registos propostos são privados, essa ligação tem de apontar para uma página pública que publique a mesma política. 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.

#Como validar artigos com as regras do wp_knowledge antes de publicar

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

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

#Como funcionam a validação de blocos e as depreciações no Gutenberg

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.

#Como construir uma extensão wp_knowledge para várias redações

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.

O prefixo importa. O manual de extensões sobre tipos de conteúdo personalizados diz: «Para garantir a compatibilidade futura, não use wp_ como identificador» (WordPress Plugin Handbook, tradução própria). A experiência do Gutenberg só regista o wp_knowledge se esse tipo de conteúdo ainda não existir. Uma extensão que ocupe o nome primeiro troca um armazenamento privado pelas definições que escolheu, incluindo public a true. Por isso o esboço abaixo usa wppoland_knowledge.

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

#O wp_knowledge ajuda no AEO de sítios B2B

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 como experiência no Gutenberg. À 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 as diretrizes estruturadas contam para a visibilidade B2B

1. Verificação E-E-A-T (sinais de confiança): os motores de resposta favorecem fontes transparentes e autoritativas. Políticas editoriais, biografias de especialistas e fluxos de verificação só ajudam quando estão em páginas públicas que os bots de IA conseguem ligar a autores ativos. Os registos no armazenamento wp_knowledge proposto são privados, por isso alimentariam as suas próprias ferramentas, não os crawlers.
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 (a propriedade publishingPrinciples). 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.

#O que fazer depois de atualizar para o WP 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.