Quelque soit le raisonnement et le code source déployé, si petit soit-il, le traitement doit s’exécuter à la perfection.

J’en envie de vous rapporter deux citations qui me tiennent à cœur, et que je garde en tête comme une philosophie fondamentale pour avancer :

Beaucoup de choses motivent les développeurs :

• la fierté artistique
• la satisfaction du travail bien fait proche de l’artisanat
• le sentiment idéaliste de faire partie de quelque chose de plus important que vous, quelque chose qui vous dépasse
• le désir d’aider le monde et de trouver des solutions aux problèmes

En l’absence de rémunération, dans la plupart des cas, les gens cherchent surtout à se forger une réputation auprès de leurs pères.

Eric Raymond (Programmeur et inventeur du terme Open Source)

Pour moi le code présente beaucoup de similitudes avec la poésie ou certains genres d’écritures. Sa beauté réside dans sa structure et dans le fait de classer les idées une par une de façon claire.

Si le code est bon, vous pouvez le lire, sans commentaires. Vous comprendrez immédiatement pourquoi il a été écrit et combien il est élégant.

Vous recherchez un code à la fois élégant et clair, mais qui ne repose pas sur des astuces de programmation, qui ne fasse pas d’hypothèses qui risqueraient de s’avérer fausses à l’avenir, parce-que la dernière chose que vous voulez, c’est avoir trop de code dans le noyau final.

Le but n’étant pas de programmer et de reprogrammer à l’infinie.

Alan Cox (Programmeur et bras droit de Linus Torvalds)

2 options sont donc envisageables pour PrestaShop

Si vous êtes un développeur / intégrateur, si vous avez besoin d’une assistance ponctuelle pour résoudre un problème de comportement anormal sur votre boutique ou si vous avez une page blanche et que vous ne comprenez pas pourquoi, etc., alors éditez votre fichier ./config/config.inc.php, et modifier les variables telles qu’elles sont présentées ci-dessous :

/* Debug only */
@ini_set('display_errors', 'on');
define('_PS_DEBUG_SQL_', true);

$start_time = microtime(true);

/* Compatibility warning */
define('_PS_DISPLAY_COMPATIBILITY_WARNING_', true);

Si vous ne constatez rien d’anormal, si votre boutique est en production, ou si vous n’êtes pas en phase de développement ou de débug, alors éditez votre fichier ./config/config.inc.php, et modifier les variables telles qu’elles sont présentées ci-dessous :

/* Debug only */
@ini_set('display_errors', 'off');
define('_PS_DEBUG_SQL_', false);

$start_time = microtime(true);

/* Compatibility warning */
define('_PS_DISPLAY_COMPATIBILITY_WARNING_', false);

Le debug de smarty peut vous aider

Il existe aussi la possibilité d’activer la résultante complète du template Smarty en cours d’exécution. Ce mode débug n’est pas un résultat d’erreurs, mais un contenu permettant de visualiser si les démarches du développeur sont bien prises en compte pour l’intégration des traitements et des valeurs dans le template de la boutique PrestaShop. Vous pouvez alors l’activer ponctuellement en éditant votre fichier ./config/smarty.config.inc.php, et en autorisant la valeur ci-dessous :

$smarty->debugging = true;

Pensez à remettre cette valeur à false par défaut, une fois vos démarches terminées.

Vous souhaitez sécuriser un peu plus votre hébergement web

Ce qui suit ne s’arrête pas simplement à l’usage de PrestaShop dans votre hébergement web, mais ceci est une partie des optimisations web qui font la différence au quotidien et sur Internet en terme de sécurité et de garantie d’avoir un site web qui dure dans le temps.

Si votre hébergement web fait partie d’un service web que vous gérez, et si les publications web mises à disposition sont vouées à l’utilisateur final et non à un mode de développement ou de pré-production, alors je vous conseille vivement de modifier un élément important dans votre fichier php.ini, et de le désactiver comme ceci :

display_errors = Off

Cette option est associée à la variable error_reporting de ce même php.ini. Elle permet de donner le niveau d’alertes à afficher si des erreurs et/ou warnings failliraient le traitement. En mode de développement pure, il convient de passer cette valeur comme ceci :

