25. Repositorio oficial WordPress.org

Si tú quieres hospedar tu plugin en WordPress.org, sólo debes pedírnoslo.

Si estás empezando, piensa primero en cómo planear tu plugin.

Características

Todos los plugins hospedados en WordPress.org tienen acceso a:

  1. Monitor de descargas
  2. Estadísticas de versiones
  3. Recibir feedback y revisiones de los usuarios
  4. Proveer soporte a través de un foro gratuito.

También tenemos un Plugin API WordPress.org que se puede usar para monitorizar estadísticas de plugins.

 

Requisitos

Tenemos una larga lista de Guías detalladas de plugin, con ejemplos detallados y explicaciones. Lo que sigue es una breve visión de los aspectos más importantes:

  1. Tu plugin debe ser compatible con la licencia ‘GNU General Public License v.2’ o posterior. Recomendamos encarecidamente utilizar la misma licencia que WordPress – “GPLv2 o posterior”.
  2. Si no especificas compatibilidad con una licencia, se considera GPLv2 o posterior.
  3. Ni el plugin ni el desarrollador deben hacer nada ilegal, deshonesto, u ofensivo moralmente.
  4. El repositorio provisto de ‘Subversion’ debe ser utilizado sólo para plugins de WordPress funcionales. El directorio es un sitio de hospedaje, no un sitio de listas.
  5. El plugin no debe incluir vínculos externos en el sitio público (como un vínculo o advertencia tipo “powered by”) si el permiso explícito del usuario.

 

Tener plugins hospedados

Para tener tu plugin hospedado en WordPress.org, sigue los siguientes pasos:

  1. Regístrate en WordPress.org con una dirección de correo electrónico válida y de uso frecuente. Si estás enviando un plugin en nombre de una empresa, utiliza una cuenta oficial de la misma para la verificación.
  2. Pon en la lista blanca de tu cuenta de correo electrónico la dirección plugins@wordpress.org para asegurarte que recibes las comunicaciones que te enviemos.
  3. Envía tu plugin con una breve descripción de lo que hace y un vínculo al fichero zip completo y funcional del plugin.

Dentro de 14 días laborables, tu plugin se revisará manualmente por un miembro del equipo de Revisiones de Plugins WordPress. Puedes recibir mails con preguntas sobre más información o cuestiones a corregir. Una vez aprobado, recibirás un correo electrónico con detalles como cómo acceder a un Repositorio de Subversión donde incluirás tu plugin.

Después de actualizar tu plugin (y un fichero readme) en dicho repositorio vía SVN, aparecerá en el directorio de plugins.

 

Leer también

 

GUIA DETALLADA DE PLUGINS

NOTA: Actualizada a 3 de noviembre de 2016.

El objetivo del Directorio de Plugins de WordPress es proveer un lugar seguro para todos los usuarios de WordPress – desde los iniciales hasta los desarrolladores – para descargar plugins que son consistentes con los objetivos del proyecto WordPress.

Para este fin, debemos asegurarnos un proceso simple y transparente para que los desarrolladores puedan subir plugins al directorio. Como parte de nuestros esfuerzos para hacer la inclusión del plugin en el directorio más transparente, hemos creado una lista de líneas guía para los desarrolladores. Nos esforzamos para crear un nivel adecuado para todos los desarrolladores.

Si tienes sugerencias para mejorar la documentación, o consultas sobre ella, por favor, envíanos un mail a plugins@wordpress.org y háznoslo saber.

 

Envíos de plugins

Para enviar un plugin, existen tres pasos, comentados más arriba en este mismo artículo. Una vez puesto en cola para revisión, nosotros revisaremos el plugin para cualquier problema. La mayor parte de problemas se pueden evitar siguiendo las líneas indicadas más abajo. Si encontramos problemas, contactamos con el desarrollador, para conseguir la resolución.

 

Expectativas del desarrollador

Los desarrolladores, todos los usuarios con acceso y todos los usuarios que oficialmente soportan un plugin, deben acatar las líneas guía del directorio. Las violaciones en plugins o datos de plugin (para plugins aprobados previamente) serán eliminados del directorio hasta que se subsanen. Datos del plugin, tales como revisiones de usuarios, no se restaurarán, dependiendo de la naturaleza de la violación y el resultado de una revisión de la situación. Las violaciones repetidas conllevarán la eliminación de todos los plugins del autor y el desarrollador será banneado del hospedaje de plugins en WordPress.org. La responsabilidad del desarrollador del plugin es asegurar que su información de contacto en WordPress.org está actualizada y correcta, para recibir todas las notificaciones del equipo de plugins.

