🌍
Français
plg a écrit:
Zaphod a écrit:
(perso je n'aime pas l'affichage du nom de fichier + taille en ko, je ne vois pas l'intérêt pour le visiteur...
Tu as parfaitement raison (en tout cas je suis bien d'accord avec toi). Je crois que ça fait parti des morceaux de code qui n'ont pas changé depuis 2001. Et en 2001, ça avait un peu de sens : les connexions internet étaient beaucoup plus lentes et savoir le poids de la photo permettait d'éviter de l'ouvrir si elle dépassait une taille raisonnable. En 2011, cela n'a plus aucun sens et c'est mauvais en terme de SEO. Il faut changer cela.
post:169553
Zaphod a écrit:
(perso je n'aime pas l'affichage du nom de fichier + taille en ko, je ne vois pas l'intérêt pour le visiteur...
Tu as parfaitement raison (en tout cas je suis bien d'accord avec toi). Je crois que ça fait parti des morceaux de code qui n'ont pas changé depuis 2001. Et en 2001, ça avait un peu de sens : les connexions internet étaient beaucoup plus lentes et savoir le poids de la photo permettait d'éviter de l'ouvrir si elle dépassait une taille raisonnable. En 2011, cela n'a plus aucun sens et c'est mauvais en terme de SEO. Il faut changer cela.
flop25 a écrit:
nan nan je suis allez voir dans le code, il modifie carrément les valeurs de l'array des miniatures
Ah OK, donc de toutes façons pas moyen de s'en sortir en affichant le titre de la photo au survol...
(perso je n'aime pas l'affichage du nom de fichier + taille en ko, je ne vois pas l'intérêt pour le visiteur... ceci dit, pour utilisation avec download multi, ça peut avoir n sens.)
flop25 a écrit:
En effet. Là ce qui m'a fait réagir c'est le fait de créer des tpl juste pour des classes
En fait non, j'utilisais déja avant un tpl spécifique.
Pas forcément hyper différent, mais d'ailleurs même si les tpl sont identiques à ceux de default, je les utilise.
Au final j'ajoute des classes mais le minimum, ce qui permet, si à un moment quelqu'un utilise un thumbnails.tpl par défaut (comme download multi) d'avoir un affichage "potable".
mon discours est très généraliste
il est vrai que pour les thèmes minimalistes les incompatibilités sont intrinsèques.
C'est même pire que ça car ça recherche juste {$thumbnail.NAME}.
Donc c'est impossible d'afficher la légende au survol si on veut utiliser downloadmulti.
nan nan je suis allez voir dans le code, il modifie carrément les valeurs de l'array des miniatures
Honnêtement si je faisais comme ça, je ne m'en sortirais pas.
Et dès qu'il y a un changement dans les tpl de base, ça mettrait le thème à genoux.
....
certes plus compatible mais impossible à maintenir.
au contraire : avec une bonne expression régulière, seule un changement radical comme une suppression aura un impact, donc en gros c'est très fiable
C'est à ce prix qu'on peut voir arriver des thèmes qui tranchent avec les thèmes du core
En effet. Là ce qui m'a fait réagir c'est le fait de créer des tpl juste pour des classes, chose que j'avais il y a fort longtemps avec floPure et maintenant je suis aux anges avec les préfiltres. Dans le cas des thèmes minimalistes, c'est un peu un autre esprit, en effet : le but n'est pas d'être compatible avec un maximum de plugin mais plutôt de rester soi même.
Zaphod fait ce qui te plait avant tout, si tu es plus à l'aise en changeant les classes, vas-y. Plus tard tu peux changer d'avis ou qqun d'autre pourra t'aider à améliorer le système.
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.
Moi je dis que c'est pas bien grave non plus de ne pas être compatible avec Download Multi. Et globalement, ce n'est pas grave qu'un thème ne soit pas compatible avec tous les plugins voir avec certaines fonctionnalités du core (exemple de Simple qui a mis longtemps à être compatible avec le calendrier ou Luciano qui n'est toujours pas compatible avec les commentaires).
C'est à ce prix qu'on peut voir arriver des thèmes qui tranchent avec les thèmes du core (qui eux sont sensés supporter toutes les fonctionnalités).
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.
flop25 a écrit:
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 ).
C'est même pire que ça car ça recherche juste {$thumbnail.NAME}.
Donc c'est impossible d'afficher la légende au survol si on veut utiliser downloadmulti.
flop25 a écrit:
-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.
Honnêtement si je faisais comme ça, je ne m'en sortirais pas.
Et dès qu'il y a un changement dans les tpl de base, ça mettrait le thème à genoux.
Il y a tellement de changements dans les tpl que tout est intégré dedans.
(et encore, j'ai fait pas mal de changements par rapport à simple qui lui-même avait fait pas mal de changements par rapport au default)
Dans stripped, je ne reprends qu'un seul tpl de base : header.tpl
Tout le reste est refait.
Je préfère arriver au résultat que je veux simplement, que de partir dans une usine à gaz qui sera certes plus compatible mais impossible à maintenir.
En plus, la compatibilité avec les plugins est de toutes façons caduque, car généralement ça pose de gros problèmes de mises en page.
Grosso modo, quelque soit le plugin, il faut adapter.
C'est là que je regrette un peu d'être sorti du style voulu de départ "minimaliste" (pas de commentaires, pas de notes, pas de calendrier, pas ou peu de plugins).
En fait j'ai déja trop adapté le thème pour différents plugins...
flop25 a écrit:
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 ) ?
C'est juste une question de lisibilité du fichier theme.css.
"wrap1" "wrap2" ça ne signifie rien pour moi, je ne sais jamais à quoi ça fait référence.
D'autre part, si on fait une règle : ".class1:first-child" au lieu de ".class1 .class2" que se passe-t-il si on insère une autre classe ensuite, entre les deux ?
C'est non seulement très peu lisible, mais pénible à gérer.
En plus ça ne marche probablement pas avec IE6 donc il faudra trouver une ruse pour ce navigateur...
C'est juste mon avis ;)
Je ne suis ni programmeur, ni expert en css ni rien, tout ce que je connais en css/js/php je l'ai appris sur le tas en personnalisant piwigo.
Donc il se peut que je ne fasse pas de la manière la plus propre possible, mais sinon je ne m'en sors pas.
Les préfiltres par exemple je n'y connais rien, et le php je n'y comprends pas grand chose.
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 ) ?
Zaphod a écrit:
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.
Bonjour,
Si ont veut absolument la compatibilité de "download multi" avec "stripped", comment peut-ont faire pour inverser le nom de fichier et le titre de l'image?
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.
alors là à froid... faut voir par ex download multi
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.
et bien les préfiltres! pour localiser les wrap1 si tu rajoutes des classes, ya de fortes chances que preg ne marchera plus (à moins que l'expression régulière soit super travaillée pour anticiper ça)
Pourquoi ? c'est super simple comme méthode.
Je ne vois pas la différence en terme de rendement.
Quels sont les désavantages ?