error_reporting = E_ALL | E_STRICT

Ce niveau permet au développeur d’afficher l’ensemble des erreurs et warnings, même de bas niveaux, ce qui assure pendant toute la phase de développement la création d’un code propre et fonctionnel. Mais le rapport d’erreur ne s’affichera que si sa dépendance display_errors est activée. C’est pour cela qu’il convient de passer l’option display_errors à false par défaut sur votre serveur web en production, ce qui n’est pas le cas par défaut habituellement.

Dans le cas où vous n’avez pas l’accès à ce fichier de configuration php.ini, vous pouvez essayer de contrôler cette option par le biais du .htaccess (de préférence celui à la racine du votre dossier web), ou par code php (de préférence avant tous les traitements).

Désactiver l’affichage des erreurs depuis le fichier .htaccess

Si vous en avez les autorisations dans les options de votre hébergement, la ligne suivante fera l’affaire en haut de votre fichier .htaccess :

php_flag display_errors off

Désactiver l’affichage des erreurs depuis le code

Si vous en avez les autorisations dans les options de votre hébergement, la ligne suivante en début des traitements php pourra annuler l’affichage des messages d’erreurs php :

error_reporting(0);

De même pour les templates Smarty, propre à PrestaShop, et à spécifier après le chargement du framework Smarty Template :

$smarty->error_reporting = 0;

Pour php, vous avez aussi la possibilité de contrôler les niveaux d’alertes :

// Rapporte les erreurs d'exécution de script
error_reporting(E_ERROR | E_WARNING | E_PARSE);

// Rapporter les E_NOTICE peut vous aider à améliorer vos scripts
// (variables non initialisées, variables mal orthographiées..)
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);

// Rapporte toutes les erreurs à part les E_NOTICE
// C'est la configuration par défaut de php.ini
error_reporting(E_ALL ^ E_NOTICE);

// Reporte toutes les erreurs PHP (Voir l'historique des modifications)
error_reporting(E_ALL);

// Reporte toutes les erreurs PHP
error_reporting(-1);

// Même chose que error_reporting(E_ALL);
ini_set('error_reporting', E_ALL);

Parano, non, mais prévoyant

Je pense que cet article peut inviter les développeurs web, les agences web, ou même monsieur tout le monde qui s’initie au développement, a considérer que les publications dynamiques sur le web sont des proies permanentes sur Internet. Si vous autorisez l’affichage d’erreurs, et que vous-même pensez que 99% de votre site est bien conçu, les 1% restant générant des erreurs sur des pages introuvables, de code, ou pire, des erreurs SQL, peuvent être indexés par les moteurs de recherches. Si vous utilisez un framework connu, un CMS en vogue, votre site web peut sortir dans les résultats de recherches liés à des erreurs engendrant des tentatives d’intrusions, ou des injections SQL ou de codes.

En conclusion, soyez prévoyant sur cet aspect parfois délesté.

Beaucoup souhaitent ajouter/afficher des données que tel ou tel contrôleur n’a pas forcément assigné à smarty et qui sont donc inaccessibles dans les fichiers .tpl .

Quand un contrôleur donné ne fourni pas ces éléments , il faut alors soit modifier le contrôleur (ou le surcharger bien sûr), soit disposer d’une fonction smarty qui permet, depuis un élément à notre disposition , d’en obtenir un ou plusieurs autres.

Il y a une foultitude d’applications de la méthode présentée ici, que je vous laisse apprécier vous même…

J’aborde donc deux notions ici , celle de la création d’un module absolument basique , mais suffisant à l’ « exercice » , ainsi qu’une fonction native de smarty absolument essentielle à son extension et très largement utilisée par PrestaShop.

Pour commencer , mais sans m’étendre , car il existe d’excellents tutoriels déjà sur la création d’un module je vais définir mon module de base , que je nommerais « mysmarty« .

Pour éviter toute frustration je commente malgré tout les lignes liées à cette étape , rien de sorcier mais si ça peut aider …

