Introduction

Dans le menu "Configuration du site" / "Performance" de Drupal, une des cases à cocher mentionne le cache des blocs, mais cette fonctionnalité est souvent méconnue, désactivée ou mal utilisée, du moins c'est ce que nous constatons lors des audits de performance que nous réalisons.

Configuration par défaut

Le cache des blocs est par défaut désactivé (comme l'ensemble des caches Drupal). Si on l'active, le paramétrage par défaut pour chaque bloc du site sera alors DRUPAL_CACHE_PER_ROLE, c'est-à-dire que le bloc sera caché pour tous les utilisateurs d'un même rôle. Et c'est ce paramétrage par défaut qui sera systématiquement utilisé à moins de préciser quelque chose d'autre lors de la déclaration du bloc dans le hook_block_info(). Or, ce réglage n'est pas toujours le plus approprié (soit par oubli du mainteneur du module, soit parce que vous utilisez sur votre site le bloc dans un contexte différent de celui initialement prévu).

Note importante : dans un site multilingue, quel que soit le réglage de cache que vous choisissez pour votre bloc, il sera TOUJOURS caché par langage également (il n'y a rien à préciser, et vous ne pouvez pas modifier ce comportement, le langage est une composante dans le clé du cache).

Attention, à l'activation du cache des blocs, les éventuels paramètres de cache d'une Vue (du module Views) seront surchargés dans le cas d'un affichage de type block par les paramètres du cache des blocs (modifiables directement dans la Vue, dans la partie "Avancés").

Problèmes récurrents

Impossibilité de l'utiliser à cause des droits d'accès

La principale raison à la sous-utilisation du cache des blocks vient de sa désactivation automatique lors de l'utilisation d'un module de droits d'accès, plus précisément qui implémente le hook_node_grants() (voir dans le code du block.module : $disabled = count(module_implements('node_grants'));).

Heureusement, il existe depuis la version 7.33 une variable block_cache_bypass_node_grants permettant d'utiliser tout de même le cache des blocs (et son gain de performance non négligeable) : $disabled = (!variable_get('block_cache_bypass_node_grants', FALSE) && count(module_implements('node_grants')));

À noter que cette fonctionnalité est à l'initiative de Makina Corpus \o/ !

Problème de javascript / css

La façon usuelle d'ajouter du CSS ou du JS à un élément Drupal et d'utiliser les 2 fonctions drupal_add_css() et drupal_add_js. Ces 2 fonctions très utilisées NE DOIVENT PAS être utilisées pour un formulaire ou un bloc drupal, cas qui nous intéresse ici.

La technique à utiliser est alors la clé #attached des Render Arrays Drupal : voir l'api pour les détails d'implémentation. En utilisant #attached, les CSS / JS seront alors mis en cache avec le block (ou le formulaire), permettant donc d'utiliser le cache des blocks y compris pour des diaporamas, sliders et autres composants javascript.

Modification du comportement d'un bloc existant

Il existe (comme toujours dans Drupal) un hook specifique : hook_block_info_alter() qui vous permet de modifier les politiques de cache des blocs définis par d'autres modules du site (et de passer outre le cache de Views, par exemple).

Imaginez qu'un bloc codé en dur utilise un cache "par utilisateur" ou "par page", il utilisera alors des requêtes de cache différentes pour chaque utilisateur ou page alors qu'un cache global (DRUPAL_CACHE_GLOBAL) serait suffisant. Ce hook peut alors vous permettre d'agir sur le bloc mal implémenté et éviter des problèmes de performance sur votre site.

Conclusion

Voilà, vous n'avez plus d'excuse pour ne pas utiliser le cache des blocs sur votre site, et améliorer encore les performances (d'autant que Google se met à pénaliser les sites lents dans ses résultats de recherche).

N'hésitez pas à contacter nos experts Drupal pour améliorer les performances de votre site.