carloscarrascal.com - Desvaríos de un desarrollador. Sobre GNU / Linux, Debian y sobre todo Drupal.

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

Instalar PHP 7.2 en Debian 9 para Drupal 8

root — Sat, 20 Oct 2018 23:19:02 +0000

Instalar PHP 7.2 en Debian 9 para Drupal 8

Domingo, Octubre 21, 2018 - 01:19

PHP

Debian

Drupal

Debian 9 trae por defecto en sus repositorios PHP 7.0.32. Desde Drupal 8.5.0 ya se soporta PHP 7.2, y por si no os habeis dado cuenta, Drupal 8 dejará de soportar PHP 5.5 y 5.6 el día 6 de marzo de 2019, así que ya va siendo hora de actualizar.

Subir a 7.2 es bastante sencillo:

sudo apt install apt-transport-https lsb-release ca-certificates
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt update

Una vez actualizado, podemos comprobar la versión instalada con:

php -v

Si no se ha actualizado automáticamente, podemos actualizar php a mano:

sudo apt install php7.2 php7.2-cli php7.2-common php7.2-curl php7.2-gd php7.2-json php7.2-mbstring php7.2-mysql php7.2-opcache

Una vez actualizado PHP, hay que actualizar el módulo que usamos en el servidor web. Para Apache:

sudo a2enmod php7.2

sudo a2dismod php7.1

Y reiniciar:

sudo service apache2 restart

Si estáis utilizando composer, es una buena idea incluir la versión de PHP a utilizar:

composer config platform.php 7.2

Y actualizar todo:

composer update

En algunos casos es buena idea borrar el fichero composer.lock antes de correr el update.

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

Crear un usuario y asignar permisos en MySQL

root — Thu, 06 Sep 2018 17:20:10 +0000

Crear un usuario y asignar permisos en MySQL

Jueves, Septiembre 6, 2018 - 19:20

MySQL

Database

Normalmente para configurar el acceso de una aplicación web a la base de datos crearemos una cuenta de servicio para esa aplicación, y le daremos permisos según necesitemos, pero solamente a esa base de datos.

Esta es una de esas cosas que uno hace mil veces pero nunca se acuerda de la sintaxis correcta. Aqui lo teneis:

CREATE USER 'nombre_de_usuario'@'localhost' IDENTIFIED BY 'vuestra_password';
GRANT ALL PRIVILEGES ON nombre_de_base_de_datos.* TO 'nombre_de_usuario'@'localhost';
FLUSH PRIVILEGES;

Si queremos asignarle todos los permisos para todas las bases de datos, el GRANT sería así:

GRANT ALL PRIVILEGES ON *.* TO 'nombre_de_usuario'@'localhost';

Normalmente, antes habremos creado la base de datos a mano, o importando los datos de algún archivo. Crear la base de datos en MySQL puede ser tan sencillo como:

CREATE DATABASE nombre_de_base_de_datos;

Suele ser buena idea probar que ha funcionado correctamente. La mejor forma es probar el acceso usando el terminal:

mysql --user=nombre_de_usuario --password=vuestra_password nombre_de_base_de_datos

Si todo está correcto, nos abrirá una sesión de MySQL en el terminal. Si no conecta, es que hemos hecho mal alguno de los pasos anteriores.

Añadir nuevo comentario

Revertir a una version anterior un paquete en Debian

root — Sat, 14 Jul 2018 20:10:45 +0000

Revertir a una version anterior un paquete en Debian

Sábado, Julio 14, 2018 - 22:10

Debian

Linux

Una de las diversiones de utilizar la versión Sid (inestable) de Debian, es actualizar paquetes. Cualquier cosa puede pasar.

Hoy tenia un rato libre y le he dado al apt upgrade a ver que pasaba. Lo que ha pasado es que VirtualBox ha dejado de funcionar, y no arranca las máquinas virtuales, con este error:

virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)

Después de revisar el hilo del error, parece que lo mas rápido es bajar de versión el paquete, ya que la última instalada es la 5.2.14-dfsg-4, por lo que parece, la versión anterior (5.2.14-dfsg-3 en este caso) parece que funciona bien.

Así que voy a intertar explicaros como he hecho para bajar el paquete de versión, sin tener que bajar e instalar a mano el paquete, sino usando los repos de Debian.

Primero, vamos a snapshot.debian.org y buscamos el paquete que nos da problemas, en mi caso virtualbox. Podemos usar la caja de búsqueda o rebuscar a mano por el índice, lo que os de mas morbo.

Hay que seleccionar la versión que buscamos, y debajo del nombre del paquete vereis algo como esto:

Seen in debian on 2018-07-12 14:59:27 in /pool/contrib/v/virtualbox.

Al pinchar en el enlace, llegamos a una dirección de este tipo:

http://snapshot.debian.org/archive/debian/20180712T211510Z/pool/contrib…

Una vez encontrada esta URL, vamos a usarla configurando una nueva fuente para Apt:

cd /etc/apt/sources.list.d

