- Statut : non résolu
- Ce sujet contient 42 réponses, 5 participants et a été mis à jour pour la dernière fois par
Lumiere de Lune, le il y a 8 années et 6 mois.
-
AuteurMessages
-
18 juin 2014 à 19 h 04 min #819843
Parce que tu laisses tes clients rester en 3.0.1 ? 😉
19 juin 2014 à 12 h 30 min #819844Ce point a rien à voir avec l’objet du topic. [à ma connaissance, la 3.0.1 a une seule faille vraiment grave si on utilise les Rôles, et facile à corriger]
20 juin 2014 à 16 h 45 min #819845La nouvelle version 0.9.5 a été publiée. Le plugin redevient compatible avec WP 3.0.1 mais comme j’ai pas eu l’occasion de tester au delà de WP 3.7.1 n’hésitez à me signaler si il vous semble opérationnel (ou non) avec des versions très récentes de WordPress.
Changelog:
* fix issue while esc_textarea() API is missing.
* 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.La grosse nouveauté c’est les conditions non-canoniques (non issues de l’API WordPress) qui permettent d’enrichir considérable les possibilités du widget.
Nb: les conditions non-canoniques sont programmées en utilisant les API
Leur utilisation est expliquée dans le ReadMe ou à la fin des « Others Notes » de la page de functionsCapacitor.Exemple: la condition in_tree_of() permet de choisir que le widget soit 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).
La catégorie Catalogue de ce site est une bonne démonstration ; 2 widgets affichent la liste des sous-catégories « Types de produits » et « Domaines d’utilisation » quand la condition in_tree_of() détecte que la page en cours (article ou catégorie) appartient au catalogue.Je pense que je vais plancher sur le même système mais appliqué aux pages statiques ce qui répondrait à mes propres besoins et aussi à la demande ci-dessous faite sur le forum du plugin par Marc Besson :
En français, je m’expliquerai sans doute mieux : en gros il me faut un widget « dynamique », qui affiche les pages enfants de la page dans laquelle je me trouve.
Exemple : si j’ai une page « Page 1 » avec des pages enfants « Page 1.1 » et « Page 1.2 », je voudrais que sur ces 3 pages (Page 1, Page 1.1 et Page 1.2) apparaisse un widget qui liste les pages 1.1 et 1.2.
Et de même pour les pages 2, 2.1 et 2.2, etc…25 juin 2014 à 17 h 00 min #819846Oyé, functionsCapacitor marche très bien avec WordPress 3.9.1
Anecdote: j’ai cru un court moment qu’il y avait bug jusqu’à ce que je me rappelle que le plugin règle par défaut l’API wp_get_recent_posts() avec le paramètre exclude=%postID% et donc ignore l’article en cours (ou le 1er article de la catégorie en cours). On peut court-circuiter ce réglage en ajoutant exclude= » dans la requête du widget.
30 septembre 2014 à 17 h 09 min #819847Passage furtif pour dire que je modifie cette semaine le plugin pour implémenter la fonction conditionnelle is_page() et créer des conditions du même style que mes _in_tree_of() précédents avec les catégories ou posts.
En gros, on pourra faire widget qui affiche une branche de l’arborescence des pages seulement quand une des pages est affichée.
Nb: ça correspond à un besoin concret pour un client, j’pourrais tester à fond 🙂
6 octobre 2014 à 13 h 43 min #819848Teasing de la future version 0.9.6 :
* support is_page() conditional function.
* add is_page_in_tree_of() conditional function (not canonical).
* in_tree_of() support page ID as argument.
* add is_page_descendant_of() conditional function (not canonical).A la différence de is_page_in_tree_of() la condition is_page_descendant_of() ne sera pas appliquée quand on est sur la page racine de l’arborescence.
On peut ainsi faire un widget qui affiche une branche de l’arborescence uniquement quand on navigue dans la branche. Souvent le parent racine contient déjà dans son contenu la liste des principaux enfants, d’où l’intérêt que le widget soit caché.
Comme les menus déroulants sont peu commodes en tactile, le plugin facilite la mise en place de menus alternatifs.29 octobre 2014 à 17 h 02 min #819849La version 0.9.6 a été publiée :
* support de la condition is_page()
* ajout de la condition is_page_in_tree_of()
* la condition in_tree_of() accepte un page ID comme argument.
* ajout de la condition is_page_descendant_of()
* testé avec WordPress 4.0J’attendais d’avoir l’occasion de la tester avec plusieurs versions anciennes de WordPress ainsi que la version 4.0
Le plugin a été amélioré dans le cadre de la refonte du thème du site du restaurant La Grignotière à la sauce « responsive design ». Le widget du plugin aide à produire les alternatives de navigation pour les mobiles.
26 janvier 2015 à 16 h 09 min #819850J’étudie l’implémentation de l’API wp_redirect()
http://codex.wordpress.org/Function_Reference/wp_redirectL’idée serait de pouvoir détourner la vocation de certains plugins. Par exemple si vous aimez un plugin de diaporama photo utilisant des articles mais que vous voudriez qu’il dirige vers des catégories, un appel à wp_redirect() sur ces pages donnerait l’effet escompté.
Ca pourrait aussi servir quand on a fait une nouvelle version de son site sur un autre domaine (avec ou sans la stratégie de permalien) pour activer des redirections au cas-par-cas. L’appel de wp_redirect() dans un widget combiné à une fonction conditionnelle le permettrait.
Problème annexe: voir si FunctionsCapacitor marche bien sur le template de page d’une pièce-jointe ou média.
Merci de faire part de vos avis et expériences dans ce domaine.
27 janvier 2015 à 17 h 42 min #819851Je dois renoncer à implémenter wp_redirect() car la redirection doit être envoyée avant d’envoyer du contenu au navigateur. Il faudrait profondément changer et complexifier le plugin pour le permettre…
24 avril 2015 à 0 h 26 min #819852Petit passage furtif pour signaler que le plugin n’est pas concerné par la faille XSS si vous en faites un usage classique, les données que WordPress relaye aux widgets et shortcode étant sécurisés. De plus le plugin n’utilise pas les deux API incriminées.
https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.htmlNéanmoins, si vous avez bricolé des scripts qui utilisent des méthodes du plugin, il vous incombe de neutraliser les arguments fournis surtout si ils proviennent de l’URL ou d’un formulaire. Précaution à prendre pour tout bricolage avec un plugin ou l’API.
20 mai 2015 à 15 h 33 min #819853Ce topic va être définitivement fermé.
Le site wordpress.org sera la seule page officielle du plugin :
https://wordpress.org/plugins/functionscapacitor/N’hésitez pas à vous exprimer en français dans le forum de support de wordpress.org :
https://wordpress.org/support/plugin/functionscapacitorVous pouvez aussi me joindre par mail à oliezekat@yahoo.fr
20 mai 2015 à 15 h 38 min #819854Hors sujet: normalement, il est interdit de s’exprimer autrement qu’en anglais sur wp.org. Pour que le maximum de monde puisse suivre les conversations.
20 mai 2015 à 16 h 28 min #819855Comme il n’y a que moi qui suis intervenue sur ce sujet depuis avril 2012, je crois qu’il n’y a pas grand risque…
-
AuteurMessages
- Le sujet ‘[plugin] functionsCapacitor : hackez le Codex dans vos pages /posts !’ est fermé à de nouvelles réponses.