wordpress-plugins

Publicación y Mantenimiento

Lleva tu desarrollo al repositorio oficial. Aprende los requisitos de aprobación, el uso de SVN, la gestión de versiones y las mejores prácticas para mantenerte actualizado.

Desarrollar un plugin robusto es solo la mitad del desafío; la verdadera prueba de fuego es compartirlo y mantenerlo vivo en el ecosistema global. En este capítulo final, dejaremos el entorno local para adentrarnos en el proceso de publicación oficial en el repositorio de WordPress.org.

Aprenderás a sortear las estrictas directrices de revisión del equipo oficial, a estructurar un archivo readme.txt que posicione correctamente tu proyecto, y a dominar Subversion (SVN) como herramienta de despliegue. Finalmente, abordaremos el ciclo de vida post-lanzamiento: versionado semántico, redacción de changelogs y rutinas de actualización de datos.

16.1 Directrices del repositorio

Publicar un plugin en el repositorio oficial de WordPress.org no es un derecho automático; es un privilegio sujeto a un conjunto estricto de reglas mantenidas por el Equipo de Revisión de Plugins (Plugin Review Team). Estas directrices están diseñadas para garantizar la seguridad, la privacidad y la libertad de los millones de usuarios que confían en el ecosistema de WordPress.

Antes de empaquetar tu código o preparar tu infraestructura de control de versiones, es imperativo auditar tu desarrollo contra estas políticas. Un incumplimiento resultará en el rechazo inmediato durante el proceso de revisión inicial o en la expulsión del repositorio si la infracción se detecta a posteriori.

1. Licenciamiento y la regla del GPL

El pilar fundamental del repositorio de WordPress es la licencia de software libre. Todo el código alojado en WordPress.org debe cumplir con esta premisa sin excepciones.

Compatibilidad estricta con GPL: Tu plugin debe estar licenciado bajo la GNU General Public License v2 (o posterior), o una licencia compatible con ella.
Alcance a terceros: Esta regla no aplica solo a tu código PHP. Cualquier biblioteca, script de terceros, framework de CSS o incluso recursos multimedia (imágenes, fuentes) incluidos en el directorio del plugin deben tener una licencia compatible con GPL. No puedes incluir dependencias propietarias o con derechos de autor restrictivos.

2. Nomenclatura y Marcas Registradas

El nombre de tu plugin es su carta de presentación, pero el equipo de revisión es sumamente estricto respecto a cómo puedes nombrarlo para evitar confusiones legales y engaños al usuario.

Restricción de la palabra "WordPress": No puedes usar "WordPress" en el nombre de tu plugin. Si necesitas hacer referencia al CMS, debes usar "WP" o formulaciones como "Mi Plugin para WordPress". (Ejemplo incorrecto: WordPress SEO Backup; Ejemplo correcto: SEO Backup for WordPress o WP SEO Backup).
Marcas de terceros: No puedes utilizar nombres de marcas registradas (como Google, Twitter, WooCommerce) a menos que poseas los derechos o utilices una nomenclatura de compatibilidad legítima (ej. Addon for WooCommerce, no WooCommerce Addon).
Prohibición de secuestro de nombres (Squatting): No puedes reservar nombres de plugins vacíos para usarlos en el futuro. Si el plugin es aprobado, debe tener código funcional.

3. Privacidad y Comunicación Externa (Phoning Home)

El repositorio protege celosamente la privacidad del usuario. Las comunicaciones no solicitadas hacia servidores externos son una de las principales causas de rechazo y expulsión.

Rastreo por defecto prohibido: Tu plugin no puede recolectar datos de uso del usuario (telemetría), información del servidor o listas de plugins activos sin el consentimiento explícito, informado y proactivo (Opt-In) del administrador. El Opt-Out (rastreo activado por defecto con opción a desactivarlo) está terminantemente prohibido.
Dependencias de servicios externos (SaaS): Si tu plugin actúa como un puente hacia un servicio externo (por ejemplo, una API de traducción o un CRM), debe indicarse claramente en la descripción. Además, cualquier transmisión de datos de usuarios hacia dicha API debe realizarse bajo el consentimiento del usuario y respetando normativas como el GDPR.
Descarga de código remoto: Está estrictamente prohibido ejecutar código o descargar ejecutables desde servidores de terceros después de la activación. Todo el código ejecutable PHP/JS debe estar contenido dentro del propio paquete del plugin en los servidores de WordPress.org.

