Un souhait pour Prestashop 2

par

Prestashop 2 est prévue pour bientôt ou pas, quoi qu’il en soit il y a un truc qu’il faudra absolument améliorer, c’est le système de messages utilisateur (erreur, confirmation, alerte).

Actuellement ça se passe ainsi :

  1. On clique sur un lien d’action. par exemple http://…?send_mail&id_client=42 pour envoyer un mail à un client
  2. on arrive sur la page qui fait l’action (page d’action)
  3. si ça marche, on est redirigé sur une page qui affiche une confirmation http://…?conf=33 conf étant l’id du message de confirmation
  4. si ça échoue, on reste sur la page et on affiche les erreurs.

La redirection est importante car si on restait sur la page d’action, il suffirait de la recharger pour exécuter de nouveau l’action ou de laisser l’onglet ouvert avant de fermer le navigateur. Pour un mail c’est pas trop grave, pour une suppression plus.

Donc tant que qu’il n’y a pas d’erreur ça marche (bin oui) mais sinon on reste sur la page d’action et c’est mal.

Vous allez dire que c’est pas grave puisque ça marche pas, il n’y a pas de risque que le mail soit envoyé si je recharge la page et si ça marche bin c’est cool c’est ce que je voulais.

Non. déjà ça peut être une erreur temporaire donc ça peut très bien fonctionner la seconde fois.

Ensuite on ne sait pas à quel moment ça a échoué. Si il fallait supprimer une commande puis envoyer un mail au client en rechargeant la page vous pouvez supprimer 3 commandes et à chaque fois ne pas réussir à envoyer les mails.

Bref le système est bancal.

En plus il est très limité :

  • Il y a un id de message de confirmation donc il y a une liste prédéfinie de message (31 dans la classe AdminControllerCore) donc si vous voulez utiliser une confirmation personnalisée ça devient compliqué.
  • Vous ne pouvez avoir qu’un seul message. Pour reprendre l’exemple on ne peut pas dire “la commande est supprimée” et “le mail est envoyé” et bien sûr on ne mixe pas (“la commande est supprimée” et “Erreur, le mail n’est pas envoyé”)
  • Si je recharge la page, j’ai de nouveau le message ce qui peut être perturbant et pas joli.

Ce qu’il faudrait c’est un vrai gestionnaire de message.

Quand quelque chose fait une action il dit “Faudra dire à untel/tout le monde/personne que j’ai fait ça” ou “Faudra dire qu’il y a cet erreur/alerte/information” comme pour un système de log (c’est la même chose en fait).

Par exemple

(bon là y a des if partout mais c’est l’idée)
et au prochain affichage d’une page on montre les messages en attente.

Ce serait utile pour les modules aussi. Le module Ebay par exemple met à jour la fiche produit sur ebay.com à chaque fois qu’on en modifie un sur Prestashop mais il peut pas le dire, l’info est perdue à la redirection. Là il pourrait mettre en attente “tel produit est à jour/désactivé/supprimé sur ebay.com” ou “impossible de contacter ebay.com”.

Donc tout ça pour dire que ce serait un truc super pratique.

Décodeur de code PHP

par

La semaine dernière avec Olea on est tombé sur un module Prestashop tout moche qui avait un code de ce style :

eval(gzinflate(base64_decode(strrev('AYwtRlkyv8MKXlcyNj09QdFyO30S'))));

Impossible donc de savoir son action. En enlevant le eval() pour voir le code

echo gzinflate(base64_decode(strrev('AYwtRlkyv8MKXlcyNj09QdFyO30S')));

on tombe sur

eval(base64_encode(str_rot13('DF5fgEZ135HHtrdfcv'))));

et ainsi de suite.

Cela s’appelle du code impénétrable ou de l’obfuscation. Très utilisé pour cacher un vilain code pas beau avec tracker, virus et tout ça.

Donc voici un décodeur pour ce genre de code. En gros il fait la même chose que eval() mais sans exécuter le code.

https://gist.github.com/Shagshag/5848915

Pour info le code du module en question avait 45 eval() imbriqués et rien de méchant. L’auteur ne voulait juste pas qu’on voit son code. (raté)

par

Xénophobie ordinaire sur un site grand public (bien orienté quand même).

J’aime pas mais pas du tout les mentalités actuelles.Ou plutôt le fait d’en être fier.

Arrêtez de nous faire suer avec les sitemaps !

par

Bon pour être clair, un sitemap ne sert à rien sauf si votre site est mal fichu.

D’après Wikipédia

