D8

Crear bloques por código en Drupal 8

root — Fri, 23 Aug 2019 12:08:55 +0000

Crear bloques por código en Drupal 8

Viernes, Agosto 23, 2019 - 14:08

En Drupal los bloques son una de las principales herramientas de que disponemos para mostrar distintos componentes o contenidos, y colocarlos en la página en distintas posiciones. Drupal viene con una serie de bloques por defecto, y cada módulo puede definir sus propios bloques, así que una de las cosas básicas de trabajar con Drupal pasa por aprender a crear nuestros propios bloques.

Empezaremos por lo básico y luego lo complicaremos un poco para tocar algunos conceptos más interesantes.

Creando un bloque sencillo

Lo primero que vamos a necesitar es crear un nuevo módulo (o utilizar uno que ya tengamos) e instalarlo, para tener un sitio donde meter nuestro código.

En Drupal 8 todos los bloques son instancias de la clase Plugin, y el gestor de bloques (Block manager) se encargará de encontrar los bloques que hayamos definido por medio de anotaciones de PHP en nuestras clases.

Primero crearemos la clase para nuestro bloque en un archivo dentro de nuestro módulo, que deberá estar en el directorio

src/Plugin/Block

El nombre del archivo debe coincidir con el nombre de la clase, o no funcionará. Por ejemplo, vamos a crear un bloque HolaMundo, por lo que crearemos el siguiente archivo:

src/Plugin/Block/HolaMundo.php

Con el siguiente código:

<?php

namespace Drupal\hola_mundo\Plugin\Block;

use Drupal\Core\Block\BlockBase;

/**
 * Clase de control del bloque HolaMundo.
 *
 * @Block(
 *   id = "hola_mundo",
 *   admin_label = @Translation("Hola mundo"),
 *   category = @Translation("Hola mundo"),
 * )
 */
class HolaMundo extends BlockBase {

  /**
   * {@inheritdoc}
   */
  public function build() {
    return [
      '#markup' => $this->t('Hola mundo!'),
    ];
  }

}

Ahora debemos limpiar la caché, y ya podremos añadir nuestro nuevo bloque a una página desde el menú Estructura > Diseño de bloques, y colocarlo en la región que queramos.

Como veis, nuestra clase extenderá de BlockBase, debemos poner las anotaciones de PHP (id, admin_label y category), y solamente tenemos que implementar el método build() que tiene que devolver un array para ser renderizado. Si utilizamos #markup, podemos devolver ahi todo el código HTML que queramos que pinte nuestro bloque.

Usando templates para nuestros bloques

Como en la mayoría de los casos lo que queremos pintar en el bloque no será algo tan sencillo como este ejemplo, es buena idea definir un template, de forma que podamos separar la lógica de la presentación, y evitemos tener que meter todo el HTML de esta forma dentro de #markup, que es bastante poco elegante, por decir algo suave.

Configurar un template o plantilla para nuestro nuevo bloque es bastante sencillo. La forma mas simple no requiere prácticamente nada, y aunque he visto muchos ejemplos donde dicen que es necesario implementar un hook_theme(), esto no es estrictamente necesario.

Primero vamos a hacer unas modificaciones en nuestra función build() del bloque que acabamos de crear para pasarle algunas variables al template, y evitar meter código HTML en nuestras clases PHP. Ahora en vez de devolver todo dentro de #markup, pasaremos distintas variables a las que asignamos el nombre que queramos, en este caso serán title y description, pero podemos llamarlas como queramos:

/**
 * {@inheritdoc}
 */
public function build() {

  return [
    'title' => t('Hola mundo!'),
    'description' => t('Esto es un bloque que pinta un hola mundo'),
  ];
}

Listo, sigamos adelante. Solamente con lo que tenemos hasta ahora, Drupal asignará por defecto ciertos templates para aplicar a nuestro bloque. Si activamos el theme debug, podremos ver los nombres de fichero que Drupal buscará dentro del tema que tengamos activo, que para nuestro caso son estos:

<!-- FILE NAME SUGGESTIONS:
   * block--holamundo.html.twig
   * block--hola-mundo.html.twig
   * block--mimodulo.html.twig
   x block.html.twig
-->

Drupal utilizará el template de bloque por defecto block.html.twig cuando ninguno de esos otros ficheros existe.

Entonces solo tenemos que crear el archivo de template para el bloque dentro de nuestro tema, usando alguno de esto nombres para el fichero. Es buena idea crear un directorio dentro del tema llamado templates/block, para tenerlos mejor organizados:

themes/custom/nuestro_tema/templates/block/block--hola-mundo.html.twig

Y dentro de este template utilizaremos las variables que hemos definido en build() para mostrar la información:

