rub a écrit:

o les traductions manquantes

je suppose que tu fais reference a l'affichage du message au milieu maintenant a la place du debut de la page... malheuresement je n'ai pas de solution pour ca...

rub a écrit:

o la création de la branche complète du répertoire de cache

je ne voulais pas que ca soit moi qui casse la compatibilite avec php 4 :-) mais il suffit de rajouter un parametre a l'appel de mkdir ...

Est-ce qu'on pourrait avoir un $template->set_rootdir?
Ou bien, je revois les mails en changeant de méthodes!
En fait, peu importe pour moi!

La césure est parfois importante, et elle sera forte en 1.8 et sur tous les points (php5, classes, template, ).
On devra fournir les mêmes "méthodes" que pour l'ancien template => pour arriver à des résultats similaires et fournir une doc pour migrer les plugin perso et les plugins tout court.

Les méthodes actuelles sont assez difficiles à mettre en place, les nouvelles seront peut-être plus faciles...

Par contre Smarty offrira beaucoup plus possibilité aux plugers.

rub a écrit:

Par contre Smarty offrira beaucoup plus possibilité aux plugers.

Je ne conteste pas...
8-)

VDigital a écrit:

Quelqu'un pourrait-il m'expliquer comment nous justifions que les conseils donnés en 1.7 comme Ajouter du code dans un fichier tpl avant un délimiteur, lesquels se généralisent via LocalFiles Editor, forceront à desactiver le "Personal Plugin" avant la migration 1.8 et que les adapations seront toutes à revoir.
D'accord, les modifications sont regroupées dans des plugins ce qui simplifie les opérations après migration, mais quand même.
Cela devait permettre de ne pas recoder les modifications locales.
Soyons clairs?
Prenons une révision simple yoga/profile.tpl et imaginons quie un site qui utilisait "Ajouter du code dans un fichier tpl avant" sur la base de ' <h2>{lang:Profile}</h2>'.
Le plugin Personnel ne fonctionne déjà plus!
Car il faut maintenant:
1 - "Ajouter du code dans un fichier tpl avant" sur la base de ' <h2>{'Profile'|@translate}</h2>' et non ' <h2>{lang:Profile}</h2>'.
2 - Ajouter du code TPL différent.
3 - Et modifier la fonction personal_add_before_tpl_code()
J'imagine que le commun des PWGnautes ne va pas très bien comprendre.

Quelqu'un peut-il justifier que notre principe soit si vite abandonné?

Vincent,
Je n'ai jamais ete pour, ni conseille la modif du template a la volee. Toute modif du template ou une nouvelle theme aurait eu le meme effet -> ca ne marche plus ...
Ma vision initiale de plugins n'etait certainement pas de modifier le code des templates a la volee ...
Avec smarty on va prevoir l'insertion du html la ou c'est necessaire.

J'ai bien compris que tu n'est pas pour smarty et oui il y aura de l'incompatibilite des plugins et du boulot a faire, mais je pense qu'a terme le gain en flexibilite grace a smarty va compenser le travail qu'on fait maintenant...

rvelices a écrit:

Je n'ai jamais ete pour, ni conseille la modif du template a la volee. Toute modif du template ou une nouvelle theme aurait eu le meme effet -> ca ne marche plus ...
Ma vision initiale de plugins n'etait certainement pas de modifier le code des templates a la volee ...

J'avais très bien compris quelle était ta position sur la modification du template à la volée et je partage totalement ton point de vue.
- Il est parfaitement illogique de modifier de la même façon un template à chaque accès,
- Ceci pénalise le serveur.
- Maintenant cela a été fait et...

rvelices a écrit:

Avec smarty on va prevoir l'insertion du html la ou c'est necessaire.

Je veux bien que tu me dises où tu as fait un exemple d'insertion dès maintenant et pas après la publication de la 1.8...
Juste pour éviter le même piège.

rvelices a écrit:

J'ai bien compris que tu n'est pas pour smarty et oui il y aura de l'incompatibilite des plugins et du boulot a faire, mais je pense qu'a terme le gain en flexibilite grace a smarty va compenser le travail qu'on fait maintenant...

Je ne suis pas contre ou pour smarty. Je suis pour des évolutions en douceur et éviter les révolutions.
Ne crois pas que je considère l'adjonction de smarty comme une révolution pour autant.
Smarty déporte des expressions ou instructions au niveau du template, il complexifie les templates, et simplifie les php.
Pour une meilleure compréhension du langage smarty, je préconise d'éviter dans la version de base l'usage des fonctions avancées de smarty.
(Enfin je pense qu'il aurait été plus acceptable de faire un autre yoga en smarty et de laisser yoga intact en 1.8 pour le faire disparaitre définitivement en 1.9. D'autant plus que tu avais fait le nécessaire pour ça. C'est mon point de vue.).

8-)

Arrêtez de penser comme des développeurs quand vous pensez aux templates.
Déjà que le HTML est un mystère pour beaucoup de gens, et les CSS c'est perçu comme de la sorcellerie, alors les instructions smarty...
C'est demander beaucoup d'efforts à ceux qui n'ont jamais codé de leur vie et vont vouloir... qui sait quoi.

Pour le reste:
Les combos, je sais bien. P@t me l'avait déjà signalé et je le savais mais là, on parle plus coté admin et je me fiche que les tpl soient complexes en admin.
2 moteurs, c'est la situation actuelle et rvelices s'en est sorti admirablement. On pouvait les garder pour le temps de la 1.8, d'ailleurs ai-je loupé une marche où l'ancien sera encore présent.
Ta conclusion UTF-8, est rigoureusement exacte mais on y peut pas grand chose c'est le sens de l'histoire.
8-)

rvelices a écrit:

P@t,
Peux-tu t'assurer que sur ton environement de dev, t'as bien dans php.ini
error_reporting  =  E_ALL
? Tu verras qu'il y a qq warnings sur user_list

Oui oui, je suis bien sur E_ALL...
Quels warnings?
EDIT: je viens de tout re-tester à fond le user_list, et je n'ai aucun message d'erreur...

Dernière modification par P@t (2008-03-08 12:36:37)