Artículos etiquetados con:comunidad
Comunidad Drupal: qué es y cómo contribuir

En el ámbito del desarrollo web contamos con muchísimas herramientas destinadas a ofrecernos la mayor funcionalidad posible a la hora de trabajar. La elección de unas u otras es completamente personal. Cada herramienta puede ofrecer mejores características en un ámbito que en otro. Entonces, ¿por qué elegir Drupal como CMS a la hora del desarrollo web?

Drupal es, actualmente, uno de los CMS más usados en el mundo. Su filosofía de ‘bien público’ ha impulsando la formación de una extensa comunidad de programadores que día a día van uniendo sinergias y mejorando el sistema, publicando sus aportaciones en beneficio de todos y haciendo más rica esta tecnología de manera directa. Así que, ¿conocemos algo mejor cómo funciona la comunidad Drupal?

 

QUÉ ES DRUPAL Y CÓMO FUNCIONA

Desde que en enero de 2001 Dries Buytaert lanzase Drupal como sistema de tablón de anuncios (BBS), el software ha experimentado una evolución total hacia el sistema de gestión de contenidos (CMS) que es hoy en día. En su versión actual, 8.x, Drupal cuenta con más de 80 módulos en su núcleo. Estos aportan distintas funcionalidades a la hora de realizar el desarrollo web.

Desde su primera versión, Drupal se ha caracterizado por ser un CMS Open Source basado en comunidad. La comunidad Drupal es, sin duda, una de las comunidades más activas en el ámbito web. El hecho de que sea software libre hace que Drupal gane enteros frente a otros CMS, ya que es fácilmente accesible por cualquier desarrollador web.

La comunidad Drupal se sustenta a base de contribuciones, tanto de ampliación de funcionalidades como de mantenimiento. Para ello existe la Issue queue, donde los usuario crean hilos con las incidencias encontradas (tanto en el core como en los módulos y temas contribuidos) y se realizan debates y/o aportaciones de código mediante parches.

Drupal cuenta además con algunas webs derivadas, como la de traducciones, y funciones comunitarias que no tienen que ver directamente con la implementación de código, como son la documentación (mejoras, modificaciones y adhesiones a la documentación oficial) o el foro de discusiones.

A nivel de desarrollo, los lenguajes de programación y marcado que se usan principalmente son:

  • PHP. Adaptado a la programación orientada a objetos
  • Javascript. Soportando librerías jQuery
  • HTML5
  • SASS. Preprocesador de CSS

Por tanto, Drupal usa herramientas de desarrollo reconocidas en el desarrollo web. La comunidad de Drupal es la base del CMS, así que…

 

¿CÓMO FUNCIONA LA COMUNIDAD DRUPAL?

Como hemos comentado anteriormente, Drupal se basa en las aportaciones de la comunidad, a través de su web oficial: www.drupal.org . La web de Drupal recoge todas las funcionalidades comunitarias que aporta el CMS, en la propia página y en páginas secundarias.

Comunidad Drupal - drupalorg - SDOS

 

Las principales funcionalidades de Drupal.org son las siguientes:

  • Descripción y definiciones de Drupal. Por qué usarlo, novedades, etc.
  • Descargas. Distribuciones (versiones del Core), módulos, temas e hilo de incidencias. Detallaremos a continuación todas las características ofrecidas aquí.
  • Soluciones. Casos de éxito y otros ejemplos.
  • Comunidad. Cómo contribuir, qué contribuir, organizaciones del ecosistema de Drupal y foros.
  • Recursos. Ofertas de empleo, eventos, patrocinadores, novedades del proyecto, guía del usuario, documentación, soporte y seguridad.
  • Asociación. Qué es, soporte, promoción de Drupal y dónde encontrarlos.

Comunidad Drupal - download - SDOS

 

En la imagen observamos la página Download & Extend, en la cual se organizan los contenidos descargables de Drupal por pestañas: contenido y descargas del core, módulos y temas. Para encontrar el módulo o el tema que más se nos adapta, nos ofrece un buscador con numerosos filtros de exclusión y ordenación.

Cabe destacar que toda esta información es fácilmente accesible desde los motores de búsqueda. Por supuesto, toda la web de la comunidad Drupal se encuentra íntegramente en inglés.

 

¿CÓMO PARTICIPAR EN LA COMUNIDAD?