Y creamos un nuevo archivo de fuente:

sudo vi virtualbox.list

Tenemos que usar parte de la URL de antes, sin poner la parte final. En mi caso añado la versión unstable, y el contrib, porque el paquete es de contrib. Quedaría algo así:

deb https://snapshot.debian.org/archive/debian/20180712T211510Z/ unstable contrib

Guardamos el archivo y actualizamos el Apt para que incluya el nuevo índice:

apt update

Una vez termine de actualizar, podemos sacar la lista de versiones disponibles del paquete que necesitamos:

apt-cache showpkg virtualbox

E instalar la que necesitemos, usando el nombre de la version en el mismo comando de Apt:

apt install virtualbox=5.2.14-dfsg-3

En mi caso, el paquete virtualbox tenía un paquete recomendado llamado virtualbox-qt, que Apt muy amablemente me indicó al tratar de instalarlo, así que decidí bajarlo de versión también por si acaso:

apt install virtualbox=5.2.14-dfsg-3 virtualbox-qt=5.2.14-dfsg-3

Con esto se actualizaron los paquetes necesarios para esas versiones, y encima tuve la suerte de que VirtualBox volvió a funcionar perfectamente. Ahora veremos que pasa cuando salga la version siguiente (5.2.14-dfsg-3) y quiera actualizarlo...

Ya os contaré.

Añadir nuevo comentario

Acceso a base datos en Drupal 7. Parte 2

root — Fri, 17 Nov 2017 21:26:38 +0000

Acceso a base datos en Drupal 7. Parte 2

Viernes, Noviembre 17, 2017 - 22:26

Drupal

Database

Issues

Continuamos con el ejemplo de acceso a base de datos en Drupal 7 que comenzamos hace unos días. Puedes consultar la primera parte del artículo para refrescar o si simplemente te la perdiste.

En esta segunda parte vamos a ver cómo:

Crear un formulario para que el usuario pueda crear un nuevo registro en nuestra tabla de issues.
Usar el mismo formulario para modificar los datos de una incidencia.
Eliminar el registro de una incidencia de la tabla.

Definir Hook menus para las acciones

Lo primero que vamos a hacer es ampliar nuestra implementación de hook_menu() para declarar las tres URLs nuevas que necesitamos:

Una URL para modificar los datos de una incidencia: /issues/edit/[issue_id]
Otra para eliminar incidencias de la tabla: /issues/delete/[issue_id]
Por último, para dar de alta incidencias desde un formulario de Drupal: /issues/create

Atención, porque las dos primeras van a necesitar un parámetro que será el identificador (issue_id) de la incidencia que queremos modificar o eliminar, y que debemos especificar en el hook_menu(), que quedaría así (ojo a las partes en negrita):

/**
 * Implements hook_menu().
 *
 * Defines URLS for the list, create, edit and delete actions.
 */
function issue_control_menu() {
  $items = array();

  $items['issues/list'] = array(
    'title' => 'Issues List',
    'description' => 'Issues List from the database.',
    'page callback' => 'issue_control_list',
    'page arguments' => array(),
    'access callback' => TRUE,
  );

  $items['issues/create'] = array(
    'title' => 'Issues Form',
    'description' => 'A form to write rows into issues table.',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('issue_control_form'),
    'access callback' => TRUE,
  );

  $items['issues/edit/%'] = array(
    'title' => 'Issues Form',
    'description' => 'A form to write rows into issues table.',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('issue_control_form', 2),
    'access callback' => TRUE,
  );

  $items['issues/delete/%'] = array(
    'title' => 'Delete issue',
    'description' => 'Deletes an issue.',
    'page callback' => 'issue_control_perform_delete',
    'page arguments' => array(2),
    'access callback' => TRUE,
  );

  return $items;
}

Las definiciones de las URLs de modificar y eliminar llevan un símbolo % que actua de comodín, y se pasa después como parámetro a la función que definimos en 'page callback', mediante la siguiente línea de 'page arguments'. En nuestro caso estamos pasando el argumento 2, ya que el 0 sería 'issues', el 1 sería 'delete' o 'edit', y el 2 será el identificador de la incidencia que ya estamos incluyendo en la URL cuando creamos nuestra lista.

De esta forma, cuando llamamos a la url http://nuestro.drupal/issue/edit/1, el último 1 (que es el issue_id) se recibirá en nuestra función como un parámetro.

Además, en el caso de las llamadas de modificar y crear, la función que ponemos en el 'page callback' no es directamente una función declarada por nosotros, sino una llamada a drupal_get_form(), a la que pasamos el nombre de nuestra función que pintará realmente el formulario.

Acceso a datos: Las funciones básicas

Antes de empezar a desarrollar el formulario para editar y crear incidencias, vamos a empezar por la parte básica primero: las funciones de acceso a datos. Es lógico que implementemos estas funciones esenciales, ya que lo normal en aplicaciones grandes es que tengamos varias llamadas, por ejemplo, para cargar una incidencia en varias partes del código, por lo podremos reutilizalas, y favorecemos la encapsulación, el principio de responsabilidad simple, etc.

