Capita di solito che un prodotto proveniente dall’immensa galassia open-source faccia praticamente tutto quello che serve ma – ahimé, per i programmatori – che non raggiunga l’assoluta eccellenza nelle personalizzazioni di cui si abbisogna.
Ecco, Prestashop è un prodotto praticamente perfetto, che di base possiede una innumerevole possibilità di personalizzazioni. Ma questa quantità, per quanto grande, non è mai sufficiente quando le sfide del mercato e del SEO si parano sempre rinnovate contro gli shop online.
Oggi vediamo come aggiungere una piccola personalizzazione al nostro negozio online che si adatterà a molteplici usi. Nel caso dell’esempio, abbiamo la necessità di rendere “globale” il valore della partita IVA e del nome dell’azienda di un determinato utente registrato e loggato. Questa necessità si pone nel caso si voglia personalizzare con offerte speciali, frasi ad-hoc, contenuti dinamici qualsiasi pagina dello shop.
La variabile partita IVA, infatti, non è compresa tra quelle globali accessibili tramite smarty (uno pseudo linguaggio di scripting minimale utilizzato da Prestashop per la composizione dei template, di cui magari parleremo più approfonditamente in un futuro articolo). In questo caso dovevo scegliere se mettere mano al Model del sistema (cosa che mi terrorizzava oltremodo) oppure ricorrere ad altra via. La scelta è caduta sullo sviluppo di un modulo ad-hoc che – se attivato – rende il contenuto di questo immediatamente disponibile in tutto lo shop.
Cosa serve per sviluppare un modulo minimale per Prestashop? Solo tre file!!!
– il file php che svolge le operazioni, solitamente nominato come il modulo (in questo caso, piva)
– un file config.xml che verrà letto dal back office
– un’icona identificatica (logo.gif)
Ecco il contenuto del file xml:
<?xml version=”1.0″ encoding=”UTF-8″ ?>
<module>
<name>ultimateXML</name>
<displayName><![CDATA[PIVA]]></displayName>
<version><![CDATA[1]]></version>
<description><![CDATA[PIVA]]></description>
<author><![CDATA[Fabio]]></author>
<tab><![CDATA[migration_tools]]></tab>
<is_configurable>1</is_configurable>
<need_instance>1</need_instance>
<limited_countries></limited_countries>
</module>
In questo caso, personalizzatelo come meglio credete.
Andiamo invece al “core” vero e proprio del modulo. Apriamo una classe come segue:
class piva extends Module
{
}
Questo dice a Prestashop di considerare la classe piva come una normale estensione della classe madre “module”.
All’interno della classe mettiamo:
public function __construct()
{
$this->name = ‘piva‘;
$this->tab = ‘front_office_features‘;
$this->version = 0.1;
$this->author = ‘Fabio‘;
parent::__construct();
$this->page = basename(__FILE__, ‘.php’);
$this->displayName = $this->l(‘Piva’);
$this->description = $this->l(‘Visualizza la PartitaIVA’);
}
Questo è il construct della classe. Ovvero la parte che viene sempre precaricata in memoria dal serve ogni volta che l’oggetto viene istanziato (indipendentemente dal fatto che verrà poi usato).
Quelle qui contenute sono – ovviamente – le informazioni riguardanti il modulo e non credo si necessiti di ulteriori informazioni.
Su Prestashop ogni modulo caricato va SEMPRE installato. L’istallazione scrive nel DB che il modulo è pronto per essere attivato. Dobbiamo quindi dire a Prestashop che il modulo deve avere la possibilità di essere installato (e disinstallato).
public function install()
{
if (!parent::install() OR !$this->registerHook(‘header’))
return FALSE;
return TRUE;
}
public function uninstall()
{
if (!parent::uninstall())
return FALSE;
return TRUE;
}
L’obiettivo di questo modulo (o di altri similari) è quello di rendere una variabile, un contenuto o uno specifico marcatore visibile globalmente dallo shop. Quindi, nel metodo install() ho impostato come contenuto dell’oggetto di registrazione (registerHook) il valore ‘header’: questo implica che il modulo – e quindi ciò che questo restituisce – sarà caricato in ogni pagina nell’header.
Ma la funzione più importante è quella che segue:
public function hookHeader()
{
global $smarty;
$context = Context::getContext();
$id_lang = $context->cart->id_lang;
$customer = $context->customer;
$id_customer = $customer->id;
$partitaiva = Db::getInstance()->executeS(“SELECT ” ._DB_PREFIX_. “customer.piva, “ ._DB_PREFIX_. “customer.company
FROM “ ._DB_PREFIX_. “customer
WHERE ” ._DB_PREFIX_. “customer.id_customer = ‘$id_customer’“);
if(!isset($partitaiva[0])) $partitaiva = FALSE;
$smarty->assign(‘piva’, $partitaiva);
$smarty->assign(‘company’, $partitaiva);
}
Questa funzione esegue la ricerca nel database partendo dalle variabili globali a nostra disposizione. Risulta chiaro che la combinazione di queste variabili può renderci conto di un enorme numero di possibilità e quindi di personalizzazioni. $id_lang, $customer, $id_customer sono ricavate dalle variabili globali che il sistema utilizza già e queste influenzeranno la nostra query e, di conseguenza, il nostro risultato.
(in questo caso, oltre al valore della partita IVA ho anche “catturato” la ragione sociale dell’azienda in company)
Infine:
public function getContent()
{
$content = NULL;
return $content;
}
Che altro non fa che restituire ciò che ci serve.
Alla fine avremo tre file. Zippateli e caricateli dal vostro Back Office. Avrete la vostra nuova variabile globale immediatamente accessibile dal vostro template.
Provate pure:
{if is_array($piva)} La partita IVA dell’utente è:{$piva[0][‘piva’]}{/if}
Alla prossima!