Para poder acceder a toda la funcionalidad de Drupal.org, y poder realizar contribuciones, hace falta crearse un usuario. Este usuario ofrece la posibilidad de crear un muro con datos propios, afiliarse al perfil de la empresa donde el usuario trabaja (si tiene perfil de empresa en Drupal) y recoger las aportaciones comunitarias del usuario. Una de las características es la obtención del rol de usuario confirmado, que se activa de forma automática con la participación en la comunidad. Este rol da acceso a la modificación de la documentación.

Comunidad Drupal - profile - SDOS

 

El perfil público del usuario se muestra en la imagen, y en él se pueden distinguir tres bloques de contenido bien diferenciados:

  1. Información personal del usuario. Foto de perfil, país de procedencia, redes sociales, empresa (y rol que desempeña), y otros datos personales como el género, los idiomas hablados, etc.
  2. Información añadida por el usuario. Los usuarios pueden poner lo que deseen. Se suelen resaltar los conocimientos que tienen o cualquier cosa que quieran destacar, como en este caso el enlace al perfil de Drupal Translations y los eventos al que ha asistido el usuario de la imagen.
  3. Contribuciones que ha realizado el usuario a la comunidad en forma de código. Las issues en las que está acreditado (con el proyecto al que pertenece) y los proyectos en los cuales participa como creador/mantenedor.

Una vez que tenemos nuestro usuario en la comunidad Drupal y puesto en orden nuestro perfil, podemos realizar nuestra primera contribución. Las páginas de traducción y de documentación pueden ser un buen punto de arranque. También podemos aportar funcionalidades al core, a módulos contribuidos, a temas (del core o contribuidos), o añadir nuestro propio módulo o tema a la lista de Drupal.

 

 

CONTRIBUYENDO AL NÚCLEO DE DRUPAL

La lista de issues se presenta como en la imagen anterior. En ella podemos distinguir distintos campos, los cuales aportan información a la hora de acceder a la descripción de la issue:

Comunidad Drupal - issue queue - SDOS

 

  1. Proyecto que tiene la issue. En este caso es el módulo Group, pero justo la issue de encima es sobre el core de Drupal. Es importante ya que es difícil resolver una issue si no se conoce el contexto del módulo (o tema, o el propio core) sobre el que se va a trabajar.
  2. Nombre que recibe la issue. Este nombre es explicativo del problema, y junto a él se muestra si existen interacciones (comentarios, parches, actualizaciones del estado, etc.) en la propia issue con el texto ‘new’ en rojo.
  3. Estado de la issue. Los estados básicos en los que puede estar la issue son: Active, Needs Work, Needs Review, Reviewed & Tested by the Community, Postponed, Fixed y Closed
  4. Prioridad de la issue: minor, normal, major o critical.
  5. Categoría de la issue: bug report, task, feature request, support request, plan.
  6. Versión del proyecto. 8.x-1.x-dev en el ejemplo.
  7. Número de comentarios y actualizaciones que hay en la issue.
  8. Fecha del último comentario publicado.
  9. Usuario al que está asignada la issue. Los usuarios se asignan las issues cuando se van a poner a trabajar en ellas, considerando un tiempo prudencial de subida de un parche o una solución coherente. Si aparece vacía es que no hay nadie asignado.
  10. Fecha de creación de la issue.

Una vez accedemos a una issue, nos encontramos con la siguiente información:

Comunidad Drupal - issue - SDOS

 

  1. Título de la issue. Como en la lista de issues hemos detallado, el título debe ser lo más descriptivo posible.
  2. Descripción de la issue. La descripción la crea el autor de la issue, pero puede ser modificada y/o actualizada por la comunidad. Además, puede incluir imágenes, soluciones propuestas y pasos a seguir por los desarrolladores que la aborden.
  3. Archivos adjuntos de la issue. Éstos son las imágenes aportadas y los parches subidos. Aquí aparecen todos los adjuntos del hilo con el comentario donde se adjuntan referenciado por su número.
  4. Orden que siguen los comentarios. Estos siguen un orden secuencial de arriba a abajo. Por tanto, los comentarios más recientes están al final del hilo.
  5. Datos básicos de la issue. Proyecto (con su versión y el tipo de componente del que se trata), la prioridad, la categoría de la issue, si está asignada, el usuario que ha reportado la issue y las fechas de creación y actualización.
  6. Estrella de ‘follow this issue’. Activándolo, el usuario tendrá en su perfil la issue con las últimas actualizaciones. Así, cada usuario puede crearse una lista propia de issues para observar su avance y/o abordarlas con comentarios o parches.

