- Statut : non résolu
- Ce sujet contient 151 réponses, 7 participants et a été mis à jour pour la dernière fois par
, le il y a 8 années et 7 mois.
-
Messages
-
Bonsoir,
De rien, j’aime bien ce plugin car il est écrit avec une requête SQL personnalisée et j’aime écrire des requêtes avec ce langage SQL. Alors, cela me plait bien de le maintenir.Pour cette version 1.7, j’ai du résoudre pas mal de problèmes :
– Le premier : comment sélectionner les catégories avec des cases à cocher (checkbox) HTML5 ?
C’est un problème récurent pour les widgets WordPress. Comme les solutions trouvées sur le net raisonnent en terme de tableau (array) et sont trop compliquées à mon goût, j’en ai trouvé une autre que je partage ici : http://stackoverflow.com/questions/14870224/checkbox-array-in-wordpress-widget/D’ailleurs en cherchant sur le net une solution à ce problème, j’ai appris qu’il y avait de nouvelles fonctionnalités dans les formulaires HTML5. Je m’en suis servi pour faire un volet d’option (summary) qui se déroule et se replie sans avoir eu besoin de jQuery, ce qui évitera les problèmes de compatibilité jQuery.
Tous les objets de formulaire en HTML 5– Le deuxième : écrire une requête SQL qui permette de trouver les « id » des posts de catégories donnée sans utiliser WP_Query.
En effet, si WP_Query permet de travailler avec les catégories assez facilement, elle ne permet pas d’exclure les derniers posts publiés ce qui contraint de fait à écrire une requête adaptée au problème. Cette requête effectue une jointure de seulement 2 tables alors que celles de WordPress font la même chose avec une jointure de 3 ou 4 tables. Ainsi, une requête adaptée est ici plus performante que celle de l’API de WordPress. Je redoutais cette requête et finalement, elle est assez simple.L’inconvénient, c’est qu’il faudra peut-être l’adapter aux changements de structure de la base de données de WordPress.
Pour l’instant, elle fonctionne avec la nouvelle structure de la base de données de WP 4.4 qui ajoute la table de données wp_termmeta.
Finalement, je suis content d’avoir résolu tous ces problèmes, même si cela m’a pris pas mal de temps.
Les explications sont trop techniques pour moi (je ne code pas, je balbutie tout juste), mais cela intéressera peut-être les codeurs 🙂
Et en effet, l’important, c’est que cela vous intéresse aussi : quand on fait les choses avec plaisir, on les fait bien en général 😎
Oui, c’est vrai, les explications sont techniques et de fait ne peuvent vraiment intéresser que les personnes ayant suffisamment de technicité.
Je les ai données afin que les développeurs français confrontés aux même problèmes puissent trouver une solution expliquée en français (et aussi comme aide-mémoire personnel).
La grande majorité des explications techniques est écrite en anglais. Or, les problèmes sont toujours bien mieux pensés dans la langue maternelle.
Il est donc nécessaire de parler et de penser les problèmes informatiques en français. La langue française est une langue qui a porté la science pendant des siècles. Il n’y a aucune raison de vouloir penser mal en anglais quand l’on pense bien dans sa langue maternelle !
Oui, j’essaie de faire bien mais à chaque nouvelle version je m’aperçois que le code de la version précédente aurait pu être plus simple. ainsi, chaque nouvelle version tout à la fois simplifie le code de la version précédente et complexifie le code par l’ajout de nouvelles fonctionnalités.
J’aime le langage MySQL car c’est un langage qui lorsque l’on raisonne avec la théorie des ensembles permet de résoudre des problèmes complexes avec simplicité et élégance là où PHP présente des solutions lourdes et verbeuses.
Ce langage est trop souvent ignoré, alors que WordPress, c’est un logiciel qui gère une base de données ! Si les requêtes MySQL sont mal pensées, le site rame ! La première optimisation d’un site web, c’est celle de ses requêtes MySQL, et là WordPress, à mon goût n’est pas très performant.
Bonjour,
Je viens de publier la version 1.8 qui permet de choisir les post types et les custom post types à afficher.J’ai régardé comment j’avais fait cela dans la variante que j’avais déjà écrit il y a un an sans l’avoir publié sur le dépôt de WordPress et je me suis aperçu que je mémorisais les checkbox dans un tableau (array) php, ce que j’avais complètement oublié ! Or, c’est exactement ce que je n’avais pas réussi à faire dans la version 1.7 ! Comme quoi, si on ne programme pas tous les jours, on oublie les solutions que l’on avait pourtant trouvées aux mêmes problèmes.
Du coup, cette version 1.8 gère les catégories de façon bien plus simple. J’ai à nouveau donné ma solution (au moins en aide mémoire perso) sur stackoverflow ici Checkbox array in WordPress widget?
Il reste encore la limitation dans le temps comme le propose fge, je n’ai pas encore réfléchi à ce problème.
Super 👏
Je mets en œuvre le plugin sur un petit site familial privé … sur lequel je n’écris(publie) pas souvent, la possibilité de mettre une limite dans le temps serait pas mal.
Flobogo wrote:la possibilité de mettre une limite dans le temps serait pas mal.Bonjour,
Avec ls nouvelles possibilités des formulaires HTML5; les dates sont prises en charge sans jQuery, ce qui simplifie tout.En plaçant un champs date, les navigateurs placent un datepicker, un calendrier qui permet de choisir une date. Comme indiqué ici : Formulaires HTML5 : Champ de types date, time et datetime. Avec ce système je peux calculer la durée entre le moment où le widget est enregistré et celui de la date choisie avec le datepicker.
Cet intervalle de temps devenant ainsi la limite dans le temps.Sinon, il faut utiliser du jQuery pour choisir une durée, et là, cela complique tout car une durée peut se définir en secondes, minutes, heures, jours, semaines, mois, années, ce qui est compliqué à gérer.
Comment voyez-vous cela ? Qu’est-ce qui d’après vous serait le plus pratique pour un utilisateur lambda ?
En plaçant un champs date, les navigateurs placent un datepicker, un calendrier qui permet de choisir une date.
Clairement, le plus simple pour l’utilisateur lambda (moi, par exemple 😇 ), c’est de pouvoir choisir sur un calendrier la date à laquelle l’article ou page (ou autre CPT) ne sera plus affiché dans le widget.
Donc, cette solution-là me semble la bonne … et en plus, elle semble plus simple pour vous à mettre en œuvre 😎Bonsoir,
D’après ce que je comprends,
– vous préférez choisir une date limite future de limite dans le temps à partir de laquelle le widget ne s’affiche plus s’il n’a plus aucun article à afficher.
Par exemple, vous choisiriez le 1 janvier 2016, date à partir de laquelle le widget n’affiche plus rien ?!– Ou alors préfériez-vous choisir un intervalle de temps. le datepicker permettant de choisir une date, le widget calcule l’intervalle de temps entre les deux dates.
Par exemple, vous choisissez le 25 septembre 2015, ce qui définit un intervalle de 30 jours. Chaque jour, le widget s’actualise et n’affiche plus les articles écrit 30 jours auparavant.– autre idée ?
Le problème étant de savoir ce que l’on fait lorsqu’il n’y a plus aucun article à afficher :
– on place un texte choisi par l’usager indiquant qu’il n’y a pas d’article mis à jour,
– on n’affiche plus le widget,
– autreOn peut faire beaucoup de choses avec un datepicker, reste à savoir quoi !
En fait, je n’avais plus trop en tête le fonctionnement du widget.
Je viens de le mettre à jour sur mon site familial. La possibilité d’inclure/exclure des catégories est vraiment géniale, plus de risque de voir un article de test affiché (en principe, je les « dé-publie » après test, mais ça m’arrive d’oublier). Je crée aussi un « mini-article » par personne de la famille (pour un plugin d’arbre généalogique), cela me permettra de les exclure.
Bref, du coup, je me demande comment intégrer au mieux cette limite dans le temps.
il faudrait pouvoir dire au widget « je veux que les articles/pages/CPT soit affichés durant x jours ou x semaines ou x mois » (avec case à cocher : jour / semaines / mois)Ce qui revient au même que :
Luciole135 wrote:Chaque jour, le widget s’actualise et n’affiche plus les articles écrit 30 jours auparavant.A ce niveau-là, le date-picker n’est pas forcément adapté, puisqu’il ne s’agit pas de choisir une date de fin mais plus une durée.
Luciole135 wrote:Le problème étant de savoir ce que l’on fait lorsqu’il n’y a plus aucun article à afficher :
– on place un texte choisi par l’usager indiquant qu’il n’y a pas d’article mis à jour,
– on n’affiche plus le widget,
– autrePour moi, le choix serait : « on n’affiche plus le widget« , ça me semble le plus simple.
Mais dans certaines configurations de site, ou si la « hauteur » de sidebar a de l’importance, d’autres utilisateurs pourraient souhaiter mettre un texte à la place (même si à mon avis, c’est pas très « fun » d’écrire « nous n’avons aucun article récent à afficher« )
L’idéal serait donc d’avoir le choix : texte choisi par l’usager ou ne plus afficher le widget.En tous cas, ce widget est déjà génial dans sa forme actuelle 👏 👏 👏
J’ai mis mon commentaire (et 5 étoiles) sur le support/reviews du plugin … je pensais même l’avoir déjà fait !Flobogo wrote:Bref, du coup, je me demande comment intégrer au mieux cette limite dans le temps.
il faudrait pouvoir dire au widget « je veux que les articles/pages/CPT soit affichés durant x jours ou x semaines ou x mois » (avec case à cocher : jour / semaines / mois)C’est facile nativement à faire en HTML5 avec les champs « range » des formulaires comme montré ici : Formulaires HTML5 : Champ de type range Il suffit de mettre un range pour les jours, un autre pour les semaines, un autre pour les mois.
Je peux très bien aussi proposer les deux : le datepicker servant à la fois à définir une date limite ultérieure (la date est future) ainsi qu’un intervalle (si la date est dans le passé). Voire un datepicker et des ranges, tout est envisageable et sans problème technique majeur.
Flobogo wrote:Pour moi, le choix serait : « on n’affiche plus le widget« , ça me semble le plus simple.Oui, c’est le plus logique et ce qui semble évident, mais techniquement c’est le plus difficile à faire. Souvent en sciences, les évidences sont les choses les plus difficiles à réaliser ou à expliquer.
Plusieurs idées de réalisation techniques :
– agir sur la variable globale qui définit les widghets $wp_registered_widgets WordPress Widget System – How it Works. Le problème c’est qu’agir depuis le widget sur son propre affichage risque de créer une problème d’auto référence (ce que l’on appelle en informatique la récursivité).
En effet, en PHP quand une fonction lance une action, elle attend la fin de sa réalisation. Or, ici l’action déclenchée par le widget, c’est de ne plus afficher le widget lui-même. le widget peut-il agir avec WordPress sur la variable globale qui le définit ?
Peut-être avec l’instruction php break ?– agir sur l’affichage du widget avec le CSS, du genre, au bout de x temps, masquer le widget.
– ou alors, introduire un test conditionnel dans la sidebar elle-même, ce que je ne sais pas encore faire non plus.
– autre idée technique bienvenue…
– :search:Techniquement, si quelqu’un a une idée de ce qui est faisable, je suis preneur, car cette idée simple et logique est techniquement complexe (du moins avec mes connaissances actuelles). Je vais continuer de réfléchir, consulter les forums anglais en espérant qu’un lecteur français aura une idée ici même ! 😇
Flobogo wrote:Mais dans certaines configurations de site, ou si la « hauteur » de sidebar a de l’importance, d’autres utilisateurs pourraient souhaiter mettre un texte à la place (même si à mon avis, c’est pas très « fun » d’écrire « nous n’avons aucun article récent à afficher« )
L’idéal serait donc d’avoir le choix : texte choisi par l’usager ou ne plus afficher le widget.Mettre un texte est simple à faire techniquement parlant. certes, pas forcément joli, mais facile à faire techniquement.
Flobogo wrote:En tous cas, ce widget est déjà génial dans sa forme actuelle 👏 👏 👏
J’ai mis mon commentaire (et 5 étoiles) sur le support/reviews du plugin … je pensais même l’avoir déjà fait !merci des compliments et du review.
Je vous laisse le soin de la réalisation technique, mais l’idée, c’est ça :
– agir sur l’affichage du widget avec le CSS, du genre, au bout de x temps, masquer le widget.
Donc, pourquoi pas en CSS si c’est possible techniquement.
Par contre, côté « utilisateur lambda », ce « x temps » doit pouvoir être exprimé soit en jours, soit en semaines, soit en mois.
Exemples : pour mon site familial, je pourrais choisir « 3 mois », tandis que sur le site bourguignon, je pourrais choisir « 6 semaines »
Quelqu’un qui met fréquemment le site ou les articles à jour pourrait choisir « 15 jours » …
Quitte à ce que « derrière » (techniquement) chacune de ces durées soient converties en heures/minutes/secondes si il le faut.J’espère que vous trouverez l’aide technique nécessaire.
Mais le plugin est déjà très bien 🙂Flobogo wrote:Je vous laisse le soin de la réalisation technique, mais l’idée, c’est ça :– agir sur l’affichage du widget avec le CSS, du genre, au bout de x temps, masquer le widget.
Donc, pourquoi pas en CSS si c’est possible techniquement.
Je pense que c’est faisable, mais le CSS est le langage que je maîtrise le moins bien. Je ne sais pas vraiment ce qui se passe à l’affichage de la page lorsque l’on masque. Il me semble que les informations sont présentes mais non visibles.
Cela semble faisable, reste à apprendre le CSS nécessaire pour ce faire ! :fouet:Flobogo wrote:Par contre, côté « utilisateur lambda », ce « x temps » doit pouvoir être exprimé soit en jours, soit en semaines, soit en mois.
Exemples : pour mon site familial, je pourrais choisir « 3 mois », tandis que sur le site bourguignon, je pourrais choisir « 6 semaines »
Quelqu’un qui met fréquemment le site ou les articles à jour pourrait choisir « 15 jours » …
Quitte à ce que « derrière » (techniquement) chacune de ces durées soient converties en heures/minutes/secondes si il le faut.J’ai appris le calcul des durées en PHP lorsque j’ai maintenu un plugin de statistiques. Il y a plein de calculs de date et de durée dans ce genre de plugin. Ce n’est plus un problème technique pour moi. le problème est juste un problème d’interface utilisateur : comment présenter le plus simplement possible les choix à faire.
Ainsi côté utilisateur :
Choix d’une date butoir d’affichage du widget :
– est-il utile de proposer le choix d’une date butoir (avec datepicker) à partir de laquelle le widget ne s’affiche plus du tout si entre-temps les articles sont mis à jour ?Choix de l’âge maximum des mises à jour :
– faut-il choisir un intervalle de temps avec un autre datepicker, la différence entre la date choisie et celle du jour d’enregistrement du widget définissant de fait cet intervalle.
– faut-il choisir un intervalle de temps avec des curseurs (jours, semaines, mois)
Qu’est-ce qui sera le plus pratique ?Flobogo wrote:J’espère que vous trouverez l’aide technique nécessaire.Cela permettrait une réalisation plus rapide, avec moins de recherches.
Flobogo wrote:Mais le plugin est déjà très bien 🙂Merci.
A défaut de l’aide technique, je peux donner mon avis côté utilisateur 😉
Donc :Luciole135 wrote:Choix d’une date butoir d’affichage du widget :
– est-il utile de proposer le choix d’une date butoir (avec datepicker) à partir de laquelle le widget ne s’affiche plus du tout si entre-temps les articles sont mis à jour ?Ça ne me paraît pas très pertinent :
– soit la personne met souvent le site à jour, et n’en a pas besoin du tout
– soit la personne ne met pas souvent à jour (comme moi), mais ne sait pas précisément quand elle mettre à jour …Sur mon site familial, j’ai réglé le widget pour afficher les 3 derniers articles/pages créés ou mis à jour –> aujourd’hui 25 octobre, il affiche :
– une page créée hier 24 septembre,
– une page créée au tout début du site (c’est l’accueil après login), mais mise à jour hier
– une page avec les anniversaires, créée il y a plus d’un an, mais mise à jour début octobreMais je ne sais pas quand je reviendrai faire des modif sur le site : ça peut être en fonction d’un évènement familial (naissance/décès), comme il peut aussi ne rien se passer pendant quelques mois.
Seule ma page « anniversaires » est mise à jour à peu près tous les mois ou tous les 2 mois.Le principe du widget, c’est d’attirer le visiteur vers les nouveautés ou les mises à jour. Mais à la date d’aujourd’hui, je suis incapable de dire si d’autres pages ou articles seront créés/mis à jour d’ici 1 mois ou 3 mois … Donc, comment mettre une date butoir … qu’il faudrait éventuellement modifier par la suite.
Par contre, j’estime pour ce site, qu’une page/article non mis à jour dans un délai de 3 mois n’est plus une nouveauté.
Donc, c’est bien un délai qu’il faut fixer, que vous appelez « l’âge maximum des mises à jour«
Et pour moi, il me semble que le plus pratique serait ça :Luciole135 wrote:– un intervalle de temps avec des curseurs (jours, semaines, mois)Mais on ne doit utiliser qu’un seul curseur à la fois, genre :
choisir :
– entre 1 et 365 jours
ou
– entre 1 et 52 semaines
ou
– entre 1 et 12 moisOu alors, je verrais plutôt des boutons radios, genre :
« je choisis la durée d’affichage en :
. jours
. semaines
. mois »et à côté (ou en-dessous) on définirait alors le nombre.
Mais bon, forcément, l’utilisateur ne doit pas pouvoir indiquer « 15 jours « et « 3 mois », ce qui est contradictoire.
Je ne sais pas si je suis claire …En tous cas, l’idée du « datepicker » était séduisante pour sa simplicité d’utilisation, mais en fait, je ne vois pas comment l’interpréter aisément, car ici, un délai ne s’exprime pas sur le calendrier par une date butoir, mais en durée d’affichage
Flobogo wrote:A défaut de l’aide technique, je peux donner mon avis côté utilisateur 😉Oui, l’utilisateur se moque en général de ce qui est derrière les fonctionnalités. Il faut quelque chose de simple et d’intuitif qui se comprend facilement sans avoir besoin de lire une documentation technique. Comme on dit, il faut quelque chose de « user friendly »
Flobogo wrote:Le principe du widget, c’est d’attirer le visiteur vers les nouveautés ou les mises à jour. Mais à la date d’aujourd’hui, je suis incapable de dire si d’autres pages ou articles seront créés/mis à jour d’ici 1 mois ou 3 mois … Donc, comment mettre une date butoir … qu’il faudrait éventuellement modifier par la suite.Je suis d’accord, une date butoir est inutile.
Flobogo wrote:Par contre, j’estime pour ce site, qu’une page/article non mis à jour dans un délai de 3 mois n’est plus une nouveauté.Donc, c’est bien un délai qu’il faut fixer, que vous appelez « l’âge maximum des mises à jour«
Je cherche un vocable qui parle au plus grand nombre. Je ne suis pas certain que l’utilisateur lambda comprenne immédiatement « âge maximum des mises à jour » ni « délai de mise à jour ».
Comment le dire de la façon la plus intelligible qui soit ?Flobogo wrote:Et pour moi, il me semble que le plus pratique serait un intervalle de temps avec des curseurs (jours, semaines, mois)
Mais on ne doit utiliser qu’un seul curseur à la fois, genre :
choisir :
– entre 1 et 365 jours
ou
– entre 1 et 52 semaines
ou
– entre 1 et 12 mois
Ou alors, je verrais plutôt des boutons radios, genre :
« je choisis la durée d’affichage en :
. jours
. semaines
. mois »
et à côté (ou en-dessous) on définirait alors le nombre.Mais bon, forcément, l’utilisateur ne doit pas pouvoir indiquer « 15 jours « et « 3 mois », ce qui est contradictoire.
Je ne sais pas si je suis claire …Il suffit de proposer les intervalles :
– entre 0 et 365 jours
ou
– entre 0 et 52 semaines
ou
– entre 0 et 12 moisEt de fait, les trois curseurs peuvent s’additionner, ce qui est le plus pratique tant pour la programmation que pour l’utilisateur lambda.
Lorsque 0 est sélectionné partout (par défaut), aucune date n’est exclue, tout simplement.Flobogo wrote:En tous cas, l’idée du « datepicker » était séduisante pour sa simplicité d’utilisation, mais en fait, je ne vois pas comment l’interpréter aisément, car ici, un délai ne s’exprime pas sur le calendrier par une date butoir, mais en durée d’affichageEn effet, elle nécessite une explication de texte et de fait n’est pas « user friendly ». Ce n’est donc pas une bonne solution.
- Le forum ‘Dépôts pour les extensions, trucs, astuces’ est fermé à de nouveaux sujets et réponses.