A noter que devant l’imminence de la sortie de la 1.5 , le code fourni n’est pas compatible avec la 1.3 , mais peut être adapté bien sûr … tout comme il devra l’être pour la 1.5 .

Si besoin je m’étendrais un peu sur les différences et raisons qui font que ce code ne tournera ni sur la 1.3 ni sur la 1.5 , mais pour l’heure je me borne au présent tutoriel.

Dans smarty , on peut donc enregistrer deux types de codes personnalisés , à savoir le type plugin, qui sont des fonctions classiques pouvant retourner à peu près n’importe quoi , et le type modifiers, qui eux appliquent une modification à la chaine qui le précède .

Un exemple de plugin dans smarty est par exemple Convertprice .

Un exemple de modifier est le modifier Truncate , qui permet de tronquer une chaine.

Dans l’exemple présent je m’intéresse au type plugin. Il faut savoir qu’il y a deux façons d’enregistrer un plugin , et c’est là où je souhaite en venir avec cette article. Nombre de fonctions enregistrées sont des méthodes statiques, qui ont leur intérêt mais aussi leurs limites.

Mais il est également possible comme on va le voir ici d’enregistrer des méthodes d’instance, et pouvoir donc utiliser les méthodes héritées de l’instance d’objet , comme une , relativement intéressante , la fonction l héritée de Module.

On y va, nous créons donc un dossier mysmarty , dans le dossier modules, dans lequel on crée un fichier mysmarty.php :

Bien sûr on commence par déclarer la classe (le module donc):

<?php
// déclaration de la classe : tout module étend la classe Module
class MySmarty extends Module
{

Ensuite un constructeur :

    // le constructeur , indispensable pour que le module soit géré et affiché en back office notamment
    public function __construct()
    {
	// NB : la propriété name doit impérativement correspondre au nom de classe , en minuscule
	$this->name = 'mysmarty';
	// la section dans laquelle sera classé le module , ici fonctionnalités front office...
	$this->tab = 'front_office_features';
	$this->version = "1.0"; // no comment , n'est-ce pas ?
	// mine de rien, à défaut de vouloir réécrire une tonne de code déjà géré par la classe parente, on doit tout de même appeler son constructeur
	parent::__construct();
	$this->author = 'Broceliande'; // besoin de commentaire là dessus ?
	$this->displayName = $this->l('Smarty Funcs'); // nom affiché dans le BO , l'utilisation de la fonction l héritée de Module permet de rendre ceci multilingue
	$this->description = $this->l('Adds smarty usefull funcs'); // idem pour la description
    }

Vient le tour de l’ « installeur » du module. On souhaite que la fonction smarty soit définie le plus tôt possible pour y avoir accès partout dans les tpl . Pour cela le hook header est idéal , car à ce stade aucun tpl n’est encore chargé.

    public function install()
    {
	// on souhaite que la fonction soit disponible partout , alors on greffe le module sur le hook header
	if  (!$this->registerHook('header')) return false;
	// on laisse la classe parente faire son job
	if (!parent::install())	return false;
	return true;
    }

enfin puisque le module est greffé sur le hook header , il convient d’implémenter la méthode qui sera automatiquement appelée par presta. C’est ici que nous allons enregistrer notre (ou nos) fonction(s) dans smarty :

    public function hookHeader($params)
    {
	// ceci changera dans la 1.5 avec la disparition des globales et l'apparition du contexte...
	global $smarty;
	// c'est la seule ligne un peu particulière de ce module
	// on définit un callback vers une instance du module:  $this est bien sûr le module , & devant permet de le passer par référence
	$callback = array(&$this,'maFonctionSMarty');
	$type =
	// l'enregistrement proprement dit dans smarty
	// methode implémentée dans prestashop (smarty.config.inc.php)
	// cette methode fonctionne aussi bien pour smarty 2 que pour smarty 3
	smartyRegisterFunction($smarty, 'function', 'maFonctionSMarty', $callback);
	// une alternative , appeler la methode native de l'objet smarty , mais il y a une syntaxe différente selon la version de smarty : ici la syntaxe smarty 3
	//$smarty->registerPlugin('function', 'maFonctionSMarty', $callback);
    }

C’est fait , on a enregistré notre méthode maFonctionSmarty , mais évidemment il faut également définir cette méthode (on préfère dire implémenter):

