pom_theme_configure_content_model: configurar contenido estructurado
Las filas nuevas requieren un repeater_identifier estable. Reutiliza ese identificador en la vista previa, la aprobación y la ejecución; las filas del modelo de contenido existentes pueden conservar sus identificadores guardados. Aplícalo mediante el flujo de trabajo de aprobación de escritura.
Crea tipos de contenido, taxonomías, campos personalizados y plantillas —y los conecta entre sí— en una sola llamada. La escritura individual más grande que expone POM AI.
Argumentos
| Argumento | Significado |
|---|---|
archive_templates |
Filas de plantillas de archivo |
single_templates |
Filas de plantillas individuales |
feed_templates |
Filas de plantillas de feed |
post_types |
Filas de tipos de contenido, con referencias de plantilla opcionales |
taxonomies |
Filas de taxonomías, con los tipos de contenido a los que se aplican |
custom_fields |
Filas de campos personalizados, con los tipos de contenido a los que se aplican |
metas |
Un alias de custom_fields |
dry_run |
Valida e informa del plan sin escribir |
Ninguno es obligatorio individualmente, pero al menos uno debe estar presente o la llamada devuelve pom_ai_mcp_empty_content_model_update.
Si se envían ambos custom_fields y metas, se usa custom_fields y metas se ignora.
Permisos
Permitir escrituras de POM Theme abierto, más manage_options.
Por qué existe
Construir un modelo de contenido por partes significa crear plantillas, luego un tipo de contenido, luego asignarle cada plantilla, luego taxonomías, luego campos: cinco o seis llamadas que deben secuenciarse correctamente, con un tipo de contenido a medio configurar visible en el administrador en el intervalo.
Esta herramienta lo hace en el orden correcto en una sola solicitud. Las plantillas se crean primero para que los tipos de contenido puedan hacerles referencia por clave, y las asignaciones se hacen a medida que se crean los tipos de contenido.
No es atómico
El modelo completo se valida antes de que comiencen las escrituras, incluidas las selecciones de recursos de plantilla y las claves de campos personalizados. Los fallos de validación detienen la escritura. Los fallos de almacenamiento o los cambios concurrentes durante la ejecución pueden dejar escritas las etapas anteriores: no hay transacción ni reversión automática.
Así que una llamada fallida no significa que no haya ocurrido nada. Lee cómo se ve realmente el sitio antes de reintentar:
La llamada falló. Enumera las plantillas y los tipos de contenido y dime qué ya existe.
Reintentar ingenuamente crea plantillas duplicadas.
Haz siempre una prueba en seco primero
La prueba en seco se propaga por cada etapa y devuelve el plan completo en changes, agrupado por lo que crearía: plantillas, tipos de contenido, asignaciones de archivo y feed, taxonomías, campos personalizados.
Dado el tamaño de esta escritura y su falta de reversión, la prueba en seco no es un lujo:
Haz una prueba en seco del modelo de contenido y muéstrame cada cambio que haría, agrupado por tipo.
Lee el plan completo. Un modelo de contenido es una decisión estructural sobre el sitio, y es mucho más barato corregir sobre el papel.
Las plantillas se validan con la misma rigurosidad que en cualquier otro sitio
Las filas de plantillas pasan por la misma validación que pom_theme_upsert_html_template: etiquetas PHP rechazadas, etiquetas de combinación desconocidas rechazadas, bloques {{if}} desequilibrados rechazados, marcado vacío rechazado.
El HTML se filtra con las reglas KSES de la instalación incluso para administradores. La plantilla js_scripts acepta solo identificadores existentes de pom_theme_get_script_catalog con target: template; css_stylesheets acepta identificadores de hojas de estilo existentes y tokens nativos. Omitir cualquiera de los dos campos conserva su selección actual, mientras que un array vacío la borra. Los agentes no pueden crear fuentes de script ni alterar las reglas de permisos del modelo de contenido. Los campos personalizados no pueden usar claves internas protegidas, de credenciales o de metadatos de script.
Las reglas de reescritura se vacían por ti
Cuando cambian los tipos de contenido, las taxonomías o las asignaciones de archivo de CPT, las reglas de enlaces permanentes se reconstruyen automáticamente en la siguiente solicitud de WordPress, después de que las nuevas definiciones se hayan registrado. La respuesta de escritura informa de rewrite_rules_pending: true y rewrite_rules_flushed: false. Haz otra solicitud antes de comprobar las nuevas URL.
Eso importa porque un tipo de contenido nuevo sin reglas vaciadas produce errores 404 en su archivo. Hacerlo automáticamente elimina el fallo clásico, pero también significa que la llamada es más pesada de lo que sugiere su tamaño, y no hace nada en un sitio con los enlaces permanentes desactivados.
Los tipos de contenido son permanentes en la práctica
No hay ninguna herramienta MCP que elimine un tipo de contenido o una taxonomía. Lo que esto crea, no puede eliminarlo.
Más importante aún, el contenido creado bajo un tipo de contenido se vuelve inaccesible si el tipo de contenido se elimina después a mano. Los slugs son especialmente difíciles de cambiar después: aparecen en las URL y en las asignaciones almacenadas.
Decide los slugs deliberadamente, y prefiere crear un tipo de contenido y revisarlo a crear cinco en lote.
Los campos personalizados son definiciones, no valores
Declarar un campo personalizado lo pone a disposición en los tipos de contenido que nombres. No rellena nada.
Las plantillas hacen referencia a esos campos mediante etiquetas de combinación y condicionales {{if meta="…"}} —así que el nombre del campo en la definición y el nombre en la plantilla deben coincidir exactamente, y esta herramienta no comprueba que lo hagan.
Después de ejecutarlo
- Lee la respuesta y da cuenta de cada cambio.
- Comprueba que el tipo de contenido aparece en el administrador de WordPress.
- Crea una publicación de prueba, publícala y carga tanto su página individual como el archivo.
- Confirma que el archivo no es un 404 —esas son las reglas de reescritura.
- Lee las asignaciones y confirma que las plantillas están adjuntas.
- Purga la caché.
El paso 3 es la prueba real. Un modelo de contenido que valida puede no renderizar nada útil.
Problemas comunes
| Síntoma | Causa |
|---|---|
| La escritura se rechaza | Puerta de escritura de POM Theme cerrada |
pom_ai_mcp_forbidden |
Falta manage_options |
pom_ai_mcp_empty_content_model_update |
No se proporcionó ninguna sección |
pom_ai_mcp_template_validation_failed |
Marcado incorrecto en una fila de plantilla |
| Las plantillas existen pero nada más | Una etapa posterior falló; no hay reversión |
| Plantillas duplicadas tras un reintento | El primer intento ya las había escrito |
| El archivo es un 404 | Reglas de reescritura; vuelve a ejecutar o guarda de nuevo los enlaces permanentes |
El {{if meta}} de una plantilla nunca coincide |
El nombre del campo no coincide con la definición |
| El tipo de contenido no se puede eliminar | Correcto; ninguna herramienta MCP elimina uno |
Relacionado
- Crear un modelo de contenido de POM
- Configurar el modelo de contenido
- Guía del modelo de contenido
pom_theme_assign_template— la alternativa de uno en uno