Suggestions pour améliorer les thèmes dans Prestashop

[Peha]

Bonjour

 

je met ici quelques idées pour améliorer / faciliter le système de thèmes sous Prestashop.

Dites moi ce que vous en pensez.

 

Lisibilité / Nommage

 

 

_Un truc qui me faciliterai beaucoup la vie serait de différencier les fichier .tpl statiques des fichier .tpl à inclure

par exemple avec un préfixe :

ps_category.tpl

ps_product.tpl

≠

header.tpl

footer.tpl

 

 

 

_les fichier correspondant au tunel de commande ne sont pas nommés de manière très logique, il faudrait les regrouper et éviter les confusions avec les tpl correspondant à la partie "mon compte" de la boutique

(par exemple réserver le mot clé "order")

ps_order-……….tpl

 

 

 

_d'une manière générale, il y'a trop de .tpl, qui font parfois pratiquement la même chose :

 

category.tpl

best-sales.tpl

discount.tpl

affichent tous une liste de produits

 

donc réfléchir à comment réduire ne nombre de fichier tpl intelligemment serait plus qu'utile

 

 

[aparté rien à voir avec les thèmes]

Dans le même logique de lisibilité en vue des mises à jour de Prestashop

il faudrait différencier les modules inclus de base de ceux quʼon installe nous même (via addons par exemple) afin dʼéviter dʼavoir à tenir une liste

 

/ps_blockcart

/ps_paypal

 

/monModulePasDeBase

 

[fin de l'aparté]

 

 

 

Hiérarchie des tpl

 

Une feature très intéressante de Wordpress est la hiérarchie de thèmes, reprendre cette idée rendrait Prestashop très puissant en terme de customisation graphique.

 

on aurait possibilité de faire des .tpl spécifique aux catégories, pages cms, produits etc.

simplement en nommant un fichier tpl avec l'id de la page

par exemple

category-5.tpl

 

si le fichier category-5.tpl n'existe pas dans le thème,

alors c'est le fichier par défaut category.tpl qui serait utilisé.

 

je vous renvoie à la doc WP pour mieux comprendre -> http://codex.wordpre..._fichiers_mod�les

 

 

 

 

inclusion des modules

 

il yʼa 2 sortes de hooks

les hooks du FrontOffice et tous les autres

il yʼa 2 sortes de modules

les modules greffables sur les hooks du FO (appelés widget sur WP) et tous les autres

 

tous les widgets devraient être greffables sur tous les hooks du FO et se comporter de la même manière (un seul tpl par widget)

 

mais un module devrait pouvoir définir plusieurs widgets à greffer où on veut.

( séparation module / widget )

_il devrait être possible dʼafficher un widget nʼimporte où dans un thème avec un syntaxe du genre

{module (ʻleWidgetʼ)}

 

 

 

inclusion des tpl

 

chaque .tpl correspondant à une vue devrait inclure lui même son header.tpl et le tpl suivant sanss que ça soit automatique.

Ainsi on pourrais faire des headerAlternatif.tpl

 

 

 

inclusion des CSS et JS

 

Il est illogique que les scripts Javascript utilisés dans un thème soient placés dans le dossier JS à la racine de Prestashop, ils devraient être dans le dossier JS du thème. (pour des raisons de versions, ça permet au créateur du thème d'utiliser ce qu'il veut selon ses besoins)

De plus, ce n'est pas au niveau des contrôleurs que doit être décidé quel script est ajouté. (surcharger un contrôleur juste pour ça est un peu disproportionné non ?)

je propose :

[/size][/size]
{addJS ("Fancybox.js") }
//ajoute le script /themes/monTheme/js/fancybox.js à la liste des scripts à inclure sur toutes les pages
{addJS ("Fancybox.js" ; 0 ;  "index.php" ) }
//ajoute le script /themes/monTheme/js/fancybox.js à la liste des scripts à inclure sur toutes les pages sauf index.php
{addJS ("Fancybox.js" ; 1 ;  "product.php, "category.php" ) }
//ajoute le script /themes/monTheme/fancybox.js à la liste des scripts à inclure seulement sur les pages category.php et index.php
pour finir {addJS}

/*nous donne
<script…
<script…
<script… */

idem pour les css

 

 

 

Class en amont

 

certaines infos seraient très utiles dès le body mais certaines variables ne sont pas accessible depuis header.tpl

devise

langue

soldes sur toute la boutique

id catégorie

id catégorie parente

id catégorie ancêtre

etc.

 

 

Enfin…

 

 

Je pense qu'imposer des librairies en natif comme 960grid et jquery.UI est néfaste (comme évoqué lors de la journée communautaire)

il faut laisser la liberté aux designers d'interface d'utiliser ce qui leur semble le mieux pour leur projet : c'est leur métier..

 

à la limite, lesscss serait intéressant car ça n'influence pas le design, ça permet juste d'écrire beaucoup moins de code css.

(pour wordpress ça existe sous forme de module http://case.oncle-to...dpress-wp-less/ je rêve de la même chose pour Presta (je veux dire la compilation en php, pas simplement l'inclusion d'un javascript))

 

 

Merci d'avoir lu jusqu'au bout

 

 

pa.

[Romain28]

+1

[coeos.pro]

salut,

 

1- il y a beaucoup trop à lire

2- certains conseils existent déjà ou alors sont à proscrire, exemple :

on aurait possibilité de faire des .tpl spécifique aux catégories, pages cms, produits etc.

tu parles des layout ? http://www.prestasho...ayout-template/

tous les widgets devraient être greffables sur tous les hooks du FO et se comporter de la même manière (un seul tpl par widget)

et si mon module est affiché dans la colonne de droite et dans le footer, j'ai besoin d'avoir 2 tpl différents affichant les +/- d'infos et avec un design différent...

pour des raisons de versions, ça permet au créateur du thème d'utiliser ce qu'il veut selon ses besoins

rien ne t’empêche de créer des fct js spécifique et de les inclures dans le thème que tu créé, je vois pas trop le problème que ça génère...

 

 

_il devrait être possible dʼafficher un widget nʼimporte où dans un thème avec un syntaxe du genre

{module (ʻleWidgetʼ)}

ce serait bien que tu nous donnes TA définition de widget, mais en l'état il est déjà possible d'afficher certains résultat à différents endroits...

 

_d'une manière générale, il y'a trop de .tpl, qui font parfois pratiquement la même chose :

...

donc réfléchir à comment réduire ne nombre de fichier tpl intelligemment serait plus qu'utile

réduire le nombre de tpl équivaut à augmenter la difficulté de personnalisation de chaque page individuellement à mon avis

 

 

inclusion des tpl

 

chaque .tpl correspondant à une vue devrait inclure lui même son header.tpl et le tpl suivant sanss que ça soit automatique.

Ainsi on pourrais faire des headerAlternatif.tpl

là je n'ai juste pas compris où tu voulais en venir

Edited December 17, 2012 by coeos.pro (see edit history)