Le découpage du HOOK

[Diaz]

Slt,
Je découvre prestashop et je m'empresse alors de faire un template, par contre après une prise en main relativement simple, je me retrouve coincé avec un problème de conception de prestashop.

ex: header.tpl

                
                   {$HOOK_TOP}

Et dans ce HOOK_TOP je me rends compte que y a les devises, le langage, la boite de connexion, etc... des blocs modules dans /modules/
Trop de choses qui ne en l'état ne permettent pas de coder correctement mon header seulement avec header.tpl et avoir quelque chose du style:

                

                      bla bla code devise


                      blabla language


blabla bla ...................

de telle sorte à ne plus avoir un seul HOOK_TOP englobant tout.

Donc en état, pour mn cas la meileur façon est-elle de supprimer ce HOOK_TOP et remplacer par le code addhoc des blocs à afficher ?
Ni risque t'il pas d'y avoir des répercusions avec les codes des blocs en question dans /modules/blockxxxxxxx/

Mon intérêt étant par exemple de mettre le bloc language en footer.

Merci

[Peha]

Bonjour,
j'ai la même question. Quelqu'un as t il une solution ?

[Edit] juste après avoir posté ce message, je me suis souvenu que l'on pouvait modifier l'ordre des éléments et modules dans le back office de la boutique. ça règle mon problème.
Mais mon thème, pour fonctionner, devra être configuré dans un certain ordre.
J'imagine qu'a terme ça sera le rôle du fichier conf.xml

voila,
merci pour votre attention.

[Cédric Girard]

Bonjour

Je pense que l'on peut faire ce que l'on veut en préservant les hooks tels qu'ils sont (en utilisant effectivement l'ordonnancement des modules dans chaque hook, PUIS ENSUITE en travaillant sur les CSS pour en décliner l'interprétation visuelle si j'ose dire)

On ne touche jamais directement aux fichiers XML de configuration de la boutique ;-)


Maintenant, on peut très bien imaginer qu'effectivement un thème donné doive respecter un ordre défini des modules pour convenablement fonctionner. C'est le cas de tous les templates que j'ai développé à ce jour...

Je vais tâcher de trouver 5 minutes pour expliquer comment on peut coder simplement de nouveaux hooks pour les modules (en clair, comment faire afficher par exemple le blockcategories dans le hook "top" alors que par défaut ce module n'est pas prévu pour s'afficher dans ce dernier ;-) )

[Atch]

Je vais tâcher de trouver 5 minutes pour expliquer comment on peut coder simplement de nouveaux hooks pour les modules (en clair, comment faire afficher par exemple le blockcategories dans le hook "top" alors que par défaut ce module n'est pas prévu pour s'afficher dans ce dernier ;-) )

Bonne idée

Atch

[Diaz]

Slt,
Il y a une possibilité qui permet d'avoir un blockxxxx.tpl personnalisé sans toucher au bloc.tpl original

Ex pour le block language

dans le theme
On ajoute un rep /modules/blocklanguages/

et on met dedans son propre bloc personnalisé qui sera utilisé par défaut

blocklanguages.tpl

Ca résoud une partie du problème....Où sinon tout gérer en manuel par l'affichage sans passer par l'admin de presta et utilisation des blocs.
Ainsi on zappe les HOOK

[Cédric Girard]