Una vez que encontramos una issue que podemos abordar, nos ponemos manos a la obra y aportar nuestro primer parche. Vamos a detallar cómo subir un parche al core (cuyo proyecto es Drupal Core). Más adelante veremos que contribuir en módulos o temas contribuidos es prácticamente lo mismo.

 

SUBIR UN PARCHE AL CORE

El primer paso que tenemos que realizar es asignarnos las issue, con el fin de que en la comunidad sepan que estás trabajando en ella. El estado de la issue debe ser ‘Needs Work’, y podemos activarlo nosotros mismos.

Una vez asignada, necesitamos clonarnos la versión del repositorio en nuestra máquina. Normalmente lo haremos en una máquina virtual vacía, para trabajar sin correr peligro. Accediendo pues, a nuestra máquina, nos colocamos en el directorio raíz donde vamos a instalarnos nuestro Drupal, y clonamos la versión del proyecto que se detalla en la issue:

cd /var/www/html/
git clone --branch 8.6.x http://git.drupal.org/project/drupal.git
cd drupal

Hemos supuesto que nuestra máquina es en base linux (ubuntu 16.04) y usamos la ruta /var/www/html/ como directorio raíz. La versión escogida es la 8.6.x, ya que actualmente es la versión que se encuentra en desarrollo.

Una vez que tenemos nuestro proyecto Drupal instalado y configurado, ya podemos ponernos manos a la obra. Nos creamos una rama en git para realizar nuestro parche (se recomienda usar el número de la issue y una breve descripción como nombre de la rama) y nos colocamos en ella, identificamos nuestras modificaciones, las aplicamos y testeamos que todo funcione conforme a lo que estamos buscando:

git branch [issue-number]-[issue-description]
git checkout [issue-number]-[issue-description]
/* realizamos los cambios pertinentes */

