Création d’un module Magento de formulaire d’abonnement Mailjet

Cet article explique comment créer un module Magento de formulaire d’abonnement à une newsletter pour Mailjet.

Le module Feub Mailjetform dans l'interface d'admin de Magento
Le module Feub Mailjetform dans l’interface d’admin de Magento

Cette semaine j’ai du effectuer une migration (c’est un bien grand mot) de Mailchimp vers Mailjet, le leader européen en matière de service pour l’emailing marketing, principalement pour des raisons de coût, car il faut l’avouer, il n’y a pas photo avec Mailchimp qui est vite cher pour des petits/moyens volumes.

Bref, après la configuration du back office, une des choses les plus naturelles à faire est d’intégrer un formulaire d’abonnement, et bien qu’elle ne fut pas ma surprise de ne rien trouver du côté de Mailjet. Il existe bien un petit générateur de widget très minimaliste qui crée un bout de code iframe à insérer dans son code, un peu léger car pas moyen de personnaliser l’apparence du formulaire. L’autre solution, c’est de taper dans l’API et d’écrire son propre code.

J’ai donc cherché pas mal en ligne pour trouver un module pour Magento, en vain. Je me suis rabattu sur du PHP lambda à intégrer, un bout de code pour ajouter un banal formulaire de souscription à une newsletter Mailjet. Rien, même après plusieurs heures.

J’ai donc décidé que j’allais écrire mon propre module Magento en utilisant l’API de Mailjet.

Continuer la lecture de « Création d’un module Magento de formulaire d’abonnement Mailjet »

Laravel : ignorer une règle de validation unique lors d’un update

Un petit point de base manquant dans les règles de validation d’un formulaire du framework Laravel est le cas où on veut ignorer un champ unique lors d’une mise-à-jour. Je m’explique. Prenons le début d’une classe modèle de gestion d’utilisateurs avec les règles de validation dans un attribut statique comme suit :

class User extends Eloquent
{
	public static $rules = array(
		'name'					=> 'required|alpha|min:2',
		'username'				=> 'required|alpha|min:2',
		'email'					=> 'required|email|unique:users,email',
		'password'				=> 'required|alpha_num|between:6,12|confirmed',
		'password_confirmation'	=> 'required|alpha_num|between:6,12'
	);
	
	// ...

On voit que l’email doit être unique, pas de problème lors de l’ajout, mais lorsque l’on met à jour un utilisateur, cette règle nous bloque, car l’email doit être unique. Il existe un moyen d’ignorer un certain ID en l’ajoutant à la fin, comme ceci 'required|email|unique:users,email,10', mais il est difficile d’ajouter cet ID dynamiquement dans le modèle sans ajouter du bruit à notre code. Une solution consiste à laisser le modèle en l’état, mais de hacker cet élément du tableau de règle depuis la méthode d’update du controlleur :

public function postUpdate($id)
{
	$user = User::find($id);

	// On récupère les règles
	$userrules = User::$rules;
	
	// On met à jour la règle pour le champ email avec l'ID courant
	$userrules['email'] = 'required|email|unique:users,email,' . $id;

	// Validation des champs
	$validator = Validator::make(Input::all(), $userrules);

	if ($validator->passes()) {
	
	// ...

Il semble un peu bizarre que ce mécanisme ne soit pas pris en compte par défaut dans Laravel, en espèrant qu’il le soit dans une prochaine version.