Hello, je suis en train de tester la beta 2, à propos des dates, quand je publie un article, en renseignant 3 dates différentes (publication, création, mise à jour) pour tester, quand je vais sur l'article au final sur l'article, il n'y a qu'une seule date qui apparaît : celle de publication (comme dans la 5.4).
Les 2 autres dates apparaissent nulle part, j'ai cherché dans la source, dans le code html, pas vu les 2 autres dates.
Donc ma question est la suivante : les dates de création et mise à jour, on pourra les voir que du côté administration ?
Je pensais qu'on allait avoir au moins 2 dates qui apparaissent : publication et date de mise à jour (publié le, mis à jour le...quelque chose comme ça), ce sera le cas dans la version finale ?
Ça m'aura pris jusqu'à maintenant pour, comme disent les anglais, "jeter mon nom dans le chapeau" et installer cette chose toute nouvelle toute belle. Partant d'une installation neuve, vous savez bien que tout c'est bien passé, il ne restait qu'à me lancer. Presque tout le monde connaît mon appréciation (le mot est faible) pour le plugin Vignette, je me suis donc précipité sur la nouvelle fonction machin d'accoche d'image à même l'écran d'édition d'article. J'ai consulté quelques instants les références pour savoir comment afficher ladite accroche sur ma première page d'article. Tout est là bien en vue, je trépidais d'impatience.
Je ne cacherai pas plus longtemps ma déception, il est sans doute bien trop tard me plaindre, j'avais des attentes disproportionnées comme révolutionner tous mes thèmes et en retirer la mention copiée-collée "plugin Vignette obligatoire". J'annonce avec regret que, dans sa version courante, cette fonction ne me sera d'aucune utilité. Le machin tant prometteur ne fait qu'un chose, afficher en format original une image avec tous les paramètres HTML "gelés" pour nous sans espoir de les modifier facilement. Je n'ai jamais autant espéré ne pas avoir tout compris, vous me sauverez si c'est le cas.
Pour sécher mes pleurs, le plugin Vignette a pris la relève en quelques minutes et fonctionne à merveille sans le moindre ajustement. Si rien n'est fait, ce sera mon prix de consolation, ma mention copiée-collée restera, je continuerai de chanter les louanges du plugin, peut-être qu'on fera des modifications pour la seule raison de ne plus m'entendre, vous vous doutez bien que ce ne sera pas la première fois...
Longue vie à PluXml version 5.5! (mais j'ai déjà hâte à la 5.6...)
J'ai retrouvé mes esprits et je suis entré dans le core (j'avais quand même résisté de longues minutes) pour étudier la fonction.
Eureka! Tout est là! Le format par défaut peut être modifié, exactement comme le demandaient mes prières. Je retire mon pied de ma bouche et je fais d'autres tests mais les choses sont très prometteuses.
J'y suis presque, j'ai posé la question sur le fil qui explique en toutes lettres ce que je demandais et clamais n'avoir pas reçu pour Noël. Au moins l'ajout est très récent, mon orgueil n'en souffrira pas trop. J'ajoute l'insulte à l'injure en reposant ici la même question:
La variable #img_url retourne le chemin entier pour l'image en question mais comment pouvons-nous afficher le chemin relatif (qui commence par défaut à "data/medias/...") exactement comme on le voit dans le formulaire de l'écran d'édition d'article?
J'imagine que ce n'est pas trop difficile pour les experts en la matière. Après quelques essais infructueux, je remets mon sort entre vos mains une fois de plus.
Incroyable mais vrai, j'y suis arrivé. Si tout continue sur cette lancée, je devrais très bientôt arrêter de vous casser les pieds avec mon plugin adoré Vignette. La raison de ma demande précédente était une contrainte de l'utilitaire cImage qui ne semblait pas apprécier les URL trop longs. Il s'agissait d'une protection dudit utilitaire qui empêchait d'aller chercher des images sur des hébergeurs externes. Cette variable est paramétrable et on peut enlever la protection en connaissance de cause. En bonus, l'application accepte autant les URL relatifs que les absolus lorsque ce paramètre est désactivé.
Il ne me restera qu'à remercier une dernière fois Rockyhorror pour avoir permis la construction si simple de pages avec des images dédiées aux articles. Il est fort possible que Vignette soit encore nécessaire à quelques endroits mais cette nouvelle fonction fera le travail dans la grande majorité des cas.
Pour les intéressés, vous pouvez donc utiliser l'utilitaire cImage de la façon suivante:
par exemple, pour rogner une image et la placer dans un gabarit de 300X200. Cette fonction bien anodine permet de charger dans le répertoire médias une photo originale et la placer à plusieurs endroits aux gabarits différents en ne changeant que la taille dans les paramètres w et h.
Merci, je suis certain que ça me servira même si j'avais trouvé une solution de contournement.
J'en ai une autre pour vous, nous en avions beaucoup parlé, la situation est causée par la fâcheuse habitude des fonctions de PluXml de finir par un ECHO plutôt que par un RETURN avec la cargaison de la donnée (ou la chaîne) produite.
En gros je cherche à utiliser la variable de l'url de l'image à l'intérieur d'une fonction formattée, surtout avec lastArtList(). Je bloque parce que je ne peux pas inscrire un $plxShow->artThumbnail('#img_url') au beau milieu de la chaîne de format...
Il suffit de dupliquer la fonction plxShow::artThumbnail() et de remplacer echo par return. Il faut gérer en plus le cas où il n'y a pas d'image d'accroche.
Et comme je n'aime pas les empilages de str_replace, on aboutit à ceci :
Mise à jour, ça ne fonctionne pas. Mon besoin de l'insérer dans une fonction comme lastArtList n'est pas répondu par le dernier subterfuge. J'ai pris le temps d'étudier un peu la méthode que j'utilise avec Vignette, la fonction "retapée" appelée vignetteArtList fonctionne tellement facilement que la tentation de garder le plugin revient me hanter.
@Stephane:
Est-il possible de simplement insérer les variable "#img_title", "#img_alt" et surtout "#img_url" directement dans lastArtList() ? Je pourrais évidemment le faire dans le core mais peut-on espérer voir ces variables insérées de facto?
On le fait en modifiant class.plx.show vers la ligne 960 de:
C'est 100% "legacy-compatible", toutes les autres variables cohabitent sans problème. On peut même laisser le plugin Vignette en place pendant la transition et faire les bouts de code un à un avec ces nouvelles valeurs plus pratiques.
En fait, ce changement ne sera pas aussi pratique que ma suggestion parce qu'il encapsule toute la fonction. D'ailleurs, je trouve un peu sémantiquement rigolo d'appeler la variable thumbnail alors qu'elle peut servir partout où une image est utilisée. Le nom img_url de la "sous-variable" Par exemple, mes immenses images d'un slider de page d'accueil feront un très bon usage de cette nouvelle fonction. Pour moi, le mot thumbnail réfère spécifiquement à une miniature, mais bon, je m'éloigne du sujet.
Ainsi, s'il est possible de reculer un peu et de faire le petit ajout des trois variables (url, title et alt), à mon avis, ça offre une plus grande flexibilité et surtout la possibilité d'utiliser un utilitaire externe pour rogner ladite image à la volée, un élément très important pour permettre de n'utiliser qu'une version d'une image mais à plusieurs endroits aux formats différents.
si je te donne les variables url, title et alt, tu vas/veux en faire quoi ? les mettre dans une balise <img> ? car je ne vois pas l’intérêt de les utiliser autrement (sauf si tu me donnes les bons exemples). donc autant avoir toute la syntaxe disponible pour avoir l'affichage de l'image tout de suite, sans rallonger les paramètres. je rappelle aussi que lastArtList a fonctionnellement un but bien précis, et très souvent son utilité est détournée pour d'autres besoins qui n'ont rien à voir avec ce pourquoi lastArtList a été développée.
quand tu dis "ce changement ne sera pas aussi pratique". peux-tu expliquer stp et surtout donner des exemples sur ce qui pour toi est pratique et dans quel contexte ?
je te titille volontairement pour que tu arrives à faire basculer la balance de ton coté en amenant des arguments et des exemples pour me convaincre si je donne l'impression de chercher la petite bête c'est parce que je vois certaine choses plus loin que le simple ajout de 3 variables url, title et alt, ça m'aide à me projeter sur d'autres idées qui mûrissent doucement dans ma tête, d'imaginer d'autres axes de travail et d'amélioration.
exemple: si ça devient trop alambiquer d'utiliser lastArtList pour répondre à certains besoins, ça veut peut être dire que la fonction est devenue au fil des versions inadaptées et donc ça vaut peut-être aussi le coup d'en (re)développer une autre plutôt que de rajouter une rustine.
merci
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Pas de problème, c'est loin d'être un caprice, c'est important de bien en comprendre l'impact avant de modifier le core, même si peu. La fonction lastArtList est l'une des plus utilisées, y compris par moi, ça n'est pas sur le point de changer. Le meilleur exemple est celui mentionné plus haut d'une utilisation externe de ces variables, dans mon cas, cImage avec son fichier img.php dont je parle dans chacun de mes thèmes. Je te donne une ligne classique qui sera sans doute utilisée des douzaines de fois dans mes thèmes qui vont rouler sous 5.5:
Cette ligne bien anodine appelle l'utilitaire cImage pour rogner l'image et la faire entrer clairement dans un gabarit de 300X200. D'innombrables autres fonctions sont possibles directement dans la ligne d'appel alors les autres alternatives comme le CSS ou autres sont toutes plus compliquées.
Je répète que l'ajout de ces trois petites variables n'affecte absolument aucune installation passée de lastArtList. Pour ceux qui ne voient aucune utilité aux variables concernées, ils ne les verront jamais à part en fouillant dans la fonction dans le core (ou en lisant le manuel, mais qui fait ça!). Plus sérieusement, si ces variables ne font pas partie du bagage de base, je devrai continuer d'inclure Vignette avec tous mes thèmes ou fournir une class.plx.show avec chacun, ce qui risque d'efffrayer les frileux ou ceux qui ont possiblement déjà touché au fichier en question.
y a t-il une raison particulière pour ne pas préparer tes miniatures de 300x200 à l'avance.
pourquoi lors de l'upload des images via le gestionnaire de médias, tu ne génères pas une miniature de 300x200 que tu pourrais utiliser comme image d'accroche. ça éviterait d'utiliser cImage à la volée qui va consommer de la ressource inutilement. L'utilisation serait simplifié dans lastArtList
sinon j'ai bien compris le pourquoi de ta demande maintenant. je regarde ce que je peux et comment le faire proprement
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Voilà la force de cImage dévoilée, la même image pigées dans le dossier Médias est utilisée en format 960X340 dans un slider de l'accueil, en format 160X160 dans une sidebar affichant les dernières nouvelles, en version verticale de 150X500 dans une version publicitaire promotionnelle (je fabule) ailleurs dans une autre sidebar. On peut donner à chacune de ces instances des effets visuels comme une version noir et blanc qui se transforme en couleur quand on survole l'image avant de cliquer, une image arrière volontairement floue pour offrir en rotation un échantillon des images des articles, assurant un look dynamique.
Je pourrais en écrire pendant des heures. Cette fonction peu connue est le couteau suisse (ou devrais-je dire suédois pour honorer son créateur) de la gestion d'images.
et de l'utilisation qu'en font tous ceux qui utiliseront les thèmes que j'adapte et que je place dans la rubrique Ressources, les versions passées seront mises à jour et fortement simplifiées, les futures commenceront leur vie sans le plugin Vignette, une chose de moins à demander d'installer avant qu'un thème démarre correctement.
Je pourrais dire en riant de télécharger presque n'importe lequel des thèmes à mon nom ou de faire une recherche dans les forums, je casse les pieds de nos collègues depuis des mois, auparavant, je leur cassais les pieds avec Timthumb qui remplissait le même rôle.
Alors, le concepteur de cImage offre le tout sur github où l'on télécharge l'unique fichier img.php
mais les explications de ses prouesses se trouvent sur son site web
Il gagne à être connu mais pour les Pluxémélistes qui veulent accélérer le processus, ils n'ont qu'à utiliser l'un de mes thèmes pour le voir en action.
Dans la dernière modif de la fonction plxShow::artThumbnail(), si le champ thumbnail de la fiche article est vide et qu'on a mis le paramètre $echo à false dans l'appel de la fonction, on ne retourne aucune valeur. C'est un peu frustant. Il vaudrait mieux retourner la valeur false :
Ma foi, ce GUI de sélecteur de thème dans l'admin, c'est tellement génial!
On fait un fichier "preview.png" et un infos.xml pour chacun et on lance sa gomme à l'écran... Ça va donner le goût de changer de thème tous les jours.
Dans la dernière modif de la fonction plxShow::artThumbnail(), si le champ thumbnail de la fiche article est vide et qu'on a mis le paramètre $echo à false dans l'appel de la fonction, on ne retourne aucune valeur. C'est un peu frustant. Il vaudrait mieux retourner la valeur false :
tu peux utiliser maintenant #img_url, #img_title, #img_alt dans lastArtList en + de #art_thumbnail
Ça va telllllllement bien! T'as pas idée.
J'ai déjà hâte de convertir mon premier thème en 5.5 avec la mention marketing "aucun plugin nécessaire". [del]J'espère que le thème aura pas de page contact ou d'outil de recherche [/del] (insérer GROS CLIN D'OEIL ici!).
après cette mise a jour j'ai ce message d'erreur uniquement dans la sidebar des page statique dans les Dernieres Articles
Fatal error: Call to a member function f() on null in /home/xxx/xxx/xxx/xxx/core/lib/class.plx.show.php on line 527
et je n'ai plus de footer visible e le reste du contenu de la sidebar( non plus )
Réponses
Les 2 autres dates apparaissent nulle part, j'ai cherché dans la source, dans le code html, pas vu les 2 autres dates.
Donc ma question est la suivante : les dates de création et mise à jour, on pourra les voir que du côté administration ?
Je pensais qu'on allait avoir au moins 2 dates qui apparaissent : publication et date de mise à jour (publié le, mis à jour le...quelque chose comme ça), ce sera le cas dans la version finale ?
Pierre Aribaut - zetrader & zeforums
http://forum.pluxml.org/viewtopic.php?pid=47631#p47631
http://forum.pluxml.org/viewtopic.php?pid=47656#p47656
Code pour cacher la date de mise à jour si identique à la date de création ?
http://forum.pluxml.org/viewtopic.php?pid=47686#p47686
http://forum.pluxml.org/viewtopic.php?pid=47691#p47691
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je ne cacherai pas plus longtemps ma déception, il est sans doute bien trop tard me plaindre, j'avais des attentes disproportionnées comme révolutionner tous mes thèmes et en retirer la mention copiée-collée "plugin Vignette obligatoire". J'annonce avec regret que, dans sa version courante, cette fonction ne me sera d'aucune utilité. Le machin tant prometteur ne fait qu'un chose, afficher en format original une image avec tous les paramètres HTML "gelés" pour nous sans espoir de les modifier facilement. Je n'ai jamais autant espéré ne pas avoir tout compris, vous me sauverez si c'est le cas.
Pour sécher mes pleurs, le plugin Vignette a pris la relève en quelques minutes et fonctionne à merveille sans le moindre ajustement. Si rien n'est fait, ce sera mon prix de consolation, ma mention copiée-collée restera, je continuerai de chanter les louanges du plugin, peut-être qu'on fera des modifications pour la seule raison de ne plus m'entendre, vous vous doutez bien que ce ne sera pas la première fois...
Longue vie à PluXml version 5.5! (mais j'ai déjà hâte à la 5.6...)
J'ai retrouvé mes esprits et je suis entré dans le core (j'avais quand même résisté de longues minutes) pour étudier la fonction.
Eureka! Tout est là! Le format par défaut peut être modifié, exactement comme le demandaient mes prières. Je retire mon pied de ma bouche et je fais d'autres tests mais les choses sont très prometteuses.
La variable #img_url retourne le chemin entier pour l'image en question mais comment pouvons-nous afficher le chemin relatif (qui commence par défaut à "data/medias/...") exactement comme on le voit dans le formulaire de l'écran d'édition d'article?
J'imagine que ce n'est pas trop difficile pour les experts en la matière. Après quelques essais infructueux, je remets mon sort entre vos mains une fois de plus.
Il ne me restera qu'à remercier une dernière fois Rockyhorror pour avoir permis la construction si simple de pages avec des images dédiées aux articles. Il est fort possible que Vignette soit encore nécessaire à quelques endroits mais cette nouvelle fonction fera le travail dans la grande majorité des cas.
Pour les intéressés, vous pouvez donc utiliser l'utilitaire cImage de la façon suivante:
<img src="img.php?src=<?php $plxShow->artThumbnail('#img_url'); ?>&w=300&h=200&crop-to-fit">
par exemple, pour rogner une image et la placer dans un gabarit de 300X200. Cette fonction bien anodine permet de charger dans le répertoire médias une photo originale et la placer à plusieurs endroits aux gabarits différents en ne changeant que la taille dans les paramètres w et h.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
J'en ai une autre pour vous, nous en avions beaucoup parlé, la situation est causée par la fâcheuse habitude des fonctions de PluXml de finir par un ECHO plutôt que par un RETURN avec la cargaison de la donnée (ou la chaîne) produite.
En gros je cherche à utiliser la variable de l'url de l'image à l'intérieur d'une fonction formattée, surtout avec lastArtList(). Je bloque parce que je ne peux pas inscrire un $plxShow->artThumbnail('#img_url') au beau milieu de la chaîne de format...
Imaginez par exemple:
<?php $plxShow->lastArtList('<li><img src="img.php?src='.artThumbnail('#img_url').'&w=300&h=200&crop-to-fit"></li>'); ?>
Vous voyez le genre, c'est le artThumbnail('#img_url') au milieu que j'ai inventé ici pour illustrer, il n'est pas permis.
Et comme je n'aime pas les empilages de str_replace, on aboutit à ceci :
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Merci pour le coup de main.
@Stephane:
Est-il possible de simplement insérer les variable "#img_title", "#img_alt" et surtout "#img_url" directement dans lastArtList() ? Je pourrais évidemment le faire dans le core mais peut-on espérer voir ces variables insérées de facto?
On le fait en modifiant class.plx.show vers la ligne 960 de:
à
C'est 100% "legacy-compatible", toutes les autres variables cohabitent sans problème. On peut même laisser le plugin Vignette en place pendant la transition et faire les bouts de code un à un avec ces nouvelles valeurs plus pratiques.
Tu peux l'utiliser de cette façon par exemple
c'est dispo à partir du github: https://github.com/pluxml/PluXml/archive/master.zip
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Ainsi, s'il est possible de reculer un peu et de faire le petit ajout des trois variables (url, title et alt), à mon avis, ça offre une plus grande flexibilité et surtout la possibilité d'utiliser un utilitaire externe pour rogner ladite image à la volée, un élément très important pour permettre de n'utiliser qu'une version d'une image mais à plusieurs endroits aux formats différents.
quand tu dis "ce changement ne sera pas aussi pratique". peux-tu expliquer stp et surtout donner des exemples sur ce qui pour toi est pratique et dans quel contexte ?
je te titille volontairement pour que tu arrives à faire basculer la balance de ton coté en amenant des arguments et des exemples pour me convaincre si je donne l'impression de chercher la petite bête c'est parce que je vois certaine choses plus loin que le simple ajout de 3 variables url, title et alt, ça m'aide à me projeter sur d'autres idées qui mûrissent doucement dans ma tête, d'imaginer d'autres axes de travail et d'amélioration.
exemple: si ça devient trop alambiquer d'utiliser lastArtList pour répondre à certains besoins, ça veut peut être dire que la fonction est devenue au fil des versions inadaptées et donc ça vaut peut-être aussi le coup d'en (re)développer une autre plutôt que de rajouter une rustine.
merci
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
lastArtList($format='<li><img src="img.php?src=#img_url&w=300&h=200&crop-to-fit" title="#img_title" alt="#img_alt"><a href="#art_url" title="#art_title">#art_title</a></li>')
Cette ligne bien anodine appelle l'utilitaire cImage pour rogner l'image et la faire entrer clairement dans un gabarit de 300X200. D'innombrables autres fonctions sont possibles directement dans la ligne d'appel alors les autres alternatives comme le CSS ou autres sont toutes plus compliquées.
Je répète que l'ajout de ces trois petites variables n'affecte absolument aucune installation passée de lastArtList. Pour ceux qui ne voient aucune utilité aux variables concernées, ils ne les verront jamais à part en fouillant dans la fonction dans le core (ou en lisant le manuel, mais qui fait ça!). Plus sérieusement, si ces variables ne font pas partie du bagage de base, je devrai continuer d'inclure Vignette avec tous mes thèmes ou fournir une class.plx.show avec chacun, ce qui risque d'efffrayer les frileux ou ceux qui ont possiblement déjà touché au fichier en question.
pourquoi lors de l'upload des images via le gestionnaire de médias, tu ne génères pas une miniature de 300x200 que tu pourrais utiliser comme image d'accroche. ça éviterait d'utiliser cImage à la volée qui va consommer de la ressource inutilement. L'utilisation serait simplifié dans lastArtList
sinon j'ai bien compris le pourquoi de ta demande maintenant. je regarde ce que je peux et comment le faire proprement
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je pourrais en écrire pendant des heures. Cette fonction peu connue est le couteau suisse (ou devrais-je dire suédois pour honorer son créateur) de la gestion d'images.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Alors, le concepteur de cImage offre le tout sur github où l'on télécharge l'unique fichier img.php
mais les explications de ses prouesses se trouvent sur son
site web
Il gagne à être connu mais pour les Pluxémélistes qui veulent accélérer le processus, ils n'ont qu'à utiliser l'un de mes thèmes pour le voir en action.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
À ce moment, on peut dire de produire un comportement différent SI la valeur est présente ou absente.
On fait un fichier "preview.png" et un infos.xml pour chacun et on lance sa gomme à l'écran... Ça va donner le goût de changer de thème tous les jours.
dans le fichier core/admin/parametres_edittpl.php
la liste restreinte de types de fichiers acceptés pour l'édition en ligne n'inclut pas le "xml" pour notre nouvel ami infos.xml
merci. pris en compte
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
c'est dispo à partir du github: https://github.com/pluxml/PluXml/archive/master.zip
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
pris en compte. modif dispo
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Ça va telllllllement bien! T'as pas idée.
J'ai déjà hâte de convertir mon premier thème en 5.5 avec la mention marketing "aucun plugin nécessaire". [del]J'espère que le thème aura pas de page contact ou d'outil de recherche [/del] (insérer GROS CLIN D'OEIL ici!).
Bravo en attendant.
après cette mise a jour j'ai ce message d'erreur uniquement dans la sidebar des page statique dans les Dernieres Articles
Fatal error: Call to a member function f() on null in /home/xxx/xxx/xxx/xxx/core/lib/class.plx.show.php on line 527
et je n'ai plus de footer visible e le reste du contenu de la sidebar( non plus )
une idee?