Planète

Drupal 8 propose un système de cache très puissant et à plusieurs niveaux.

Ici nous allons voir comment stocker simplement le résultat d'une requête en cache afin de ne pas avoir à la lancer la requête SQL à chaque appel.

Commençons par définir notre « conteneur » de cache dans le fichier mon_module.services.yml :

  cache.mon_module:
    class: Drupal\Core\Cache\CacheBackendInterface
    tags:
      - { name: cache.bin }
    factory: cache_factory:get
    arguments: [mon_module]

mon_module sera le nom de notre conteneur de cache.

Cela permettra de distinguer les données que nous mettrons dedans et de ne pas écraser d'autres caches d'autres modules. Si vous utilisez le cache en base de données (par défaut) vous verrez qu'une nouvelle table cache_mon_module a été créée.

Ensuite voici un exemple de lecture du cache, et d'écriture si la donnée n'est pas présente :

public function getVersion() {
  // On teste si la clé « database.version » est présente dans le conteneur de cache « mon_module »
  if ($results = \Drupal::cache('mon_module')->get('database.version')) {
    // Si c'est le cas, les données stockées sont dans l'attribut « data »
    return $results->data;
  }
  // Sinon on effectue la requête désirée
  $version = $this->connection->select('version', 'v')->fields('v', ['version'])->execute()->fetch();
  // Et on met la valeur en cache
  \Drupal::cache('mon_module')->set('database.version', $version->version);
 
  return $version->version;
}

Il est possible aussi de donner date d'expiration afin que cette clé de cache ne soit plus valable une fois cette date passée :

// cache valable 1 h (3600 secondes)
\Drupal::cache('mon_module')->set('database.version', $version->version, date('U') + 3600);

Outre la base de données « classique » de drupal, il est aussi possible de se connecter à une autre base de données.

Pour cela dans le fichier de settings il faut définir les identifiants :

$databases['seconde_db'] = $databases['default'];
$databases['seconde_db']['default']['host'] = 'HOST_SECONDE_DB';
$databases['seconde_db']['default']['database'] = 'SECONDE_DB';
$databases['seconde_db']['default']['username'] = 'USER_SECONDE_DB';
$databases['seconde_db']['default']['password'] = 'PASSWORD_SECONDE_DB';

Ensuite dans le code de notre drupal on peut sélectionner cette seconde base de données :

# On sélectionne la base secondaire
Database::setActiveConnection('seconde_db');

Pour ensuite effectuer les requêtes que l'on souhaite, via la database API de drupal.

Attention à la fin ne pas oublier de rebasculer sur la base de données par défaut afin de ne pas casser tout le drupal :

# On bascule sur la base de données par défaut
Database::setActiveConnection();

L'élément, selon moi, le plus important d'un site web est la qualité de ses menus. Comme il est possible d'arriver par n'importe quelle page sur un site, il est donc important que l'internaute puisse y naviguer de façon simple et fluide. Voici comment gérer une partie de vos menus dynamiquement sous Drupal 8.

Une petite dépendance à ajouter à son composer.json qui permet d'économiser pas mal de ram lors des taches lourdes de composer (update notamment)

composer require zaporylie/composer-drupal-optimizations:^1.1

Simplement en supprimant des anciens tags des package de symfony, cela peut diviser par deux la mémoire vive nécessaire.

Plus d'informations : https://github.com/zaporylie/composer-drupal-optimizations

Lors d'une manipulation de formulaire, il est assez fréquent de vouloir la main sur la structure HTML. Par défaut les champs s'affichent les uns en dessous des autres avec uniquement le balisage des éléments du formulaire.

Pour gérer facilement la structure HTML d'un Form sous Drupal 8, il faut se tourner vers les thèmes ...

Lors d'une manipulation de formulaire, il est assez fréquent de vouloir la main sur la structure HTML. Par défaut les champs s'affichent les uns en dessous des autres avec uniquement le balisage des éléments du formulaire.

Pour gérer facilement la structure HTML d'un Form sous Drupal 8, il faut se tourner vers les thèmes ...

Quand un template est appelé via un « reder array », le template va être cherché en priorité dans le thème actif, puis dans le module qui déclare ce template.

Dans certains cas, cela peut poser problème : Si un template peut-être appelé dans un contexte back ou front, les thèmes sont la plupart du temps différents. La solution de feignant pourrait être de dupliquer ce template dans les deux thèmes. Mais c'est évidement pas une bonne solution.

Dans la déclaration du template on peut spécifier où trouver le template en question :

  $themes['xml_sitemap'] = [
    '#template' => 'xml-sitemap',
    'path' => drupal_get_path('theme', 'mon_theme_back') . '/templates',
    'variables' => [
      'urls' => [],
    ],
  ];

Ainsi peut importe si mon template est appelé depuis le front ou depuis le back ça sera toujours le fichier :

themes/custom/mon_theme_back/templates/xml-sitemap.html.twig qui sera utilisé.

Lors d'une manipulation de formulaire, il est assez fréquent de vouloir la main sur la structure HTML. Par défaut les champs s'affichent les uns en dessous des autres avec uniquement le balisage des éléments du formulaire.

Pour gérer facilement la structure HTML d'un Form sous Drupal 8, il faut se tourner vers les thèmes ...