Estas son las funciones que vamos a necesitar:

Acción	Función	Descripción
Cargar	issue_control_load_issue()	Devuelve una incidencia.
Nueva	issue_control_add()	Crea una indicencia en la tabla.
Modificar	issue_control_edit()	Modifica los datos de una incidencia.
Eliminar	issue_control_delete()	Eliminar una indicencia.

Es buena práctica en Drupal que todas los nombres de funciones que declaremos se precedan con el nombre de nuestro módulo. Asi nos evitaremos sorpresas desagradables, ya que si dos funciones en distintos módulos se llaman igual, tendremos un error de PHP.

Cargar incidencia

La primera función de acceso a datos que necesitamos va a ser para obtener los datos de una incidencia de la tabla a partir de su identificador (issue_id).

function issue_control_load_issue($issue_id) {
  $issue = NULL;

  if (isset($issue_id)) {
    $issue = db_select('{issues}', 'i')
      ->fields('i')
      ->condition('issue_id', $issue_id, '=')
      ->execute()
      ->fetchAssoc();
  }

  return $issue;
}

Estamos utilzando en este caso la función db_select() de la API de Drupal para recuperar un único registro mediante la condición de que coincida el issue_id con el que recibimos por parámetro. Esta función nos devolverá un objeto de tipo SelectQuery que este caso estamos ejecutando directamente en la misma línea con execute() y recuperando el registro con fetchAssoc().

La función nos devolverá un array con los valores de los campos hemos especifiquedo en fields, en este caso todos. Para acceder mas tarde a los datos de los campos lo haremos así:

$issue = issue_control_load_issue($issue_id);
print ($issue['title']);

Crear incidencia

La siguiente función que vamos a necesitar será para dar de alta una nueva incidencia en la tabla. El código es el siguiente:

/**
 * Creates an issue.
 */
function issue_control_add($form_state) {
  global $user;

  $issue_id = db_insert('{issues}')
    ->fields(array(
      'title' => $form_state['values']['title'],
      'description' => $form_state['values']['description'],
      'uid' => $user->uid,
    ))
    ->execute();

  $message = t('New issue [@issue_id] has been created by uid [@uid].',
    array('@issue_id' => $issue_id, '@uid' => $user->uid)
  );
  watchdog('watchdog_form', $message);
  drupal_set_message($message);
}

En esta función estamos recibiendo como parámetro un array $form_state, que es que nos llega cuando se envía el formulario que construiremos mas tarde. De momento podeis ver que este $form_state obtenemos los valores de los campos para guardar el registro.

El otro dato que necesitamos a la hora de crear la incidencia es el identificador del usuario que la esta creando. Para ello usamos la variable global $user de Drupal, de la que podemos obtenemos el uid.

Aquí la parte importante es la función db_insert() de Drupal que es la encargada de guardar dicho registro. La sintaxis es muy sencilla, recibe por parámetro el nombre de la tabla y después usamos el método fields para añadir los campos y sus valores, y llamamos al execute() para lanzar la consulta.

A continuación estamos creando un mensaje con información del registro que acabamos de crear con el que vamos a hacer dos cosas:

Lo guardamos al watchdog de Drupal, para dejar un registro de cuando se creó.
Lo pasamos a drupal_set_message(), y Drupal lo mostrará en la siguiente página, para informar al usuario.

Esta función no devuelve ningún valor, aunque deberíamos añadir al menos un control de errores.

Modificar incidencia

Vamo ahora con la modificación de datos de una incidencia. En este caso también vamos a recibir por parámetro un array $form_state que vendrá del envío del formulario de edición.

function issue_control_edit($form_state) {
  global $user;

  db_update('{issues}')
    ->fields(array(
      'issue_id' => $form_state['values']['issue_id'],
      'title' => $form_state['values']['title'],
      'description' => $form_state['values']['description'],
      'uid' => $user->uid,
    ))
    ->condition('issue_id', $form_state['values']['issue_id'], '=')
    ->execute();

  $message = t('Issue [@issue_id] has been edited by uid [@uid].',
    array('@issue_id' => $form_state['values']['issue_id'], '@uid' => $user->uid)
  );
  watchdog('watchdog_form', $message);
  drupal_set_message($message);
}

Igual que en el caso de la creación del registro, usamos la variable global $user para obtener el uid del usuario que esta modificando la incidencia.

Para este caso, utlizamos la función db_update() de Drupal, y de forma similar a la creación del registro, obtenemos los valores de los campos del array $form_state, y establecemos que la condición para modificar los registros es la coincidencia por el issue_id con el que hemos recibido.

De la misma forma que en el caso anterior, componemos un mensaje que se manda al watchdog y se muestra al usuario.

Eliminar incidencia

La última función de acceso a datos es para borrar incidencias de la tabla.

