Julien Bourdeau

What do you mean? I don't get it. I'll have a look for the rest.

Hi, When you install a theme, the custom modules defined by the theme as dependencies are installed. In 1.7, the theme maker can define what he wants to achieve with modules: enable/disable, hook/unhook, and so on. If there is any special modules, they are bundled with the theme and installed at the same time. Everything happens in the theme.yml: http://developers.prestashop.com/themes/gettingstarted/index.html#theme-yml We thought it didn't make much sense to ask anything to the use at this step. If you want to disable a module afterwards, you can do it in your module page of course. I hope this answers your question.

Ah oui ok. C'est pas ce que j'avais compris. Donc non c'est pas possible, je ne peux pas m'engager mais à mon avis ça ne le sera jamais dans le core avec le theme par défaut (trop spécifique). Je pense que par contre prestashop offre la possiblité à ton theme d'implementer ce genre de comportement.

Déjà merci pour ton message, mais ta compaison n'est pas la bonne. La bonne analogie c'est: "c'est un peu comme si vous disiez à un type qui fait une cuisine honnête qu'il ne peut pas être bénévole dans votre resto sous prétexte qu'il ne fait pas de l'assez bonne qualité". C'est ça la situation, et du coup ca me parait quand meme moins choquant. Le fait que ca soit plus rapide pour nous que pour toi ne me semble absolument pas un arguement valide. En soit j'aimerais bien passer plus de temps à debugger et merger avec la communauté (comme tout le monde ici) mais malheureseuement le temps manque cruellement. Par contre bonne nouvelle, Github nous permet depuis peu d'editer les PR des contributeurs, ça devrait regler ce problème.

C'est possible puisque toutes les declinaisons ont une url unique (basé sur l'id combinaison qui a ete rajouté dans l'url). J'ai bien compris la question? Sinon je veux bien un peu plus d'explications.

Hi, Here is the pull request, it will be merged soon. Once merged, you can export your theme with this command: "php app/console prestashop:theme:export themename" :tada:

Have you actually looked at it? I really don't get how you can say that it's not easier/faster. Look at ANY template in default-bootstrap and compare it to the 1.7 template (either StarterTheme or Classic, I guarantee you'll find it **much** cleaner and clearer. I understand it can be hard to re-learn and it's not always nice to see things changing, but if you make this little effort at the beginning, you'll see that you'll never touch default-bootstrap ever again.

Maintaining 2 modules might be complicated but maintaining backward compat' is WAY worse.

1. you should create a thread dedicated for this I would be happy to share my preferences and I guess many people can join in. 2. Not yet, but I'd like to make one. 3. The best way so far is to create a custom module to do that. Every developer will create their own. We would like to have a special kind of module, a "theme option module" 4. Nope. StarterTheme is agnostic, there is no lib bundled at all. The best way will be to use npm to get bootstrap 4, then import it in your theme.css and theme.js. Then modify templates to use bootstrap classes. 1. Thomas is working hard on the module validator right now, it should be in production soon. 2. Having a module compatible with both version is a **very very very very bad idea**. 1.6 will be maintained for a long time but there is no new features and such so your module shouldn't require much modification. Since 1.7 is a major version, loads of things have changed, like PHP version for example. There is also loads of great new features for front office: widgets, smarty is automatically escaped in 1.7, many smarty functions has been removed. If you want to have your module compatible, it will be hard, plus you won't be able to use ANY new feature (for example because namespace will break on PHP < 5.4. If you want to I believe the best way will be to have 2 modules.

Effectivement il y a 24h de cache. Si tu connais une solution. je suis preneur.

On a eu un bug dans l'API, ça a été corrigé. Merci pour l'alerte.

Je veux bien des exemples précis stp. On a porté tous les modules les plus utiles. On ne peut pas tout faire dans une version! Si on a viré des modules comme themeconfigurator ou blockstores c'est justement parce qu'on voudrait refaire un système beaucoup plus simple et puissant. Par exemple blockstores, editorial et tout un tas d'autres modules similaires peuvent etre remplacer un module de contenu. Il faut aussi cette fameuse feature de hooker un module plusieurs fois sur le meme hook. L'intéret de cette 1.7 c'est poser des bases pour le futur. Refaire live edit ou la gestion du contenu sera beaucoup plus simple avec ces bases saines.

Il faut bien comprendre les differents scénarii. Tu hook ton module sur un hook connu (genre displayLeftColumn) et tu geres le cas dans renderWidget() donc l'utilisateur final peut utiliser ton module sur n'importe quel hook. Tu peux même faire du preg_match sur le hookname, par exemple le comportement different sur un hook qui contient "column" ou "footer". Il faut quand meme toujours un comportement par defaut. Pour gerer la compat' avec un module 1.6, le mieux c'est de definir les methodes hookDisplayxxx qui fait un simple appel à renderWidget avec les bons parametres NOTE: Du coup tu ne peux pas implémenter l'interface puisqu'elle n'existe pas en 1.6. Il faut faire les methodes mais sans le "implement". Dans ton theme tu peux definir des hooks custom pour rajouter des features. En 1.7 c'est cool grace aux widget, en 1.6 il te faudra des modules compatibles (donc que les tiens avec une methode hookDisplayCustomxxx() ) Ensuite pour le {widget name="socialsharing"}: l'intéret c'est de pouvoir placer un module n'importe ou dans un theme. Ca ne crée pas de hook, ça appelle juste le module. C'est une feature qui est destiné aux marchants qui font un peu de custom eux meme ou des agences qui font un theme pour un client. Il vaut mieux l'éviter pour un theme Addons puisque ca n'est pas personnalisable dans la page module position, il faut forcement passer par le code.

L'interet d'utiliser render widget c'est pouvoir hooker ton module sur un autre hook, y compris un hook custom d'un theme: hookDisplayProductDescriptionAfter par exemple. Si tu gardes la fonction hookxxx ton module ne marchera QUE sur le hook qui porte tres exactement ce nom. Du coup je vois pas trop de bonne raison de ne pas utiliser renderWidget ^^

Effectivement tout l'intérêt de pouvoir casser la compat' était de pouvoir réorganiser tout ce qui est passé à Smarty et d'éviter les globales dans tous les sens. Toutes les URLS sont maintenant dans `$urls` et si besoin il y a un helper smarty {url}. Pour les fonctions sur les prix, elles ont été retiré du front (toujours dispo pour les PDF et l'Admin). Normalement les prix sont sensés arrivés dans la bonne currency et formatée. Si tu veux ajouter des trucs dans ton module et l'assigner dans smarty, tu peux le formaté coté PHP. Je t'encourage même à créer un presenter. Normalement ca marche exactement de la même manière.