    public function maFonctionSMarty($params)
    {
	return $this->l('mon texte traduit');
    }

Voilà qui est fait.

On ferme tout de même la classe ainsi crée :

}

L’exemple est on ne peut plus basique, mais la chose intéressante est que la chaîne affichée sera administrable avec les traductions du présent module.

Vous pouvez donc dans la méthode maFonctionSmarty intégrer tout appel type $this->method() , etc, ce qui représente un avantage certain dans beaucoup de cas , et dont je vous laisse apprécier l’intérêt.

Il reste à voir comment sera appelée cette méthode fraîchement enregistrée dans vos tpl :

Selon les besoins , on peut ou non passer des paramètres à la fonction .

Sans paramètre , on appellera la fonction de cette manière dans le tpl :

{maFonctionSmarty}

Avec paramètres

{maFonctionSmarty monParametre="toto" monParametre2=3}

A noter que ces paramètres sont transmis sous forme de tableau.

On accédera donc à ces derniers de cette manière :

    public function maFonctionSMarty($params)
    {
	$monParametre = $params['monParametre'];
	$monParametre1 = $params['monParametre1'];
	return $this->l('parametres: ').$monParametre.", ".$monParametre1;
    }

C’est tout pour cette fois mais je considère que cet article n’est qu’une introduction et devra probablement être approfondi et complété selon vos questions/commentaires tant les possibilités sont vastes.

Merci de votre lecture

• Le guide du développeur
• Le guide du designer / intégrateur

Contenu du guide du développeur :

• Créer un module PrestaShop
• Tutoriels pour développeurs
• Tutoriel Webservice REST
• Chapitre 1 – Mise en place _ Création des accès dans le Back Office
• Chapitre 2 – Découverte _ Tester l’accès au service web avec le navigateur
• Chapitre 3 – Premiers pas _ Accéder au service web et lister les clients
• 3.1 Accéder au service web
• 3.2 Gestion des erreurs
• 3.3 Lister les clients
• Chapitre 4 – Récuperer des données _ Récupérer un client
• Chapitre 5 – Modification _ Mettre à jour un client
• Chapitre 6 – Création _ Formulaire d’ajout à distance
• Chapitre 7 – Suppression _ Retirer des comptes client de la base
• Chapitre 8 – Utilisation avancée
• Mémento _ Notions énoncées dans ce tutorial
• Modules, surcharge, web service
• Mieux comprendre et utiliser les hooks
• La synchronisation via les Hooks
• Cours de sécurité accéléré no. 1 – Never trust foreign data
• Cours de sécurité accéléré no. 2 – Injections SQL
• Surcharge et override
• Les bonnes pratiques de la classe Db sur Prestashop 1.4
• Cours de sécurité accéléré no. 3 – XSS
• Les modules transporteurs – fonctionnement, création, configuration
• Cours de Sécurité accéléré no. 4 – CSRF

Contenu du guide du designer / intégrateur :

• Conseils de design
• Penser en amont
• Recommandations techniques
• Ergonomie
• Créer un thème
• Concepts et informations techniques
• Personnaliser le thème par défaut
• Créez votre propre thème
• Intégration : où vont les points d’accroche et les modules

Le projet est en fait un portage du célèbre framework Zend, sur la plateforme PrestaShop (qui elle même est son propre framework). Les avantages et inconvénients sont à débattre et dans tous les cas, cette initiative mène tout de même à plusieurs réflexions qui feront plus tard de PrestaShop un outil de plus en plus évolutif et ouvert.

On peut imaginer que des projets déjà en place avec Zend puissent s’intégrer facilement sur PrestaShop comme modules supplémentaires, par simples installations de ces derniers. Vous pouvez suivre la discussion à cette adresse : http://www.prestashop.com/forums/topic/145847-outils-oops-un-framework-pour-prestashop.

L’auteur met aussi à disposition ses sources et l’archive, en libre accès sur https://github.com/alexsegura/Oops

