Linee guida per la risoluzione delle incompatibilità e best practices per la scrittura di nuovi moduli.
Questa nuova versione di Magento o la patch nello specifico, penso che meritino un articolo dedicato viste le incompatibilità che si vengono a verificare con le precedenti versioni.
- Aggiornando la propria installazione a Magento 1.9.2.2, si potrebbe verificare che in amministrazione, alcuni moduli di terze parti o i proprio moduli custom non vengano più visualizzati, oppure che cliccando sul link che rimanda al relativo pannello, questo dia un errore 404.
- Inoltre, se si sono utilizzate in frontend per la visualizzazione di elementi nelle pagine o blocchi cms, le variabili che richiamano blocchi particolari (un esempio su tutti un blocco di iscrizione alla newsletter), questi elementi non compaiono più.
- Altro caso, nelle email transazionali, alcuni elementi o blocchi di testo potrebbero sparire.
- Potrebbero inoltre verificarsi errori durante il processi di login e di reset della password.
Tutti questi “malfunzionamenti”, sono dovuti alla nuova versione. Una serie di modifiche nel codice di Magento per la sicurezza.
Per far funzionare di nuovo tutto quello che andava già prima bisognerà agire seguendo le nuove linee guida.
[info ]Se non sai come installare una Magento Patch ma imparare a farlo, leggi questo articolo: Installare Magento Patches[/info]
moduli in amministrazione
La patch responsabile di questa modifica, è disabilitata di default, ed è attivabile andando su Sistema->Configurazione->Amministratore->Sicurezza
Per chi non è sviluppatore o ha acquistato un modulo di terze parti, conviene aspettare l’aggiornamento dei moduli stessi.
Se invece si è creato un modulo custom, con relativi pannelli amministrativi, di cui però i controller non risiedono all’interno dell’admin path di Magento, bisogna apportare per l’appunto questa modifica. Abilitando la patch, d’ora in poi Magento non permetterà più l’accesso a tutte quelle pagine amministrative che non risiedono all’interno dell’admin di default.
In pratica va effettuata una modifica al file di configurazione config.xml del proprio modulo.
Se prima una route poteva essere scritta in questo modo
1 2 3 4 5 6 7 8 9 10 11 | <admin> <routers> <custom_module> <use>admin</use> <args> <module>custom_module</module> <frontName>custom_module</frontName> </args> </custom_module> </routers> </admin> |
ora deve necessariamente essere scritto in questo modo:
1 2 3 4 5 6 7 8 9 10 11 | <admin> <routers> <adminhtml> <args> <modules> <custom_module after="Mage_Adminhtml">CustomModule_Adminhtml</custom_module> </modules> </args> </adminhtml> </routers> </admin> |
Così si risolverà il problema delle url in amministrazione.
Visualizzazione nelle pagine cms e nei blocchi statici
Il problema dei blocchi scomparsi è dovuto ad una nuova whitelist aggiunta con questa patch. In pratica, verrano visualizzati solo quei blocchi cms che sono presenti nella whitelist.
Da amministratore, puoi aggiornare questa lista andando rispettivamente in Sistema->Permessi->Variabili, e Sistema->Permessi->Blocchi, aggiungendo quello di cui hai bisogno e salvando
Se si sta creando un nuovo modulo o tema in cui sono previste variabili nei blocchi, pagine cms ed email transazionali, bisognerà creare un install script per l’inserimento di questi valori.
Se sei interessato a come scrivere un modulo per l’inserimento di valori nel db di Magento, puoi leggere questo articolo, Magento Install Script.
Se invece preferisci scaricare un modulo da personalizzare, ho provveduto a scriverne uno, Magento Project Variables Installer che utilizzo per i miei progetti, scaricabile gratuitamente da GitHub, le istruzioni su come utilizzarlo sono sul repository stesso.
I blocchi che di default hanno i permessi per essere visualizzati sono:
1 2 | core/template catalog/product_new |
Tutti gli altri blocchi, che si vogliono visualizzare tramite variabile, invece devono essere inseriti tramite il modulo.
Le variabili di default per le email transazionali invece sono:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | web/unsecure/base_url web/secure/base_url trans_email/ident_support/name trans_email/ident_support/email trans_email/ident_general/name trans_email/ident_general/email trans_email/ident_sales/name trans_email/ident_sales/email trans_email/ident_custom1/name trans_email/ident_custom1/email trans_email/ident_custom2/name trans_email/ident_custom2/email general/store_information/name general/store_information/phone general/store_information/address |
Anche qui, se si ha necessità, si deve inserire tramite modulo la variabile che si desidera.
Malfunzionamenti login e password
La patch applica due form_key al file template/customer/form/register.phtml, template/customer/form/resetforgottenpassword.phtml, template/persistent/customer/form/register.phtml, template/persistent/customer/form/resetforgottenpassword.phtml e relative configurazione xml in layout/customer.xml.
Se nel tuo tema sono state apportate modifiche a questi file, bisognerà quindi aggiungere:
1 | <input name="form_key" type="hidden" value="<?php echo Mage::getSingleton('core/session')->getFormKey() ?>;" /> |
ai relativi form. Altre modifiche vanno applicate per quanto riguarda alle istruzioni in customer.xml, se sono state ridefinite da zero.
Puoi vedere le differenze tra come era prima della patch e come è ora cliccando sui link sottostanti:
- app/design/frontend/base/default/layout/customer.xml
- app/design/frontend/base/default/template/customer/form/register.phtml
- app/design/frontend/base/default/template/customer/form/resetforgottenpassword.phtml
[…] Fate particolare attenzione se decidete di installare la patch SUPEE-6788, in quanto questa è una delle pochissime patch con compatibility break. Dovrete andare a modificare manualmente alcuni file phtml del vostro tema personalizzato oppure, se avete acquistato un tema di terzi parti, aggiornarlo all’ultima versione disponibile. In ogni caso, ho scritto un articolo apposito riguardante questa particolare patch che è sicuramente il caso di leggere. Magento 1.9.2.2 e SUPEE-6788 […]