Todo el código en el directorio debe ser lo más seguro posible. La seguridad es la responsabilidad última del desarrollador de un plugin, sin embargo el Directorio de Plugins se esfuerza para que sea nuestra mejor habilidad. Si se encuentra un plugin que tiene problemas de seguridad, será cerrado hasta que se resuelva la situación. En casos extremos, el plugin puede ser actualizado por el equipo de Seguridad de WordPress y publicado para la seguridad del público general.

Todo y que intentamos dar cuenta de todas las máximas interpretaciones importantes de las líneas guía como es posible, no es razonable esperar que todas las circunstancias estén explícitamente cubiertas. Si dudas si un plugin puede violar las líneas guía, contacta con nosotros en plugins@wordpress.org y pregunta.

 

LAS LINEAS GUIA

1. Los plugins deben ser compatibles con la GNU General Public License v2, o cualquier versión posterior, para hospedarse en WordPress.org.

Aunque se acepta cualquier licencia compatible GPL, lo recomendado es utilizar la misma licencia que WordPress (“GPLv2 o posterior”). Todo el código, los datos, y las imágenes – cualquier cosa guardada en el directorio – debe cumplir con la GPL (cualquier versión, 2 o posterior), pese lo que le pese a su creador. Librerías incluidas externas también deben ser compatibles. Para una lista específica de licencias compatibles, leer el GPL-Compatible license list on gnu.org.

2. Los desarrolladores de los plugins son responsables de los ficheros que suben y los servicios que utilizan.

Es responsabilidad exclusiva del desarrollador del plugin asegurarse que todos los ficheros contenidos en sus plugins cumplen con las líneas guía.

3. Una versión estable de tu plugin debe estar disponible en su página del Directorio de Plugins de WordPress.

La única versión del plugin que distribuye WordPress.org es la primera del directorio. Aunque puedas desarrollar tu código en algún otro lugar, recuerda que los usuarios descargarán del directorio, no de tu entorno de desarrollo.

4. Haz tu código legible.

Oscurecer el código intencionadamente no se permite en el directorio. Desafortunadamente algunas personas utilizan métodos para esconder código malicios, tal como puertas traseras o rastreos. Además, el código WordPress pretende que cualquiera lo pueda aprender, editar y adaptar. Hacer el código difícil de leer fuerza a futuros desarrolladores a un duro obstáculo. El código minificado se puede utilizar, aunque las versiones no minificadas se deben incluir siempre que sea posible. Recomendamos seguir los Estándares de Código del Nucleo de WordPress.

5. Software de prueba (trialware) no está permitido en el directorio.

Intentar la venta de otros productos y características al usuario se acepta dentro de unos límites:

  • Las notificaciones de venta no deben ser demasiado grandes o molestas.
  • Los plugins no contendrán funcionalidades capadas o bloqueadas, sólo para ser desbloqueada mediante pago o actualización. La funcionalidad por pago debe ser parte de otro servicio de hospedaje externo o un plugin separado, que no se hospedará en wordpress.org.
  • Los plugins no pueden desactivar funcionalidades después de un periodo de prueba.

6. Software como Servicio está permitido en el directorio.

Plugins que actúan como interface a algún servicio externo (por ejemplo, un sitio de hospedaje de vídeos) están permitidos, incluso para servicios de pago.

Servicios y funcionalidades no permitidas, incluyen:

  • Un servicio que existe para el único propósito de validar licencias o llaves, mientras todos los aspectos funcionales del plugin están incluidos localmente.
  • Creación de un servicio, mediante el movimiento arbitrario de código fuera del plugin, de manera que el servicio aparenta proveer las funcionalidades suplementarias.
  • Escaparates que no son servicios. Un plugin que actúa sólo como un front-end para productos de sistemas externos.

7. El plugin no puede “llamar a casa” o trackear a los usuarios sin su consentimiento informado, explícito y aceptado.

En el interés de proteger la privacidad del usuario, los plugins no pueden contactar servicios externos sin el consentimiento explícito del usuario mediante su registro. La documentación de cómo se recogen los datos de usuario y se utilizan, debe estar incluida en el fichero readme del plugin, preferentemente con una clara política de privacidad.

