---
title: "Cómo preparar tu plugin para el directorio de WordPress.org"
description: "https://wordpress.tv/2026/06/06/get-your-plugin-ready-for-submission-to-the-directory/ En la WordCamp Europe de Cracovia estuvimos de ponentes Fran Torres y yo. Justo después de comer, con el..."
url: https://davidperezgar.com/blog/charlas/como-preparar-tu-plugin-para-el-directorio-de-wordpress-org/
date: 2026-06-10
modified: 2026-06-10
author: "David Pérez"
image: https://davidperezgar.com/wp-content/uploads/wceu-talk-03-scaled.avif
categories: ["Charlas"]
type: post
lang: es
---

# Cómo preparar tu plugin para el directorio de WordPress.org

En la WordCamp Europe de Cracovia estuvimos de ponentes Fran Torres y yo. Justo después de comer, con el público luchando contra la siesta del mediodía, pero con ganas. La charla giraba en torno a algo que los dos vivimos cada semana: revisar plugins para el directorio de WordPress.org.

Somos miembros del Plugins Team, yo patrocinado por Hostinger y Fran por SiteGround, y lo que hacemos básicamente es revisar los plugins que llegan al directorio, detectar problemas, reportarlos al autor y acompañarle hasta que el plugin está listo para publicarse. Suena sencillo, pero el volumen es considerable: en una semana gestionamos unos 700 envíos nuevos, hacemos cerca de 2.000 revisiones y respondemos alrededor de 4.000 correos. Hace un año eran 200 envíos semanales. El salto tiene mucho que ver con la IA generando código y plugins a toda velocidad. De hecho, nosotros mismos ya usamos IA en parte del proceso de revisión.

La idea de la charla no era enseñar a hacer un plugin desde cero, sino mostrar qué es lo que falla más cuando un plugin llega al equipo, con ejemplos reales de código vulnerable encontrado en plugins con cientos de miles o millones de instalaciones activas.

**Lo que más vemos incumplido**

Lo primero es lo más básico: el código tiene que ser legible. El directorio es open source, con licencia GPL, y eso significa que el código tiene que poder leerse y modificarse. No permitimos código ofuscado ni encriptado. Los archivos minificados están bien, pero siempre tiene que venir acompañado del código fuente.

Otro punto que genera mucha confusión es la funcionalidad sin restricciones artificiales. El directorio de WordPress.org no es un marketplace. No se pueden meter paywalls internos ni limitaciones intencionales dentro del plugin, como limitar a cuatro el número de slides que puedes crear. Si quieres monetizar, el camino correcto es un add-on externo o un servicio de pago, no meter una restricción dentro del propio plugin. En el contributor day justo antes de la charla revisamos un plugin que necesitaba conectarse a un servidor externo para generar un número aleatorio. No, no es razonable.

Con el nombre también hay problemas frecuentes. Si usas el nombre de otra marca o proyecto de una forma que parezca una integración oficial, tienes que poder demostrarlo. Si no eres WooCommerce, tu plugin no puede llamarse algo que suene a que lo es. Y los nombres genéricos como «SEO» ya tienen más de 2.000 resultados en el directorio, así que lo único que consigues es que tu plugin sea imposible de encontrar. Un truco rápido antes de enviar: busca el nombre en Google junto a «WordPress» y mira qué aparece.

En cuanto a las llamadas externas, las librerías JS tienen que ir dentro del plugin, no cargarse desde CDNs externos. Hay razones de seguridad, rendimiento y disponibilidad geográfica para ello. El tracking y la telemetría tienen que estar desactivados por defecto y requerir opt-in explícito. Y cualquier servicio externo que uses tiene que estar documentado en el README: quién lo presta, qué datos se envían, y enlaces a términos de servicio y privacidad.

**Los security nightmares**

Esta fue la parte más técnica, y la que más atención generó. Mostramos código real de vulnerabilidades detectadas en plugins con entre 600.000 y 5 millones de instalaciones activas. La conclusión es que muchas veces el agujero de seguridad no es algo sofisticado. Es simplemente un input que va directo a la base de datos sin sanitizar.