4. Prácticas de Código y Experiencia de Usuario

Aunque la revisión manual evalúa estándares de seguridad (como los vistos en el Capítulo 10), hay directrices operativas específicas para el repositorio:

Prohibición de ofuscación: Todo el código debe ser legible por humanos. Herramientas de ofuscación como eval(), base64_decode() aplicadas a lógicas complejas, o compresores que impidan la auditoría del código, causarán el rechazo automático. La minificación de archivos CSS y JS está permitida, pero se recomienda (y a veces se exige) proporcionar los archivos originales no minificados.
Secuestro de la interfaz (Hijacking): Tu plugin no debe alterar drásticamente la interfaz de usuario de WordPress. Esto incluye insertar anuncios invasivos en paneles de otros plugins, modificar menús del núcleo para forzar tu visibilidad, o impedir que el usuario descarte avisos (notices) de administración.
Limitaciones de versiones "Pro": El repositorio de WordPress.org es para software gratuito. Si tu plugin utiliza un modelo Freemium (ofreciendo una versión gratuita y vendiendo una versión premium externa), la versión gratuita alojada en el repositorio debe ser funcional por sí misma. No puede ser simplemente un "anuncio" que requiera un pago para realizar su función principal prometida.

Flujo de Auditoría de Directrices

A continuación, se ilustra el árbol de decisiones básico que aplica el equipo de revisión automatizado y manual (Plugin Check) antes de aprobar un desarrollo:

TEXT
+-------------------------------------------------------------------+
|               AUDITORÍA DE DIRECTRICES (PRE-SVN)                  |
+-------------------------------------------------------------------+
                               |
                               v
               [ ¿Cumple el código con GPLv2+? ]
               / (Sí)                    (No) \
              v                                v
[ ¿Dependencias también GPL? ]          ( RECHAZO: Licencia inválida )
        / (Sí)       (No) \
       v                   v
       |           ( RECHAZO: Conflicto de bibliotecas )
       v
[ ¿El nombre viola marcas registradas o usa "WordPress"? ]
        \ (No)       (Sí) /
         v               v
         |         ( RECHAZO: Infracción de Trademark )
         v
[ ¿Realiza llamadas salientes (telemetría) sin Opt-In? ]
        \ (No)       (Sí) /
         v               v
         |         ( RECHAZO: Violación de privacidad )
         v
[ ¿Contiene código ofuscado o descarga scripts remotos? ]
        \ (No)       (Sí) /
         v               v
         |         ( BLOQUEO: Riesgo de seguridad crítico )
         v
[ APROBACIÓN: Pase a revisión de seguridad manual y creación de SVN ]

5. Documentación y Honestidad

El repositorio exige honestidad en el marketing interno. Las prácticas de "Spam de SEO" (como repetir excesivamente palabras clave en la descripción) o la asignación de etiquetas irrelevantes para ganar visibilidad están penalizadas. El equipo de revisión puede modificar tu archivo readme, eliminar etiquetas de búsqueda abusivas o, en casos extremos, suspender temporalmente el plugin hasta que corrijas las tácticas promocionales engañosas.

16.2 Preparación del archivo readme

El archivo readme.txt es mucho más que un simple documento de texto para los desarrolladores; es el motor que genera la página de presentación de tu desarrollo en el directorio oficial de WordPress.org y la información que se muestra en el panel de administración de los usuarios.

WordPress utiliza un analizador estricto (parser) para procesar este archivo. Si la sintaxis es incorrecta o faltan campos obligatorios, la página de tu plugin mostrará información errónea, advertencias de incompatibilidad o directamente no se actualizará, afectando drásticamente su adopción.