8. El plugin no puede enviar código ejecutable a sistemas externos.

La carga externa de código de servicios documentados está permitida, aunque todas las comunicaciones deben hacerse lo más seguramente que sea posible. Ejecutar código externo dentro de un plugin que no está actuando como servicio, no está permitido.

9. El plugin y sus desarrolladores no pueden hacer nada ilegal, deshonesto, o moralmente ofensivo.

10. El plugin no puede contener vínculos externos o créditos en el sitio público sin el permiso explícito del usuario.

11. El plugin no puede hackear el panel de administración

Los usuarios prefieren y esperan plugins que se sientan como parte de WordPress. Esta experiencia se rompe con alertas constantes.

Avisos de mejoras, noticias y alertas se deben limitar en el ámbito de la página de ajustes del plugin.

12. Las carátulas públicas en WordPress.org no podrán contener vínculos.

Incluyendo readmes y ficheros de traducción, no podrán contener vínculos esponsorizados o de afiliación.

13. La página del plugin en el directorio no puede incluir más de 12 etiquetas.

14. Se debe evitar comprometerse frecuentemente a un plugin

15. El número de versión del plugin se debe incrementar cada vez que se lanza una nueva versión.

16. El plugin completo debe estar disponible en el momento de presentarlo al directorio.

17. Respetar marcas registradas y proyectos.

18. Nos reservamos el derecho de alterar las Líneas Guía de Plugins en cualquier momento, con o sin aviso.

 

PLANIFICA TU PLUGIN

1. Testea tu plugin una vez, y otra.

2. Selecciona un buen nombre.

3. Escribe una gran documentación.

El fichero README.txt es el mejor lugar para empezar, ya que es el punto de referencia estándar para todos los plugins. Asegúrate que incluyes:

  • Descripción concisa de qué hace actualmente tu plugin. Si hace muchas, quizá sería mejor en dos plugins.
  • Instrucciones de instalación, especialmente si hay que hacer una configuración especial. Si un usuario necesita registrarse con tu servicio, asegúrate que lo enlazas.
  • Direcciones donde obtener soporte.

4. Envía una primera versión a WordPress.org

El directorio de plugins de WordPress.org es la forma más fácil de descargar e instalar tu plugin para potenciales usuarios. La integración de WordPress con el directorio de plugins significa que tu plugin puede ser actualizado por el usuario en un par de pares de clicks.

Cuando estés listo para lanzar tu primera versión, querrás inscribirla. Después de que el proceso de revisión esté completo sin incidencias, tendrás concedido un Repositorio de Sub-versión para tu código. El sitio WordPress.org tiene buena documentación para hacer tu primer cometido subversión y el proceso en general.

5. Abraza el código abierto

El código abierto es una de las ideas más poderosas de nuestro tiempo porque permite la colaboración más allá de los límites. Alentando las contribuciones, estás permitiendo a los demás amar tu código más de los que lo amas tú. Existen diferentes opciones para hacer tu código abierto:

  • Github
  • Bitbucket
  • El directorio de plugins de WordPress.org

6. Escucha a tus usuarios

Generalmente encontrarás que tus usuarios pondrán tu código en muchos más casos de prueba que tú podrías imaginar. Esto puede ser un feedback tremendamente valioso.

Lanzando tu código a través de WordPress.org significa que tu plugin tiene automáticamente un foro de soporte. Utilízalo. Te puedes subscribir para recibir nuevos posts por correo electrónico y responder a tus usuarios de una manera inmediata. Ellos te lo agradecerán.

7. Lanza nuevas versiones regularmente

Los mejores plugins son aquellos que se mantienen durante el tiempo, lanzano pequeños cambios a lo largo del camino.

8. Lava y repite

Como en otras partes de la vida, las mejores cosas llegan de la paciencia y el trabajo duro.

 

COMO UTILIZAR LA SUBVERSION

Vamos a describir aquí algunos de los principios sobre el uso de la subversión: empezando, cambiando cosas y etiquetando versiones.

Este documento no es una completa y robusta explicación sobre el uso de SVN, es más una rápida guía para empezar con los plugins en WordPress.org. Para una documentación más extensa, ver The SVN Book.

Primero, alguna terminología

Si eres nuevo en las subversiones, necesitarás saber lo que significan algunas palabras.

