Traduction française actualisée du plugin WordPress « Search Unleashed »

Ayant eu besoin récemment du plugin « Search Unleashed » pour un blog WordPress, et constatant que la version dans la langue de Molière n’était pas à jour, j’ai donc réalisé la traduction française actualisée du plugin Search Unleashed pour WordPress

(décompressez ce fichier .zip dans le dossier du module)

Merci à Vincent Granger pour la traduction initiale.

Using layer navigation in Prestashop

The layered navigation (since Prestashop 1.4 but, really usable in 1.4.5),  allows users to define in a simple way some criterias to filter category products (as you can find on CalumetPhoto or other shops).To use it, it is very easy : just define « templates » (group of criterias, like features (capacity, etc), brands, stock level).Once it have been done, you will be able to to link these templates to categories, for example the « DSLR cameras » for the cameras categories.
Each template can be used on as many categories as you want.

To use layered navigation, just follow these steps:

  • In back-office, go to Modules / Layered navigation block
  • Go to Build your own filters template and check Specific categories (0 selected):
  • In the block which appears, please select the categories on which you want to apply this template and click on Save this selection:
  • In the criteria list, you will be able to select some of them, by checking it:
  • Let’s give a name to this selection and click on Save this filter template

With the example data above, the resulting block on the front-office will be, only for « Accessories » category, something like that:

Beware : the available criteria depend on the category you choose.

In our example, the products have not « features » (in a Prestashop way). But if I select the « iPods » category (iPods have « features »), the choices I can made will be different:

Utiliser la navigation à facettes de Prestashop

 

La navigation à facettes, apparue avec la version 1.4 de Prestashop (mais réellement utilisable à partir de la version 1.4.5), permet d’une manière assez simple de définir des critères pour filtrer les résultats d’une catégorie (comme on le retrouve sur Pixmania ou d’autres sites de e-commerce).Elle fonctionne de la manière suivante : vous allez déterminer des modèles (c’est à dire un ensemble de critères, comme les caractéristiques (capacité, etc), les marques, l’état du stock, etc).Ensuite vous allez pouvoir associer ces modèles à des catégories, par exemple le modèle « pour les appareils photo » aux catégories comprenant les appareils photo.

Continuer la lecture de « Utiliser la navigation à facettes de Prestashop »

Traduction française actualisée du plugin WordPress « Custom Field Template »

Dans un de mes récents projets, j’ai (re)découvert le plugin « Custom Field Template », qui vous permet de facilement créer des formulaires d’édition de vos champs personnalisés (en clair, étendre les champs associés à un article, par exemple pour des annonces immobilières).

La traduction française fournie avec la dernière version (au 01/12/2011) datant un peu, voici la traduction française actualisée du plugin Custom Field Template pour WordPress

(décompressez le contenu du .zip et copiez-le directement dans le dossier du plugin)

Passer de BlogSpirit à WordPress : nouvelle version de l’importeur !

Suite à un commentaire de Capripot, j’ai découvert son travail sur l’importeur BlogSpirit vers WordPress que j’avais moi-même repris à l’époque. Il a notamment corrigé les problèmes suivants :

* importation des article se basant sur la page complète de la liste des articles par catégorie
* « / » en trop à la fin de l’adresse ce qui empêchait l’import des articles d’une catégorie
* bug de version lors de l’import dans wordpress)
* script un peu plus bavard
* choix du nom au départ ou écriture du nom du blog dans NOM_SITE.txt
* dialog.rb renommé en import.rb pour plus de clareté
* non blocage du script à la fin
* correction de l’import des commentaires
* ajout d’un fichier LISEZ-MOI

Télécharger nouvelle version importeur BlogSpirit vers WordPress

Son site : http://www.capripot.com/

Et vous pouvez retrouver l’outil pour passer d’OverBlog à WordPress sur la page dédiée

L’initiative #opendata69 (et petits rappels sur le principe des données ouvertes)

Les données ouvertes sont presque devenues le buzz word de la décennie, le passage obligé pour n’importe quelle administration, politique ou startup.