{#
/**
 * @file
 * Hola mundo block.
 */
#}
<div class="wrapper hola-mundo--block">
  <h1>{{ content.title }}</h1>
  <p>{{ content.description }}</p>
</div>

Importante aquí que nuestras variables deben prefijarse con content.nombre_de_variable, o no veremos ningún resultado.

No queda más que borrar caches y probar nuestro nuevo bloque.

Comments

Veo que sigues dándole al…

Veo que sigues dándole al Debian. Me sonaba que te habías cerificado en RedHat o algo así.
Comentario Certified by DAI™.
:-P

Un saludo tron que se me ha…

Un saludo tron que se me ha olvidao en el otro mensaje!!

Añadir nuevo comentario

Importando metatags con Drupal 8 y Migrate

root — Fri, 12 Oct 2018 18:11:26 +0000

Importando metatags con Drupal 8 y Migrate

Viernes, Octubre 12, 2018 - 20:11

Migrate

Drupal

Estoy en mitad de un proyecto en el que estamos importando a Drupal 8 contenidos que vienen de un repositorio central, y se consumen usando una API REST en formato JSON.

Hasta ahora esta funcionando bastante bien y sin muchos dolores de cabeza, pero tratando de importar los metadatos que vienen con nuestros contenidos a los campos que trae el módulo Metatag he tenido que pegarme un poco hasta dar con la solución.

Actualmente (octubre de 2017), el módulo Metatag no tiene soporte para Migrate en forma de plugins. Hay un ticket abierto desde hace tiempo, con varios parches disponibles, pero aún no está completo. Lo bueno es que en ese mismo hilo hay un par de personas que cuentan como lo han hecho sin necesitar el parche, que era justo lo que yo intentaba, pero se me estaba escapando un detalle: serializar.

Para esta importación estamos usando los siguientes módulos:

migrate: en el core de Drupal
migrate_tools: en contrib
migrate_plus: en contrib

Para importar contenido usando migrate_plus vamos a necesitar una serie de componentes:

Un archivo YML de control para la migración, donde especificaremos el tipo de proceso, los campos entrada y salida
Un plugin de importación de contenido, que será una clase que extienda de SourcePluginBase, y donde podremos hacer algunas transformaciones.
Lo normal será que hayamos creado un módulo custom para controlar toda nuestra importación.

No me quiero meter mucho en detalle de cómo se hace la importación usando migrate_plus, porque quiero escribir un artículo entero para ello, así que me voy a centrar en importar los metadatos.

Primero el archivo YML que controla la importación en mi módulo, migrate_plus.migration.json_page.yml:

id: json_page
label: 'JSON migration for content type: Page'
migration_group: my_group
source:
  plugin: json_page
  cache_counts: true
  high_water_property:
    name: changed
destination:
  plugin: entity:node
  bundle: page
process:
  uuid: uuid
  langcode: language
  type:
    plugin: default_value
    default_value: page
  title: title
  created: changed
  changed: changed
  'body/format': 'body/format'
  'body/value': 'body/value'
  'body/summary': 'body/summary'
  'field_page_teaser/format': 'teaser/format'
  'field_page_teaser/value': 'teaser/value'
  'path/alias': alias
  'promote/value':
    plugin: default_value
    default_value: 0
  field_meta_tags: meta_tags

# use forced module dependency so uninstall/reinstall works properly
dependencies:
  enforced:
    module:
      - my_module_name

Lo pongo entero por si ayuda para ver como estoy importando otros campos, pero lo importante es esta línea para los metadatos:

field_meta_tags: meta_tags

Esta línea va a intentar importar los metadatos desde un campo 'meta_tags' en el origen (el source), a un campo llamado field_meta_tags, que ya hemos creado en nuestro tipo de contenido, en este caso page, y que es de tipo Meta tags.

En mi caso, los metadatos vienen en JSON que representa un nodo en este formato. Atención al detalle de que es 'metatags', no 'meta_tags':

    "metatags":{  
      "title":"a simple node title | [site:name]",
      "og:title":"a simple node title",
      "twitter:title":"a simple node title",
      "description":"a simple description",
      "og:description":"a simple description",
      "og:updated_time":"2018-08-27T08:40:34-04:00",
      "article:published_time":"2017-04-13T04:26:00-04:00",
      "article:modified_time":"2018-08-27T08:40:34-04:00",
      "twitter:description":"a simple description",
      "canonical":"[site:url][current-page:url:path]",
      "og:site_name":"[site:name]",
      "og:type":"article",
      "og:url":"[site:url][current-page:url:path]",
      "twitter:card":"summary",
      "twitter:url":"[site:url][current-page:url:path]"
    },

Como veis ya vienen con tokens que Drupal va a entender, asi que genial. Lo que vamos a hacer es utilizar el plugin que hemos definido para esta importación (json_page) para coger estos datos que vienen en el source de la importación como 'metatags', darles el formato adecuado, y colocarlos en 'meta_tags', que es lo que espera el proceso de migración, definido en el archivo YML de antes.

Este es el código de mi plugin:

class MyJsonPlugin extends SourcePluginBase {

  public function prepareRow(Row $row) {

    // Set URL alias.
    $alias = $row->getSourceProperty('alias');
    if (!empty($alias)) {
      $row->setSourceProperty('alias', '/' . $alias);
    }

    // Set meta tags.
    $row->setSourceProperty('meta_tags', $row->getSourceProperty('metatags'));

    return parent::prepareRow($row);
  }

  protected function processMetaTags($data) {
    $metatags = [];

    if ($data) {
      foreach ($data as $key => $value) {
        $transforms = [
          'twitter:card' => 'twitter_cards_type',
          'twitter:url' => 'twitter_cards_page_url',
          'twitter:description' => 'twitter_cards_description',
          'twitter:site' => 'twitter_cards_site',
          'twitter:site:id' => 'twitter_cards_site_id',
          'twitter:creator' => 'twitter_cards_creator',
          'twitter:creator:id' => 'twitter_cards_creator_id',
          'twitter:title' => 'twitter_cards_title',
          'canonical' => 'canonical_url',
          'og:url' => 'og_url',
          'og:title' => 'og_title',
          'og:site_name' => 'og_site_name',
          'og:type' => 'og_type',
          'og:description' => 'og_description',
          'og:image' => 'og_image',
          'og:image:url' => 'og_image_url',
          'og:image:secure_url' => 'og_image_secure_url',
          'og:image:type' => 'og_image_type',
          'article:published_time' => 'article_published_time',
          'article:modified_time' => 'article_modified_time',
        ];

        if (array_key_exists($key, $transforms)) {
          $key = $transforms[$key];
        }

        if ($value) {
          $metatags[$key] = $value;
        }
      }
    }

    if (!$metatags) {
      return NULL;
    }

    return serialize($metatags);
  }

...

}

Básicamente hay dos funciones importantes: en prepareRow, cogemos los metadatos desde 'metatags' que tiene el JSON, los formateamos y los volvemos a dejar bien bonitos en 'meta_tags', y en la función processMetaTags los procesamos y serializamos.

Aquí hay dos cosas a tener en cuenta:

Mis datos de origen en el JSON, vienen con los nombres de campo de Drupal 7, por ejemplo twitter:card, y los nombres de los campos de Drupal 8 son diferentes, por eso en la función processMetaTags revisamos las claves las cambiamos por las que corresponden. En esta lista no están todas las posibles pero sí las más importantes. Intentaré actualizarla en el futuro cuando la tenga completa.
Una vez construido el array con los meta datos, tenemos que serializarlo (función serialize de PHP) antes de llamar a setSourceProperty, porque si no lo hacemos, los datos no se guardarán correctamente.

Y esto es todo amigos, si teneis alguna idea mejor o algún problema podéis dejar una nota en los comentarios.

Referencias

El artículo original con el que empece a jugar con Migrate: https://www.metaltoad.com/blog/drupal-8-migrating-data-json-files
El ticket del modulo Metatags para incluir los plugins de Migrate: https://www.drupal.org/node/2563649

Comments

Migración Meta tags

Hola Carlos, te quería agradecer tu articulo.

Te he encontrado a partir del ticket de Metatags (https://www.drupal.org/node/2563649). Te has ganado un follower! :-D

Saludos!

Añadir nuevo comentario

Como añadir Google Fonts a nuestro tema de Drupal 8

root — Mon, 30 Oct 2017 11:05:04 +0000

Como añadir Google Fonts a nuestro tema de Drupal 8

Lunes, Octubre 30, 2017 - 12:05

Drupal

Esta es la mejor forma de añadir fuentes de Google en vuestro tema de Drupal 8 sin tocar un template.

Primero, incluimos en nuestro fichero nuestro-tema.info.yml:

libraries:
  - 'bs_css/fonts'

Después, incluimos las fuentes en el archivo nuestro-tema.libraries.yml:

fonts:
  css:
    theme:
      '//fonts.googleapis.com/css?family=Coda:regular,800|Comfortaa:regular,700,300|Raleway:regular&subset=latin-ext': { type: external, minified: true }

Es una buena práctica agrupar todas las fuentes en la misma llamada, en lugar de poner una entrada para cada fuente, ya que nos ahorraremos algunas peticiones HTTP.

Si no podeis tocar código (o no quereis), existe un módulo llamado @font-your-face, que nos permite añadir y configurar fuentes de varios proveedores, no solo Google, desde la interfaz de administración de Drupal.

Añadir nuevo comentario

Bootstrap + Less + Gulp para Drupal 8

root — Mon, 16 Oct 2017 19:19:41 +0000

Bootstrap + Less + Gulp para Drupal 8

Lunes, Octubre 16, 2017 - 21:19

Gulp.js es un gestor de tareas en Javascript que nos va ayudar a automatizar tareas repetitivas en nuestro proyecto Drupal. Una de las que mas vamos a repetir mientras estamos desarrollando es compilar el tema para generar el CSS si estamos utilizando un preprocesador como SASS o Less, con el tema de Bootstrap, por ejemplo, o con nuestro propio tema 'custom'.

Añadir Gulp a nuestro tema para compilar nos proporciona unas cuantas ventajas, entre las que podemos destacar:

Recompilar el tema automáticamente cada vez que modificamos un archivo less.
Y recargar automáticamente el navegador cuando cambia el CSS.
Minificar el CSS para mejorar el rendimiento.
Ejecutar test y chequear el código al compilar el tema, para controlar errores de sintaxis, estándares, etc.
Gestionar dependencias y minificar nuestros ficheros Javascript.
Realizar operaciones con ficheros: copiar, mover, borrar, etc.

Vamos a ver una forma sencilla y rápida que nos dará un buen punto de partida para comenzar a utilizar Gulp para compilar nuestro tema de Drupal 8 basado en Bootstrap. Yo estoy utilizando la versión normal que viene con Less por defecto. Si estáis usando SASS en vez de Less podéis darle un vistazo a este artículo (en inglés).

Si habéis seguido las instrucciones para crear un subtema de Bootstrap, ya tendréis una estructura parecida a esta:

DRUPAL_ROOT/themes/custom/vuestro_subtema
- less
  - style.less <-- Este el archivo principal Less para compilar el tema.
- css
  - style.css <-- Archivo CSS resultado de compilar el tema.

En este punto, y si no queremos complicarnos la vida, podremos compilar nuestro tema de forma sencilla con un comando llamando al compilador de Less:

lessc less/style.less > css/style.css

Yo tenía esta línea metida en un script bash sencillo llamado compile.sh, y lo ejecutaba cuando necesitaba compilar, así:

sh ./compile.sh

Pero claro, si estáis leyendo es que os va la marcha, así que vamos a ver cómo montamos Gulp en un periquete. Primero vamos a necesitar crear en la raíz de nuestro tema (subtema si usais Bootstrap), un archivo package.json para controlar las dependencias de Npm. Será muy sencillo:

{
  "name": "nombre_del_tema",
  "version": "0.0.0",
  "description": "Paquete para compilar subtema de Bootstrap con Gulp",
  "author": "nombre",
  "contributors": [
    {
      "name": "nombre",
      "email": "direccion@email.com"
    }
  ],
  "dependencies": {},
  "devDependencies": {},
  "license": "Private"
}

Obviamente vamos a necesitar tener instalado npm, ya que lo vamos a utilizar para instalar cómodamente todos los paquetes y dependencias que necesitamos.

Primero instalamos Gulp como paquete global para no tener problemas con el ejecutable:

npm install -g gulp

Una vez instalado, desde la raíz de nuestro tema, instalamos las dependencias y le decimos a npm que las añada a nuestro fichero package.json con el parámetro --save-dev:

npm install gulp gulp-less gulp-livereload gulp-sourcemaps gulp-watch --save-dev

Después de ejecutar este comando deberíamos tener un directorio node_modules con los paquetes que acabamos de instalar:

ll node_modules/

total 0
drwxr-xr-x  12 charles  staff  408 16 Oct 19:36 gulp
drwxr-xr-x   8 charles  staff  272 16 Oct 19:36 gulp-less
drwxr-xr-x  11 charles  staff  374 16 Oct 19:36 gulp-livereload
drwxr-xr-x   8 charles  staff  272 16 Oct 19:36 gulp-sourcemaps
drwxr-xr-x   7 charles  staff  238 16 Oct 19:36 gulp-watch

Y en nuestro archivo package.json se habrán incluido las dependencias (los números de versión pueden cambiar):

  "devDependencies": {
    "gulp": "^3.9.1",
    "gulp-less": "^3.3.2",
    "gulp-livereload": "^3.8.1",
    "gulp-sourcemaps": "^2.6.1",
    "gulp-watch": "^4.3.11"
  },

Ahora necesitamos crear el archivo de control para Gulp, llamado gulpfile.js, también en la raíz de nuestro tema, con lo básico para empezar a funcionar:

var gulp       = require('gulp');
var less       = require('gulp-less');
var watch      = require('gulp-watch');
var livereload = require('gulp-livereload');
var sourcemaps = require('gulp-sourcemaps'); 
 
gulp.task('less', function () {
  gulp.src('less/style.less')
    .pipe(sourcemaps.init())
    .pipe(less())
    .pipe(sourcemaps.write('.'))
    .pipe(gulp.dest('css'))
    .pipe(livereload());
});
 
gulp.task('watch', function() {
  livereload.listen();
  gulp.watch('less/*.less', ['less']);
}); 

gulp.task('default', ['watch']);

Con esto deberíamos poder ejecutar dos comandos para compilar:

gulp less

Que simplemente compilará el tema creando los CSS dentro del directorio css, o también:

gulp watch

Que dejará el proceso corriendo, vigilando modificaciones en nuestros archivos less y recompilando el tema si detecta algún cambio. Este comando se ejecutará por defecto si solo hacemos:

gulp

Vamos a ver en detalle que hemos metido en este fichero de control de Gulp:

Las líneas var van a cargar las dependencias que necesitamos.
- Gulp y gulp-less: Carga la libreria y la extension para less.
- gulp-watch: Carga el módulo para vigilar los archivos del tema.
- gulp-livereload: Carga el módulo livereload para automatizar la recarga del navegador. Para que funcione tenemos que instalar una extensión del navegador. Hay extensiones disponibles para Chrome, Firefox y Safari.
- gulp-sourcemaps: Carga el paquete para generar sourcemaps de nuestros ficheros CSS. Tal como está configurado creará un fichero .map separado en el mismo directorio /css. Estos ficheros sirven para ayudar en la depuración de nuestros estilos.
Tarea less:
- Compila el CSS, aplica el módulo de livereload y genera los sourcemaps necesarios.
Tarea watch:
- Activa el livereload y vigila los archivos con extension .less, dentro de la carpeta less por si cambian, lo que recompilará el tema completo.
Tarea default:
- Se ejecuta cuando corremos gulp sin parámetros, y por defecto lanzará la tarea watch.

Con estos sencillos pasos tendremos configurado Gulp en muy poco tiempo, y a partir de esta configuración inicial podremos ir ampliando e introducir otras mejoras o librerías en nuestro proyecto Drupal.

Referencias

Añadir nuevo comentario

Configuración en Drupal 8. Parte 2: Config Split

root — Sat, 07 Oct 2017 15:26:51 +0000

Configuración en Drupal 8. Parte 2: Config Split

Sábado, Octubre 7, 2017 - 17:26

Drupal

En esta segunda parte de la gestión de la configuración en Drupal 8, vamos a ver cómo podemos mantener diferentes configuraciones para cada entorno.

Si te has perdido la primera parte de este artículo, en ella vimos los principios básicos para gestionar la configuración de nuestros sitios con Drupal 8, y deberías darle un repaso antes de seguir con este.

Antes de empezar vamos a hacer un pequeño ejemplo y explicar cuales son los casos de uso.

El problema

En cualquier proyecto en el que tengamos varios entornos (integración, desarrollo, producción, etc.) es muy probable que queramos tener configuraciones distintas de nuestro sitio para cada uno de ellos, o varios, o uno solo. Por ejemplo:

Activar módulo Devel en el entorno de desarrollo. Este es el ejemplo típico.
Distinta configuración de URLs o IPs de servidores con los que tengamos integraciones. Por ejemplo, podemos tener un servidor LDAP para desarrollo y otro para producción.
Configuración específica para producción: caches, módulos de log, varnish, CDNs, etc.

Normalmente esto supone que tendremos un bloque de configuración gordo que será común a todos los entornos, pero también bloques específicos que sólo se aplicarán en algunos de ellos.

En principio, podríamos sobreescribir la configuración añadiendo líneas al archivo settings.php de los diferentes entornos que tengamos, así:

$config['system.logging']['error_level'] = 'verbose';

Para casos sencillos y concretos puede ser una solución válida, pero usar $config tiene varios inconvenientes:

No se puede añadir nueva configuración, solo modificar la ya existente.
No se puede hacer un unset, no se borrará la configuración.
No se pueden activar o desactivar módulos de esta forma.
El fichero settings sería complicado de mantener si empezamos a meter morralla.

Se va viendo ya donde está el problema, ¿verdad?

¿Que solución hay?

La gente de Nuvole ha estado desarrollando una serie de módulos que nos van a ayudar con este pequeño jaleo. Vamos a ver Config Filter, que va a ser la clave para solucionar el problema que acabamos de ver. La primera versión estable ha visto la luz hace bien poquito, y tuve la suerte de asistir a la conferencia que dió Fabian Bircher en Drupalcon Viena 2017, porque era exactamente lo que estaba buscando.

Usando Config Split vamos a poder agrupar y separar bloques de configuración, que podremos activar o desactivar en cada entorno, así como exportar o importar los ficheros desde directorios diferentes a nuestro sync. Este y otros módulos desarrollados también por Nuvole, necesitan el módulo Config Filter, como una dependencia en la que se basan.

Cómo funciona

Para cada bloque de configuración (Split) que configuremos vamos a poder indicar un directorio donde se guardarán los archivo de configuración de los componentes de ese Split. Mientras el Split esté activo, la configuración de sus componentes se exportará e importará siempre desde ese directorio.

Hay dos modos de funcionamiento para la configuración:

Split completo: Inicialmente se llamaba Blacklist o lista negra. Los componentes indicados aquí se gestionarán exclusivamente desde el Split, por lo que sus archivos de configuración se eliminarán del directorio Sync principal. En este modo podremos incluir módulos completos o bien componentes concretos de esos módulos.
Split condicional: Llamado inicialmente Graylist, con este modo la configuración de sus componentes no se elimina del Sync global, pero mientras el Split este activo, se importará y exportará al Split. Esto nos permite tener configuraciones alternativas por entorno. En este modo solo se nos permite incluir componentes específicos.

Además, para cada Split podremos definir un peso, de forma que si varios Splits definen la misma configuración, el peso marcará cual tiene prioridad.

Config Split incorpora dos nuevos comandos de Drush para manejar la configuración, son config-split-import y config-split-export:

drush csim

drush csex

Instalación

Lo primero que necesitamos hacer es instalar y activar los módulos:

drush dl config_filter config_split
drush en config_filter config_split

Una vez activados vamos a configurar el Split de la configuración. Vamos al panel de administración, en Inicio » Administración » Configuración » Development » Sincronizar, donde podemos comenzar a crear grupos.

En la imagen se puede ver un Split configurado que hemos llamado Dev, y que está activo en este entorno. Vamos a hacer el ejemplo sencillo de usar este Split para activar el módulo Devel en el entorno de desarrollo. Veámos la configuración básica de este Split en la siguiente imagen.

Indicamos la ruta física donde se van a guardar los archivos de configuración de este split, relativa a la raíz de Drupal. Le damos un peso e indicamos si está activo o no.

A continuación, y para este ejemplo, seleccionamos el módulo Devel en el bloque de Complete Split, para sacar completamente la configuración de este módulo de la general, ya que solamente vamos a querer activarlo en desarrollo.

Guardamos la configuración del Split, y para aplicarla tenemos que exportar, con Drush config-split-export:

drush csex

Cuando termine el comando, los archivos de configuración de Devel estarán en el directorio del split, y como los pusimos en el modo completo, serán eliminados del directorio Sync general. En mi caso, tengo algo así.

$ ll dev/

total 24
-rw-rw-r--  1 charles  staff  281  7 Oct 15:21 devel.settings.yml
-rw-rw-r--  1 charles  staff  279  7 Oct 15:21 devel.toolbar.settings.yml
-rw-rw-r--  1 charles  staff  283  7 Oct 15:21 system.menu.devel.yml

Ahora podemos ir a nuestro entorno de producción y desactivamos en nuestro entorno de producción este split, sobreescribiendo la configuración en el archivo settings.php del servidor:

// Desactivar configuracion de split de Dev
$config['config_split.config_split.dev']['status'] = FALSE;

Por supuesto que esto podemos hacerlo al revés, configurarlo como desactivado por defecto, y activarlo solamente en nuestro entorno de desarrollo, y en este caso puede que fuese la mejor opción, porque nos ahorraremos tocar nada de configuración en producción.

Flujo de trabajo

Esta es una lista básica de los pasos que vamos a necesitar para trabajar con esta configuración en varios entornos. Espero que ayude a clarificar el proceso.

En nuestro entorno local:

Obtener la base de datos de producción y bajarla a nuestro entorno local.
Borrar caches (drush cr).
Actualizar nuestro repositorio de control de versiones. La forma de hacer esto dependerá mucho de nuestro proyecto, pero básicamente lo que queremos es hacer un git pull.
Importar la configuración de Dev que hemos preparado. Al venir de producción ésta BD no tiene esa configuración (drush csim dev).
Comprobar si hay algún cambio de configuración que se haya hecho en producción, y si es así exportarlo para no perderlo (drush csex).
Guardar estos cambios en el control de versiones (git commit + git push).
Trabajar en las modificaciones de configuación que queramos hacer sobre nuestro entorno local.
Exportar nuestros cambios (drush csex).
Subirlos al control de versiones (git commit + git push).

En el entorno de producción:

Desplegar los cambios en los ficheros de configuración en el entorno de producción. Esto dependerá de la forma en que estemos trabajando. Puede ser tan sencillo como hacer un git pull, o desplegar con un Jenkins.
Importar la configuración con los últimos cambios. Si nuestro Config Split de Dev está desactivado en el settings.php, esa configuración no se importará (drush csim).

Conclusiones

Config Split es justo la pieza que me faltaba para poder hacer una gestión medianamente decente de la configuración en Drupal 8 para proyectos grandes, sin usar Features.

Hasta ahora me esta funcionando sin problemas y en general me gusta como se configura y trabaja con el. Recomiendo sin duda darle una oportunidad porque los chicos de Nuvole han hecho un gran trabajo,

Referencias

Añadir nuevo comentario

Related By Terms para Drupal 8

root — Tue, 03 Oct 2017 22:17:37 +0000

Related By Terms para Drupal 8

Miércoles, Octubre 4, 2017 - 00:17

Drupal

RelatedByTerms

Ayer publiqué la primera version estable de la rama 8.x de Related By Terms. La funcionalidad es prácticamente la misma que tiene la versión de Drupal 7, pero como podréis imaginar, he tenido que reescribir prácticamente todo el módulo. Lo único que se ha salvado, y de milagro es la query que estaba utilizando para obtener los nodos relacionados.

Para refrescar la memoria, este módulo nos da:

Un bloque que podemos colocar donde queramos que mostrará una lista de nodos relacionados con el que estamos viendo, ordenados por el número de coincidencias en términos de taxonomías.
Una página de configuración en el panel de administración donde podemos configurar el número de relacionados a mostrar y el Display mode que se usará para pintarlos.
En el caso de la versión para Drupal 8, un servicio que puede ser usado por otros módulos para obtener simplemente la lista de relacionados, para procesarlos de la manera más conveniente.

Por supuesto, tengo instalado el módulo en este sitio, es el bloque que podéis ver en la barra lateral derecha debajo del título 'Relacionado'.

Esta es la lista de los nuevos y flamantes componentes del módulo:

relatedbyterms/LICENSE.txt
relatedbyterms/README.md
relatedbyterms/relatedbyterms.info.yml
relatedbyterms/relatedbyterms.install
relatedbyterms/relatedbyterms.links.menu.yml
relatedbyterms/relatedbyterms.module
relatedbyterms/relatedbyterms.permissions.yml
relatedbyterms/relatedbyterms.routing.yml
relatedbyterms/relatedbyterms.services.yml
relatedbyterms/config/install/relatedbyterms.settings.yml
relatedbyterms/config/schema/relatedbyterms.schema.yml 
relatedbyterms/src/Form/RelatedByTermsForm.php
relatedbyterms/src/Plugin/Block/RelatedByTermsBlock.php
relatedbyterms/src/RelatedByTermsService.php
relatedbyterms/src/RelatedByTermsServiceInterface.php

Como podéis ver si habéis dado un vistazo al código de la versión 7, aquí hay bastante chicha para un módulo tan sencillo. Vamos a ver qué hace cada cosa:

Los archivos README.md y LICENSE.txt no creo que necesiten mucha explicación.
Archivo info.yml: Información básica del módulo.
El fichero install contiene una simple inicialización de permisos.
links.menu.yml: Define el elemento del menú de administración para acceder a la configuración del módulo.
En el archivo .module tan solo hay una implementación de hook_help() para mostrar un texto de ayuda.
permissions.yml tiene la definición de un permiso especial para acceder a la configuración.
routing.yml define una ruta para la página de administración, le asigna una clase de control para crear el formulario (RelatedByTermsForm) y comprueba que el usuario tenga el permiso necesario para acceder.
services.yml sirve para declarar un nuevo servicio relatedbyterms.manager, y le asigna una clase de control, RelatedByTermsService. Este servicio puede ser utilizado por otros módulos para obtener una lista de nodos relacionados a partir de un Nid.
Luego tenemos un directorio install, que guarda los archivos de configuración del módulo.
Y por fin en el directorio src, encontramos:
- RelatedByTermsForm: Controla el formulario de administración del módulo.
- RelatedByTermsBlock: Para definir el bloque que va a mostrar los contenidos relacionados.
- RelatedByTermsServiceInterface: Interfaz para la definición de los métodos del servicio.
- RelatedByTermsService: Clase que define el servicio. Esta clase contiene la lógica de negocio del módulo, y puede ser cargado desde otros módulos.

Espero que lo probéis. Cualquier comentario, peticiones, o si veis que he metido la pata en algún sitio, dejad un comentario, poneros en contacto conmigo, o mejor aún, crear un ticket en Drupal.org para el módulo.

Saludos

Añadir nuevo comentario

Como instalar composer en Debian 8

root — Sat, 30 Sep 2017 23:58:12 +0000

Como instalar composer en Debian 8

Domingo, Octubre 1, 2017 - 01:58

Debian

Drupal

Instalar composer en Debian 8 es muy sencillo:

$ cd /usr/src
$ sudo apt-get install curl php5-cli
$ curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer

Después podemos comprobar si se ha instalado correctamente:

$ composer --version

A día de hoy, este comando muestra:

Composer version 1.5.2 2017-09-11 16:59:25

Añadir nuevo comentario

Gestión de la configuración en Drupal 8

root — Sat, 23 Sep 2017 10:45:51 +0000

Gestión de la configuración en Drupal 8

Sábado, Septiembre 23, 2017 - 12:45

Drupal

Una de las novedades mas celebradas de Drupal 8 ha sido sin duda la nueva gestión de la configuración. Es un concepto clave para trabajar con Drupal profesionalmente, y que no existía de forma nativa en Drupal 7.

Para ilustrar el problema, vamos a verlo con un ejemplo. En cualquier proyecto de desarrollo con Drupal que se precie lo normal es mantener varios entornos:

Desarrollo: Donde se llevan a cabo los cambios por los desarrolladores.
Producción: El entorno donde está publicada la versión real de la aplicación, a la que acceden los usuarios.
Opcionalmente: Entornos intermedios de integración o preproducción, testing, UAT, etc.

Para no complicar mucho el ejemplo, pongamos que tan solo tenemos un entorno de desarrollo y otro de producción. Cuando un desarrollador crea una nueva funcionalidad, se utiliza un entorno de desarrollo, y una vez la funcionalidad está completa y probada, se decide que es el momento de desplegarla en el entorno de producción. En algunos casos puede que sea tan sencillo como subir un módulo nuevo y listo, pero muchas veces nos encontraremos con la necesidad de crear elementos como vistas, o tipos de contenido, que ya tenemos en el entorno de desarrollo, pero que habría que crear de nuevo en el entorno de producción.

Aquí era donde empezaban los problemas con Drupal 7, ya que no había una forma nativa de exportar configuración, y aunque en algunos casos no nos llevaría mucho tiempo crear los componentes a mano en el otro entorno, no es una práctica nada recomendable, por mil razones, pero principalmente porque es fácil cometer errores y por la falta de un sistema de control de versiones que nos permita volver a un estado anterior.

Teníamos que usar el módulo Features, que aunque fué una bendición, no estaba exento de sus propios demonios, como problemas de sobreescritura (Overrides) en algunos componentes, Features que no se pueden revertir, dependencias y conflictos entre distintas Features, y un largo etcétera.

Además, en muchos casos cada módulo almacenaba la configuración como podía o quería. Una opción bastante común era usar variables, pero al final esa tabla era como un agujero negro donde cada módulo podía dejar cualquier cosa, ya que era fácil exportar después esas variables con Features y Strongarm, pero podía descontrolarse muy fácilmente.

La nueva gestión de configuración que hace Drupal 8 pretende ayudar a solucionar todos esos problemas, y de momento parece que lo esta consiguiendo.

Para empezar, ahora cada módulo puede definir su propia configuración en un archivo Yaml dentro de su directorio config. Este archivo contendrá todos los valores de configuración inicial que el módulo necesita. Por ejemplo, un viejo conocido como Pathauto tiene esta configuración:

enabled_entity_types:
  - user
punctuation:
  hyphen: 1
verbose : FALSE
separator : '-'
max_length : 100
max_component_length: 100
transliterate : TRUE
reduce_ascii : FALSE
case : TRUE
ignore_words : 'a, an, as, at, before, but, by, for, from, is, in, into, like, of, off, on, onto, per, since, than, the, this, that, to, up, via, with'
update_action : 2

Esto complica un poco la creación de módulos, pero a cambio permite tener perfectamente estructurada la configuración de cualquier cosa. Por ejemplo, esto es un fragmento del tipo de contenido que uso para publicar artículos en esta página:

uuid: 8cec381d-8247-47b3-b899-ed0adfb3bd36
langcode: en
status: true
dependencies:
  config:
    - core.entity_view_mode.node.teaser
    - field.field.node.blog_post.body
    - field.field.node.blog_post.comment
    - field.field.node.blog_post.field_blog_post_image
    - field.field.node.blog_post.field_tags
    - field.field.node.blog_post.field_teaser
    - image.style.teaser
    - node.type.blog_post
  module:
    - ds
    - image
    - text
    - user

... continúa, es muy muy largo

Lo que nos va a permitir este sistema es poder exportar a un puñado de archivos toda la configuración de nuestro sitio Drupal, copiarlos, moverlos, pasarlos a un control de versiones tipo Git, y después importarlos en otro de nuestros entornos para tener disponibles todos los nuevos cambios o componentes.

Todo puede hacerse desde la administración de Drupal, pero es mucho más cómo utilizar Drush para todo el proceso.

Vamos a ver entonces cómo trabajar con la configuración.

Configuración inicial

Por defecto cuando instalamos Drupal 8 va a guardar la configuración en un directorio con nombre aleatorio, dentro de la carpeta files. Algo así:

sites/default/files/config_XXXX

Dentro de ese directorio se podrán ir almacenando los ficheros de configuración. Lo ideal sería mantener los archivos de configuración fuera del DocumentRoot de nuestro servidor web para que no sean accesibles, e incluirlos en nuestro sistema de control de versiones. Para cambiar este directorio de configuración podemos añadir lo siguiente en el archivo settings.php de nuestro sitio:

$config_directories = array(
  CONFIG_SYNC_DIRECTORY => '/directorio/de/configuracion/sync',
);

Ahora Drupal va a utilizar ese directorio para importar y exportar los archivos.

Exportar configuración

Como ya hemos comentado, tenemos dos opciones para hacer la exportación, bien desde el menú de administración o utilizando Drush. Podemos acceder desde Inicio Administración > Configuración > Desarrollo > Sincronizar, y:

Podemos exportar todo en un único fichero comprimido que y descargarlo desde el servidor con el navegador directamente a nuestro disco. Esto puede ser muy útil en determinados momentos si no tenemos un acceso por SSH a mano, por ejemplo.
Exportar componentes individuales, seleccionando el que nos interese. Esto nos mostrará la configuración de ese elemento en formato Yaml, pero solo podremos copiarla y pegarla en un fichero o en otro entorno de forma manual.

Sin embargo usando Drush podemos generar de una vez todos los ficheros en nuestro directorio sync, con el comando config-export, o su alias cex:

drush cex

Cuando termine el comando tendremos un archivo .yml por cada elemento de configuración de nuestro sitio. Además, tiene algunas opciones que pueden ser interesantes, como --add o --commit para incorporar automáticamente los cambios a nuestro repositorio Git.

Importar configuración

Para realizar el proceso inverso e importar configuración con nuevas funcionalidades o cambios, podremos utilizar la interfaz de administración de manera análoga a la exportación:

Importar toda la configuración en un único archivo comprimido,
Importar configuraciones individuales, pegando el contenido en formato Yaml en la caja de texto.

De nuevo la mejor opción suele ser usar Drush, para lo que primero colocaríamos los ficheros de configuración que queremos importar en nuestro directorio sync, bien a mano, con un script o con git pull, y después ejecutamos config-import, o su alias corto:

drush cim

Este comando nos mostrará primero las configuraciones que van a modificarse al importar, indicando si son nuevos bloques, modificaciones o eliminaciones, como se puede ver en la siguiente captura:

Hay que tener cuidado, porque una vez aceptemos los cambios se modificará nuestra instalación de Drupal, con lo que podemos perder información, por lo que siempre es recomendable sacar una copia de la base de datos antes de hacer la importación.

Puede ser interesante utilizar la opción --partial, que no eliminará la configuración de elementos si faltan sus archivos de configuración.

Otras operaciones con Drush

Usando Drush también es posible obtener una lista de todas las configuraciones disponibles:

drush config-list

Una vez sepamos el nombre de la configuración que buscamos podemos obtenerla y editarla directamente desde la consola con el editor que tengamos configurado por defecto, y se guardará como configuración activa.

Por último, tenemos un comando que nos permite importar directamente la configuración desde otro sitio Drupal directamente usando los alias de Drush:

drush config-pull @produccion @desarrollo

Este comando exportará la configuración del sitio @produccion y la importará en @desarrollo, guardando además los correspondientes archivos de configuración en el directorio sync de @desarrollo.

Conclusiones

Hasta ahora todo lo que he hecho con la configuración de Drupal 8 ha funcionado prácticamente sin problemas, y tener toda esta capacidad incluida en el core es sin duda un gran paso adelante. Todavía tendremos que ver cómo se comporta o que problemas pueden surgir en proyectos grandes y complejos, o cuando entren en juego elementos más complicados como lo que podíamos hacer en Drupal 7 con Features overrides, por ejemplo.

De momento, y como ya ha apuntado mucha gente, me parece que este es el gran cambio que va a aportar Drupal 8 con respecto a la versión anterior.

Referencias

https://drushcommands.com/drush-8x/config/

https://chromatichq.com/blog/drupal-7-features-vs-drupal-8-configuratio…

https://www.drupal.org/docs/8/configuration-management/managing-your-si…

Añadir nuevo comentario

Estrenando Drupal 8. Primeras impresiones

root — Wed, 20 Sep 2017 18:47:33 +0000

Estrenando Drupal 8. Primeras impresiones

Miércoles, Septiembre 20, 2017 - 20:47

Drupal

La versión 8.0.0 de Drupal salió oficialmente en noviembre de 2015, así que bueno, solo he tardado dos años en actualizar mi Drupal 7. No esta mal.

Desde entonces ha llovido mucho, y el estado general de Drupal 8 ha mejorado bastante, hay que reconocerlo, porque hasta esta versión 8.3.7 que acabo de instalar ha pasado de todo, pero aun así mi primera impresión es que todavía le falta mucho camino para estar realmente maduro, sobre todo a nivel de módulos contribuidos. Hay muchos de ellos clave en una instalación normal de Drupal 7 que aun están muy verdes en sus versiones para D8.

Para este blog que es un proyecto muy, muy sencillo, esto es a grandes rasgos lo que tengo instalado:

Drupal: 8.3.7 corriendo sobre Apache en Debian.
Tema personalizado basado en Bootstrap 8.x-3.5
Pathauto y Menu Trail by Path para controlar URLS y menús de forma sencilla.
Recaptha para los formularios y comentarios. Hasta ahora funciona muy bien, casi ningún comentario... xD
XMLSitemap, altamente recomendable para SEO y tener contento a Google.
Metatag, aunque aun no lo he configurado mucho.
Google Analytics
Display Suite para controlar la presentación de los nodos porque ahorra muchas plantillas y me gusta.
TagClouds para la nube de etiquetas que aparece en la barra lateral, que parece que da un poco de vida, pero en una version de desarrollo, 8.x-1.x-dev.
RelatedByTerms, mi propio módulo contrib que he aprovechado para ponerme a picar en Drupal 8,
SMTP para el correo electrónico, gracias a Mailgun.

Todo esta funcionando mas o menos igual que antes con D7, pero como he dicho este es un proyecto muy sencillo. Vamos al grano...

La parte buena

A estas alturas ya se hablado y comentado mucho de Drupal 8, así que llego un poco tarde. Aún así, espero que este artículo pueda ser útil si aun no has dado el paso para empezar con Drupal 8, aunque solo sea como confirmación de lo que el resto de la gente cuenta.

Lo primero a destacar son los módulos gordos que ahora están incluidos en el core de Drupal:

Views, por fin.
CKEditor configurado de serie.
Breakpoint y Reponsive image para el control de imágenes en dispositivos móviles.
Quick edit es bastante molón.
Los módulos de idioma: Language, Configuration translation, Content translation e Interface translation.
Configuration manager, una de las grandes mejoras de esta versión para trabajar de verdad con Drupal.

El segundo punto es que a nivel de gestión de contenido, todo sigue mas o menos en su sitio, por lo que el trabajo de los redactores (si los tenéis) no se verá muy afectado. A nivel de interfaz la verdad es que todo son mejoras.

Mirad por ejemplo una captura de la edición rápida mientras escribía este artículo:

Te permite editar el contenido en vivo, manteniendo y aplicando los estilos CSS mientras escribes. Sin instalar ningún módulo extra. Esto es un caramelo para enseñar a potenciales clientes. Queda genial en una demo y me tiene muy contento.

Con el sistema de plantillas (templates) aún no me he metido a fondo, pero lo que he visto hasta ahora de Twig me gusta. Está mas orientado a separar el diseño y presentación de la página de la lógica de negocio que ahora si la podemos tener bien estructurada usando controladores, lo que me lleva a lo que para mi es a la vez la mayor mejora y posiblemente el mayor obstáculo que va a encontrar mucha gente para trabajar con Drupal 8 ...

El código. Nos olvidamos de viejas chapuzas escribiendo PHP barato, y ahora si, tenemos una arquitectura potente, escalable, con orientación a objetos de verdad: clases, interfaces, factorías, etc. y mejor separación entre código, configuración, lógica de negocio y presentación de datos.

He disfrutado como un enano picando la versión para D8 de mi módulo RelatedByTerms, y espero poder publicar en breve una versión inicial. Viniendo de tantos años en Java mi pequeño corazoncito Javero lloraba cuando al fin pude crear un controlador en un módulo de Drupal con sentido de verdad.

El inconveniente de esto puede ser que técnicamente va a ser mas complejo trabajar con Drupal 8. Hay que tener una buena base de orientación a objetos y eso puede ser un problema para mucha gente que trabaja con Drupal 7, y que hasta ahora no necesitaban grandes esfuerzos de aprendizaje para escribir módulos sencillos.

Por último, y ya se que llego tarde y ya se ha hablado mucho del tema, la gestión de la configuración que hace Drupal 8 sin necesidad de usar el módulo Features es otra de las grandes mejoras de esta versión. Exportar e importar configuración de un entorno a otro va a ser ahora un poquito mas fácil y creo que nos va a ahorrar unos cuantos juramentos en Arameo a mas de uno.

Las cosas malas

Cambiar el idioma por defecto sigue siendo una odisea. De hecho hay avisos por todos lados en las pantallas de configuración avisando de que no se haga. ¿Entonces para que tenemos esa opción?

Muchos módulos que llevamos años usando en Drupal 7 todavía están muy verdes. Algunos ejemplos son Context, aun en beta2, SMTP que está en beta3, XMLSitemap que sigue en alpha2, y una larga lista. La parte positiva de esto es que si te apetece contribuir al desarrollo de Drupal, este es un gran momento para hacerlo.

La otra desventaja, como ya he comentado antes es que aumenta la complejidad de crear nuestros módulos, y habrá que meter un buen número de horas de aprendizaje. Si piensas que vas a pasar de D7 a D8 en unos días, siento desilusionarte pero va a ser que no.

Otra cosa que he notado, es que he visto bastantes errores al tratar de hacer cosas, como activar un módulo y tener un pantallazo blanco hasta que borras la cache, petardazos al guardar alguna pantalla de configuración, pero no tengo ejemplos concretos. Pasa de vez en cuando.

Por ejemplo, los enlaces de la configuración de los contenidos y términos de la pestaña de configuración del módulo XMLSitemap están rotos, y hay que pasarlo a la version de desarrollo para que se arreglen, o acceder desde la pestaña de Sitemap entities, que si que funcionan, aunque tarde un rato en darme cuenta.

Problemas gordos

Las cosas mas chungas que me he encontrado durante la migración desde D7, no han sido muchas, pero si que son graciosas.

Lo primero, hay unos módulos experimentales que vienen en el core para ayudarnos con la migración: Migrate (viejo conocido ya en D7), Migrate Drupal y Migrate Drupal UI. En mi caso era bastante sencillo, con un solo tipo de contenido custom, un par de vistas, términos de taxonomías estándar y poco mas...

Pues la migración me la hice a mano. Con los pocos artículos que tengo publicados tardaba menos en copiar y pegar que ponerme a hacer un proceso de migración, ya que lo intenté con la importación automática y fue bastante desastroso:

Creó el tipo de contenido custom y las vistas, pero...
Los contenidos del campo body no se copiaron.
Cuando los intentaba poner a mano no se veían en las páginas.
Las vistas no funcionaban bien.
Las taxonomías tampoco...

Al final tuve que empezar otra vez tirando de un backup que hice antes de lanzar la migración. Acordaros de hacer un backup antes si queréis probarlo.

Otro problema fue al activar el módulo Context (8.x-1.0-alpha1) con los módulos de traducción activados. Vais a ver una buena cantidad de pantallazos blancos, y este error:

Error: Call to a member function getPath() on null in /var/www/whatever/web/core/modules/config_translation/src/ConfigNamesMapper.php on line 233

La incidencia ya esta resuelta, pero hay que pasarse a la versión de desarrollo del módulo, porque aun no han publicado una release con este código arreglado. De momento no necesito el módulo y lo tengo desactivado.

Conclusiones

En general creo que todos los cambios de arquitectura van a contribuir mucho en llevar a Drupal a un mercado mas "profesional", y al mismo tiempo tener el efecto negativo de alejarlo un poco de todos los usuarios menos técnicos, como pueden ser agencias de diseño, o incluso diseñadores puros sin conocimientos avanzados de programación (conozco unos cuantos), que trabajan con Drupal como freelance para pequeños y medianos clientes.

Por otro lado, me parece que mientras se madura el nivel de los módulos contribuidos vamos a tener Drupal 7 para una buena temporada, y no me extrañaría en absoluto que algún fork de Drupal (véase Backdrop CMS) o similar se lleve el gato al agua y extienda la vida útil de Drupal 7 de forma indefinida.

Por mi parte, seguiré formándome por mi cuenta en Drupal 8 y empezaré a preparar el plan de formación para mi equipo de trabajo en D8 para el año que viene.