Estructura y Sintaxis Básica

El archivo utiliza una variante específica de Markdown estructurada mediante niveles de encabezados (===, ==, =). Todo plugin profesional debe incluir una plantilla base que cubra los metadatos esenciales, las dependencias y las pestañas de navegación del repositorio.

A continuación, se muestra la anatomía estándar requerida para el archivo readme.txt:

TEXT
=== Nombre Exacto de tu Plugin ===
Contributors: tu_usuario_wp, otro_colaborador
Tags: seguridad, firewall, login
Requires at least: 5.8
Tested up to: 6.4
Stable tag: 1.0.0
Requires PHP: 7.4
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Esta es la descripción corta. Debe tener un máximo de 150 caracteres y es lo que los usuarios leerán en los resultados de búsqueda dentro de su panel de WordPress.

== Description ==

Esta es la descripción detallada. Aquí explicas qué hace tu plugin, por qué es útil y cualquier característica destacada. Puedes usar Markdown para estructurar este contenido con listas, negritas y enlaces.

* Característica 1
* Característica 2

== Installation ==

1. Sube la carpeta `mi-plugin` al directorio `/wp-content/plugins/`.
2. Activa el plugin a través del menú 'Plugins' en WordPress.
3. Ve a 'Ajustes > Mi Plugin' para configurarlo.

== Frequently Asked Questions ==

= ¿Es compatible con multisitio? =
Sí, el plugin ha sido probado en entornos multisitio.

== Screenshots ==

1. Panel principal de configuración.
2. Vista del widget en el frontend.

== Changelog ==

= 1.0.0 =
* Lanzamiento inicial.

Análisis de los Metadatos Críticos

La sección superior del archivo (la cabecera) controla la lógica de distribución y la seguridad visual de tu plugin en el ecosistema. Errores aquí pueden provocar que WordPress marque tu plugin como "incompatible" con versiones recientes.

Contributors: Son los nombres de usuario (ID de WordPress.org) de los desarrolladores. Estas personas tendrán acceso de escritura en el repositorio SVN (si el propietario principal se los otorga) y aparecerán públicamente en la página del plugin.
Tags: Las palabras clave (separadas por comas) por las que los usuarios te encontrarán. El límite estricto es de 5 etiquetas. Si añades más, el repositorio las ignorará.
Requires at least / Requires PHP: Establecen los requisitos mínimos del sistema. Si un usuario intenta instalar tu plugin con una versión inferior a las declaradas aquí, WordPress bloqueará la instalación para prevenir errores fatales (Fatal Errors).
Tested up to: Este es el campo que debes actualizar religiosamente con cada nueva versión mayor de WordPress. Si no coincide con la versión actual del núcleo, aparecerá un temido aviso amarillo indicando: "Este plugin no ha sido probado con tu versión actual de WordPress".
Stable tag: Indica qué versión del código debe descargar el usuario. Si usas la etiqueta trunk, los usuarios descargarán siempre el último código subido (no recomendado para producción). Lo ideal es apuntar a un número de versión específico (ej. 1.0.0) que corresponda a una carpeta de etiqueta en tu repositorio SVN.

Mapeo de la Interfaz del Repositorio

Para comprender cómo el parser de WordPress.org transforma tu texto en una página web interactiva, observa el siguiente esquema de renderizado:

TEXT
+------------------------------------+       +---------------------------------------------+
| Secciones en readme.txt            |       | Interfaz de Usuario en WordPress.org        |
+------------------------------------+       +---------------------------------------------+
| === Mi Plugin ===                  | --->  | Título principal de la página (H1).         |
| Descripción corta (150 chars).     | --->  | Subtítulo bajo el H1 / Snippet de búsqueda. |
| Metadatos (Requires, Tested...).   | --->  | Barra lateral derecha (Información meta).   |
| == Description ==                  | --->  | Pestaña "Detalles" (La vista por defecto).  |
| == Installation ==                 | --->  | Pestaña "Instalación".                      |
| == FAQ ==                          | --->  | Pestaña "Soporte" o sección de FAQ.         |
| == Screenshots ==                  | --->  | Pestaña "Capturas de pantalla" (*).         |
| == Changelog ==                    | --->  | Pestaña "Desarrollo" (Registro de cambios). |
+------------------------------------+       +---------------------------------------------+