function issue_control_delete($issue_id) {
  global $user;

  db_delete('{issues}')
    ->condition('issue_id', $issue_id)
    ->execute();

  $message = t('Issue [@issue_id] has been deleted by uid [@uid].',
    array('@issue_id' => $issue_id, '@uid' => $user->uid)
  );
  watchdog('watchdog_form', $message);
  drupal_set_message($message);
}

En este caso también es necesario recibir como parámetro el identificador de la incidencia para poder eliminarla utilizando db_delete() de Drupal.

Como en los casos anteriores, componemos un mensaje informativo y lo enviamos al watchdog y al usuario.

El formulario de creación y modificación

Una vez tenemos nuestra API de acceso a base de datos, solo nos queda contruir el formulario de creación y modificación de incidencias, y la llamada para eliminarlas.

Para construir el formulario vamos a utilizar la Form API de Drupal, que nos permite definir un formulario completo utilizando un array asociativo para definir los controles.

La función se llamara issue_control_form() y quedará así, atención a las partes en negrita:

function issue_control_form($form, &$form_status, $issue_id = NULL) {

  $issue = issue_control_load_issue($issue_id);

  $form['issue_id'] = array(
    '#type' => 'textfield',
    '#title' => 'Id',
    '#required' => TRUE,
    '#disabled' => TRUE,
    '#default_value' => isset($issue) ? $issue['issue_id'] : '',
  );

  $form['title'] = array(
    '#type' => 'textfield',
    '#title' => 'Title',
    '#required' => TRUE,
    '#default_value' => isset($issue) ? $issue['title'] : '',
  );

  $form['description'] = array(
    '#type' => 'textarea',
    '#title' => 'Description',
    '#default_value' => isset($issue) ? $issue['description'] : '',
  );

  if (isset($issue)) {
    $submit_message = t('Save issue');
  }
  else {
    $submit_message = t('Create issue');
  }

  $form['submit_button'] = array(
    '#type' => 'submit',
    '#value' => $submit_message,
  );

  return $form;
}

El formulario en este caso es muy sencillo, con tres campos y botón para envíar el formulario:

Identificador issue_id: Será un campo de texto sencillo (textfield), pero lo vamos a desactivar para que el usuario no pueda escribir en el.
Campo title: el título de la incidencia. Otro campo tipo textfield.
Campo description: Descripción de la incidencia. Este campo es mas largo, asi que usaremos un tipo textarea para mostrar una caja de texto grande con multiples líneas. Este tipo de campo puede configurarse también para usar un editor de texto enriquecido.

Usando Bootstrap se vería algo parecido a esto:

Lo imporante en este caso es que esta función sera utilizada por drupal_get_form(), y puede recibir un tercer parámetro que será el issue_id, en el caso de que sea llamada desde el hook_menu() para modificar.

En el caso de recibir ese parámetro, cargamos los datos de esa incidencia mediante issue_control_load_issue(), y ponemos los valores por defecto de los campos a los valores correspondientes, para que el usuario ya vea el formulario relleno con los datos y pueda modificarlos.

Dependiendo del caso, ajustaremos tambien el texto del botón de enviar el formulario, mostrando el mensaje correspondiente a cada caso: Guardar o modificar.

Ahora necesitamos la función que va a controlar que hacer cuando el usuario envía el formulario:

function issue_control_form_submit($form, &$form_state) {

  if (empty($form_state['values']['issue_id'])) {
    issue_control_add($form_state);
  }
  else {
    issue_control_edit($form_state);
  }

  drupal_goto('/issues/list');
}

Esta función simplemente comprueba el issue_id que viene al envíar el formulario (en el $form_state) está vacío, en cuyo caso se tratará de una nueva incidencia, y llamamos a nuestra función issue_control_add para crear el nuevo registro.

Si por el contrario tenemos un valor en issue_id, se tratará de una moficiación, por lo que se llama a issue_control_edit().

En ambos casos, el usuario será redirigido a la página del listado de incidencias.

Eliminando incidencias

Para este ejemplo lo haremos muy sencillo, implementando la función que se llamará desde el hook_menu:

function issue_control_perform_delete($issue_id) {
  issue_control_delete($issue_id);
  drupal_goto('/issues/list');
}

Esta función simplemente llama a nuestra función de acceso a datos issue_control_delete() y le pasa el identificador de la incidencia. Una vez eliminada, devolvemos al usuario a la lista de incidencias.

Lo suyo sería implementar algún mecanismo para obtener una confirmación del usuario antes de eliminar, para evitar errores, pero no me quiero extender mas con este ejercicio, mejor lo dejamos para otro rato. Si alguien tiene interés que me deje un comentario.

Espero que el ejemplo no haya quedado demasiado espeso y que os ayude. A modo de cierre un par de cosas que quedan en el aire:

Habria que sacar el HTML de la lista de incidencias que vimos en la primera parte a un template.
Ojo porque no hemos hablado nada de seguridad. Todas las funciones de base de datos de Drupal que estamos usando estan protegidas contra inyección de SQL, pero es una buena práctica utilizar la funcion check_plain() cada vez que vayamos a pintar información que viene de la base de datos.

