Suggestion pour les modules

[Julien Breux]

Bonjour à toutes / tous,

 

Je créé ce topic dans le but de rassembler des idées pour que Fab' ne se sente pas seul

 

Tout d'abord, il y'a déjà un ou deux sujets qui traitent de cela ici : http://www.prestashop.com/forums/topic/136318-suggestions-for-modules-in-15/

 

A vous de jouer :-)

[olea]

Dans la class AdminTab, on dispose du membre _fieldsOptions et de la méthode displayOptionList(), bien pratique pour gérer des paramètres de config.

 

Cette notion devrait également être disponible dans le panneau de configuration d'un module (plutôt que de devoir ré-écrire du code à chaque module)

 

J'ajouterai un plus qui serait de pouvoir faire plusieurs fieldset et non pas un seul comme le optionList

[olea]

Autre suggestion :

un module peut installer des AdminTab

1/ il serait bien que l'identité du module soit rappelé en pied de page de ces AdminTab (nom module, version, auteur)

2/ si le module est désactivé (ou en cours d'upgrade), rendre ces admintab inaccessibles

[Julien Breux]

• Ok sur le point sur la configuration
  
• Ok sur le point "désactiver", ceci dit, j'ajouterai trois methodes : reset(), active() et inactive().
  

[chantane]

Bonjour,

Totalement d'accord.

J'avais modifié le module newsletter pour ne plus supprimer les datas car sa désinstallation supprimait les inscrits à la newsletter. même chose pour la configuration des blocs cms.

 

Concernant l'installation des modules, la gestion des pages d'exception n'est pas pratique à mon sens.

mis à part les modules des footer et header, la plupart de mes modules sont affichés dans un seul type de page.

Plutôt que de gérer les exceptions et d'en oublier, j'aimerais avoir la possibilité de choisir les pages.

 

Je suggère d'avoir dans le BO une case à cocher : gestion par présence ou exception,

suivie de la liste des pages

 

Les messages d'erreur sont souvent laconiques, pas seulement pour les modules, alors que quelques informations comme le nom du module aideraient à la compréhension.

Ces informations pourraient être dans le log d'erreurs php

 

 

Merci

[papich]

Un module de statistique prenant donnant accès au bénéfice net, la possibilité de désactiver les langues non utilisées (à l'heure actuelle si j'utilise que le francais dans l'évaluation catalogue j'ai quand même toutes les langues dans l'évaluation.

 

La gestion des professionnels serait la bienvenue aussi.(configuration du minimum d'achat distinct particulier/pro, frais de port offert....)

[yannml]

Un module A/B testing, car une boutique n'est jamais terminé, il y a toujours des choses a tester pour augmenter sa performance.

[hutarios]

Bonjour,

 

J'ai une suggestion pour les caractéristiques des produits (j’espère que c'est le bon topic)

 

Pour chaque caractéristiques on ne peut mettre qu’une valeur prédéfinie ou alors une valeur personnalisé mais elle n'est pas exploitable avec la navigation a facette (que je trouve essentielle pour la recherche de produits).

 

exemple avec des imprimantes :

Pour la caractéristique interface on peut avoir USB, Wifi, RJ45, parallèle, Bluetooth, ...

 

Chaque imprimante peut avoir un ou plusieurs types d'interface, ce qui reviendrait a créer plusieurs valeurs prédéfinies : -USB, -Wifi, -RJ45, ... mais aussi -USB et Wifi, -USB et Wifi et RJ45, -Wifi et Bluetooth, ... donc beaucoup trop de valeurs et surtout une incompréhension pour le client lors de l'utilisation de la navigation a facette.

 

Il faudrait pouvoir attribuer plusieurs valeurs a une caractéristique, lorsqu’un client sélectionne une valeur de caractéristique dans la navigation a facette il devrait avoir en résultat tous les produits ayant cette valeur de caractéristique qu'elle soit unique pour la caractéristique ou pas sur le produit.

 

En allant plus loin, il faudrait aussi avoir le choix du type de recherche (ET ou OU) lorsqu'un client sélectionne plusieurs valeurs en fonction des caractéristiques et autoriser ou non la sélection de plusieurs valeurs.

 

Tout cela permettrait un classement plus efficace des produits pour un tri plus approfondi.

(dans l'exemple je prend un produit IT mais c'est valable pour beaucoup d'autres domaines)

[yannml]

Tu peux contourner ce problème en utilisant la caractéristique "Wifi" et les attributs "oui/non". Mais effectivement, la navigation a facettes demande vraiment a être développé !

[olea]

Autres suggestions concernant les modules :

 

1/ Champs génériques en adminTab :

Dans les adminTab installés par les modules, il est fréquent d'utiliser des champs qui ont un comportement générique

• champ de saisie de date ou date/heure
  
• champ de sélection de catégories dans l'arbre des catégories
  
• champ multilang
  
• champ RichText
  
• champ RichText mulitlang
  

En 1.2, 1.3, 1.4, il faut s'écrire son propre code pour que ces champs aient ces comportements et ce code doit être adapté à chaque version (cf le includeDatePicker ou l'inclusion tinyMCE ou le recurseCategoryForInclude() )

 

Il serait bien que des routines génériques permettent de facilement créer de tels champs (tout au moins dans le display, le postProcess dépendant de l'endroit où est stockée l'info)

 

 

 

2/ Jusqu'en 1.4, les controllers admin (situé dans le répertoire d'admin) peuvent instancier le cookie ps_admin.

Par contre, si un controller est localisé dans un module, il ne peut pas instancier ce cookie, sans doute pour raison de sécurité (genre le controller pdf.php ne pourrait pas être placé dans un module)

-> je pense que cette évolution sera couverte par les nouveaux controllers d'admin, isn't it ?

[yannml]

Le module relance de panier abandonné peut être poussé plus loin.

 

Ne pas relancer deux fois un même panier, choisir le nombre de jours/heure avant de relancer un panier, pouvoir éventuellement choisir nouveau clientou ancien client (les anciens savent deja commander commander), et le top serait de connaitre ou ils ont quitté le site.

[RUNps]

Salut à tous

 

Je viens vous faire un petit retour suite à un problème que je viens de résoudre.

Cela ne concerne pas un module en particulier, mais de la configurations des modules en général, c'est à dire, une fois avoir cliqué sur le lien "configuration" (pour ceux qui en ont besoin).

 

 

Les liens pointer vers le fichiers index.php du BO (et il y a entre autre le nom du "tab" en paramètre : tab=AdminModules).

 

D'après ce que je comprends, le fait que ça pointe sur l'index.php plusieurs fichiers seront inclus, comme le header.inc.php, de même qu'à un moment donné le buffer est vidé (ob_clean), et encore après du HTML sera généré.

 

Tout cela avant que ce qui concernera le AdminModules sera exécuté.

 

Pour résumer la situation et de se que j'en conclus : Il est (théoriquement) impossible d’exécuter un code avant que ne soit renvoyé l'entête (le header), ce qui empêche de faire certaines opérations.

Du moins, il n'y aurait pas d'autres solutions que de le faire via du JS (encore que), ce qui me semble pas très propre.

 

 

De plus, en observant les modules qui demandent à faire certains traitements de configurations, quasi tous reprennent ce qu'on retrouve dans le AdminTab, c'est à dire les méthodes comme :

_postProcess()

_postValidation

etc ...

Cependant, tout cela est exécuté à l'origine dans la méthode getContent().

 

Finalement, et pour gérer les modules, on ne disposerait que d'une seule méthode getContent() qui est à mon sens prévue pour générer du contenu HTML.

 

Est-ce qu'il est prévu de fournir une méthode (ne serait-ce qu'une) pour exécuter du code avant qu'une entête soit renvoyée (un header() j'entends) ?