(Nota sobre Screenshots: El texto introducido en esta sección del readme sirve como pie de foto para las imágenes físicas que subirás posteriormente a la carpeta /assets/ de tu repositorio SVN, nombradas como screenshot-1.png, screenshot-2.png, etc.)

Validación Previa

Antes de enviar tu código para la revisión oficial, es una práctica estándar pasar tu archivo por el validador oficial (wordpress.org/plugins/developers/readme-validator/). Esta herramienta procesará el archivo tal cual lo haría el repositorio real, permitiéndote detectar errores de formato en Markdown, etiquetas estables mal referenciadas o información de licencias incompleta antes de impactar en la página pública.

16.3 Gestión de versiones con SVN

Aunque Git se ha consolidado como el estándar de la industria para el control de versiones, la infraestructura del repositorio de WordPress.org sigue operando sobre Subversion (SVN). Este suele ser el mayor punto de fricción para los desarrolladores modernos.

Sin embargo, es fundamental entender un paradigma clave: no estás obligado a desarrollar usando SVN. La práctica recomendada es utilizar Git y GitHub/GitLab para tu flujo de trabajo diario y tratar a SVN estrictamente como el mecanismo de despliegue final.

La Estructura de Directorios SVN

Cuando tu plugin es aprobado, WordPress.org genera un repositorio SVN vacío. Al clonarlo (hacer checkout), te encontrarás con una estructura de carpetas predefinida e inmutable que debes respetar escrupulosamente.

TEXT
mi-plugin-repositorio/
├── assets/       # Banners, iconos de la cabecera y capturas de pantalla.
├── branches/     # Ramas de desarrollo alternativas (Rara vez utilizado en WP).
├── tags/         # Versiones publicadas e inmutables (ej. 1.0.0, 1.1.0).
│   ├── 1.0.0/    # Copia exacta del código de la versión 1.0.0.
│   └── 1.0.1/    # Copia exacta del código de la versión 1.0.1.
└── trunk/        # El código base activo. Equivalente a 'main' o 'master' en Git.

trunk/: Aquí reside el código en desarrollo. Si en tu readme.txt configuraste Stable tag: trunk, los usuarios descargarán lo que haya en esta carpeta. No se recomienda; trunk debe ser un área de pruebas para la próxima versión.
tags/: Este directorio es sagrado. Cada subcarpeta aquí representa una versión oficial (relase). Cuando configuras Stable tag: 1.0.0 en el readme, WordPress busca la carpeta /tags/1.0.0/ y empaqueta su contenido como el archivo ZIP que descargarán los usuarios. Nunca modifiques el código dentro de un tag existente; si hay un error, debes lanzar una nueva versión (ej. 1.0.1).
assets/: Aloja los elementos visuales de la página del repositorio, ajenos al código del plugin. Aquí van archivos con nomenclaturas estrictas como icon-256x256.png o banner-772x250.png. No se incluyen en el ZIP que descarga el usuario, ahorrando peso.

Flujo de Trabajo Manual: De Git a SVN

Si no utilizas automatizaciones, el proceso de publicar una nueva versión implica sincronizar tu código local con el repositorio SVN mediante la línea de comandos.

A continuación, se ilustra el ciclo de vida completo de un lanzamiento inicial (versión 1.0.0):

Bash
# 1. Hacer checkout (clonar) tu nuevo repositorio SVN localmente
svn co https://plugins.svn.wordpress.org/tu-plugin-slug mi-plugin-svn
cd mi-plugin-svn