Muchas gracias y saludos

Comments

Consulta abrir venta de un link de una consulta base de datos

Muy interesante y completo sus explicación sobre las base de datos, me queda una inquietud, si me podría ayudar al listar los datos de una base datos y crear un link que abra una venta nueva y pida datos para una nueva consulta.
Gracias.

tutorial

Esplendido!! me ayudado muchísimo, estoy siguiendo un tutorial sobre un libro de drupal 7 y en esta parte de entidades me había quedado clavado. Gracias a este tutorial me he quedado sin ninguna duda.Muchas gracias.

Añadir nuevo comentario

Acceso a base datos en Drupal 7

root — Sat, 11 Nov 2017 13:50:48 +0000

Acceso a base datos en Drupal 7

Sábado, Noviembre 11, 2017 - 14:50

Drupal

Database

Issues

Estamos haciendo unas sesiones de formación en el trabajo con Drupal 7, y nos ha quedado un ejercicio bastante completo que creo que merece la pena publicar por si puede ayudar a alguien mas.

La idea es mostrar cómo podemos crear un módulo en Drupal 7 que cree su propia tabla en la base de datos, y realizar operaciones sobre ella usando la API de acceso a datos de Drupal.

Para este ejemplo vamos a crear un módulo que nos permita gestionar una tabla sencilla de incidencias (Issues). Los objetivos va a ser:

Crear una nueva tabla en la base de datos de Drupal.
Listar todos los registros de la tabla
Crear nuevos registros mediante un formulario
Modificar los datos de un registro
Eliminar registros de la tabla

Voy a partir el ejercicio en dos artículos para que no me quede un ladrillo infumable, a ver si lo consigo.

Antes de empezar un par de cosas:

Estoy usando un Drupal 7 corriente y moliente. Para este ejemplo no necesitamos instalar ninguna dependencia (de módulos).
El tema de presentación que uso es Bootstrap, así que el HTML que vamos a ver usará algunas clases de Bootstrap que nos ayudará un poco con la presentación. No es realmente necesario y el HTML tendréis que adaptarlo según vuestras necesidades.
Todos los nombres de campos, tablas, etc. van a ir en inglés. Los textos de la interfaz (botones, etiquetas, etc.) también, ya que vamos a usar siempre la función t() de Drupal para traducir.

Comencemos.

Creando nuestro módulo

Para el ejemplo vamos a crear un nuevo módulo para el control de nuestra tabla de incidencias, que llamaremos issue_control. Lo creamos en el directorio estándar:

sites/all/modules/custom/issue_control

Tan sólo vamos a necesitar tres archivos:

issue_control.info: Archivo de control del módulo.
issue_control.module: Aquí tendremos nuestro código PHP.
issue_control.install: Lo usaremos para definir la tabla en la base de datos.

Para empezar, será suficiente con completar el archivo info, con algo parecido a esto:

name = Issues control
project = "issue_control"
description = "Store information into a database table"
package = Custom
core = 7.x
version = "7.x-0.0-rc1"

De momento, con esto nos vale para comenzar. Ojo, es mejor no instalar o activar el módulo todavía, hasta que tengamos la definición del esquema de base de datos. Vamos a ello, a ver como creamos nuestra tabla.

Hook Schema: Creando nuestra tabla

Perfecto, ya tenemos nuestro módulo. Ahora la idea es que al instalar el módulo, este nos cree automáticamente la tabla que necesitamos en la base de datos. Para ello vamos a usar el hook_schema(), que vamos a implementar en el archivo issue_control.install que acabamos de crear.

Pero primero vamos a ver que campos necesitamos en nuestra tabla. Hagamos algo sencillo:

Campo	Tipo	Nulo	Descripción
issue_id	Int	NO	El identificador de la incidencia. Debería ser una secuencia o un autoincrement. No puede ser nulo, ya que lo vamos a usar como identificador y primary key. En Drupal usaremos el tipo serial, que nos permite hacer justamente eso y no tener que preocuparnos de rellenarlo nosotros.
title	String (255)	NO	Título de la incidencia. Una cadena de caracteres no muy larga. No queremos que se quede vacío. En Drupal usaremos el tipo varchar.
description	String (Largo)		Este será el campo para guardar el contenido de la incidencia. Queremos que sea una text area donde el usuario pueda meter mucho texto. Para esto en Drupal tenemos el tipo text.
uid	Int	NO	Vamos a incluir el id del usuario (uid) que crea o modifica la incidencia, para que nos dé un poco de juego el ejercicio. Este sera un campo numérico sencillo de tipo int en nuestro Drupal.

Bien, ahora que tenemos mas o menos claro los campos que queremos, vamos a crear nuestro hook_schema. Este hook debe ser implementado en el archivo .install del módulo, y nos va a permitir declarar una o varias tablas que se crearán cuando se instale el módulo (ojo: instalación, no activación) y se eliminarán automáticamente cuando se desinstale (ojo otra vez: desinstalar, no deshabilitar).

Vamos a ver el código:

<?php