Mais avant d’être un mot à la mode, qu’est ce qu’on appelle l’Opendata ? Si on se réfère à la définition donnée par Wikipedia, « Une donnée ouverte (en anglais open data) est une information publique brute, qui a vocation à être librement accessible. La philosophie pratique de l’open data préconise une libre disponibilité pour tous et chacun, sans restriction de copyright, brevets ou d’autres mécanismes de contrôle. »

Cette définition n’est pas parfaite mais elle a le mérite d’expliquer le principe de base : il s’agit d’une donnée (publique,  ou privée, dans le cas d’entreprises agissant pour le compte des collectivités) pouvant être réutilisée à sa guise par un tiers, cela de manière désintéressée (par les citoyens eux-même ou via une association, etc) ou à des fins commerciales (intégration dans une application payante, par exemple).

Le principe d’ouverture de l’Opendata n’est pas « l’ouverture pour l’ouverture », mais correspond à plusieurs objectifs :

  • Transparence des actions menées par les entités publiques (budget, etc)
  • Possibilité d’appropriation par le simple citoyen des données publiques, et donc travailler à rétablir ce lien entre lui et l’administration, à la reprise en main par le « peuple » de la politique quotidienne de l’Etat
  • Egalité d’accès à l’information, que l’on soit pauvre ou riche, avec des contacts bien placés ou isolé
  • Confrontation de l’information à la réalité du terrain, et donc enrichissement en retour de cette information, par ses utilisateurs
L’Opendata a énormément d’applications pratiques. En voici quelques unes (existantes, ou potentielles) :
  • Montréal : l’arrondissement « Le Plateau Mont-Royal » a pris le parti d’interroger ses habitants sur les priorités budgétaires à donner, en leur permettant d’effectuer visuellement une simulation de leurs choix politiques
  • Rennes : l’ouverture des données publiques et de transport par Rennes Métropole et Keolis Rennes a permis la réalisation d’une application à destination des handicapés moteurs, leur permettant de calculer leurs trajets en fonction de l’accessibilité des lieux
  • Handicapés visuels : si la liste des feux rouges « avec vibreur » était publique, ils pourraient également optimiser leurs trajets en fonction de ce critère
  • Transports en Commun Lyonnais (TCL) : les plans et horaires n’étant pas disponibles de manière ouverte, il n’est pas possible de monter une application les utilisant (ou même un site de remplacement ajoutant des fonctionnalités à l’existant, comme la mémorisation des arrêts favoris). On peut également citer le problème rencontré par « Check My RATP », atttaqué en justice par la RATP pour « piratage » des tracés des lignes, donnée pourtant publique.
  • Revenu moyen par ville/quartier : cette information permettrait aux associations d’optimiser leurs campagnes de dons
  • etc

Cependant, on constate au quotidien plusieurs freins à sa mise en place :

  • budget : en effet, collecter ces données, les ordonner et les mettre à disposition a un coût (très variable), d’où des réticences des administrations concernées
  • technique : les systèmes informatiques étant très hétérogènes, ou très anciens, formater ces données pour les rendre intelligibles est compliqué et nécessite un gros travail d’interfaçage (cela peut aller de simples fichiers texte dans le meilleur des cas jusqu’à des documents papier non numérisés dans la pire des situations)
  • protectionnisme et hiérarchie : ce vieux principe de « chasse gardée », qui consiste à penser qu’on garde le pouvoir sur les citoyens en « gardant pour soi l’information et en la distribuant comme bon nous semble »
  • anonymisation : certaines données personnelles doivent être purgées avant la mise en ligne, et le problème consiste à déterminer ce qui est « identifiant » et ce qui ne l’est pas
Quelques initiatives existent déja en France. Citons, entre autres :
On peut également citer le projet OpenStreetMap, alternative participative à Google Maps
C’est à ce niveau-là qu’intervient l’initiative #opendata69 : un groupe informel, avec un panel de profils très variés, mais tous animés par la volonté de promouvoir les données ouvertes dans le Rhône.
La réunion du 2 novembre 2011 à l’Atelier des médias, initiée par Pascale Lagahe, a permis de rassembler une assemblée d’une trentaine de personnes composée entre autres de :
  • développeurs
  • responsables politiques
  • collectivités (Grand Lyon, etc)
  • universitaires
  • libristes et activistes citoyens
  • entrepreneurs