Todos tus archivos se guardarán centralmente en el repositorio svn en nuestros servidores. Desde dicho repositorio, cualquiera puede chequear una copia de los archivos de tu plugin en su máquinas locales, pero, como autor de plugins, sólo tú tienes la autoridad de chequeo. Eso significa que tú puedes hacer cambios a los ficheros, añadir nuevos fichero, y borrar ficheros en tu máquina local y subir dichos cambios al servidor centras.
Es este proceso de registro que actualiza tanto los archivos del repositorio como la información que se muestra en el Directorio de Plugins de WordPress.org.

La subversión guarda la pista de todos estos cambios, por lo que puedes volver atrás y mirar versiones o revisiones antiguas más tarde si lo necesitas. Además, al recordar cada revisión individual, puedes indicar a la subversión que etiquete ciertas revisiones del repositorio para una referencia fácil. Las etiquetas son idoneas para etiquetar diferentes versiones de tu plugin.

Los subdirectorios SVN

Los repositorios SVN vienen con cuatro subdirectorios

  • /assets/ para los screenshots, cabeceras e iconos del plugin.
  • /branches/ las diversas ramas de código.
  • /tags/ donde van las versiones.
  • /trunk/ todo el trabajo de desarrollo.

Incluso si tú haces el trabajo de desarrollo en cualquier otro lugar (como un repositorio git), recomendamos mantener el sistema de subdirectorios con tu código para comparaciones SVN fáciles.

Tarea 1: Empezar desde cero con tu nuevo plugin

Todo lo que necesitas hacer es añadir los archivos del plugin que ya tienes en tu nuevo repositorio SVN.

Para hacerlo, necesitas primero crear un directorio local en tu máquina para habitar una copia del repositorio SVN:

Entonces, chequea el repositorio pre-construido:

Como puedes ver, la subversión ha añadido los directorios desde el repositorio central SVN a tu copia local. Ahora puedes añadir ficheros a tu directorio /trunk/ local como quieras.

Una vez tus ficheros están en el directorio trunk, tienes que dejar a la subversión saber que quieres añadir los nuevos ficheros al repositorio central.

Después de añadir los ficheros, chequea los cambios en el repositorio central.

Se requiere incluir un mensaje para todos los chequeos.

Tarea 2: Editar un fichero que ya está en el repositorio

Asumamos que ya tenemos tu repositorio de plugin con los ficheros que se necesitan. Ahora, supongamos que necesitas editar uno de los fichero para mejorar el plugin.

Primero entra en tu copia local del repositorio y asegúrate que está actualizado.

En este último ejemplo, lo tenemos todo actualizado. Si hubiera habido cambios en el repositorio central, habrían sido descargados y actualizados en tu copia local.

Ahora puedes editar el fichero que necesitas.

Si no estás utilizando una herramienta SVN GUI (como SubVersion o Coda) también puedes chequear y ver las diferencias entre tu copia local y el repositorio central después de que hagas cambios. Primero, chequeamos el estado de la copia local:

Esto nos dice que nuestro archivo local trunk/my-plugin.php es diferente de la copia que descargamos del repositorio central (“M” por “modificado”).

Veamos qué ha cambiado exactamente en este fichero, luego podemos chequearlo y asegurarnos que todo está bien.

Si todo parece correcto, chequeamos los cambios en el repositorio central.

Finalizado.

Tarea 3: “Etiquetando” una nueva versión

Cada vez que haces una versión formal de tu plugin, debes etiquetar una copia del código de dicha versión. Esto permite a tus usuarios coger la última (o una antigua) versión, y te permite a ti mantener una trazabilidad más fácil de los cambios, y permite al Directorio de Plugins de WordPress.org saber qué versión de tu plugin va a mostrar a los usuarios para que se la descarguen.

Para hacerlo, necesitas acordarte de actualizar el campo ‘Stable Tag’ en ‘trunk/readme.txt’ de antemano!

Primero, copia tu código en un subdirectorio en el directorio /tags/. Por el bien del navegador de plugin WordPress.org, el nuevo subdirectorio siempre se verá como un número de versión.

Queremos utilizar ‘svn cp’ en lugar de ‘cp’ para aprovechar las características del SVN.

Ahora, como siempre, chequeamos los cambios.

Alternativamente, puedes utilizar http URL para copiar.

Haciendo esto, realizas la copia remotamente en lugar de copiar cada cosa localmente y subiendo después. Esto puede ser beneficioso si tu plugin es muy largo.

Enhorabuena! Has subido tu código.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *