Crear un plugin de WordPress con ayuda de la IA: instrucciones, revisión y pruebas

Con un asistente de programación (los hay integrados en editores como VS Code o en la terminal), describir un plugin y tenerlo funcionando toma minutos. El problema es que funcionar no es lo mismo que estar bien hecho: la IA puede usar funciones que no existen, olvidar comprobar permisos, no escapar lo que imprime o resolver en 300 líneas lo que WordPress ya hace con una función.

La buena noticia es que se puede trabajar con método. Esta guía es el flujo que recomendamos.

Paso 1: un archivo de instrucciones permanentes

Los asistentes de programación leen un archivo de instrucciones en la raíz del proyecto antes de empezar. El nombre más extendido es AGENTS.md; algunas herramientas usan su propio nombre (como CLAUDE.md) o permiten importar el otro. Ahí pones las reglas que la IA debe seguir siempre, para no repetirlas en cada conversación.

Un punto de partida para plugins de WordPress:

# Instrucciones para este plugin

## Contexto
- Plugin de WordPress. Requiere WordPress 6.6+ y PHP 8.1+.
- Prefijo de funciones, clases, opciones y hooks: `cwp_` (clases: `CWP_`).
- Text domain: `cwp-mi-plugin`. Todas las cadenas visibles, traducibles.

## Reglas de seguridad (obligatorias)
- Todo archivo PHP empieza con `defined( 'ABSPATH' ) || exit;`.
- Sanitiza toda entrada (`sanitize_text_field`, `absint`, `sanitize_email`...).
- Escapa toda salida (`esc_html`, `esc_attr`, `esc_url`, `wp_kses_post`).
- Formularios y acciones: nonce (`wp_nonce_field` / `check_admin_referer`)
  y permisos (`current_user_can`).
- Endpoints REST: siempre `permission_callback` real, nunca `__return_true`
  para acciones que modifican datos.
- Consultas a la base de datos: siempre `$wpdb->prepare()`.

## Estilo
- WordPress Coding Standards (tabs, espacios dentro de paréntesis, Yoda).
- Usa las API de WordPress antes que código propio.
- No agregues dependencias externas sin preguntar.

## Forma de trabajar
- Antes de escribir código, propón un plan y espera aprobación.
- Si tienes dudas de que una función o hook exista, dilo.
- Después de cada cambio, ejecuta `vendor/bin/phpcs` y corrige los errores.

Mantén el archivo corto y concreto. Una lista de 20 reglas claras funciona mejor que un documento de 10 páginas, y lo puedes ir ampliando cada vez que la IA cometa el mismo error dos veces.

Paso 2: pedir por pasos

El error más común es pedir todo de una vez: «hazme un plugin de reservas con calendario, pagos y correos». Sale un archivo enorme imposible de revisar.

Mejor así:

1. Describe el objetivo y pide un plan: qué archivos, qué hooks, qué datos se guardan y dónde. Corrige el plan antes de que escriba código.
2. Pide la estructura mínima: el archivo principal con su cabecera, la activación y una pantalla vacía.
3. Agrega una funcionalidad por vez, y pruébala antes de pasar a la siguiente.
4. Pide explicaciones de lo que no entiendas: «¿por qué usaste este hook y no otro?». Si no puedes explicar el código, no lo instales en un sitio real.

Paso 3: revisar con herramientas

Plugin Check

Es el plugin oficial que usa el equipo de WordPress.org para revisar los plugins que se publican en el directorio. Instálalo en tu sitio de pruebas (Plugins → Añadir nuevo, busca «Plugin Check»), ve a Herramientas → Plugin Check, elige tu plugin y ejecuta la revisión. Te marca problemas de seguridad, de cabeceras, de internacionalización y de buenas prácticas.

También se puede usar desde WP-CLI:

wp plugin check cwp-mi-plugin

PHP_CodeSniffer con los estándares de WordPress

Revisa el estilo y detecta muchos problemas de seguridad (salida sin escapar, entradas sin sanitizar, consultas sin prepare). En la carpeta del plugin, con Composer instalado:

composer require --dev wp-coding-standards/wpcs dealerdirect/phpcodesniffer-composer-installer
vendor/bin/phpcs --standard=WordPress --extensions=php --ignore=vendor .

Muchos errores de estilo se corrigen solos con:

vendor/bin/phpcbf --standard=WordPress --extensions=php --ignore=vendor .

Que las herramientas no marquen errores no garantiza que el plugin sea seguro. Revisa tú, o pídele a la IA en una conversación nueva, sin el contexto anterior, que audite el código buscando específicamente: entradas sin sanitizar, salidas sin escapar, acciones sin nonce ni permisos y consultas sin prepare.

Paso 4: probar en un entorno aislado

Nunca pruebes un plugin recién generado en el sitio real.

• WordPress Playground (playground.wordpress.net): un WordPress completo que corre en el navegador, sin instalar nada. Subes el zip del plugin y lo pruebas en segundos.
• Un entorno local (como wp-env, que usa Docker, o las aplicaciones de WordPress local) para pruebas más largas.
• Una copia de pruebas de tu sitio, si el plugin depende de tus datos reales.

Activa WP_DEBUG durante las pruebas y revisa el debug.log: los avisos de PHP son pistas de errores que la IA no vio.

Lo que la IA hace bien y lo que no

Bien: estructura inicial, código repetitivo (registrar tipos de contenido, pantallas de ajustes), explicar código ajeno, escribir pruebas, traducir mensajes de error.

Hay que vigilar: funciones o hooks inventados, seguridad incompleta, soluciones complicadas para problemas que WordPress ya resuelve y código copiado de versiones antiguas de WordPress.

¿Creaste un plugin con IA y quieres una segunda opinión? Compártelo en el foro (sin claves ni datos privados) y lo revisamos en comunidad.