Le soucis avec la surcharge dans les thèmes, est effectivement que l'on ne peut (à priori, en tout cas je n'ai pas réussi à les faire fonctionner : ça fonctionne par contre très bien avec les tpl) surcharger les fichiers PHP des modules :-(

Cela aurait apporté une souplesse extraordinaire...

Du coup je préfère "jouer" en direct dans les modules : moins propre, moins souple mais de toute façon une boutique va être "figée" généralement pour 2 à 4 années avant renouvellement visuel...

[Peha]

J'ai lu quelque part qu'il suffisait de faire dans le theme un dossier modules/monModule pour surcharger les fichiers des modules... non teste...

[Cédric Girard]

Oui, mais ne fonctionne (à priori) que pour les tpl, pas pour les fichiers php (en tout cas mes tests n'ont pas fonctionné )

[Peha]

A ok, à mon avis c'est normal. C'est la même chose sur GalleryMenalto par exemple.

[SotEW]

J’ai lu quelque part qu’il suffisait de faire dans le theme un dossier modules/monModule pour surcharger les fichiers des modules… non teste…

Exacte.

Oui, mais ne fonctionne (à priori) que pour les tpl, pas pour les fichiers php (en tout cas mes tests n’ont pas fonctionné )

Exacte aussi.

En fait, les modules sont inscrit sur des hook. Lorsque smarty, le gestionnaire de template, trouve une variable de type {HOOK_xxx}, il va observer dans la base de données quels sont les modules inscrit sur ce hook, et, sur chacun de ces modules, va appeler la fonction hookXxx, contenu dans la classe du module (fichier PHP). Ces fichiers .php n'affichent rien par eux mêmes. En effet, Ils font appel à la fin de la fonction hookXxx à $this->display('nomdufichier.php', 'nomdutplaafficher.tpl').

C'est cette fonction display, qui va récupérer le nom de la classe (nomdufichier.php sans l'extension), et regarde s'il existe un fichier nommé nomdutplaafficher.tpl dans le dossier /themes/nomdutheme/modules/nomdufichier/. Si c'est le cas, il affiche celui là, sinon celui qui est contenu à coté du .php, c'est à dire dans le dossier même du module.


Ainsi, les .php ne changent pas grand chose à l'affichage : ils définissent les variables à afficher (prix, etc...) et désigne le nom du .tpl

Et on a bien une surcharge de l'affichage des modules en cas de présence d'un .tpl dans le dossier/themes/montheme/modules/nomdumodule/

La façon de faire donc un theme robuste, consiste donc à conserver les hook, placer correctement les modules grace au backoffice, puis ne plus toucher à cet ordre.

On peux donc ensuite avoir recours aux fichier .tpl du theme des modules, et ne pas avoir tout à refaire en cas de mise à jour.

[Cédric Girard]

Oui, mais le soucis majeur est que par défaut, on ne peut pas placer n'importe quel module dans n'importe quel hook.

L'exemple des catégories est éloquent : par défaut, c'est columnLeft ou columnRight ! Il n'y a pas top ou header, ce qui ne facilite pas la mise en oeuvre de catégories en menus déroulants sans bidouillage

C'est pour cette raison que je préfère rajouter des lignes dans les fichiers PHP pour prendre en charge les nouveaux appels. Et cela, on ne peut le faire que dans les modules directement ;-)


(j'ai aussi eu le cas pour les tags, que j'ai placé en footer, ou encore les best sellers, placés sur la page d'accueil...)

[SotEW]

Et bien, c'est vrai que j'ai fait la distinction Graphisme/placement des modules, pasque ça ne me semblait pas le même problème. il est évident que ce n'est pas en changeant le .tpl qu'on va le déplacer du header au footer, mais je ne pense pas que ce soit un problème insurmontable.

Les modules ont l'avantage d'être très compatible d'une version à une autre. En changeant le nom d'un module, on peux s'assurer qu'il ne soit pas écrasé lors d'une mise à jour, et il suffit :

- D'inscrire le module dans le hook de son choix (fichier .php, fonction install()). La liste des modules est présente dans la base de donnée, et il suffit de rajouter dans le test un

OR !$this->registerHook('nomDuNouveauHook')

pour qu'il soit inscrit lors de l'installation (la désinscription au hook lors de la désinstallation se fait automatiquement lors de l'appel de 'parent::uninstall();')

- De rajouter une fonction hookNomDuNouveauHook en s'inspirant de celui/celle existant dans ce module ou, mieux, celui d'un module inscrit dans le hook en question. Cette fonction devra retourner impérativement

return $this->display(__FILE__, 'nomdutpl.tpl');

, avec ce que ça implique sur le thème. Il ne reste plus qu'à créer/modifier le tpl pour que l'affichage soit convenable. Encore une fois, le tpl existant peut être une bonne base.


Comme la personnalisation avec changement de hook DOIT se faire en touchant au code, autant le faire au maximum proprement et version-proof, non ?

[Cédric Girard]

On est bien d'accord ;-)

De toute façon il est indispensable de toucher au code...

[m1bs]

Perso je fais autrement mais c'est vraiment pas l'idéal mais bon au moins j'arrive au résultat que je veux.

Je sacrifie un module genre bloc des monnaies.tpl , et je copie le code des autres tpl à l'intérieur donc je perd la traduction.
Dans mon cas c'est pas grave car dans le header c'est souvent des infos genre :

mon compte
monnaie
me connecter etc...

Je refais une traduction pour le textes dans les langues du site ( dans le fichier.php genre if lang = fr -> echo mon text_fr
) Ensuite je serre tout ça dans un tableau html un peu en mode forcing, mais ensuite on obtient le résultat.

Après bon... on peut bien évidemment faire mieux

[SotEW]

pourquoi faire sauter la traduction ?

Si on est dans un tpl : {l s='texteenanglais' mod='nomdumodule'} et on retrouve la chaine de caractère dans la traduction du module

[m1bs]

oui effectivement c'est peut-être bien plus intelligent ^^

[Cédric Girard]

À nous tous nous allons arriver à faire quelque chose de nickel :-)

[Diaz]

@ sotEw

Par l'exemple

si on supprime le {$HOOK_TOP} dans header.tpl et que l'on veut par exemple à la place ajouter les liens du bloc blockpermanentlinks-header.tpl

on rajoute le code suivant dans le header.tpl

><!-- Block permanent links module HEADER -->
</pre>
<ul>
{l s='contact' mod='blockpermanentlinks'}
{l s='sitemap' mod='blockpermanentlinks'}

       [removed]writeBookmarkLink('{$come_from}', '{$shop_name|addslashes|addslashes}', '{l s='bookmark' mod='blockpermanentlinks'}');[removed]

</ul>
<br><!-- /Block permanent links module HEADER 

Par contre reste le soucis du multilangage et là j'ai pas encore saisi l'explication :-/

Tu peux donner l'exemple sur ce morceau de code (coté visuel: bookmark en anglais à faire passer en favoris en français et vice/versa selon la langue choisie (clic des drapeaux))

[removed]writeBookmarkLink('{$come_from}', '{$shop_name|addslashes|addslashes}', '{l s='bookmark' mod='blockpermanentlinks'}');[removed]

[m1bs]

au fait lorsque l'on retouche le header, ça part un peu dans tous les sens les bloc viennent vite en conflit les uns avec les autres à croire que c'est réglé au mm près.

[Cédric Girard]

Mmmm pas bête de carrément inclure le code dans les tpl, mais bon ça peut vite devenir usine à gaz si on greffe beaucoup de modules pas fait pour à l'origine :cheese: (chose dont je suis un spécialiste...)

Je suis en train de voir si je ne vais pas prendre 2/3 jours à temps plein pour me refaire un thème de A à Z, from scratch (je parle évidemment au niveau CSS !)

Un thème "vide" avec uniquement le layout (les "tiroirs", un par hook, et dedans les "boîtes" : les modules)



Ce serait pas du luxe, parce que bon, le template de base est pas trop mal, mais c'est quand même une usine à gaz au niveau CSS...

[SotEW]

hmm, et bien, Diaz, il faudrait faire des tests, mais deux cas de figures s'imposent :


Soit smarty ne fait pas attention à quel endroit précisement se trouve le .tpl, et tu auras la traduction disponible dans le backoffice (Onglet Outil, section 'Traductions', choisis 'Traduction des modules')

ou bien smarty fait attention à l'emplacement, et dans ce cas la traduction se trouvera dans le backoffice aussi, mais dans le 'Traduction du front office'

[Diaz]

Bon je fais faire d'autres essais, j'ai des idées en tête....

Mmmm pas bête de carrément inclure le code dans les tpl, mais bon ça peut vite devenir usine à gaz si on greffe beaucoup de modules pas fait pour à l’origine cheese (chose dont je suis un spécialiste…)

Je suis en train de voir si je ne vais pas prendre 2/3 jours à temps plein pour me refaire un thème de A à Z, from scratch (je parle évidemment au niveau CSS !)

Un thème “vide” avec uniquement le layout (les “tiroirs”, un par hook, et dedans les “boîtes” : les modules)

Ce serait pas du luxe, parce que bon, le template de base est pas trop mal, mais c’est quand même une usine à gaz au niveau CSS…

Perso je préfère travailler en manuel car bcp ++++ de contrôle et de flexibilité

Bien en fait c'est ce que je suis en train de faire sur la base d'un framework YAML
http://www.prestashop.com/forums/viewthread/13084/graphisme/prestashop_et_yaml_premiers_screens


J'ai commencé par avoir mes propre blockxxx.tpl persos inclus dans la template et je suis en train de découper chaque portion de code du global.css pour chaque bloc que j'appelle via des imports.
Niveau clarté et dev c'est l'idéal à mon gout et pour la production je frais un seul css compressé ;-)

Si y en a qui sont intéressés, j'en profte en même tps pour revoir le coté seo

@++

[Diaz]

Slt,
Je reup le post du fait qu'il n'y a pas encore de solution viable, au stade actuel:

- On sait avoir un tpl particulier pour un bloc particulier
- On sait inclure le contenu d'un bloc directement dans le header.tpl par exemple mais la manip ne gère pas le multilanguage
- On ne sait pas encore séparer et découper les blocks contenus par ex dans HOOK_TOP de telle sorte à avoir un affichage particulier lié au thème et non pas au backoffice.

En poussant la réflexion , n'est il pas possible de créer soit même ses propres HOOK personnalisés?

Ex je créer un {$HOOK_LANGUAGE} faisant seulement référence au blocklanguages.tpl, ainsi on peut vraiment faire ensuite ce que l'on veut niveau template, ça simpliferais tout et coté flexibilité c'est l'idéal ce même si coté backoffice y a plus aucun controle mais c'est accessoire à mon gout.

A voir.....

Si y en a qui ont déjà essayé ?