Après un rappel des notions évoquées plus haut (définition et utilisations possibles), nous avons évoqué ensemble quels peuvent être les objectifs d’un tel groupe :
  • vulgarisation : comme nous l’avons constaté plusieurs fois, l’Opendata est un terme qui peut faire « peur ». L’anglicisme et la notion très « technique » peuvent rebuter le non-initié : un des buts à atteindre est donc de démocratiser ce principe, afin que le grand public fasse sienne cette cause.
  • recensement : à quelques exceptions près, les données ouvertes sont peu visibles, car noyées dans la multitude de sites publics. Un axe de travail peut donc être de les lister sous une forme lisible sur un site dédié.
  • sensibilisation : les acteurs publics ou privés peuvent facilement se sentir perdus devant cette nouveauté qu’est l’Opendata. Nous pouvons donc travailler à les accompagner en les informant sur les initiatives existantes, sur les écueils qu’ils peuvent rencontrer.
  • applications pratiques : vu les ressources techniques à notre disposition, il est assez simple de réaliser quelques exemples « du quotidien » pour montrer comment on peut utiliser les « données ouvertes »
Nous avons mis en place quelques outils afin de pouvoir commencer à travailler ensemble sur ce projet :
L’initiative Opendata69 n’a bien sur pas prétention d’être le « référent données ouvertes » du Rhône : des initiatives locales existent déja à ce niveau-là. Mais les formaliser et leur permettre de se fédérer efficacement est clairement un objectif que nous allons nous employer à atteindre.

 

Rajouter un nouveau hook dans Prestashop 1.4 grace à l’override

Prestashop, dans sa dernière version (de mars 2011), propose une vraie amélioration (parmi beaucoup d’autres) : l’override.

Avant de rentrer dans les détails de ce système, rappelons comment est architecturé Prestashop :

  • Les classes, dans /classes, définissent le comportement des fonctionnalités principales (Cart, Order, Customer, etc)
  • Les modules, dans /modules, permettent d’étendre les possibilités de base (newsletter, alertes email, paiement, etc)

Parallèlement, il existe à de nombreux endroits dans Prestashop des hooks (« crochets ») qui sont des points dans le code sur lesquels les modules peuvent se brancher (dans les classes, ou même dans les fichiers à la racine, qui gèrent le panier, le compte-client, etc).

Une bonne manière de comprendre le fonctionnement de ces « hooks » est de les comparer au déroulement d’une vie : vous pouvez intervenir à des moments stratégiques de celle-ci, pour modifier ou non le comportement d’une personne. C’est un peu pareil avec les hooks : ils permettent aux modules de déclencher des actions à des moments-clés du fonctionnement de Prestashop (à l’affichage de l’en-tête, mais aussi au passage d’une commande ou lors de son annulation, etc). Autre exemple : un développeur peut décider d’utiliser le hook « panier » et d’afficher à cet emplacement du contenu (par exemple la météo ou des produits associés).

Certains hooks sont « invisibles » et sont plus des hooks de calcul ou de traitement (génération de PDF, envoi de mail).

Le problème avec ces hooks est qu’ils sont pré-existants dans l’application : en clair, il peut arriver qu’il en manque un précisément là où il serait nécessaire.

Jusqu’à Prestashop 1.3.7, le seul moyen était de le rajouter à la main dans le code, mais avec le risque qu’à la mise à jour suivante, ces modifications disparaîtraient.

Depuis Prestashop 1.4, il existe un dispositif qui permet de résoudre ce problème : l’override.

Derrière cet anglicisme se cache tout simplement la possibilité de « surcharger » Prestashop, c’est à dire de redéfinir ce que fait l’application, et sans craindre de perdre ces changements à la prochaine évolution.

En effet, ces « surcharges » se situent dans un répertoire /override, vide par défaut dans les versions téléchargeables de l’outil, donc qui ne sera pas écrasé par une mise à jour.