Ce qu’il nous faut au préalable

Pour notre exemple, nous allons travailler dans le répertoire du module nommé MonModule, soit /modules/monmodule/. Dans ce dossier, nous allons créer la structure de fichiers qui va permettre de tirer profit de la traduction linguistique du contenu des mails. Ainsi, il convient de créer la structure suivante (ceci est une proposition) : cf. Image 1.

Image 1

NB : Les fichiers index.php que l’on retrouve dans chaque répertoire ont leur utilité dans le redirection vers la page principale de la boutique, afin d’éviter l’accès, le listage, l’indexage ou l’archivage du contenu du dossier. Je vous mets à disposition en bas de page un éventuel contenu* pour ces fichiers index.php.

L’arborescence du module est entourée en rouge. On y retrouve le chemin de la classe du module /modules/monmodule/monmodule.php avec lequel vous savez déjà travailler. Les répertoires et les fichiers utiles aux traductions sont construits ainsi :

• /modules/monmodule/mails/[langue]/monmessage.html
• /modules/monmodule/mails/[langue]/monmessage.txt

[langue] prend le code des langues que vous souhaitez utiliser dans vos traductions (en, fr, es, it, …), tout en sachant que les langues disponibles aux visiteurs sont celles que vous avez choisi. A défaut de traductions, la langue de fonctionnement est celle du noyau soit l’anglais (en).

le fichier monmessage.html

Ce fichier correspond à la version HTML de votre message. La grande majorité des clients de messagerie autorisent pas défaut l’affichage du contenu sous forme de « page web ». Ceci permet d’enrichir un peu plus les contenus, de créer des tableaux, d’intégrer des images, etc. La visualisation des contenus html est donc possible dans vos clients de messagerie, mais controversé en terme de sécurité.

Voici un exemple de contenu en anglais pour le fichier /modules/monmodule/mails/en/monmessage.html :

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">
<html>
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	<title>Message from {shop_name}</title>
</head>
<body>
	<p><a href="{shop_url}" title="{shop_name}"><img alt="{shop_name}" src="{shop_logo}" style="border:none;" ></a></p>
	<p>Date : {date}</p>
	<p>Message :</p>
	<p>{message}</p>
	<p>-----------------</p>
	<p><a href="{shop_url}">{shop_name}</a> powered by <a href="http://www.prestashop.com/">PrestaShop™</a></p>
</body>
</html>

le fichier monmessage.txt

Pour de raison de sécurité, la version HTML des mails peut-être en option sur le client de messagerie, il est important de garder le contrôle du contenu afin d’envoyer un texte cohérent au destinataire. Il faut donc créer ainsi une version texte de ce contenu. Il sera en revanche impossible de créer des tableaux, ni même d’afficher des images.

Voici un exemple de contenu en anglais pour le fichier /modules/monmodule/mails/en/monmessage.txt :

Message from {shop_name}

Date : {date}
Message :
{message}

-----------------
{shop_url} powered by PrestaShop™

Les templatevars

Sur les deux exemples précédents des fichiers monmessage.html et monmessage.txt, des variables à contenu « dynamique » y sont utilisées. Ces variables sont encadrées par des accolades :

• {shop_name} : cette variable est déjà garnie et disponible par le noyau, elle contient le nom de la boutique web.
• {shop_url} : cette variable est elle aussi déjà garnie et disponible par le noyau, elle contient l’adresse principale de la boutique web.
• {date} : cette variable contiendra la date en cours, construite sur le format de la langue en cours.
• {message} : cette variable contiendra le message à faire passer, dans la langue du client.

A la manière du moteur smarty template, et afin de pouvoir utiliser ces variables, du moins celles de notre cru : {date} et {message}, il convient de les mettre à contribution dans notre module au préalable.

La fonction d’envoi de mail avec la gestion des langues

Voici un exemple de la méthode EnvoyerMessage() de la classe MonModule à utiliser pour l’envoi des mails avec la gestion des langues.

