- Statut : non résolu
- Ce sujet contient 42 réponses, 5 participants et a été mis à jour pour la dernière fois par
, le il y a 8 années et 6 mois.
-
Messages
-
Ok, merci.
Si je suis pas trés chaud pour le eval, par contre je pense que je vais utiliser wp_parse_args pour l’appliquer aux valeurs des parametres que ma methode récupère.
Reste à élucider un truc…
Dans WP 3.3 toutes les vieilles fonctions qui prenaient les args comme un string accepte de l’avoir comme un array. Mais j’ai pas trouvé à partir de quelle version ils les ont corrigées. Et je voudrais bien rester compatible avec WP 2.5/2.8 qui reste répandu (moins exigeant pour PHP et MySQL).
l’eval est une facilité qui permet de passer des array d’array et récuperer des arguments identiques à ceux définis dans le codex, ce qui est impossible avec wp_parse_args à moins de la redéfinir et d’adopter des conventions particulières pour cela.
Sinon, il doit être possible de faire un analyseur syntaxique pour les arguments passés, la grammaire n’est pas compliquée.
Mise à jour pour supporter wp_get_recent_posts() avec un rendu comme une liste.
Et pour faire suite à la discussion avec Guy, le plugin ne peut pas utiliser eval() qui serait une faille entre les blogs sous WordPress MU et très risqué si une faille de WP permet d’injecter du contenu dans une page, ni utiliser wp_parse_args() qui produit plein de problème si on donne les paramètres à la old-school comme « param=value¶m=value » qui a une meilleure lisibilité que une pure syntaxe PHP.
Toutefois, j’ai amélioré pour que la valeur puisse être un array() avec cette syntaxe à la PHP contenant des éléments comme une chaine, un entier, ou booléen.
Quelques exemples de syntaxes reconnues:
http://wordpress.org/extend/plugins/functionscapacitor/other_notes/Nb: les array() associatifs sont pas reconnus, mais j’y pense pour plus tard.
Dans l’immédiat, la suite sera d’intégrer un système de widget, ce qui achèverait de pouvoir se débarrasser d’un grand nombre de plugins…
Il est évident qu’eval est une faille de sécurité, mais comme je te l’avais dit, ce n’était pas ma préoccupation première pour le développement qui avait été effectué dans un cadre spécifique, et qui de plus à l’origine ne devait pas concerner des fonctions de WP.
J’attirais ton attention sur les fonctions qui prennent en argument des array dans un array non pris en compte par la forme avec &.Je t’en remercie Guy, la méthode avec & qui supporte les array() non-associatifs te semble correcte ?
L’autre souci, concerne les variables PHP utilisées comme valeurs. Elles sont par sécurité non-reconnues, d’où l’astuce des magics-keywords comme %postID% pour remplacer $post->ID. Mais faudrait me suggérer ceux qui faudrait ajouter…
Grosse mise à jour pour proposer de faire des widgets avec les fonctions de l’API WordPress. Et un logo pour le plugin ^^
http://wordpress.org/extend/plugins/functionscapacitor/La dernière mise à jour corrige un gros problème avec wp_get_recent_posts(). Cette fonction de l’API WordPress sélectionne par défaut les articles avec les status ‘draft, publish, future, pending, private’, et elle donne toutes les infos sans tenir compte des droits de lecture de l’internaute… 😉 (normal ou bug ?)
Dans l’urgence, j’ai figé l’option des status à publish et private. Mon option fct:perm=readable (activée par défaut) cachera les posts privés si l’internaute n’a pas la permission de lecture ‘read_private_posts’.
Pour les posts protégés avec un password, le titre, la miniature, et l’extrait seront affichés, mais le plugin ne créera pas un résumé avec le contenu si il n’y a pas d’extrait.
Un truc étrange : un post privé avec une date dans le futur est affiché si on est loggé avec un profil qui a ‘read_private_posts’… Encore un bug ? (du coup je vais mettre l’option status à publish par défaut)
Dans un prochain update, on pourra choisir les status ‘draft, future, pending’ et les afficher avec comportement similaire aux posts protégés sauf que le titre ne sera pas cliquable (car l’internaute aurait une erreur 404).
oliezekat wrote:La dernière mise à jour corrige un gros problème avec wp_get_recent_posts(). Cette fonction de l’API WordPress sélectionne par défaut les articles avec les status ‘draft, publish, future, pending, private’, et elle donne toutes les infos sans tenir compte des droits de lecture de l’internaute… 😉 (normal ou bug ?)Normal, c’est marqué dans le codex.
Je rappelle que dans le codex, les arguments donnés sont ceux par défaut, si d’autres valeurs sont possibles, elles sont ensuite listées dans les explications de la fonction.Donc la fonction appelle bien par défaut une liste de tous les posts, quel que soit leur statut.
oliezekat wrote:Un truc étrange : un post privé avec une date dans le futur est affiché si on est loggé avec un profil qui a ‘read_private_posts’… Encore un bug ? (du coup je vais mettre l’option status à publish par défaut)Non ce n’est pas un bug, c’est logique. Puisque l’array des posts est constituée…
Ce qu’il faut comprendre, c’est que cette fonction n’est PAS l’équivalent de query_posts, qui donne aussi par défaut les posts « récents », mais « publiés », par ordre décroissant, etc… Par ailleurs elle supprime tous les filtres. C’est donc une option, qui, a mon humble avis, n’a rien à faire dans un front end (donc dans ce que tu proposes), mais qui est à utiliser dans la programmation, en retraitant ensuite les résultats.
oliezekat wrote:Dans un prochain update, on pourra choisir les status ‘draft, future, pending’ et les afficher avec comportement similaire aux posts protégés sauf que le titre ne sera pas cliquable (car l’internaute aurait une erreur 404).Il me semble indispensable que le shortcode permette de reprendre l’ensemble des options d’une fonction, non ?
J’ai mis à jour le plugin pour boucler les soucis d’affichage avec wp_get_recent_posts. Fin du mode *Panic* ✅
Lumière de Lune wrote:oliezekat wrote:Dans un prochain update, on pourra choisir les status ‘draft, future, pending’ et les afficher avec comportement similaire aux posts protégés sauf que le titre ne sera pas cliquable (car l’internaute aurait une erreur 404).Il me semble indispensable que le shortcode permette de reprendre l’ensemble des options d’une fonction, non ?
C’est l’ideal, hormis les valeurs par défaut qui sont modifiée mais que l’on peut rétablir, il y a des options que je suis obligé de figer, notamment les echo. Tout est indiqué dans les Notes du plugin :
http://wordpress.org/extend/plugins/functionscapacitor/other_notes/#Supported-functionsNouvelle version 0.9.3 dans laquelle j’ai commencé à implémenter les fonctions conditionnelles de WordPress pour décider sur quelles pages le widget doit s’afficher :
http://wordpress.org/extend/plugins/functionscapacitor/
Pour l’heure, j’ai commencé avec is_home() et is_front_page() le temps de débusquer d’éventuels bugs, mais à terme avec toutes les fonctions conditionnelles que propose WordPress il y aura de quoi donner des orgasmes aux widgetophiles 😋
Oyé, la version 0.9.4 publiée le mois dernier ajoute l’option fct:container_id qui permet de choisir l’ID du conteneur HTML, et l’option fct:show_date pour la fonction wp_get_recent_posts().
http://wordpress.org/extend/plugins/functionscapacitor/
Ce plugin est trés utilisé dans le nouveau site parlementaire de Alain Bocquet
http://www.alainbocquet.fr/
Pour simuler une catégorie sur une page statique comme l’Accueil et les Actions parlementaires tout en réduisant le nombre de post ou en complétant pour afficher une liste de sous-catégories.
Le plugin sert aussi pour faire une liste des archives, ou comme widget pour les citations en bas de page (où l’option de l’ID du conteneur HTML permet d’associer du CSS et Javascript).Dés que j’aurais le temps, j’ajouterais les fonctions conditionnelles is_page(), is_single(), et is_category() pour le widget. Ce qui ouvrira la possibilité de personnaliser les sidebars selon la page ou type de page affiché.
Ex: afficher les sous-catégories via un widget uniquement si la page d’une catégorie est affichée.Aucun bug signalé ou constaté, des exemples et remarques d’utilisation du plugin seront appréciés 😉
Oyé, une nouvelle version est en préparation (je la teste sur un projet avant de la publier), et l’essentiel de l’effort a été sur l’ajout de fonctions conditionnelles pour le widget.
En prévision pour la version 0.9.5 :
* support is_category() conditional function.
* support cat_is_ancestor_of() conditional function.
* support is_single() conditional function.
* support in_category() conditional function.
* add is_category_in_tree_of() conditional function (not canonical).
* add is_single_in_tree_of() conditional function (not canonical).
* add in_tree_of() conditional function (not canonical).
* support get_the_post_thumbnail() function.Comme vous pouvez le voir, je me suis permis d’implémenter des fonctions conditionnelles « non canoniques » (càd ne provenant pas de l’API et Codex de WordPress) qui répondent néanmoins à des situations souvent souhaitées.
Exemple, la fonction in_tree_of() permettra de choisir que le widget sera visible seulement si la page est une catégorie ou un article appartenant à l’arbre d’une catégorie (càd ses sous-catégories).
Les fonctions « non canoniques » sont programmées en utilisant uniquement les API, ce qui réduit les risques d’incompatibilité avec les prochaines versions de WordPress.
Les suggestions sont la bienvenue, ainsi que le retour d’expérience des utilisateurs actuels du plugin.
Je développe en ce moment avec WordPress 3.7.1, merci de témoigner sur la page officielle du plugin si ça marche bien ou pas avec WP 3.8
http://wordpress.org/plugins/functionscapacitor/J’ai découvert il y a peu de temps le plugin Widget Visibility (issue de la fonction éponyme du Jetpack). Bien que ses fonctions conditionnelles soient un peu décevantes, la méthode et l’interface permettant de combiner plusieurs conditions mériteraient soit d’être implémentés dans functionsCapacitor, ou inversement créer une copie améliorée de Widget Visibility et retirer le système des conditions de functionsCapacitor… Votre avis ?
Widget logic est très bien puisque tu saisid le contenu du if, que ce soit une fonction codex ou une fonction « maison »
Widget logic exécute le contenu de la condition comme étant du PHP. Hormis que ça requiert de connaitre le langage, c’est une potentielle faille de sécurité…
Ce qui me plait dans Widget Visibility, c’est l’interface ; elle est simple à utiliser et permet de combiner plusieurs conditions.
J’ai découvert un bug cet après-midi avec un vieux WP 3.0.1 car il manque l’API esc_textarea() qui est devenu disponible à partir de WP 3.1.0
Symptôme: la gestion des widgets ne marche plus, on ne voit pas les sidebars disponibles.Dés que j’ai le temps je publie une update qui répare ce bug et WP 3.0.1 deviendra la version minimale requise. Cette prochaine update (en production chez un client depuis 3 mois) inclut des critères conditionnels de visibilité très évolués pour les widgets (notamment cibler une catégorie et ses sous-catégories).
- Le sujet ‘[plugin] functionsCapacitor : hackez le Codex dans vos pages /posts !’ est fermé à de nouvelles réponses.