Prenons un exemple pratique, pour voir comment tout cela se décompose.

Pitch : On désire rajouter du contenu avant le footer, dans une zone qu’on appellera « surfooter », indépendante du bas de page.

– 1ère étape : Créer le hook dans la base de données

En effet, pour que Prestashop puisse déclencher une action sur un hook, il faut que celui-ci soit référencé dans la liste des choix possibles.

On va ici utiliser PHPMyAdmin pour l’insérer. Rendez-vous dans la table ps_hook (ou toute table finissant par « _hook », selon le préfixe que vous avez utilisé). Cliquez sur Insérer, et complétez comme suit l’écran qui apparaît :

Et cliquez sur Exécuter.

Pour les fans du SQL, la commande suivante est équivalente :

INSERT INTO ps_hook (name,title,position,live_edit) VALUES ('surfooter', 'Hook surFooter', '1', '0')

– 2ème étape : Positionner le hook dans le code de l’application

Dans l’exemple qu’on a choisi, le « surfooter » doit se déclencher juste avant le « footer ». Comment se déclenche le hook « footer » ? Regardons dans le fichier footer.php (logique, non?) :

$controller = new FrontController();
$controller->displayFooter();

Depuis la 1.4, on utilise dans Prestashop des contrôleurs, réunis dans un dossier /controllers, qui contiennent les fonctions utilisées dans les différentes pages.

Regardons le code de la fonction displayFooter dans /classes/FrontController.php :

public function displayFooter()
	{
		global $cookie;
		if (!self::$initialized)
			$this->init();

		self::$smarty->assign(array(
			'HOOK_RIGHT_COLUMN' => Module::hookExec('rightColumn', array('cart' => self::$cart)),
			'HOOK_FOOTER' => Module::hookExec('footer'),
			'content_only' => (int)(Tools::getValue('content_only'))));
		self::$smarty->display(_PS_THEME_DIR_.'footer.tpl');
		//live edit
		if (Tools::isSubmit('live_edit') AND $ad = Tools::getValue('ad') AND (Tools::getValue('liveToken') == sha1(Tools::getValue('ad')._COOKIE_KEY_)))
		{
			self::$smarty->assign(array('ad' => $ad, 'live_edit' => true));
			self::$smarty->display(_PS_ALL_THEMES_DIR_.'live_edit.tpl');
		}
		else
			Tools::displayError();
	}

La ligne HOOK_FOOTER’ => Module::hookExec(‘footer’) permet de déclencher « les fonctions hookfooter situés dans les modules installés sur la boutique ». Parallèlement, on retrouve dans le template un bloc {$HOOK_FOOTER} qui affichera là ou il est inséré le contenu généré par les fonctions qu’on vient évoquer.

Pour notre « surfooter », il suffirait donc de rajouter :

HOOK_SURFOOTER' => Module::hookExec('surfooter'),

Mais (il y a un « mais »), comme on l’a précisé au début de l’article, ces fichiers du coeur de Prestashop seront écrasés à la prochaine mise à jour. On va donc « dupliquer » cette fonction, et créer un fichier /override/classes/FrontController.php, contenant :

//La classe d'origine située dans /classes/FrontController.php s'appelle FrontControllerCore, on utilise donc ici FrontController
class FrontController extends FrontControllerCore
{
	//Copie de la fonction displayFooter située dans /classes/FrontController.php, mais avec le "surfooter" en +
	//C'est la copie qui prendra la main sur la fonction d'origine appelée dans /footer.php
    public function displayFooter()
	{
		global $cookie;
		if (!self::$initialized)
			$this->init();

		self::$smarty->assign(array(
			'HOOK_RIGHT_COLUMN' => Module::hookExec('rightColumn', array('cart' => self::$cart)),
			//On rajoute l'appel à notre nouveau hook
			'HOOK_SURFOOTER' => Module::hookExec('surfooter'),
			'HOOK_FOOTER' => Module::hookExec('footer'),
			'content_only' => (int)(Tools::getValue('content_only'))));
		self::$smarty->display(_PS_THEME_DIR_.'footer.tpl');
		//live edit
		if (Tools::isSubmit('live_edit') AND $ad = Tools::getValue('ad') AND (Tools::getValue('liveToken') == sha1(Tools::getValue('ad')._COOKIE_KEY_)))
		{
			self::$smarty->assign(array('ad' => $ad, 'live_edit' => true));
			self::$smarty->display(_PS_ALL_THEMES_DIR_.'live_edit.tpl');
		}
		else
			Tools::displayError();
	}
}