Ou alors je suis passé à coté.

[Fabien Serny]

Effectivement, c'est un manque que je vais rajouter. Tu peux toujours appelé toi même un postProcess maison au début du getContent mais c'est pas très pratique.

Je pense juste rajouter un _postProcess() et un _postValidation() vide dans la classe Module et qui sera appelé juste avant getContent()

[olea]

Je pense juste rajouter un _postProcess() et un _postValidation() vide dans la classe Module et qui sera appelé juste avant getContent()

 

Ne faudrait-il pas les créer avec un autre nom ?

Sinon, les modules 1.4 existants qu'on va faire tourner en 1.5 vont se retrouver avec 2 appels à ces méthodes (avant et dans el getContent), sans compter que le prototype de ces méthodes ne sera peut-être pas conforme aux méthodes existant déjà dans ces modules.

[RUNps]

Effectivement, c'est un manque que je vais rajouter. Tu peux toujours appelé toi même un postProcess maison au début du getContent mais c'est pas très pratique.

Non sans vouloir insister, mais ce n'est vraiment que ce soit pratique ou pas, c'est surtout que selon ce qu'on souhaite faire, c'est impossible, même dès la 1ère ligne à l'appel de Module::getContent().

 

 

Tout est une question de déroulement, du code, lorsque l'index.php du BO est appelé.