Una vez hemos finalizado nuestros cambios y hemos comprobado que hemos resuelto la issue, ya podemos crear nuestro parche. Para subir un parche a la comunidad Drupal existe una convención de nombres que hay que respetar: descripción de la issue, número de la issue y número de comentario deben ir en ese orden en el archivo .patch. El número de la issue lo encontramos en la propia URL, siendo el número marcado en negrita en el ejemplo (http://drupal.org/node/1266348). El proceso quedará de la siguiente manera:

git status
/* Observamos los ficheros en los cuales hemos realizado cambios */
git diff 
/* Nos muestra los cambios realizados conforme al repositorio */

Si estamos conformes con los cambios realizados, exportamos las diferencias a nuestro parche, reseteamos el repositorio y aplicamos el parche, para comprobar que al aplicarlo todo funciona correctamente:

git diff > [issue-description]-[issue-number]-[comment-number].patch
git reset --hard 
/* Resetea los cambios realizados en la rama, pero no borra el parche */
git apply -v [patch-name].patch
/* Aplica el parche */

Una vez comprobado de forma definitiva que el parche funciona correctamente, ya podemos subirlo a la issue. Es tan fácil como realizar un nuevo comentario adjuntando nuestro parche, cambiando el estado a ‘Needs Review’ y quitando nuestra asignación a la issue. Desde ese momento estaremos a la espera de que la comunidad compruebe nuestro parche.

Con un poco de suerte, en la comunidad se aceptará el parche y el estado de la issue pasará a Reviewed & Tested By the Community (RTBC), estado previo a ser archivada como Fixed y recibir el usuario su acreditación.

 

 

¿PUEDO MEJORAR LA CONTRIBUCIÓN DE OTRO USUARIO O AÑADIR MI PROPIO CÓDIGO?

Como ya comentamos, el proceso de aplicación de un parche a un módulo o un tema contribuido es prácticamente idéntico al del core. La diferencia es que hay que instalar el módulo/tema en cuestión en nuestra máquina. Los del core vienen instalados por defecto.

Normalmente las issues de módulos que nos van a interesar son las de los módulos que usamos en nuestros proyectos. También podemos usar la máquina creada en el punto anterior, abriendo una rama en el repositorio principal por cada parche que vayamos a generar. Incluyendo el módulo o el tema sobre el que vamos a trabajar (mediante composer en el directorio raíz del proyecto), el procedimiento es exactamente el mismo que el anterior:

composer require drupal/project

La principal diferencia a la hora de que un parche sea aceptado (o no) en un proyecto contribuido, es que los autores o mantenedores del proyecto (módulo o tema) son los que realizan la revisión y la actualización con los parches. Por tanto, el proceso puede ser mucho más rápido o mucho más lento que el subir un parche al core.

Pero, ¿cómo encuentro las issues del módulo que necesito? Pues hay dos opciones: ir a la lista de issues y filtrar por el nombre del módulo, o acceder a la página del módulo.

Comunidad Drupal - module - SDOS

 

La presentación del módulo presenta la siguiente información:

  1. Información del módulo: dependencias, formas de descarga, actualizaciones, cómo configurarlo, etc.
  2. Usuarios que mantienen el módulo con los commits que han realizado cada uno.
  3. Información extra: listado de issues (abiertas y las totales), reporte de errores (bug report) y estadísticas del módulo.

¿Y si quiero aportar mi propio módulo o mi propio tema al repositorio de Drupal? Pues el proceso es algo diferente, ya que se trata de un proyecto completo. En el blog de SDOS explicamos hace unos meses el proceso a seguir para contribuir un módulo, así que no dudes en echarle un vistazo.

 

 

¿QUÉ GANO AL CONTRIBUIR EN LA COMUNIDAD DRUPAL?

Como recoge el dicho popular: ‘nadie da duros a pesetas’. Si lo trasladamos a las generaciones actuales, podríamos decir que ‘nadie da euros a céntimos’. Por tanto, Drupal debe ofrecer algo como moneda de cambio a las aportaciones a la comunidad. Esta moneda es la acreditación en el proyecto donde realiza la aportación, el cual aporta prestigio dentro de la comunidad.

Pero, ¿qué tipos de acreditaciones hay?

  • En issues. Son los créditos principales, los que recogen qué aportaciones (abrir una issue o subir un parche) ha realizado el usuario en Drupal. Estos créditos se guardan para siempre, pero en el perfil del usuario sólo aparecen las issues acreditadas en el último año. Para acceder al histórico del usuario existe un enlace donde se recogen todas las issues donde éste ha participado. En la imagen del perfil de usuario vista anteriormente se resaltan las contribuciones realizadas.
  • Por documentación. Al ampliar, añadir o modificar documentación oficial de Drupal, se recibe un crédito distinto. Estos créditos no referencian directamente al campo de documentación que se ha contribuido, sólo especifican que se ha realizado dicha contribución.
    Comunidad Drupal - documentacion - SDOS
  • Por traducciones. Al ampliar, añadir o modificar traducciones en Drupal, se recibe un crédito de traducción en la web derivada de traducciones. Estos créditos no referencian directamente a la traducción realizada, sólo especifican que se ha realizado dicha traducción. En el perfil de Drupal.org no aparecen estas contribuciones. Por ello los usuarios suelen referenciar sus perfiles en localize.drupal.org, donde tienen las traducciones acreditadas.
    Comunidad Drupal - traslations - SDOS

El único tipo de aportación a la comunidad Drupal que no genera créditos es el foro. Este funciona como centro de consultas y ayudas.

Comunidad Drupal - forum - SDOS

 

 

UN GIGANTE DE CÓDIGO ABIERTO

Si aún no estás convencido, puedes echarle un vistazo a la lista de webs populares recogida por Dries Buytaert.

A día de hoy, la herramienta se consolida como una de las grandes en el desarrollo web, con una comunidad Drupal cada vez más activa, con muchísimo por implementar y con funcionalidades casi infinitas. ¿Te atreves con ello?

 

 


Cómo contribuir a la comunidad un módulo en Drupal 8

El objetivo de este post es explicar, desde un punto de vista práctico, el procedimiento que debemos seguir si queremos contribuir con la comunidad de Drupal con una funcionalidad específica que hayamos desarrollado previamente. O dicho de otra forma, cómo podemos contribuir con nuestro módulo a la comunidad.

Para ello, y aunque tengamos ciertas prisas en ver nuestro flamante módulo subido a Drupal.org y disponible para su descarga por parte de otros usuarios, debemos ser conocedores de las políticas y procedimientos de publicación, especialmente desde la publicación de la versión 8 de Drupal, que ha acarreado cambios importantes en los procesos involucrados en la aceptación y publicación de un módulo.

 

SECURITY ADVISORY OPT-IN

En versiones anteriores de Drupal, para la publicación directa de un módulo necesitábamos previamente la revisión y valoración por parte de miembros de la comunidad de nuestro código, de forma que existieran ciertas garantías provenientes del criterio de usuarios experimentados y evitar así que el repositorio de módulos contribuidos se convirtiera en un peligroso cajón de código poco eficiente.

Esto tenía un inconveniente importante: a veces este proceso se demoraba en el tiempo, penalizando el incremento de módulos contribuidos por parte de usuarios. Además, en ocasiones, ocurría que durante este proceso de revisión se creaban módulos con funcionalidades similares, ya que en el momento de su escritura por parte de otros usuarios no existían módulos disponibles por estar aún en la cola de espera. Para evitar esto, se creó la Security Advisory Opt-in.

Básicamente, este nuevo sistema consiste en un proceso más permisivo de publicación. Se permite la difusión y descarga de forma directa por parte de los usuarios desarrolladores. Aunque a priori parezca que se evita el sistema de revisión pertinente que garantizaba la calidad y eficiencia de los desarrollos, queda reflejado en la ficha de cada módulo publicado si este ha sido revisado por parte de usuarios experimentados en la comunidad. En caso no ser así, aparece este mensaje:

 

En el momento de publicación de este post, podemos ver varios ejemplos:

Sin embargo, si accedemos a la ficha de descarga de módulos que sí han pasado este proceso de revisión, o su creador ya había pasado previamente por este proceso en otro módulo anterior, lo vemos reflejado con el siguiente símbolo:

 

Algunos ejemplos de módulos sobradamente conocidos son:

Más adelante ampliaremos información sobre los procesos necesarios a seguir para superar este proceso y que nuestro módulo cuente con nuestro sello de calidad. Ahora, suponiendo que ya tenemos nuestro código fuente listo para su publicación, ¡entremos en materia!

 

BECOME A ‘CONFIRMED’ USER

En primer lugar, como no podía ser de otra forma, tenemos que crearnos un perfil en Drupal.org.

Al igual que existe una política de publicación de módulos, para evitar el uso indiscriminado de spam por parte de robots en Drupal.org, existe una política de validación del perfil de los usuarios. De esta forma, tenemos que conseguir el rol “Usuario confirmado” antes de seguir con nuestro proceso de publicación.

No es un proceso complejo, simplemente basta con postear algún contenido en Drupal.org y los robots de Drupal se encargarán de asignarnos el rol directamente. Tienes más información aquí.

 

OBTAINING GIT ACCESS

Antes de subir código fuente al repositorio de Drupal, necesitamos acceso al propio Git. Para ello, basta con seguir estas instrucciones.

 

PUBLICANDO NUESTRO CÓDIGO FUENTE

Es importante hacer un ejercicio de reflexión antes de publicar nuestro primer módulo:

  • ¿Existe un módulo parecido que haga algo similar a lo que voy a publicar?
  • ¿He comprobado si más que un módulo, estoy desarrollando una funcionalidad adicional a un módulo ya existente? De ser así, a lo mejor es más interesante hacerme co-maintainer de un módulo ya existente. Aquí puedes encontrar más información al respecto.

 

SANDBOX

Para la publicación de nuestro módulo, tenemos dos caminos diferentes:

  1. Creación de un Sandbox que nos permite testear nuestro código sin necesidad de que éste se publique directamente en la comunidad. Este es el camino recomendado antes de convertir nuestro módulo en Full Project.
  2. Full Project. De esta forma, nuestro módulo quedaría expuesto directamente a la comunidad para su descarga de forma inmediata. Si no estamos completamente seguros de que nuestro módulo haya pasado todos los criterios de validación necesarios, evitaría este camino.

Una vez que tenemos claro que nuestro camino pasa por crear previamente un Sandbox, accedemos directamente a la URL de publicación del mismo.

En este formulario nos solicitarán información sobre el módulo: nombre, descripción, tipo de proyecto (es importante que, de momento, indiquemos que se trata de un Sandbox), categoría, tipo de mantenimiento, etc.

 

Una vez hayamos completado el formulario de creación de nuestro Sandbox, estamos listos para subir nuestro código. Para ello, sin entrar en profundidad, hacemos clic en la pestaña ‘Version Control’ de nuestro Sandbox, donde encontraremos información detallada sobre los comandos necesarios para pushear nuestro código al repositorio de Drupal:

Si no tienes claro el sistema de convenciones utilizado por Drupal.org para el versionado de tu módulo, puedes ampliar más información aquí.

 

 

FULL PROJECT

Durante el proceso de conversión de Sandbox a Full Project, debemos asegurarnos, entre otras cuestiones, que la calidad de nuestro código cumpla con el coding standard de Drupal. Además debe cumplir otro tipo de requisitos como las instrucciones de instalación, la descripción detallada de la funcionalidad que lleva a cabo nuestro módulo, etc.

Para ello, podemos hacer uso de varias herramientas.

La herramienta pareview.sh se encargará de revisar el coding standard y las buenas prácticas de Drupal, simplemente con indicar el repositorio Git de nuestro Sandbox, mostrando los posibles errores encontrados mediante un informe. Esta herramienta utiliza Code Sniffer para analizar el código PHP, haciendo uso de las métricas de Drupal incluidas en la herramienta Coder.

Si estamos seguros de que hemos cumplido con todos los requisitos indicados anteriormente y estamos listos para publicar nuestro módulo, es hora de convertir nuestro Sandbox en Full Project. Para ello, editamos nuestro Sandbox:

 

Y hacemos clic en la pestaña ‘Promote’:

 

Completamos el formulario asegurándonos de ingresar un nombre corto para nuestro módulo. Este nombre se usará para construir la URL: drupal.org/project/[short name]. En los módulos de sandbox, el nombre abreviado será el ID del proyecto. Así que es importante que este nombre sea descriptivo de la funcionalidad que cumple nuestro proyecto.

Una vez que nuestro Sandbox ha sido promocionado, el repositorio de código pasa de /sandbox/username/123456.git a project/project_name.git. Esto implica que tengamos que hacer de nuevo un clone de nuestro proyecto en nuestro entorno local si queremos seguir haciendo modificaciones del código.

Es hora de ver con qué tipo de release queremos salir a “producción”. Para ello, en Drupal podemos distinguir tres tipos de releases oficiales (las releases de desarrollo quedan para las versiones inestables que están actualmente en evolución por parte de los mantenedores):

  • Versión recomendada. En este caso, el mantenedor del proyecto (o sea, nosotros) considera que esta es la versión más estable para su descarga.
  • Release soportada. Para aquellos casos en los que el desarrollador piensa que es posible que no sea la mejor opción, ya sea porque la release es o muy nueva o muy antigua.
  • Versión no soportada. Por alguna razón, el mantenedor del módulo ha considerado que no es la versión más apropiada.

Aquí tienes más información sobre los tipos de release.

Así que vamos a crear nuestra primera release. Una vez la completemos, podremos decidir si pasarla a una release oficial o bien seguimos en la versión de desarrollo porque queramos seguir evolucionando el módulo. En cualquier caso, primero es necesario que creemos un tag con la release adecuada y la pusheemos a nuestro repositorio de Git de Drupal.org.

 

CREANDO NUESTRA RELEASE OFICIAL

En la ficha de nuestro Full Project, hacemos clic en la pestaña ‘Version control’ y seguimos las instrucciones indicadas en ‘Tag for a stable release’.

Una vez que hemos realizado el push de nuestra release, volvemos a la página principal de nuestro proyecto y hacemos clic en ‘Add new release’ (abajo del todo):

 

Si el nombre del tag creado ha seguido las convenciones comentadas anteriormente, el sistema nos pedirá la naturaleza de la release (New Feature, Bug, etc.). Damos a guardar y tendremos listo nuestro primer archivo descargable para su uso (ten en cuenta que el sistema puede tardar hasta 12 horas en disponer del archivo y, por lo tanto, del enlace para su descarga, así que no hay que impacientarse en este punto).

Además, recientemente se ha cambiado la política de publicación de releases, y ahora únicamente aparecen para su descarga directa las releases estables (y no las de desarrollo). Si quieres que aparezcan también las release de desarrollo, haz click en ‘Show in project’s download table when branch is supported’.

Desde este momento, ya tenemos nuestro primer módulo publicado y listo para su descarga por parte de terceros. Sin embargo, y para nuestra desgracia, vemos que nuestro módulo no está cubierto por la Security Advisory Policy. ¿Recordáis la política de publicación con la que hemos empezado este artículo? Pues bien, es hora de intentar conseguir nuestro sello.

 

SECURITY ADVISORY POLICY

Hay que tener en cuenta que esta marca solo afecta a versiones estables (ni alpha, ni beta, ni RC). Para aplicar el sello de “seguridad”, en la edición del proyecto hay que activar la opción ‘opt-in’, sin embargo no vamos a poder si no tenemos el rol adecuado (git vetted role).

Para obtener los permisos y poder acceder a esta opción, un administrador de Git de Drupal debe concedérnoslo. Para ello, debemos crear una issue de revisión que servirá para que otros usuarios puedan revisar nuestro módulo y marcarlo como apto. Aquí puedes seguir las instrucciones precisas para hacerlo.

Cuando un miembro de la comunidad nos marque el proyecto como RTBC. nuestro proyecto entrará en una lista de revisión para que un administrador nos conceda el rol vetted user y así poder marcar nosotros mismos nuestros proyectos como ‘opt-in’.

Existen dos listas de revisión de módulos:

  • Lista normal. Tarda muchísimo en ser evaluada por la comunidad (meses o años)
  • Lista prioritaria. Para acceder a esta lista tenemos que acceder al programa Review Bonus.

 

REVIEW BONUS

Si queremos priorizar nuestro post de revisión y garantizar que nuestro módulo obtiene el sello de calidad lo antes posible, tenemos que empezar a contribuir en la comunidad, y qué mejor que hacerlo a través del programa Review Bonus de Drupal.org.

Este programa consiste básicamente en ayudar a la comunidad de voluntarios de Drupal.org a revisar módulos de otros contribuidores que se encuentran en una situación similar a la nuestra. De esta forma, el sistema de Review bonus nos invita a revisar, al menos, hasta 3 módulos de otras personas que están en un proceso similar. De esta forma podemos encontrar los mismos fallos de seguridad en el código que podrían encontrar en nuestro módulo.

Debido a que el proceso de solicitud es completamente voluntario, muchos de los revisores más activos usan el programa Review Bonus para priorizar qué módulos revisan. Este programa le da prioridad a aquellos que también están ayudando a revisar otras aplicaciones.

Para comenzar el proceso de revisión de un módulo, accedemos a la ‘Lista normal’ mencionada anteriormente. Existe una plantilla que podemos tener como referencia para saber qué tenemos que revisar. Cada vez que encontramos algún error en alguno de los módulos de esta lista, realizamos un post en el hilo, copiamos la URL de nuestro post y lo referenciamos en el body del post de revisión que hemos creado para que nos validen nuestro propio módulo.

Una vez que hayamos revisado y referenciado tres incidencias en nuestro post de revisión del módulo, editamos nuestro propio post y le añadimos el tag ‘PAReview: review bonus’ en el campo ‘Issue Tags’ en el formulario de comentarios de nuestro post. Desde este momento, nuestro post de revisión estará en la lista prioritaria.

Aquí tenemos un post de ejemplo de un desarrollador que ha revisado a su misma vez otros tres posts. De esta forma podemos ver la estructura que debería tener nuestro post de revisión.

Finalmente, algún administrador de la comunidad de Drupal revisará nuestro módulo y nos concederá el rol necesario para que podamos conceder nosotros mismos los sellos de seguridad a los módulos que desarrollemos a partir de ahora sin tener que volver a pasar por este proceso.

 

DRUPAL EN SDOS

Desde SDOS impulsamos el desarrollo y la contribución a la comunidad a través de nuestros equipos multidisciplinares, estableciendo metodologías ágiles de desarrollo y siendo fieles tanto al coding standard establecido a través de la comunidad de Drupal como a sus buenas prácticas de desarrollo. Así mismo, en SDOS estamos comprometidos con la comunidad, colaborando con la Drupal Association y apostando por los diferentes eventos desarrollados a nivel nacional.


Uso de cookies

Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continúas navegando estas dando tu consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pincha el enlace para obtener más información.

ACEPTAR
Aviso de cookies