Cómo crear un plugin de WordPress paso a paso: guía de desarrollo profesional

Crear un plugin de WordPress es sencillo; crear uno que sea seguro, rápido y mantenible durante años no lo es tanto. Un plugin es, en esencia, una carpeta con código PHP que WordPress carga y que modifica el comportamiento del sitio mediante hooks. Esta guía recorre la estructura mínima y las decisiones que importan cuando el plugin va a funcionar en sitios reales.

Estructura mínima: la cabecera del plugin

Un plugin es una carpeta dentro de `wp-content/plugins` con un archivo PHP principal. Lo único imprescindible es el comentario de cabecera, con el que WordPress lo reconoce. Los campos admitidos están en la documentación oficial sobre los requisitos de la cabecera.

• Plugin Name: el único campo estrictamente obligatorio.
• Version, Requires at least, Requires PHP: evitan activar el plugin en entornos incompatibles.
• Text Domain y Domain Path: necesarios para la traducción de cadenas.
• License: recomendable y obligatoria para publicar en el directorio oficial.

Una buena práctica desde el inicio: bloquear el acceso directo al archivo con una comprobación de `ABSPATH` y usar un prefijo único (o espacios de nombres) en funciones, clases y opciones para no chocar con otros plugins.

Hooks: acciones y filtros

Todo el sistema de extensión de WordPress gira en torno a dos tipos de hooks. Las acciones (`add_action`) ejecutan código en un momento concreto, por ejemplo al iniciar WordPress o al guardar una entrada. Los filtros (`add_filter`) reciben un valor, lo modifican y lo devuelven, por ejemplo el contenido de una página o el título.

La regla práctica es no modificar nunca archivos del núcleo ni del tema, y enganchar el código al hook más específico posible. Registrar lógica en `init` para tipos de contenido, en `admin_menu` para pantallas de ajustes y en `rest_api_init` para endpoints evita cargar código donde no hace falta, algo que se nota en el rendimiento.

Ajustes, páginas de administración y API REST

La mayoría de plugins necesita guardar configuración. La vía recomendada es la Settings API, que registra opciones con funciones de saneamiento y gestiona los nonces del formulario. Para pantallas propias, se registra un menú con `add_menu_page` o `add_options_page` y se restringe por capacidad (`manage_options`, por ejemplo).

Cuando el plugin debe comunicarse con una aplicación externa o con su propio panel en JavaScript, la mejor opción es registrar rutas con `register_rest_route`, siempre con una `permission_callback` explícita. Dejarla sin definir o devolver `true` sin control de acceso es un error común que expone datos.

Seguridad: validar, sanear y escapar

La seguridad no es una fase final, es el criterio de cada línea que toca datos. La guía oficial de seguridad en plugins se resume en cuatro hábitos:

1. Comprobar capacidades: `current_user_can()` antes de cualquier acción privilegiada.
2. Verificar nonces: `wp_nonce_field` y `check_admin_referer` o `wp_verify_nonce` en formularios y peticiones AJAX, para frenar ataques CSRF.
3. Sanear la entrada: `sanitize_text_field`, `absint`, `esc_url_raw` y similares antes de guardar.
4. Escapar la salida: `esc_html`, `esc_attr`, `esc_url` y `wp_kses_post` en el momento de imprimir, no antes.

Para consultas a la base de datos con valores variables, `$wpdb->prepare()` es obligatorio. Concatenar variables en SQL es la forma más rápida de crear una inyección.

Rendimiento, internacionalización y compatibilidad

Un plugin que ralentiza el sitio se desinstala. Conviene cargar scripts y estilos solo en las pantallas donde se usan, evitar consultas en cada carga de página, guardar resultados costosos con la API de transients o con caché de objetos y no usar `autoload` en opciones grandes.

Si el plugin va a usarse fuera del propio país, hay que preparar la traducción desde el primer día: envolver las cadenas con `__()` y `_e()` usando el text domain declarado y cargar el archivo de traducción. Añadir esto al final cuesta mucho más que hacerlo al escribir cada cadena. Si el plugin también publica contenido en varios idiomas, conviene revisar cómo se comporta con AYM Multilingual y con cualquier plugin de traducción.

Finalmente, definir las versiones mínimas de PHP y WordPress, usar `register_activation_hook` y `register_uninstall_hook` para crear y limpiar datos, y probar con los constructores de páginas más comunes (Gutenberg, Elementor, Divi).

Pruebas, depuración y publicación

Antes de entregar o publicar el plugin, se activan `WP_DEBUG` y `WP_DEBUG_LOG` en un entorno local para detectar avisos, funciones obsoletas y errores silenciosos. Después se prueba con la versión mínima y la máxima de PHP y de WordPress declaradas en la cabecera, porque ahí aparecen la mayoría de incompatibilidades.

• Ejecutar PHPCS con los estándares de codificación de WordPress para revisar estilo, escapado y nonces de forma automática.
• Usar Query Monitor para detectar consultas lentas, hooks costosos y errores en cada pantalla.
• Escribir pruebas con PHPUnit para la lógica crítica y evitar regresiones al actualizar.
• Comprobar la activación, desactivación y desinstalación: el plugin no debe dejar tablas ni opciones huérfanas sin avisar.
• Si se declara compatibilidad con multisitio, probarla de verdad.

Para quien quiera distribuirlo, la documentación sobre publicación en el directorio oficial detalla los requisitos: licencia compatible con GPL, archivo `readme.txt` y revisión manual de seguridad antes de la aprobación. Aunque el plugin nunca llegue al directorio, seguir esas mismas reglas eleva la calidad del código y facilita el mantenimiento por parte de otros desarrolladores.

Cuándo conviene un plugin a medida y cuándo uno existente

Un plugin propio compensa cuando existe un flujo de trabajo específico, cuando varios plugins genéricos se solapan y ralentizan el sitio, o cuando hace falta un producto con licencia, actualizaciones y soporte. Si la necesidad ya está bien resuelta por un plugin mantenido y con buena reputación, reutilizarlo suele ser más barato y más seguro.

En AYM Flow el desarrollo de plugins WordPress cubre desde extensiones puntuales hasta productos completos, con revisión de seguridad y documentación. Quien piense en vender su plugin debe planificar también el cobro y la entrega de actualizaciones; el artículo sobre el sistema de licencias para plugins explica esa arquitectura. Y para plantear el alcance de un desarrollo concreto, el formulario de contacto es el punto de partida.

Compartir:XLinkedInWhatsApp