# 2. Copiar tu código finalizado (desde tu repo Git) a la carpeta trunk
# (Asegúrate de NO copiar la carpeta oculta .git ni archivos de desarrollo)
cp -r /ruta/a/tu/git/* trunk/

# 3. Informar a SVN de los nuevos archivos
svn add trunk/*

# 4. Enviar (commit) los cambios al servidor en trunk
svn ci -m "Lanzamiento inicial en trunk" --username tu_usuario_wp

# 5. Crear la versión estable etiquetándola (Copiando trunk a tags)
svn cp https://plugins.svn.wordpress.org/tu-plugin-slug/trunk \
       https://plugins.svn.wordpress.org/tu-plugin-slug/tags/1.0.0 \
       -m "Etiquetando versión 1.0.0" --username tu_usuario_wp

Nota sobre svn cp: Al ejecutar la copia directamente sobre las URLs remotas (como en el paso 5), la operación se realiza directamente en el servidor de WordPress, lo cual es instantáneo y evita tener que descargar y volver a subir todo el código.

Mapeo de Versiones y Sincronización

El ecosistema de WordPress cruza la información de varios archivos para determinar si una actualización debe ser notificada a los usuarios. Para que una nueva versión sea detectada e instalada correctamente, debes asegurar que tres elementos coincidan perfectamente:

TEXT
+-----------------------+     +-----------------------+     +-----------------------+
|  Archivo principal    |     |  Archivo readme.txt   |     |  Estructura SVN       |
|  del plugin (.php)    |     |  en trunk/            |     |                       |
+-----------------------+     +-----------------------+     +-----------------------+
|                       |     |                       |     |                       |
| Plugin Name: Mi Plug  |     | === Mi Plug ===       |     | /trunk/               |
| Version: 1.1.0  <----(A)--->| Stable tag: 1.1.0 <--(B)--->| /tags/1.1.0/          |
|                       |     |                       |     |                       |
+-----------------------+     +-----------------------+     +-----------------------+

(A) Consistencia de Versión: La constante Version en la cabecera de tu archivo PHP principal debe coincidir con el registro en tu readme.txt.
(B) Resolución del Directorio: El Stable tag indicado en tu readme.txt (ubicado dentro de /trunk) debe tener una carpeta equivalente con el mismo nombre exacto dentro del directorio /tags/ de tu SVN.

Automatización: Despliegue Continuo (CI/CD)

El manejo manual de SVN es propenso a errores humanos (olvidar actualizar la versión en un archivo o copiar archivos de desarrollo indeseados). En el desarrollo profesional moderno, se delega este proceso a canalizaciones de integración continua.

Si utilizas GitHub, la herramienta más adoptada por la comunidad es la acción 10up/action-wordpress-plugin-deploy. Al configurar este flujo de trabajo (Workflow), tu proceso se reduce a crear un "Release" en GitHub. La acción se encarga automáticamente de compilar los assets, ignorar archivos de desarrollo (como node_modules o tests/), hacer el checkout del SVN de WordPress.org, mover los archivos al trunk, crear el tag y hacer el commit, ocultando por completo la complejidad de Subversion.

16.4 Actualizaciones y changelogs

Publicar la versión 1.0.0 de tu plugin es solo el comienzo del ciclo de vida del software. Mantener el plugin actualizado, comunicar los cambios de forma efectiva a los usuarios y gestionar las migraciones de datos internas son responsabilidades críticas para asegurar la longevidad de tu desarrollo en el ecosistema.

El Mecanismo de Actualización del Núcleo

Para gestionar el ciclo de actualizaciones correctamente, es vital comprender cómo WordPress descubre que existe una nueva versión de tu plugin. Este proceso no es en tiempo real, sino que está gestionado por el sistema de tareas programadas (WP-Cron) interactuando con la API del repositorio oficial.

TEXT
+----------------------+        +-----------------------------------+
|  WordPress del       |        |  API de WordPress.org             |
|  Usuario (Local)     |        |  (api.wordpress.org/plugins/...)  |
+----------------------+        +-----------------------------------+
| 1. Dispara WP-Cron   | -----> | 2. Envía array de plugins activos |
|    (Cada 12 horas)   |        |    y sus versiones instaladas.    |
|                      |        |                                   |
| 5. Muestra "bubble"  | <----- | 4. Responde con metadatos de la   |
|    de actualización  |        |    nueva versión y URL del .zip   |
+----------------------+        +-----------------------------------+
                                  |
                                  | 3. La API consulta tu repositorio
                                  v
                        +-----------------------------------+
                        | Repositorio SVN de tu Plugin      |
                        | - Comprueba /trunk/readme.txt     |
                        | - Lee el campo "Stable tag"       |
                        +-----------------------------------+

Cuando configuras un nuevo Stable tag en tu readme.txt y subes la etiqueta (tag) correspondiente al SVN, la API de WordPress.org tarda unos minutos en procesar el cambio. A partir de ese momento, cualquier instalación de WordPress que realice su chequeo periódico (o un usuario que haga clic en "Buscar actualizaciones") detectará la nueva versión.

Versionado Semántico (SemVer)

WordPress recomienda encarecidamente adherirse a las prácticas de Versionado Semántico (Semantic Versioning). El número de versión debe estar estructurado en tres segmentos separados por puntos: MAYOR.MENOR.PARCHE (ej. 2.1.4).

MAYOR (Major): Cambios profundos en la arquitectura, rediseños completos de la interfaz o rupturas de compatibilidad hacia atrás (Breaking Changes). Los usuarios deben ser cautelosos al aplicar esta actualización.
MENOR (Minor): Nuevas características, funcionalidades o mejoras que son totalmente compatibles con la versión anterior.
PARCHE (Patch): Correcciones de errores (bugs), parches de seguridad o pequeñas refactorizaciones de código que no alteran la funcionalidad general.

Mantener esta coherencia genera confianza. Si un administrador ve una actualización de 1.2.3 a 1.2.4, asumirá que es segura de aplicar automáticamente. Si ve un salto a 2.0.0, sabrá que debe probarla en un entorno de staging primero.

El Arte del Changelog

El registro de cambios (Changelog) es la principal herramienta de comunicación entre tú y los usuarios (o los administradores de sistemas). Un buen changelog debe equilibrar el lenguaje técnico para los desarrolladores con beneficios claros para el usuario final.

Dentro de tu archivo readme.txt, la sección == Changelog == debe estructurarse utilizando el número de versión como encabezado de tercer nivel (= X.Y.Z =).

Prácticas recomendadas para el formato:

TEXT
== Changelog ==

= 2.1.0 =
* Añadido: Soporte nativo para bloques de Gutenberg en CPTs.
* Mejorado: Rendimiento de la consulta SQL en el panel principal (reducción del 30% en tiempo de carga).
* Corregido: Error fatal que ocurría al guardar opciones sin permisos de administrador.
* Eliminado: Soporte heredado para PHP 7.2.

= 2.0.1 =
* Corregido: Vulnerabilidad XSS reflejada en el campo de búsqueda del frontend (Gracias a @security_researcher).
* Parche: Ajuste menor en el CSS para pantallas móviles.

Nota: WordPress.org solo procesa y muestra correctamente listas con viñetas iniciadas por asteriscos (*). Clasificar cada línea con verbos de acción (Añadido, Mejorado, Corregido) facilita el escaneo rápido.

Migraciones de Base de Datos en Actualizaciones

Un desafío recurrente en plugins complejos es gestionar las actualizaciones de la estructura de datos cuando el usuario actualiza los archivos físicos del plugin. Sobrescribir los archivos .php (lo que hace WordPress durante una actualización) no altera automáticamente las tablas personalizadas o las opciones en la base de datos ($wpdb).

Debes implementar una rutina de actualización silenciosa. Esto se logra comparando la versión instalada en la base de datos con la versión declarada en el código.

PHP
/**
 * Constante con la versión actual del código del plugin.
 */