/*
 * Cette fonction peut être directement utilisée dans votre classe du module
 * Fonctions accessibles depuis la méthode de la classe MonModule :
 * $this->l()			: pour que le texte soit gérée par les langues de PrestaShop
 * Configuration::get()	: pour récupérer des valeurs de configuration
 * Tools::displayDate()	: pour récupérer la date lors de l'envoi du mail, au format de la langue en cours
 */
class MonModule extends Module {
	/*
	 * Ici se trouve normalement tout le contenu de votre classe MonModule :
	 * Méthodes, variables, etc.
	 */

	private function EnvoyerMessage() {
		global $cookie;
		$LangueAUtiliser = (int)$cookie->id_lang;	// id de la langue, vous pouvez aussi utiliser (int)Configuration::get('PS_LANG_DEFAULT'),
													// pour forcer les mails avec la langue par défaut de la boutique

		$Destinataires = array(
								"pierre@domaine.tld",
								"paul@domaine.tld"
								);

		if (sizeof($Destinataires)) { // seulement s'il existe au moins 1 destinataire
			foreach($Destinataires As $Destinataire) {
				Mail::Send(
					$LangueAUtiliser,				// langue
					'monmessage', 					// nom du fichier template SANS L'EXTENSION
					$this->l('Subject title'),		// sujet à traduire dans les langues du module
					array(							// templatevars personnelles
							'{date}'	=> Tools::displayDate(date("Y-m-d H:i:s"), $LangueAUtiliser, true),
							'{message}'	=> $this->l('Here is the message to be sent by mail.')
						),
					$Destinataire, 									// destinataire mail
					NULL, 											// destinataire nom
					strval(Configuration::get('PS_SHOP_EMAIL')),	// expéditeur
					strval(Configuration::get('PS_SHOP_NAME')),		// expéditeur nom
					NULL,											// fichier joint
					NULL,											// Choix SMTP, non traité par le coeur < PS 1.4.6.1, donc inutile
					dirname(__FILE__).'/mails/'						// répertoire des mails templates
				);
			}
		}
	}
}

Cette méthode est accessible depuis l’appel $this->EnvoyerMessage() à l’endroit que vous souhaitez dans votre classe du module. Des variantes sont aussi possibles avec le passage en paramètres des destinataires, de la langue, etc.

A vous de jouer !

Le concept étant posé, à vous d’ajouter toutes les templatevars dont vous avez besoin, avec les contenus que vous souhaitez.

* Contenu éventuel d’un fichier index.php afin de gérer la redirection vers la page d’accueil :

<?php
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");

header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

header("Location: ../");
exit;
?>

/* Debug only */
@ini_set('display_errors', 'on');
define('_PS_DEBUG_SQL_', true);

Pensez à repasser ces valeurs à off et false par la suite.

Si vous avez un beau message d’erreur du type Allow memory size…, ou Out of memory…, c’est que la configuration du serveur de votre hébergeur web ne vous permet pas de pousser les ressources un peu plus haut qu’à l’habitude. Malheureusement, si vous n’êtes pas votre propre hébergeur, vous n’avez certainement pas la possibilité de modifier l’option memory_limit dans le php.ini. Il faut donc dans votre fichier /config/config.inc.php ajouter la ligne suivante après les deux lignes vu précédemment :

/* Debug only */
@ini_set('display_errors', 'off');
define('_PS_DEBUG_SQL_', false);
ini_set('memory_limit', '64M');

La page blanche devrait ensuite disparaître pour un contenu plus attendu !

J’appelle « dynamiques » toutes les données passées en paramètres soit par des méthodes POST depuis un formulaire par exemple, soit par GET depuis une URL (l’adresse web complète avec comme attributs les fameux ?beta=para[...]).

Quelque soit le fork que vous employez pour mener à bien votre développement personnel, vérifiez que des orientations sécuritaires du même genre que celles que je décris ici sont bien disponibles ou présentes dans votre code source. Sinon, il va falloir les créer.

Quant à PrestaShop ?

L’idée de départ serai de vouloir récupérer, soit par un code de module, soit dans une page tierce de votre confection (sur un nouveau controller de page, par exemple), des données passées en paramètres. Celles-ci sont envoyées grâce à un formulaire, et donc par défaut, à l’aide à la méthode POST (vérifiez que vous possédez bien method=post dans votre balise de formulaire). Nous pouvons imaginer la séquence html suivante :

