Il footer di Magento 1 è un blocco cachato

Scrivo questo articolo su un argomento che non è particolarmente appassionante, né complesso, né vasto eppure ci sono inciampata almeno due volte con grande frustrazione e so per certo che non è successo solo a me. Quindi scrivo qualche riga così di sicuro non me lo dimenticherò più.

L’argomento è la cache del footer di Magento 1, dal punto di vista di un frontend developer che crede di aver a che fare con una richiesta molto semplice e malauguratamente abbassa la guardia.

L’obiettivo è mostrare un footer diverso in pagine diverse dello stesso ecommerce Magento.

Insomma una richiesta che non sembra essere nulla di preoccupante.

Ecco allora che il frontend developer non esita e inserisce a colpo sicuro qualcosa del genere:

<default>
  <reference name="footer">
    <block type="cms/block" name="footer-info">
      <action method="setBlockId">
      <block_id>footer-info</block_id>
      </action>
     </block>
   </reference>
</default>

[…]

<checkout_cart_index>
  <reference name="footer">
     <remove name=”footer-info”>
  </reference>
</checkout_cart_index>

Ovvero qualche istruzione nell’handle <default> che si vedrà in tutte le pagine e poi le modifiche al footer che servono nell’handle specifica.
Tutto come da manuale.

Se la cache di Magento è disabilitata nessun problema. Vi verrano a disturbare appena qualcuno la abilita.
Se invece la cache è abilitata infatti l’utente vedrà il footer in tutto il sito nel modo in cui lo visualizza la prima volta.

Rischio di essere scontata e aggiungo che quindi: sono cachati anche tutti i blocchi che aggiungerete dentro a <footer> e non funzionano neanche eventuali elementi dinamici che potrebbe venirvi in mente di inserire in questo blocco tipo language switcher o riepiloghi del carrello.

Come aggirare questo problema?

Potreste quindi pensare di disabilitare la cache per questo blocco, cosa che si può senz’altro fare ma non ci piace molto.
Se siete frontend come chi scrive, e quindi non è il vostro mestiere riscrivere le classi, potete anche cavarvela facilmente da xml con:

<reference name="footer">
   <action method="setCacheLifetime"><s>null</s></action>
</reference>

Come dicevo questa soluzione non ci piace perchè, anche se magari di poco, peggiora le perfomance e ce n’è una migliore:

<reference name="footer">
 <action method="setCacheKey">
     <key>your-own-unique-cache-key</key>
 </action>
</reference>

Il cache key è l’identificativo della cache di ogni blocco, al blocco footer di default è associata un’unica chiave, per questo una volta “salvata” una versione del footer con quella chiave ve lo mostra sempre uguale.

Con il metodo setCacheKey potete però specificare una chiave cache specifica per ogni blocco footer diverso da quello standard, in questo modo le performance sono salve e il vostro footer cambia come richiesto!

È una soluzione che consente teoricamente di scalare all’infinito e quindi avere un footer diverso per ogni pagina del sito, anche se in qualche caso limite ( ad esempio un footer diverso per ogni categoria su un sito con moltissime categorie ) potrebbe essere necessario ricorrere ad un rewrite per evitare di specificare tantissime cache key manualmente, ma rimangono comunque buone possibilità di cavarsela senza disturbare nessun collega backend dev.