J'ai remis les span et les wrap mais pour l'instant j'ai laissé mes classes en plus.
Je ne trouve pas ça très logique mais bon, ça n'est pas bien grave !

Est-ce que de cette manière il peut y avoir des problèmes de compatibilités ?

(bon il y a toujours des possibilités de problèmes quand on change des templates, mais j'essaie juste de les limiter)
Pour ce que je veux faire... je suis obligé de rajouter des classes (car les classes en question dépendent des options de config)

Dernière modification par Zaphod (2011-05-24 22:40:25)

Dans l'absolu, si, mais ça me parait plus compliqué à faire.
Là j'affecte une classe en fonction de la valeur de config et tout est dans le theme.css.

Joure sur le css, je l'ai déja fait dans le cas d'un argument séparé (forcer la casse en miniatures, dans ce cas j'appelle un fichier css en plus).
Mais là, ça m'obligerait à morceller les css des miniatures sur plusieurs fichiers.
C'est sans doute plus propre mais plus difficile à gérer.

Pourquoi ? c'est super simple comme méthode.
Je ne vois pas la différence en terme de rendement.

Quels sont les désavantages ?

Dernière modification par Zaphod (2011-05-24 22:55:27)

Oui mais dans ce thème, il y a de toutes façons des classes et des id rajoutées partout (j'en ai besoin pour maîtriser la mise en page).

As-tu des exemples de plugins qui utilisent ce genre de préfiltre que je fasse des tests ?


Si ça plante trop, je peux abandonner les classes, mais j'abandonne alors l'option qui va avec... sinon ça met trop le bordel dans le theme.css ça devient trop difficile à maintenir.
(vu que c'est une option que perso je n'utiliserai pas... je n'y suis pas des masses attaché)
A moins qu'il y ait un truc simple pour agir sur les css en fonction de variables de config.

Dernière modification par Zaphod (2011-05-24 23:17:53)

C'est un bon exemple, car ça ne marche effectivement pas ;)
Ni avant ma modif, ni après.

Avant, ça ne peut pas marcher car de base il est impossible d'afficher les légendes des miniatures avec stripped. (c'est justement le principe de la modif).
Au final ça donne ça, avec modif et en activant les légendes :
http://www.audreyetjulien.fr/test/index.php?/category/3
(avant la modif, c'est la même chose sans la légende et sans la checkbox, mais avec les caractères bizarroïdes).

[edit] En fait le souci viens juste du fait que je mets le titre de l'image et pas le nom de fichier au survol, et que du coup Download multi édite la balise title de l'image...
Comme je ne veux surtout pas afficher le nom du fichier... ça me parait difficile d'être compatible avec download multi.

Dernière modification par Zaphod (2011-05-24 23:37:52)

j'ai pris cette exemple au hasard (il est mauvais car le plugin change carrément la valeur de $thumbnail.NAME plutôt que de préfiltrer {if isset($thumbnail.NAME)}{$thumbnail.NAME}{/if}, ce qui m'étonne carrément ! Car dès que les nom est utilisé ailleurs ou sa valeur traité dans un plugin, ça va se retrouver parasité par downloadmulti ).

mais la nuit portant conseil j'ai réfléchit au bénéfices/problèmes d'un changement de cette ordre.
En fait tout dépend de où on rajoute des classes et surtout comment :
-si tu changes les tpl par préfiltres pour rajouter tes classes et faire des changements mineurs comme le {if isset($thumbnail.NAME)}title="{$thumbnail.NAME}"{else}title="{$thumbnail.TN_TITLE}{/if}, tout va bien. Il faudrait mettre une priorité basse afin de laisser les plugins préfiltrer les tpl default. ceux voulant préfiltrer une modif de stripped mettront une priorité encore plus basses que la tienne.
-si tu ne peux pas et que tu fais des tpls, alors ça devient du cas par cas. Dans les plugins, il y a peu de préfiltre actuellement (ou alors je n'ai pas les bons plugin ^^)  mais basiquement les moyen de se repérer dans le code c'est soit les tag smarty, soit les classes/id ...c'est pourquoi je conseille un préfiltre si tu veux rajouter une classe

Mais là on touche au problème de compatibilité plugin/thème inhérent à tout script qui gère ce genre d'extensions : honnêtement on est loin de wordpress où l'artisanat (l'entente directe entre auteur de plugin et auteur de thèmes) a fait place au DIY (faites le vous même si ne ça marche pas en plaçant la fonction qui va générer le code, dans les fichiers thèmes)

Par contre je ne comprends pas pourquoi tu as besoin de rajouter autant de classes/id : tu ne peut pas te repérer via les sélecteurs en jouant sur parents/enfants/à coté de ( http://www.xul.fr/css/selecteur.php ) ?

Sinon, là où ça pose un problème avec DownloadMulti, c'est pour l'affichage du panier.
Ca sera forcément moche à moins de passer beaucoup de temps à essayer de ruser pour réussir à obtenir une mise en page correcte sans les sélecteurs qui vont bien.
J'avoue que je n'en ai pas le courage pour l'instant ;) (d'autant que pour bien faire il faudrait aussi changer les icones qui ne vont pas avec le thème)

Alors qu'un plugin comme PWG stuffs va chercher le thumnails.tpl du thème par exemple, du coup c'est beaucoup plus facile à maîtriser.


Après il y a toujours le choix :
- soit on cherche la compatibilité à tout prix et on est très restreint dans la mise en page
- soit on cherche le maximum de souplesse sur la mise en page et forcément ça sera plus difficile avec les plugins.

Je préfère la deuxième solution, et encore je trouve que je n'ai pas été assez loin dans l'écart avec le thème default.
Globalement, ça reste un thème assez classique alors que j'avais imaginé au départ quelque chose qui tranche plus, quitte à perdre des fonctionnalités.

Dernière modification par Zaphod (2011-05-25 13:52:50)

Bon en tous cas je suis revenu en arrière sur les appellations (tant pis pour la lisibilité...)  parce que du coup on peut assurer la compatibilité facilement sans perdre en fonctionnalités.

En revanche... c'est toujours pas très beau... mais ça tant pis ;) forcément un plugin qui rajoute des icones ne peut pas s'intégrer bien avec tous les thèmes.

Dernière modification par Zaphod (2011-05-25 14:39:22)