/**
 * Implements hook_schema().
 */
function issue_control_schema() {
  $schema['issues'] = array(
    'description' => 'Table for storing issues',
    'fields' => array(
      'issue_id' => array(
        'type' => 'serial',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'description' => 'Issue ID',
      ),
      'title' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
        'description' => 'Issue title',
      ),
      'description' => array(
        'type' => 'text',
        'size' => 'normal',
        'description' => 'Issue description',
      ),
      'uid' => array(
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
        'description' => 'User uid for the issue',
      ),

    ),
    'primary key' => array('issue_id'),
    'indexes' => array(
      'issueid' => array('issue_id'),
    ),
  );

  return $schema;
}

La referencia del Schema API de Drupal tiene bastante miga, y daría para varios artículos, pero no es el objetivo de este post. Recomiendo darle un buen repaso a la documentación, aunque no he podido encontrarla en castellano.

Es importante tener en cuenta que si tenéis errores en este fichero o en este hook, lo más probable es que pete al instalar el módulo y no cree nada. Para que Drupal vuelva a ejecutar el hook_schema después de una prueba fallida, teneis que desinstalar el módulo por completo y volver a instalar. Podeis usar drush pmu issue_control, o bien utilizar el módulo Devel, que tiene una opción para reinstalar módulos muy útil para esto, hasta que consigáis que funcione correctamente la creación de la tabla.

Listado de registros de la tabla

Lo primero que vamos a hacer es preparar una página para mostrar el listado de las incidencias guardadas en la tabla. Logicamente, al principio estará vacía si acabamos de instalar el módulo. Podemos crear algunos registros a mano, o bien utilizando una herramienta como phpMyAdmin. Una ejemplo sencillo para tener algunos datos de prueba podría ser usando Drush:

drush sql-cli

insert into issues (title, description, uid) values ('Un titulo', 'Description de pruebas', 1);

Para hacer nuestro listado vamos a utilizar dos funciones en nuestro archivo .module:

Un hook_menu para definir la URL que usaremos para la lista, y la función a llamar para pintarla.
Una función nuestra que devolverá el listado de incidencias en formato HTML.

Primero, vamos a crear un hook_menu, y definiremos la URL /issues/list para nuestro listado de incidencias. De esta forma, cuando carguemos la URL http://misitio.drupal/issues/list, obtendremos la lista de incidencias.

En nuestro archivo .module, declaramos el hook_menu:

/**
 * Implements hook_menu().
 *
 */
function issue_control_menu() {
  $items = array();

  $items['issues/list'] = array(
    'title' => 'Issues List',
    'description' => 'Issues list from the database.',
    'page callback' => 'issue_control_list',
    'page arguments' => array(),
    'access callback' => TRUE,
  );

   return $items;
}

Con este hook definimos la URL y especificamos que al cargar dicha URL, se ejecutará la función issue_control_list() para pintar los resultados.

Después implementamos esa función para listar:

/**
 * Shows a list with all issues in the database table.
 */
function issue_control_list() {

  $content = '<table class="table table-hover table-striped">';
  $content .= '<tr>';
  $content .= '<th>' . t('Issue Id') . '</th>';
  $content .= '<th>' . t('Title') . '</th>';
  $content .= '<th>' . t('Description') . '</th>';
  $content .= '<th>' . t('Username') . '</th>';
  $content .= '<th>' . t('Actions') . '</th>';
  $content .= '</tr>';

  $results = db_query('SELECT * FROM {issues}');
  foreach ($results as $row) {
    $user = user_load($row->uid);

    $content .= '<tr>';
    $content .= '<td>' . $row->issue_id . '</td>';
    $content .= '<td>' . $row->title . '</td>';
    $content .= '<td>' . $row->description . '</td>';
    $content .= '<td>' . (!empty($user->name) ? $user->name : t('Anonymous')) . '</td>';
    $content .= '<td class="btn-toolbar">';
    $content .= '<a class="btn btn-xs btn-primary" href="' . url('/issues/edit/' . $row->issue_id) . '">' . t('Edit') . '</a>';
    $content .= '<a class="btn btn-xs btn-danger" href="' . url('/issues/delete/' . $row->issue_id) . '">' . t('Delete') . '</a>';
    $content .= '</td>';
    $content .= '</tr>';
  }

  $content .= '</table>';
  $content .= '<a class="btn btn-success" href="' . url('/issues/create') . '">' . t('Add an issue') . '</a>';

  return $content;
}

Con este código estamos obteniendo todos los registros de la tabla issues y pintando una tabla HTML para mostrar los resultados. Esta función tiene varias partes interesantes.

Se utiliza una variable $content para ir guardando el HTML que vamos construyendo.
Primero creamos las cabeceras de la tabla con los nombres de los campos.
Después, se lanza la consulta a la base de datos para pedir todos los registros de la tabla issues.
A continuación se utiliza un bucle para pintar cada uno de los registros. Para cada registro cargaremos el usuario de Drupal correspondiente al uid que venga en la issue, y pintamos su nombre.
Las clases CSS que estoy utilizando son para Bootstrap, por ejemplo, los table y table-striped nos proporcionarán una tabla más pintona, o los btn y btn-primary para los botones de acción.