define( 'MI_PLUGIN_VERSION', '2.1.0' );

/**
 * Hook que se dispara cada vez que WordPress carga, ideal para comprobar actualizaciones.
 */
add_action( 'plugins_loaded', 'mi_plugin_comprobar_actualizacion' );

function mi_plugin_comprobar_actualizacion() {
    // Recuperar la versión registrada en la base de datos (por defecto '1.0.0' si no existe)
    $version_db = get_option( 'mi_plugin_version_db', '1.0.0' );

    // Si la versión del código es superior a la de la BD, necesitamos actualizar
    if ( version_compare( $version_db, MI_PLUGIN_VERSION, '<' ) ) {
        mi_plugin_ejecutar_migraciones( $version_db );
        
        // Actualizar la opción en la base de datos para no repetir la migración
        update_option( 'mi_plugin_version_db', MI_PLUGIN_VERSION );
    }
}

/**
 * Lógica condicional de migración.
 */
function mi_plugin_ejecutar_migraciones( $version_db ) {
    global $wpdb;

    // Si el usuario actualiza desde una versión anterior a la 2.0.0
    if ( version_compare( $version_db, '2.0.0', '<' ) ) {
        // Ejemplo: Modificar una tabla personalizada creada en el Capítulo 5
        $tabla = $wpdb->prefix . 'mis_registros';
        $wpdb->query( "ALTER TABLE {$tabla} ADD COLUMN status VARCHAR(20) DEFAULT 'active';" );
    }

    // Si actualiza desde una versión anterior a la 2.1.0
    if ( version_compare( $version_db, '2.1.0', '<' ) ) {
        // Ejemplo: Migrar una vieja opción singular a un nuevo array de configuración
        $vieja_opcion = get_option( 'mi_plugin_color_viejo' );
        if ( $vieja_opcion ) {
            $nueva_config = array( 'tema' => 'custom', 'color' => $vieja_opcion );
            update_option( 'mi_plugin_settings', $nueva_config );
            delete_option( 'mi_plugin_color_viejo' );
        }
    }
}

Este patrón garantiza que, sin importar si un usuario actualiza tu plugin desde la versión inmediata anterior o desde una versión de hace dos años, las migraciones de datos se ejecuten secuencialmente y su instalación quede perfectamente sincronizada con la nueva arquitectura del código.

Resumen del capítulo

En este capítulo final hemos cubierto los pasos esenciales para transicionar un desarrollo privado hacia el ecosistema público de WordPress.org:

Directrices del repositorio: Comprendimos las reglas inquebrantables impuestas por el equipo de revisión, destacando la necesidad absoluta de compatibilidad con la licencia GPLv2+, el respeto por las marcas registradas y las estrictas normativas de privacidad que prohíben la telemetría sin consentimiento o el rastreo oculto.
Preparación del archivo readme: Analizamos la sintaxis Markdown requerida para estructurar la página pública del plugin, prestando especial atención a metadatos críticos como Tested up to, Requires PHP y el Stable tag, los cuales dictan la compatibilidad y disponibilidad de la descarga.
Gestión de versiones con SVN: Desmitificamos Subversion (SVN) tratándolo como una herramienta exclusiva de despliegue. Repasamos la estructura inmutable de los directorios /trunk, /tags y /assets, y establecimos la importancia de alinear la constante de versión en PHP con el tag estable del SVN.
Actualizaciones y changelogs: Finalmente, exploramos el flujo asíncrono de actualización que realiza el núcleo de WordPress. Aprendimos a estructurar un changelog efectivo y a implementar una rutina de migración en PHP impulsada por la función version_compare(), asegurando que las actualizaciones físicas de código vayan acompañadas de la correcta evolución del esquema de la base de datos.

Epílogo: El Futuro de tu Código

Has llegado al final de este viaje. Ahora posees el conocimiento técnico para trascender de simple usuario a arquitecto de soluciones, dominando las APIs del núcleo, la seguridad, la manipulación de datos y la publicación oficial.

El ecosistema de WordPress es dinámico y exige un aprendizaje continuo. Mantén la curiosidad, audita tus desarrollos frente a las nuevas versiones del núcleo y no dudes en contribuir a la comunidad de código abierto. Con estas bases sólidas, tienes en tus manos el poder de crear herramientas robustas que potencien miles de proyectos web a nivel global. ¡Mucho éxito en tus próximos desarrollos!

Editar esta página