Dans la version 1.4.6.2 on a ceci comme toutes 1ère lignes de code :

define('_PS_ADMIN_DIR_', getcwd());
define('PS_ADMIN_DIR', _PS_ADMIN_DIR_); // Retro-compatibility
include(PS_ADMIN_DIR.'/../config/config.inc.php');
include(PS_ADMIN_DIR.'/functions.php');
include(PS_ADMIN_DIR.'/header.inc.php');

En bien plus tardivement (ligne ~ 106) :

$adminObj->displayConf();
$adminObj->postProcess();
$adminObj->displayErrors();
$adminObj->display();

Dès le départ le header.inc.php est inclu, et dans celui-ci c'est du HTML, sans compter qu'après il y a encore du HTML de généré, donc une entête sera automatiquement renvoyée.

L'Objet "AdminModules" serait créé à mon sens trop tardivement, de ce fait, rajouter ces méthodes comme postProcess() risque de ne rien résoudre, tout juste donner l'illusion que ce soit plus propre.

 

 

Ceci dit, ce n'est qu'une remarque, peut être prévoyez-vous de revoir en parrallèle le déroulement.

 

 

Ne faudrait-il pas les créer avec un autre nom ?

Sinon, les modules 1.4 existants qu'on va faire tourner en 1.5 vont se retrouver avec 2 appels à ces méthodes (avant et dans el getContent)

Admettons que ces nouvelles méthodes soient implantées dans la 1.5, cela suppose de faire évoluer les modules concernés aussi.

Au pire, PS devrait supprimer de cette version tout module incompatible.

Si personne ne fait évoluer quoi que ce soit, je ne vois pas comment on peu avancer.

 

Pour ce qui est du Prototype, si PS les rajoutes sans faire aucun traitement (dans un 1er temps), ça devrait aller, non ?

Le principale à mon sens, c'est quand, à quel moment ces méthodes seront exécutés par rapport à l'ensemble de la page.

[Fabien Serny]

Alors en fait, à présent l'admin est en smarty et l'affichage se fait à la fin.

Donc logiquement ça ne devrait pas te poser de soucis (tous les display smarty sont fait à la fin)

 

Pour ce qui est la rétrocompatibilité. Le fait qu'il y ait un appel parent d'une fonction vide ne faisant rien puis de celle du module, cela n'est pas gênant. Par contre, pour le conflit du prototype, je n'y avais pas pensé, je réfléchis et je regarde ce qui peut être fait.

[olea]

à présent l'admin est en smarty et l'affichage se fait à la fin.

-> RUN semblait demander l'équivalent d'un hookHeader pour le backoffice

 

Le fait qu'il y ait un appel parent d'une fonction vide ne faisant rien puis de celle du module, cela n'est pas gênant.

-> si le getContent d'un module appel $this->_postProcess(), c'est celui de ce module qui est appelé.

C'est aussi celui là qui serait appelé avant le getContent() apr la classe mère et non pas le vide de la classe mère

[chantane]

Bonjour,

 

Pour le module editorial, lors des mises à jour, il est facile d'oublier de remplacer l'image homepage par défaut qui se trouve dans ce module. Je pense que cette image devrait se trouver dans le dossier theme courant. Car ainsi elle serait copiée en même temps que le thème.

 

Si on pouvait avoir des images homepage_fr, homepage_en, en fonction de la langue d'affichage, ce serait un plus, car les images peuvent ausi contenir quelques mots.