Obteniendo los datos

Vamos a ver un poco mas en detalle cómo estamos obteniendo los registros de la base de datos. En este caso como es una query muy sencilla, usaremos la función db_query de Drupal:

$results = db_query('SELECT * FROM {issues}');

Esta llamada nos devuelve el resultado de la query como un array en la variable $results. Un detalle importante es utilizar el nombre de la tabla entre llaves, ya que Drupal lo reemplazará por la tabla correcta si nuestro sitio usa un prefijo (prefix) para la base de datos.

Este array tendrá un objeto de tipo stdClass por cada registro de la base de datos que devuelva la consulta, y en cada uno de estos objetos podremos acceder a los campos de la tabla como si fuesen propiedades, por ejemplo $row->title, nos devolverá el título.

De esta forma, para leer y pintar los registros usaremos un bucle, e iremos recogiendo los valores de cada campo que queremos mostrar:

foreach ($results as $row) {
  $user = user_load($row->uid); // Aquí cargamos el usuario correspondiente por su uid.
  
  $content .= '<tr>';
  $content .= '<td>' . $row->issue_id . '</td>'; // Pintamos el campo issue_id.
  ... 
}

No debemos usar db_query para realizar operaciones de insert, update o delete, y si necesitamos realizar operaciones con la query antes de ejecutarla, es mejor usar la función db_select que veremos más adelante.

Resultados

Si todo ha ido bien tendremos algo parecido a este ejemplo que se ve bastante resultón gracias a Bootstrap:

Como podéis ver, estamos ya pintando los botones de acción para cada registro: Edit y Delete, que son enlaces a otras páginas que aún no existen, y después de la tabla tenemos otro botón para crear una incidencia nueva. Estos enlaces serán:

Un enlace /issues/edit/[issue_id] para modificar los datos de una incidencia.
Otro a /issues/delete/[issue_id] para eliminar incidencias de la tabla.
Por último, /issues/create para dar de alta incidencias desde un formulario de Drupal.

Estas tres acciones las veremos en el próximo artículo, en el que os dejaré un enlace para descargar todo el código del ejemplo completo.

Como pequeña puntualización, esta función para pintar la lista tiene demasiado código HTML. Lo correcto sería utilizar una plantilla o template para pintar la lista, de forma que todo el HTML estaría dentro del template. Hay mil ejemplos en internet para utilizar templates en nuestros módulos con Drupal 7, pero aún así pienso escribir otro artículo después de estos para mostrar cómo hacerlo en condiciones con este ejemplo.

Muchas gracias y hasta pronto.

La segunda parte de este artículo esta aquí.

Añadir nuevo comentario

Rendimiento en Drupal: Google Page Speed

root — Fri, 20 Oct 2017 19:44:28 +0000

Rendimiento en Drupal: Google Page Speed

Viernes, Octubre 20, 2017 - 21:44

Drupal

Rendimiento

Page Speed es una herramienta de Google que nos puede ayudar a optimizar el tiempo de carga de nuestro sitio Drupal. No es que lo vaya a arreglar por nosotros, pero al menos nos puede dar varias ideas interesantes de por dónde van los tiros. Para utilizarlo nos va a pedir una URL del sitio que queramos probar, y nos puntúa de 0 a 100 el rendimiento de esa URL teniendo en cuenta varios factores.

Sin tocar demasiado de la configuración inicial de Drupal 8, mi sitio estaba alrededor de un 60/65 calificado como Pobre (Poor), tanto para escritorio como para móviles. Para Drupal 7 y sin grandes esfuerzos en sitios pequeños o medianos, es fácil subir por encima de 90 en ambas puntuaciones.

Cabe destacar que para poder puntuar bien en el apartado de dispositivos móviles, lo primero es que nuestro tema sea adaptable (Responsive). En mi caso estoy utilizando Bootstrap como tema base, que puede que no sea lo mas puntero a día de hoy pero funciona muy bien. A estas alturas puede que parezca una tontería siquiera tener que recordarlo, pero es que aun se ve cada cosa por ahí que asusta.

En mi caso, para este sitio, las áreas de mejora eran bastante comunes, vamos a verlas:

Optimizar imágenes

Este es un problema bastante común: las imágenes que mostramos en nuestro sitio son demasiado grandes o no están optimizadas.

El primer paso es revisar todas las imágenes de estructura que estemos usando en nuestro diseño, es decir, logos, imágenes para bullets, fondos, etc. que utilice nuestro tema. Por ejemplo, este sitio tiene cuatro imágenes en el pie que van a 40px de alto. Si van fijas a 40px con CSS, pues las imágenes no deberían ser más grandes de ese tamaño, y Page Speed lo va a comprobar.