Sitemaps are a useful tool for making sites built in Flash and other non-html languages searchable.
The basic premise is that some sites have a large number of dynamic pages that are only available through the use of forms and user entries.

Donc si votre site n’est pas en flash ( on est plus en 2000 ) et que toutes les pages intéressantes sont trouvables sans passer par la recherche (j’espère pour vous), le fichier sitemap ne sert à rien.

Un bon référenceur qui veut vendre sa camelote vous dira que ça aide Google à trouver les liens. Merci pour lui mais il sait faire tout seul. S’il y a un lien dans le sitemap qu’il n’a pas trouvé tout seul ça veux dire que :

  1. Personne ne fait de lien vers cette page
  2. Ou elle n’est pas accessible depuis votre site sans passer par un formulaire ou sans être connecté
  3. Ou elle n’existe pas/plus/pas encore

Donc :

  1. Elle n’est pas intéressante => Elle ne ressortira pas dans Google
  2. Ou on ne peut pas y accéder directement => Google ne peut pas faire de lien vers elle
  3. Ou votre sitemap est foireux => il sert doublement à rien et votre référenceur est nul.

Enfin le fait que Google trouve des liens dans un sitemap ne veut pas dire qu’il ira les visiter et qu’il les visite ne veut pas dire qui va les indexer.
En gros ça sert à rien !

Donc arrêtez de nous faire suer avec ça et ne demandez plus de module d’optimisation de sitemap pour Prestashop. Y a plus important à faire pour le référencement.

alternative à parse_str sans limitation

par

Bon c’est un peu technique mais la fonction PHP parse_str est limité par la directive max_input_vars ce qui fait que par défaut on ne peut traiter que 1000 paramètres avec cette fonction.

Comme j’ai eu besoin d’en traiter plus que ça voici une réécriture de parse_str sans limitation. Elle supporte les tableaux imbriqués et c’est déjà pas mal.

https://gist.github.com/Shagshag/5849065

Soignez vos emails, gagnez en crédibilité

par

Ce n’est pas dans mes habitudes de parler de ça mais quand même.

Je viens de recevoir ceci

Avant d’envoyer un message à ses clients, il faut réfléchir à l’image qu’il donne de vous.
Là clairement ça ne fait pas pro : écrire en gros, violet et en Comic Sans MS ça fait gamin qui kikoolol sur son skyblog.

Plus discret mais j’y suis sensible le “via hotmail.fr” à côté de l’expéditeur ne fait pas pro non plus.

Quelques conseils tirés de email-cible.com :

  • La lisibilité : Le message que vous vous apprêtez à envoyer va être consulté par des centaines de paires d’yeux, plus ou moins performantes, et qui, pour certaines, ont déjà parcouru dans la journée des centaines de lignes de texte affichées sur un écran. Ce message doit donc être composé avec une police reconnue pour sa lisibilité et affichée dans une taille suffisante (12 pixels minimum pour le corps du texte, 10 pour les notes de bas de page).

  • L’image : La police que vous utilisez doit refléter votre professionnalisme et à ce titre certaines polices sont à proscrire. Par exemple, ‘Comic Sans MS’ donne le sentiment que le message été rédigé par un enfant, ‘Courier’ est une police dite monospace dans laquelle chaque glyphe a une largeur fixe. Idéal pour donner un look “machine à écrire” à votre message, mais au XXIème siècle, qui le souhaite encore ?

  • La disponibilité : Il est important de savoir que la police que vous choisissez ne sera pas forcément celle qui s’affichera sur les écrans de vos utilisateurs. Pourquoi ? Tout simplement parce que, pour pouvoir être affichée dans un navigateur ou un client mail, une police doit être installée sur l’ordinateur à partir duquel on lit le texte. Il est donc inutile d’employer une police esthétiquement parfaite de votre point de vue mais qui ne sera pas présente sur la plupart des ordinateurs de vos destinataires.

Et d’après moi :

  • envoyez un message au format texte dès que possible, le message sera alors affiché dans la police choisie par le destinataire et c’est tant mieux

  • utilisez une police simple, courante et sans empâtement. Verdana est parfaite pour être lu sur le web. Pas de couleur, ça n’apporte rien et ça fatigue les yeux.

  • Si votre public est ciblé, vous pouvez quand même adapter mais de toute facon il faut rester sobre.

Quelques conseils sur la lisibilité de vos mails : http://www.miratech.fr/blog/faciliter-lecture-web.html

Edit du 20/04/2012 : ça aussi ça ne fait pas pro !!!