<form action="#" method="post">
    <input type="text" name="MonPara" value="" />
</form>

Une fois ce formulaire posté, il faut le traiter en toute sécurité. Contrairement à vos réflexes de développeur, vous n’allez pas directement accéder au contenu du tableau $_POST, qui réuni l’ensemble des données postées par le formulaire. L’erreur serai donc de lire le contenu ainsi :

$MaValeur = $_POST["MonPara"];

En revanche, vous allez exploiter une méthode déjà travaillée par la team PrestaShop pour sécuriser la récupération des données. Celle-ci est disponible depuis le noyau de toutes les versions PrestaShop, grâce à la classe Tools (située dans /classes/Tools.php) :

	/**
	* Get a value from $_POST / $_GET
	* if unavailable, take a default value
	*
	* @param string $key Value key
	* @param mixed $defaultValue (optional)
	* @return mixed Value
	*/
	public static function getValue($key, $defaultValue = false)
	{
	 	if (!isset($key) OR empty($key) OR !is_string($key))
			return false;
		$ret = (isset($_POST[$key]) ? $_POST[$key] : (isset($_GET[$key]) ? $_GET[$key] : $defaultValue));

		if (is_string($ret) === true)
			$ret = urldecode(preg_replace('/((\%5C0+)|(\%00+))/i', '', urlencode($ret)));
		return !is_string($ret)? $ret : stripslashes($ret);
	}

Pourquoi cette méthode ?

Elle garantie un retour de contenu sans aucune donnée « malsaine » tels que les double-quotes bien connus des tentatives d’injections SQL, ou bien des injections de code javascript.

Elle permet aussi de passer en revue soit la méthode POST, soit GET. Ainsi, quelque soit son usage, vous n’avez plus à les différencier.

Comment dois-je m’en servir ?

Il convient au préalable d’avoir inclue l’ensemble des librairies nécessaires du noyau PrestaShop. Si vous passez par un controller ou un module, vous n’aurez pas de problème. En revanche, si vous avez créés votre propre page de code, vérifiez que vous incluez bien au minimum :

include('config/config.inc.php');

Enfin, pour utiliser cette méthode plus sécuriser, il vous suffit simplement de procéder ainsi (dans le cas de l’exemple ci-dessous) :

$MaValeur = Tools::getValue("MonPara");

Et c’est tout ?

Malheureusement, il subsiste un petit problème tout de même, mais celui-ci reste très bénin et ne vous pénalisera pas pour 98% de votre code. Imaginons que sur une même page, la méthode GET et POST sont employées en même temps, car ceci est tout à fait possible à l’aide d’un formulaire, et que pour un même paramètre à passer, vous ayez deux valeurs différentes, il faudra contourner ce problème.

Je vous le présente plus en détails, par le formulaire ci-dessous :

<form action="mapage.php?MonPara=12" method="post">
    <input type="text" name="MonPara" value="14" />
</form>

Vous comprendrez vite que le paramètre MonPara est envoyé par la méthode GET depuis l’action du formulaire, et par la méthode POST depuis l’input, et ne possède pas la même valeur. Ce qui serai bloquant pour vos traitements postérieurs. Il n’y a pas vraiment de recette miracle, même s’il l’emploi distinct dans votre code de $_GET["MonPara"] et de $_POST["MonPara"] serai tentant, je ne le vous conseille pas. Préférez simplement changer le nom de l’une ou l’autre variable afin d’éviter des problèmes plus graves :

<form action="mapage.php?MonPara1=12" method="post">
    <input type="text" name="MonPara2" value="14" />
</form>

A vous de jouer !

Les codes sources proposés permettent à l’intéressé de mieux comprendre la logique et l’algorithmique d’un traitement, d’un script, d’une portion de script, ou d’une méthode particulière. L’éditeur de ces ressources (DevNet) ne pourra être tenu pour responsable des manipulations personnelles effectuées par l’intéressé suite à la récupération de ses informations.

Bonne lecture !