Lo siguiente sería asegurarse que todas las imágenes en contenidos están utilizando un Estilo de imagen apropiado (Image styles) cuando se pintan en la página, con la resolución apropiada. En este sitio, para la versión de escritorio las imágenes que se muestran en los artículos no van ser nunca más anchas de 850px, porque así está definido en el diseño. Prestad atención a las imágenes que van en los teasers, destacados en bloques, etc.

Por último, pensemos en los dispositivos móviles. Siguiendo con el ejemplo anterior, si nuestras imágenes son de 850px de ancho, van a ser demasiado grandes para cualquier teléfono. La guinda del pastel es tener configurados diferentes estilos de imágenes para cada uno de los saltos de resolución o media queries que tengamos en nuestro tema. Para esto es muy útil el módulo Breakpoints, que en Drupal 8 se incluyó en el core.

Otro módulo útil para Drupal 8 es Entity embed, que aunque aún está en beta, funciona bastante bien y nos permite junto con Entity browser añadir imágenes desde el CKEditor y seleccionar el Image style en que se van a mostrar, con lo que podremos tener todas las imágenes del contenido controladas y responsive.

El objetivo final de este proceso de cara a mejorar el rendimiento de nuestro sitio es sencillo: si nuestras imágenes están bien optimizadas, tendrán un menor tamaño, se enviarán menos datos por la red, y tendremos un mejor tiempo de carga.

Minificar archivos CSS y Javascript

Compactar nuestros archivos de estilos y Javascript puede ahorrar un buen montón de bytes que nos ayudará a mejorar otro poquito el rendimiento.

El primer paso en este sentido es asegurarse que tenemos activado en el apartado de Configuración / Rendimiento las opciones para agrupar CSS y Javascript, como muestra la siguiente captura.

A partir de aquí el tema se complica un poco mas. Aunque tengamos el mejor y más bonito tema del mundo para nuestro sitio, perfectamente estructurado con Gulp, tirando de mil paquetes de NodeJS, y podamos compilar nuestro SASS o Less y minificarlo nosotros mismos, vamos a estar usando montones de librerías de terceros, código JS y CSS de otros módulos Drupal, etc. que no tiene porqué estar tan bonito como el nuestro.

Para remediar esto yo he optado por instalar el módulo Advanced CSS/JS Aggregation, que ya habia estado usando en Drupal 7, y nos permite configurar un montón de opciones, entre ellas, minificar todo el código JS y CSS, sin muchas complicaciones, como se puede ver en las siguientes capturas.

Especificar caché de navegador

Este caso es especialmente curioso, porque se queja de este fichero:

https://www.google-analytics.com/analytics.js (2 horas)

Es el archivo Javascript de Google Analytics, que carga el módulo. Solucionar este problema fué sencillo, el propio módulo tiene una opción para cachear localmente el Javascript, así que la activamos y adiós a el problema.

Normalmente el resto de opciones de caché estarán correctamente configuradas en una instalación normal de Drupal, gracias al sistema de caché y al fichero .htaccess para Apache que viene por defecto con la distribución.

Eliminar el JavaScript que bloquea la visualización y el CSS del contenido de la mitad superior de la página

Este es el punto que mas quebraderos de cabeza me está dando. Con Drupal 7 si he conseguido solucionarlo usando solamente el módulo AdvAgg y jugando con las opciones. Hay una referencia muy buena aquí sobre como configurarlo que a mí me ha dado buenos resultados.

Ahora bien, con Drupal 8 aún no he conseguido solucionarlo del todo, y este blog me sigue dando el error. He probado varias configuraciones y no ha habido forma:

Estaba usando el módulo @font-your-face para cargar las Google Fonts. Como uno de los avisos que da Page Speed era precisamente el de la carga de las fuentes, lo he desactivado y he añadido la fuente directamente en el tema. No ha habido ninguna mejora, pero me he quitado un módulo.
He probado diferentes opciones del bundler de AdvAgg pero no he conseguido mejoras tampoco.
No he podido activar la opción de AdvAgg para cargar el CSS por medio de Javascript, que creo que es lo que podría ayudar, porque al activarlo deja de funcionar el File Browser para gestionar las imágenes al editar contenidos. Voy a seguir investigando por aquí, porque este punto es la diferencia entre la configuración que me funciona para Drupal 7 y Drupal 8

Ampliaré este artículo si consigo encontrar una solución, de momento cualquier comentario al respecto sería bienvenido.

Conclusiones

Después de los ajustes que hemos visto y el uso del módulo AdvAgg, he pasado de un 60/65 a un 75/90. Aunque quedan algunas cosas por solucionar, está bastante mejor. En mi caso para la versión móvil, aún tengo que optimizar algunas de las imágenes, que es lo que más me está penalizando, y falta encontrar una solución para el bloqueo causado por el CSS, pero sin mucho esfuerzo ya hemos obtenido bastantes mejoras.

Referencias

Consejos de configuración de AdvAgg: https://groups.drupal.org/node/517292
Añadir fuentes de Google a nuestro tema: https://duntuk.com/how-add-google-fonts-drupal-8-theme-proper-way

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,