Desde su creación, el Directorio de Plugins de WordPress ha sido una plataforma esencial para los desarrolladores y usuarios que buscan ampliar las capacidades de sus sitios web. Sin embargo, con un ecosistema tan grande y en constante evolución, era necesario establecer un conjunto claro de reglas que guiaran a los desarrolladores en la creación y distribución de plugins.
En 2016, WordPress decidió revisar y simplificar sus Directrices del Directorio de Plugins que tienes disponibles en GitHub y que te traducimos más abajo. El objetivo era que fueran más fáciles de entender sin perder la esencia de lo que pretendían lograr: garantizar que los plugins respeten los valores y principios del software de código abierto, manteniendo la calidad y seguridad de las soluciones ofrecidas.
¿Por qué son importantes estas directrices?
Aunque uno podría pensar que es suficiente con no ser «una mala persona o un spammer», la realidad es que algunos desarrolladores necesitan que se les expliquen ciertas pautas de manera explícita. Además, muchas situaciones dentro del ecosistema de WordPress son difíciles de resumir en simples reglas.
Estas directrices fueron revisadas inicialmente por el equipo de revisión de plugins y posteriormente por voluntarios en WordCamps de todo el mundo. Finalmente, se pusieron a disposición del público para que la comunidad en general pudiera contribuir y ofrecer sugerencias.
Un esfuerzo de la comunidad
El esfuerzo de actualización de las directrices fue un proceso colaborativo en el que cualquier miembro de la comunidad de WordPress pudo participar. La idea era que las directrices no solo fueran comprensibles para los desarrolladores experimentados, sino también para aquellos que pudieran no tener un dominio completo del inglés o no estar familiarizados con el lenguaje técnico.
De hecho, el uso de palabras complejas o innecesarias ha sido deliberadamente evitado, para que todos los niveles de desarrolladores puedan comprenderlas y aplicarlas sin dificultad.
Directrices del Directorio de Plugins de WordPress.org
Introducción
El Directorio de Plugins de WordPress tiene como objetivo proporcionar un lugar seguro para que todos los usuarios de WordPress, desde los no técnicos hasta los desarrolladores, puedan descargar plugins que sean coherentes con los objetivos del proyecto WordPress. Para lograr este fin, se busca garantizar un proceso simple y transparente para que los desarrolladores envíen sus plugins al directorio.
Como parte de los esfuerzos continuos para hacer que el proceso de inclusión en el directorio sea más claro, se ha creado una lista de directrices para los desarrolladores. El objetivo es crear un campo de juego equitativo para todos los desarrolladores.
Si tienes sugerencias para mejorar las directrices o preguntas sobre ellas, puedes enviar un correo electrónico a [email protected] y hacérnoslo saber.
Expectativas para los desarrolladores
Se espera que los desarrolladores, todos los usuarios con acceso de envío y todos los usuarios que apoyen oficialmente un plugin cumplan con las siguientes directrices:
Las violaciones de estas directrices pueden dar lugar a que los plugins o los datos relacionados (para plugins previamente aprobados) sean eliminados del directorio hasta que los problemas se resuelvan. Los datos del plugin, como las reseñas de los usuarios y el código, pueden no ser restaurados dependiendo de la naturaleza de la violación y los resultados de una revisión entre pares de la situación. Las violaciones reiteradas pueden resultar en la eliminación de todos los plugins del autor y en la prohibición del desarrollador para alojar plugins en WordPress.org.
Es responsabilidad del desarrollador del plugin asegurarse de que su información de contacto en WordPress.org esté actualizada y sea precisa, de manera que puedan recibir todas las notificaciones del equipo de plugins. No se permiten respuestas automáticas ni correos que se dirijan a un sistema de soporte, ya que históricamente esto impide que las personas aborden los correos electrónicos de manera oportuna.
Todo el código en el directorio debe ser lo más seguro posible. La seguridad es responsabilidad última del desarrollador del plugin, y el Directorio de Plugins hace cumplir esto en la medida de sus posibilidades. Si se encuentra que un plugin tiene problemas de seguridad, será cerrado hasta que se resuelva la situación. En casos extremos, el equipo de seguridad de WordPress podría actualizar el plugin y propagarlo por la seguridad del público en general.
Si bien intentamos considerar la mayor cantidad posible de interpretaciones relevantes de las directrices, es irrazonable esperar que todas las circunstancias estén explícitamente cubiertas. Si tienes dudas sobre si un plugin podría violar las directrices, contacta a [email protected] y pregunta.
1. Los plugins deben ser compatibles con la Licencia Pública General de GNU v2
Aunque cualquier licencia compatible con GPL es aceptable, se recomienda encarecidamente usar la misma licencia que WordPress, es decir, “GPLv2 o posterior”. Todo el código, datos e imágenes, en resumen, cualquier recurso almacenado en el directorio de plugins alojado en WordPress.org, debe cumplir con la licencia GPLv2. Esto incluye también las bibliotecas de terceros, códigos, imágenes u otros componentes que puedan estar integrados. Para una lista específica de licencias compatibles, se puede consultar el listado de licencias compatibles con GPL en gnu.org.
2. Los desarrolladores son responsables del contenido y las acciones de sus plugins.
Es responsabilidad exclusiva de los desarrolladores de plugins asegurarse de que todos los archivos dentro de sus plugins cumplan con las directrices. Está prohibido escribir código intencionalmente para eludir las normas, o restaurar código que se les haya pedido eliminar (ver el punto #9 sobre acciones ilegales o deshonestas).
Los desarrolladores deben verificar, antes de subir su plugin al SVN, la licencia de todos los archivos incluidos, desde el código fuente original hasta imágenes y bibliotecas. Además, deben cumplir con los términos de uso de todos los servicios y APIs de terceros que utilicen en sus plugins. Si no es posible validar la licencia de una biblioteca o los términos de una API, entonces no se pueden utilizar.
3. Una versión estable del plugin debe estar disponible en la página del directorio de plugins de WordPress.
La única versión del plugin que distribuye WordPress.org es la que se encuentra en el directorio. Aunque los desarrolladores pueden trabajar en su código en otros lugares, los usuarios siempre descargarán la versión del directorio, no desde el entorno de desarrollo.
Distribuir el código a través de métodos alternativos y no mantener la versión alojada en el directorio actualizada puede resultar en la eliminación del plugin.
4. El código debe ser (en su mayoría) legible para los humanos
No se permite ocultar o ofuscar el código utilizando técnicas como la función de ofuscación de p,a,c,k,e,rmangle de uglify o convenciones de nombres poco claras como $z12sdf813d
Exigimos que los desarrolladores proporcionen acceso público y mantenido a su código fuente y cualquier herramienta de compilación de alguna de las siguientes maneras:
- Incluir el código fuente en el plugin desplegado.
- Incluir un enlace en el archivo
readmea la ubicación del desarrollo.
Recomendamos encarecidamente documentar cómo deben utilizarse las herramientas de desarrollo.
5. El software de prueba no está permitido
Los plugins no pueden incluir funcionalidades restringidas o bloqueadas que solo se desbloqueen mediante pago o actualización. No está permitido desactivar funcionalidades después de un periodo de prueba o cuando se alcance una cuota. Además, los plugins que proporcionan acceso únicamente a un entorno de pruebas (sandbox) para APIs y servicios también se consideran plugins de prueba o experimentales, y no están permitidos.
Se permite la funcionalidad de pago en los servicios (ver la guía 6: software como servicio), siempre que todo el código dentro del plugin esté completamente disponible. Se recomienda el uso de plugins complementarios, alojados fuera de WordPress.org, para excluir el código premium. Los casos en los que un plugin esté destinado únicamente como herramienta para desarrolladores se revisarán individualmente.
Está permitido intentar vender productos y funciones adicionales, siempre que se ajuste a la norma 11 (modificación de la experiencia del administrador).
6. El uso de Software como Servicio (SaaS) está permitido.
Los plugins que actúan como una interfaz para un servicio externo de terceros (por ejemplo, un sitio de alojamiento de videos) están permitidos, incluso si se trata de servicios pagos. Sin embargo, el servicio debe proporcionar una funcionalidad sustancial y estar claramente documentado en el archivo readme que se presenta con el plugin, preferiblemente con un enlace a los Términos de Uso del servicio.
No se permiten los siguientes tipos de servicios y funcionalidades:
- Un servicio que exista únicamente para validar licencias o claves, mientras que todos los aspectos funcionales del plugin estén incluidos localmente, no está permitido.
- La creación de un servicio moviendo código arbitrario fuera del plugin para que el servicio parezca falsamente proporcionar una funcionalidad suplementada está prohibida.
- Tiendas en línea que no sean servicios. Un plugin que actúe únicamente como un front-end para productos a comprarse en sistemas externos no será aceptado.
7. Los plugins no pueden rastrear a los usuarios sin su consentimiento.
En aras de proteger la privacidad del usuario, los plugins no pueden contactar con servidores externos sin el consentimiento explícito y autorizado del usuario. Generalmente, esto se realiza mediante un método de «opt in», que requiere el registro en un servicio o una casilla de verificación dentro de las configuraciones del plugin. La documentación sobre cómo se recopilan y usan los datos del usuario debe estar incluida en el archivo readme del plugin, preferiblemente con una política de privacidad claramente establecida.
Algunos ejemplos de rastreo prohibido incluyen:
- La recopilación automatizada de datos del usuario sin confirmación explícita de su parte.
- Engañar intencionadamente a los usuarios para que envíen información como un requisito para el uso del propio plugin.
- Descarga de recursos (incluidas imágenes y scripts) que no están relacionados con un servicio.
- Uso de datos externos (como listas negras) no documentado o documentado de manera deficiente.
- Mecanismos de publicidad de terceros que rastrean el uso y/o las vistas.
Una excepción a esta política es el Software como Servicio (SaaS), como Twitter, un plugin de CDN de Amazon o Akismet. Al instalar, activar, registrar y configurar plugins que utilizan esos servicios, se concede el consentimiento para que esos sistemas puedan funcionar.
8. Los plugins no pueden enviar código ejecutable a través de sistemas de terceros.
Está permitido cargar código externamente desde servicios documentados, siempre y cuando toda la comunicación se realice de la manera más segura posible. No está permitido ejecutar código externo dentro de un plugin cuando no actúa como un servicio, por ejemplo:
- Ofrecer actualizaciones o instalar plugins, temas o complementos desde servidores que no sean WordPress.org.
- Instalar versiones premium del mismo plugin.
- Llamar a CDN de terceros para algo que no sea la inclusión de fuentes; todo el JavaScript y CSS no relacionado con servicios debe incluirse localmente.
- Usar servicios de terceros para gestionar listas de datos que se actualizan regularmente, a menos que esté explícitamente permitido en los términos de uso del servicio.
- Utilizar iframes para conectar páginas de administración; se deben utilizar APIs para minimizar riesgos de seguridad.
Los servicios de gestión que interactúan con un sitio y empujan software hacia él están permitidos, siempre y cuando el servicio maneje la interacción desde su propio dominio y no dentro del panel de control de WordPress.
9: Los desarrolladores y sus plugins no deben realizar actividades ilegales, deshonestas o moralmente ofensivas.
Este principio, aunque subjetivo y bastante amplio, tiene la intención de evitar que los plugins, los desarrolladores y las empresas abusen de las libertades y derechos de los usuarios finales, así como de otros desarrolladores de plugins.
Entre las prácticas prohibidas (aunque no limitadas a estas) se incluyen:
- Manipulación artificial de los resultados de búsqueda mediante técnicas como el relleno de palabras clave o SEO de «sombrero negro».
- Ofrecer aumentar el tráfico de los sitios que utilizan el plugin.
- Compensar, engañar, presionar, extorsionar o chantajear a otros para obtener reseñas o soporte.
- Insinuar que los usuarios deben pagar para desbloquear funciones que ya están incluidas.
- Crear cuentas para generar reseñas o tickets de soporte falsos (conocido como sockpuppeting).
- Presentar como propio el trabajo de otros desarrolladores o plagiar plugins.
- Implicar que un plugin puede crear, proporcionar o garantizar el cumplimiento legal.
- Utilizar el servidor o los recursos del usuario sin su permiso, como en casos de botnets o minería de criptomonedas.
- Violar el Código de Conducta de la Comunidad WordPress.org.
- Violar el Código de Conducta de WordCamp.
- Violar las Directrices del Foro de WordPress.
- Hostigamiento, amenazas o abusos dirigidos a cualquier otro miembro de la comunidad de WordPress.
- Falsificar información personal para disfrazar identidades y evitar sanciones por infracciones anteriores.
- Intentar explotar intencionalmente lagunas o vacíos en las directrices.
Este conjunto de normas tiene como objetivo mantener la ética y el respeto dentro de la comunidad de desarrolladores y usuarios de WordPress, garantizando que el ecosistema de plugins siga siendo seguro y respetuoso.
10. Los plugins no pueden incrustar enlaces externos o créditos en el sitio público sin el permiso explícito del usuario.
Cualquier visualización de «Powered By» o créditos incluidos en el código del plugin deben ser opcionales y, por defecto, no mostrarse en los sitios web visibles por los usuarios. Los usuarios deben optar por mostrar estos créditos y enlaces mediante opciones claramente expuestas y comprensibles, no ocultas en los términos de uso o documentación. Los plugins no pueden requerir que se muestren créditos o enlaces para que el plugin funcione. Se permite que los servicios incluyan su marca en sus resultados siempre que el código sea manejado por el servicio y no por el plugin.
11. Los plugins no deben secuestrar el panel de administración.
Los usuarios prefieren y esperan que los plugins se integren como parte de WordPress. Las notificaciones constantes y la sobrecarga del panel de administración con alertas innecesarias perjudican esta experiencia.
Las solicitudes de actualización, avisos, alertas y similares deben ser limitadas en su alcance y utilizadas con moderación, ya sea de manera contextual o solo en la página de configuración del plugin. Los avisos a nivel de todo el sitio o los widgets integrados en el panel de control deben ser descartables o autoeliminarse una vez resueltos. Los mensajes de error y alertas deben incluir información sobre cómo resolver la situación y eliminarse una vez completada la acción.
La publicidad dentro del panel de control de WordPress debe evitarse, ya que generalmente es ineficaz. Los usuarios suelen visitar las páginas de configuración solo cuando están tratando de resolver un problema. Dificultar el uso de un plugin no suele fomentar una buena reseña, por lo que recomendamos limitar cualquier publicidad en esas áreas. Recuerda: no se permite el seguimiento de referencias a través de esos anuncios (ver la directriz 7), y la mayoría de los sistemas de terceros no permiten anuncios en el back-end. Abusar de las normas de un sistema publicitario resultará en que los desarrolladores sean reportados a las entidades correspondientes.
Se anima a los desarrolladores a incluir enlaces a sus propios sitios o redes sociales, así como a incorporar imágenes dentro del propio plugin para mejorar la experiencia del usuario.
12. Las páginas públicas en WordPress.org (archivos readme) no deben hacer spam
Las páginas públicas, incluidos los archivos readme y de traducción, no pueden utilizarse para hacer spam. El comportamiento de spam incluye (pero no se limita a) enlaces de afiliados innecesarios, etiquetas a complementos de competidores, uso de más de 12 etiquetas en total, SEO de sombrero negro y sobrecarga de palabras clave.
Se permiten enlaces a productos directamente requeridos, como temas u otros complementos necesarios para el uso del plugin, siempre que sea con moderación. De manera similar, se pueden utilizar productos relacionados en las etiquetas, pero no productos de la competencia. Si un complemento es una extensión de WooCommerce, puede usar la etiqueta ‘woocommerce’. Sin embargo, si el complemento es una alternativa a Akismet, no puede usar ese término como etiqueta. El uso repetitivo de una etiqueta o término específico se considera sobrecarga de palabras clave y no está permitido.
Los readmes deben estar escritos para personas, no para bots.
En todos los casos, los enlaces de afiliados deben ser divulgados y deben enlazar directamente al servicio de afiliados, no a una URL redirigida o enmascarada.
13. Los plugins deben utilizar las bibliotecas predeterminadas de WordPress.
WordPress incluye una serie de bibliotecas útiles, como jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, entre otras. Por razones de seguridad y estabilidad, los plugins no pueden incluir estas bibliotecas en su propio código. En su lugar, los plugins deben utilizar las versiones de estas bibliotecas que vienen empaquetadas con WordPress.
Para obtener una lista completa de las bibliotecas de JavaScript incluidas en WordPress, puedes revisar la página Scripts predeterminados incluidos y registrados por WordPress.
14. Evitar los commits frecuentes en un plugin
El repositorio SVN es un repositorio de lanzamientos, no de desarrollo. Cada commit, ya sea en los archivos de código o en los archivos de readme, desencadenará la regeneración de los archivos zip asociados con el plugin. Por lo tanto, solo se debe subir al SVN código que esté listo para su despliegue (ya sea una versión estable, beta o RC). Se recomienda encarecidamente incluir un mensaje descriptivo e informativo con cada commit. Los mensajes de commit frecuentes y poco informativos como “update” o “cleanup” dificultan el seguimiento de los cambios para otros usuarios. Además, múltiples commits en ráfaga que solo modifican aspectos menores del plugin (incluyendo el readme) generan una carga innecesaria en el sistema y pueden interpretarse como un intento de manipular las listas de plugins «Recientemente Actualizados».
Una excepción a esta regla es cuando se actualizan archivos readme únicamente para indicar compatibilidad con la última versión de WordPress.
15. Los números de versión del plugin deben incrementarse con cada nueva versión.
Los usuarios solo son alertados sobre actualizaciones cuando se incrementa la versión del plugin. El archivo readme.txt en la carpeta principal (trunk) debe reflejar siempre la versión actual del plugin. Para obtener más información sobre cómo etiquetar versiones, por favor consulta nuestras instrucciones de SVN sobre etiquetado y cómo funciona el archivo readme.txt.
16. El plugin debe estar completo al momento de su envío.
Todos los plugins son examinados antes de su aprobación, por lo que se requiere un archivo zip en el momento del envío. No se pueden «reservar» nombres para un uso futuro o para proteger marcas (ver la guía #17: respeto a las marcas). Los nombres de directorios de plugins aprobados que no sean utilizados podrán ser asignados a otros desarrolladores.
17. Los plugins deben respetar marcas registradas, derechos de autor y nombres de proyectos.
El uso de marcas registradas u otros proyectos como el único o el término inicial de un slug de plugin está prohibido, a menos que se pueda confirmar la propiedad legal o representación. Por ejemplo, la Fundación WordPress ha registrado la marca «WordPress», y es una violación usar «wordpress» en un nombre de dominio. Esta política se extiende a los slugs de los plugins, y no permitiremos un slug que comience con el término de otro producto.
Por ejemplo, solo los empleados de Super Sandbox deberían usar el slug “super-sandbox» o su marca en un contexto como “Super Sandbox Dancing Sloths”. Los no empleados deberían usar un formato como “Dancing Sloths para Superbox” para evitar confundir a los usuarios haciéndoles creer que el plugin fue desarrollado por Super Sandbox. De manera similar, si no representas el proyecto «MellowYellowSandbox.js», es inapropiado usar ese nombre como el de tu plugin.
Se recomienda crear una marca propia, ya que no solo ayuda a evitar confusiones, sino que también es más memorable para el usuario.
18. Nos reservamos el derecho de mantener el Directorio de Plugins de la mejor manera posible
Nuestra intención es aplicar estas directrices con la mayor equidad posible. Hacemos esto para garantizar la calidad general de los plugins y la seguridad de sus usuarios. Con ese fin, nos reservamos los siguientes derechos:
- … actualizar estas directrices en cualquier momento.
- … deshabilitar o eliminar cualquier plugin del directorio, incluso por razones no explícitamente cubiertas por las directrices.
- … otorgar excepciones y permitir a los desarrolladores tiempo para abordar problemas, incluso relacionados con la seguridad.
- … retirar el acceso de un desarrollador a un plugin en favor de un nuevo desarrollador activo.
- … realizar cambios en un plugin, sin el consentimiento del desarrollador, en interés de la seguridad pública.
A cambio, prometemos usar estos derechos con moderación y con el mayor respeto posible tanto para los usuarios finales como para los desarrolladores.