La regla es clara: sanitizar en la entrada, escapar en la salida. Sin excepciones. No confiar en ninguna fuente, ni `$_POST`, ni `$_SERVER`, ni APIs externas, ni la propia base de datos. WordPress tiene funciones para todo: `sanitize_text_field()`, `sanitize_url()`, `esc_html()`, `esc_attr()`, `esc_url()`, `$wpdb->prepare()`… Mostramos un plugin con 5 millones de instalaciones donde la solución a una vulnerabilidad crítica era añadir una sola línea. Y un caso de SQL injection en un plugin con un millón de instalaciones activas, causado simplemente por no usar `$wpdb->prepare()`.

Con los endpoints vimos cosas todavía más llamativas. El permission callback tiene que estar siempre. Poner `return true` sin más ya nos indica que no se ha pensado en la seguridad. Mostramos un endpoint que devolvía el contenido de cualquier post sin verificar si el usuario tenía acceso, lo que incluía borradores, posts protegidos con contraseña y pedidos de WooCommerce. Mostramos un endpoint de pago donde el importe venía directamente de `$_POST['amount']` y el único control era que fuera mayor que cero, lo que permitía pagar prácticamente lo que quisieras. Y el caso más grave: un endpoint de confirmación de pago que leía el estado de la transacción desde el input del usuario, lo que permitía a cualquiera marcar cualquier pedido como pagado con una simple petición manipulada.

Para endpoints, la recomendación es REST API como primera opción, Admin Ajax con nonce y verificación de capacidades si es necesario, y alejarse de ficheros PHP standalone y de XML-RPC.

Sobre los nonces, que es algo que mucha gente no termina de entender bien: sirven para verificar el origen de una petición y evitar ataques CSRF. Mostramos un caso donde la diferencia entre usar `&&` y `||` en la verificación del nonce dejaba un endpoint de exportación de CSV completamente abierto sin autenticación. La diferencia visual era mínima, la consecuencia no. Las funciones son `wp_create_nonce()` y `wp_verify_nonce()`.

Y los prefijos, que también causan problemas graves. Todas las funciones, clases, variables globales, shortcodes, post types, endpoints Ajax y opciones en base de datos tienen que usar un prefijo único y distintivo. Sin prefijo, dos plugins que declaren la misma función provocan un fatal error, y si sobreescriben la misma opción en base de datos, puedes perder datos. Tenemos una lista de prefijos que vemos constantemente y que hay que evitar: `set`, `get`, `save`, `admin`, `ai`, `google`, `loop`, `ajax`, `elementor`, e incluso extensiones de imagen como `.jpg`.

**Herramientas que recomendamos**

Para revisar tu plugin antes de enviarlo, la primera opción es Plugin Check (PCP), el plugin oficial del equipo, disponible en WordPress.org. Detecta la mayoría de los checks automáticamente y exporta los resultados a Markdown, lo que lo hace muy fácil de usar con herramientas de IA. PHPCS con WPCS es otra opción sólida, integrable en el editor y en pipelines de CI/CD. Y si usas IA para desarrollar, puedes preguntarle directamente si el plugin es seguro usando el WordPress Coding Standards AI Skill.

**El proceso de revisión y los tiempos**

Cuando llega un plugin, enviamos un informe con todo lo que hay que corregir. El autor lo arregla y reenvía, y el ciclo se repite hasta que el plugin está listo. Actualmente el tiempo para la primera revisión está en torno a 5 días, aunque hace dos meses era de dos semanas y hace tres años llegaba a los tres meses. Las fluctuaciones dependen del número de voluntarios activos y del volumen de envíos. En total, si sigues bien las directrices, entre dos semanas y un mes es un tiempo razonable. Una vez aprobado, eres tú quien decide cuándo publicar.

Una cosa importante: no hagas ping al email del equipo preguntando por el estado de tu envío. Gestionamos 700 envíos semanales y hay una cola.

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-09-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-08-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-07-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-06-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-05-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-04-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-03-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-02-1-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-02-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*

!(https://davidperezgar.com/wp-content/uploads/wceu-talk-01-1082x721.avif)*WordCamp Europe 2026 – Talks Day 1 Afternoon
David Perez, Fran Torres: Get your plugin ready for submission to the directory*