Preparación para wordpress.org¶

21/10/2026 · Nada se ha publicado. Este documento responde a una pregunta concreta: ¿se puede publicar esto en el directorio de WordPress? La respuesta, medida: sí, los ocho plugins y el tema pasan las comprobaciones automáticas y el checklist; lo que queda son decisiones de producto (ver el final), no defectos.

Cómo se ha medido¶

Tres capas, y ninguna se fía de la memoria:

1. Plugin Check (PCP) en el CI de cada repo, sobre el paquete limpio —nunca sobre el árbol de desarrollo, que produce errores fantasma—. Versión fijada y cacheada. El tema usa Theme Check.
2. Auditor propio: convoca-health-check/scripts/check-wporg-requisitos.py, que mide lo que PCP no mira (coherencia del readme, Tested up to contra la última de WordPress, Requires Plugins, dominio de texto, licencia, código ofuscado, recursos de fuera, servicios externos, .distignore).
3. Checklist a mano, con la respuesta escrita por plugin.

Resultado por plugin¶

Lo que estaba mal y se ha corregido¶

La primera pasada real del auditor dio 17 puntos en 8 plugins. Ninguno se arregló «a ojo»:

• Tested up to: 7.1 cuando WordPress va por 7.1.3 (en los ocho y en el tema). El directorio exige la última versión. Se declara 7.1.3 porque es la que corren demo y Lugg —comprobado con wp core version—, no por rellenar el campo.
• .distignore sin .htaccess en los ocho. El empaquetador ya los quitaba, pero la exclusión ahora está declarada: una línea por repo, y el paquete no puede llevárselos ni por descuido.
• FullCalendar se cargaba desde cdn.jsdelivr.net (shifts). Este era el único bloqueante de código: wordpress.org no admite recursos de terceros (EnqueuedResourceOffloading). La librería viaja ahora en assets/vendor/fullcalendar/ (v6.1.15, con su banner de licencia) y se sirve desde el propio plugin. De paso, el calendario deja de depender de un CDN externo.
• Tres falsos positivos del auditor, corregidos en el auditor: base64_decode() en la firma de Redsys, en los tokens de OAuth y en el cifrado del publisher no es código ofuscado —es descifrar datos—. El patrón ahora busca ejecución dinámica (eval, assert, create_function, gzinflate), no decodificación.

Comprobaciones que importan y no son de estilo¶

• El paquete es el que se audita. pack-plugin.py genera vendor/ de producción (composer install --no-dev): wordpress.org no ejecuta composer, y un paquete sin vendor/ es un plugin que no carga. Verificado en el paquete de shifts: 50 ficheros, con FullCalendar dentro y el mismo md5 que en el repo.
• assets/vendor/ sí viaja: el patrón vendor/ del .distignore compara por raíz (rel.startswith("vendor/")), así que no alcanza a assets/vendor/. Comprobado empaquetando, no leyendo el patrón.
• Nada de datos de clientes en código, textos, fixtures ni .pot: lo vigila el guardián de higiene en el CI de los diez repos, con la lista fuera de los repos (secret).
• Un plugin no provee la funcionalidad de otro: lo vigila el guardián de acoplamiento, estrenado esta semana tras limpiar el mismo defecto en cuatro plugins.

Lo que queda, y no es código¶

1. Requires Plugins: convoca-core apunta a un plugin que aún no está en el directorio. La instalación desde wordpress.org no resolverá esa dependencia hasta que core esté publicado. Decisión de producto: publicar core primero (y esperar a que la acción oficial lo vea) o dejar el ecosistema como está hasta tener los siete listos a la vez.
2. Capturas del panel. Los readme tienen la sección, pero las imágenes de la ficha del directorio se suben aparte y conviene que no muestren datos de ningún cliente.
3. Servicios externos: los plugins que llaman a Redsys/Stripe lo declaran. Si se añade otro, su sección en el readme es obligatoria.

Conclusión¶

Los ocho plugins y el tema pasan el corte automático y el checklist está contestado por escrito. El único defecto de código que quedaba (el CDN del calendario) está corregido y verificado en el paquete.

Publicar es una decisión de Jose Carlos, no un paso de este trabajo: no se ha enviado nada a wordpress.org —ni zip, ni SVN, ni solicitud de revisión—.