– 3ème étape : « greffer » un module sur notre hook

Que l’on souhaite être directement connecté au « surfooter », ou qu’on souhaite les relier ensuite par « Greffer un module », la procédure est la même : il faut déclarer au début du fichier du module que l’on souhaite s’y connecter.

Prenons l’exemple de « Bloc newsletter », (/modules/blocknewsletter/blocknewsletter.php) et de sa fonction install() (présente dans toutes les extensions Prestashop) :

if (parent::install() == false OR $this->registerHook('leftColumn') == false OR $this->registerHook('header') == false)
	return false;

On voit qu’est utilisée plusieurs fois la fonction registerHook, qui permet de se « référencer » sur un hook précis. On va donc modifier cette ligne ainsi :

if (parent::install() == false OR $this->registerHook('leftColumn') == false
OR $this->registerHook('header') == false  OR $this->registerHook('surfooter') == false) {
	return false;
}

Désormais, à la prochaine installation de ce module (donc par exemple si on le désinstalle/réinstalle), il se branchera sur « surfooter » et cherchera à éxécuter sa propre fonction hooksurfooter(), qu’on va créer pour l’occasion (toujours dans le même fichier /modules/blocknewsletter/blocknewsletter.php) :

function hooksurfooter($params)
	{
		//Mettre ici du code à exécuter dans le surfooter
	}

Il faudra bien sur rajouter le bout de code nécessaire dans notre template, par exemple:

{$HOOK_SURFOOTER}

(merci à Jérémy Kleinclaus pour la remarque à ce sujet là)
Bien sur, comme toute modification importante sur un template et sur la boutique, il peut être nécessaire de vider le cache Prestashop si les changements n’apparaissent pas.

On peut également utiliser ce procédé pour modifier le fonctionnement d’une fonction du core de Prestashop, sans nécessairement vouloir rajouter un hook, ou « surcharger » un contrôleur, en utilisant le répertoire /override/controllers.

Activer le Bureau à distance sur Windows 7 Home Premium

Depuis sa version 2000, Windows est équipé d’une fonctionnalité très pratique : le Bureau à distance, qui permet de se connecter à distance sur l’ordinateur, comme si on se trouvait devant.

Mais dans sa dernière édition (Windows 7), seules les versions Professionel et Ultimate en sont équipées, ce qui empêche l’immense majorité des utilisateurs (utilisant la version Home Premium) d’en bénéficier.

Un bidouilleur a donc eu l’idée de créer un patch permettant d’activer cette fonctionnalité.

Pour télécharger le fichier : Patch d’activation du Bureau à distance sur Windows 7 Home Premium

Installation de WordPress en multi domaines

Dès le début de l’année, Automattic (éditeur de WordPress), avait annoncé que la prochaine version de WordPress (3.0) gérerait de manière native le multi-domaines (anciennement assuré par WordPress MU, qui serait donc inclut directement dans WordPress 3).

La dernière version disponible (au 20 juin 2010) propose effectivement ce genre de fonctionnalités.

Cependant, de base, WordPress 3 ne propose du multi-sites (terme générique pour désigner ces fonctions) que selon les schémas suivants :

  • X sous-domaines  d’un nom de domaine : toto.domaine.com, tata.domaine.com, etc
  • X sous répertoires d’un nom de domaine : domaine.com/toto, domaine.com/tata, etc.

Cela répond à certaines problématiques, notamment pour de la mutualisation à grande échelle, mais dans des cas bien précis comme le mien (hébergement d’un nombre limité de blogs sur un même serveur dédié), il peut être intéressant de pouvoir faire tourner plusieurs blogs ayant des noms de domaine séparés sur la même base de code, notamment pour faciliter les mises à jour.

