Archives pour la catégorie PHP

Cache de bloc : attention au hook_block_view !

C’est expliqué sur drupal.org, au niveau de l’API du hook_block_view, dans un commentaire :

si le bloc est en cache, dès le 2nd affichage du bloc, le hook_block_view correspondant n’est plus appelé. Logique, c’est ce qu’on veut en mettant du cache : éviter à Drupal de recalculer à chaque coup le bloc et son rendu.

Seulement, la petite bourde facile, c’est d’utiliser drupal_add_css, drupal_add_js, drupal_add_library directement dans le callback du hook_block_view.

Erreur ! Car le JS, CSS ou la librairie ne sera ajoutée qu’une seule fois, avant que le bloc ne soit en cache. Ensuite, nada, que d’chi, vous n’aurez plus vos attachements…

Solution ?

la 1ère réponse au commentaire explique qu’on peut gérer son cache soi-même, en disant à Drupal : ne cache pas ce bloc, je m’en occupe !

La 2nde, plus « best practice » à mon sens, conseille d’utiliser tout bonnement la clé #attached de votre render Array. Ah oui, j’espère que vous utilisez un render Array, sinon, c’est pas bien !

 

En même temps, il suffit de lire la doc et de respecter les standards, mais c’est si facile de se tromper que ça valait bien un article !

Quel contenu principal pour ma homepage ?

Il y a plusieurs façons de gérer le contenu principal de sa homepage. La homepage est la page « / » ou bien « /node ».

Comportement par défaut de Drupal

Le comportement par défaut de Drupal est d’afficher les N derniers articles (N étant paramétrable) promus en page d’accueil (dans les options de publication d’un contenu).

C’est son fonctionnement de base, type « blog ».

Node en guise de contenu principal

Il est également possible de dire à Drupal d’utilise un noeud particulier pour la homepage. C’est stocké dans la variable « site_frontage », et paramétrable via l’écran d’administration « admin/config/system/site-information ».

Alors là, attention, attention, car il va vous mettre un joli « cannonical » sur la homepage, et un lien vers le node sous-jacent en shortlink.

Continuer la lecture de Quel contenu principal pour ma homepage ? 

Piège d’un render_array contenant #markup

Arg, Drupal m’a bien eu ! Je viens de passer 2 heures à comprendre pourquoi mon admin_menu n’apparaissait plus sur mon site, bien que connecté.

Et j’ai découvert qu’il fallait faire gaffe aux render Arrays contenant une clé « #markup ».

Si le tableau contient une clé #markup, il aura beau avoir d’autres clés contenant des fils (clés non préfixées par #, qui sont donc considérées comme des « children »), les fils ne seront pas « rendus ».

 

Pourquoi ?

Continuer la lecture de Piège d’un render_array contenant #markup 

Les caches de Drupal7 : base de données et Memcached

Décorticons un peu le système de cache de Drupal.

Cache des pages et cache Drupal (backend) :

Accéder à la page de configuration des caches via /admin/config/development/performance.

Cocher la case « Mettre en cache les pages pour les utilisateurs anonymes » dans Configuration>Performances

Régler les temps de caches à

  • 1 minute (60sec) pour la durée de vie minimale de la mémoire cache
  • 5 minutes pour l’expiration des pages en cache

(à vous de choisir les temps que vous souhaitez, évidemment…)

Explications

Continuer la lecture de Les caches de Drupal7 : base de données et Memcached 

Field_collection et i18n

Le module field_collection est très pratique voire indispensable lorsqu’on a des types de contenus assez poussés. Je ne vais pas expliquer à quoi il sert ici, la page du module est suffisamment explicite.

Seulement, dès qu’on utilise le module i18n pour gérer de la traduction sur son site, ça devient vite la misère si on ne fait pas attention.

Pour cela, il faut bien comprendre l’architecture utilisée par le module field_collection.

Continuer la lecture de Field_collection et i18n 

Plus loin avec le sfDoctrineGuardPlugin : performances et astuce

Nous aborderons dans cet article 2 thèmes :

Continuer la lecture de Plus loin avec le sfDoctrineGuardPlugin : performances et astuce 

Symfony : méfiez-vous des chemins relatifs

Il se trouve que le client pour lequel j’ai travaillé a une configuration d’Apache un peu particulière, qui est constituée de 2 Apaches avec du reverse proxy et tutti quanti.

Du coup, le site Symfony n’a pas son propre virtualhost exposé directement sur le Web : on ne tape pas http://monsitesymfony.com pour y accéder mais http://apps.monentreprise.com/monsitesymfony/, car ils mutualisent leurs applications.

Conséquence : deux ou trois choses ne fonctionnaient pas du 1er coup concernant les uploads et prévisualisation des fichiers uploadés ou encore l’image d’un datepicker.

Pour s’affranchir de ce genre de problème, je vous conseille de toujours faire un passe de test sans utiliser le virtualhost, mais plutôt http://votreserveur/votresite/web/, de façon à détecter ce genre de problème.

Continuer la lecture de Symfony : méfiez-vous des chemins relatifs 

Logs des requêtes Doctrine, comment les activer/désactiver ?

Je cherchais l’information pour activer les logs des requêtes Doctrine lorsque je l’utilisais au travers d’une tâche, et non d’un module Symfony.
En fait c’est simple, il suffit juste de trouver soi-même l’information !

Dans l’ordre de priorité, Doctrine s’appuye d’abord sur un paramètre logging dans le database.yml, et s’il ne le trouve pas, il s’appuye sur la valeur du logging_enabled dans le settings.yml de votre application.

Toute l’information se trouve dans sfDoctrineDatabase qui instancie un profiler sfDoctrineConnectionProfiler.

database.yml :

dev:
  doctrine:
    class: sfDoctrineDatabase
    param:
      dsn:      mysql:host=...;dbname=...
      username: ...
      password: ...
      logging: true

settings.yml :

dev:
  logging_enabled: false