WordPress 3 ne le gère pas de manière « intuitive » mais nous allons voir ensemble qu’il est possible tout de même, au prix de quelques manipulations, de le faire fonctionner parfaitement dans cette configuration.

Pré-requis :

1/ Installation de WordPress 3

Celle-ci est identique à celle des versions précédentes, mis à part que vous pouvez maintenant choisir le mot de passe de l’utilisateur principal dès l’installation.

2/ Activation du mode multi-sites

Il vous suffit de rajouter les lignes :
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);

juste après
define('WP_DEBUG', false);

dans votre fichier wp-config.php (à la racine de votre installation de WordPress)

Si vous vous reconnectez sur votre blog « principal », vous verrez alors apparaître un menu Outils / Réseau sur lequel il vous faudra cliquer :

Cette page permet de créer un réseau de sites (en d’autres termes, de mutualiser les fichiers de WordPress entre plusieurs sites).

Vous remarquez qu’il n’y a aucun mention du cas qui nous intéresse : ce n’est pas grave, nous allons contourner ce problème :

  • Sélectionnez l’option Sous-dossiers
  • Remplissez les cases Nom du réseau et Adresse de contact de l’administrateur
  • Validez

La page suivante vous indique les modifications à effectuer sur vos fichiers wp-config.php et .htaccess : pensez à en faire une sauvegarde avant !
Pensez également à créer un sous-dossier blogs.dir dans votre dossier wp-content.

Cliquez ensuite sur Se connecter en bas de la page et reconnectez-vous avec vos identifiants du blog qu’on vient de créer.

Un menu Super Admin est désormais présent en haut de la page :

3/ Paramétrage du multi domaines

Entrent maintenant en jeu le plugin domain_mapping : déposez le fichier domain_mapping.php récupéré au début dans un sous-dossier mu-plugins que vous aurez créé dans /wp-content.

Déposez ensuite le fichier sunrise.php directement dans le dossier /wp-content.

Rajoutez ensuite la ligne

define( 'SUNRISE', 'on' );
dans wp-config.php juste après les lignes que vous venez d’y rajouter.

Ces deux manipulations ont pour effet d’activer le menu Domain Mapping dans Super Admin. Dans cet écran, précisez l’IP du serveur hébergeant votre/vos site(s), cochez les 2e et 3e cases et validez :

4/ Création effective des domaines

Avant tout, rendez vous dans Super Admin / Options et choisissez Français comme langue par défaut.

Ensuite, on va se rendre dans Super Admin / Sites : comme indiqué plus haut, WordPress 3 ne gérant pas de manière native les multi domaines, nous allons devoir ruser.

Dans le formulaire Ajouter un site, saisissez le nom du site que vous voulez créer (sans les www et extension, en fait, peu importe ce que vous saisissez ici)

Complétez les champs Titre du site et Adresse de contact de l’administrateur (vous remarquerez que j’ai utilisé l’adresse principale, pour pouvoir me reconnecter facilement sur le nouveau blog).

Validez : notre nouveau blog est maintenant accessible depuis www.domaineprincipal.com/nomdusite.

Rendez-vous alors sur ce blog (via le bouton Afficher sous sa ligne dans la page des sites).

Il faut maintenant donner son URL propre à ce blog : allez sur la page d’administration du sous-blog (de la forme www.domaineprincipal.com/nomdusite/wp-admin).

Vous devriez normalement être connecté automatiquement (d’où l’intéret d’utiliser le même mail pour l’utilisateur principal).

Dans Super Admin / Domains / New Domain, saisissez le « Site ID » (à récupérer dans la page Sites du blog de base) et son domaine associé : votre sous-blog est désormais accessible par sa propre URL !

Limitations :

  • les thèmes doivent être activés par un utilisateur « Super Admin » et ne peuvent être modifiés de manière unilatérale : en clair, si je modifie un thème, il est modifié pour tous les blogs qui l’utilisent
  • dans cette configuration, tous les blogs utilisent la même base de données (je prépare un second article plus spécifique pour une solution permettant de découpler les blogs à ce niveau là).