J'ai publié un rapport de bug à ce sujet il y a quelques mois ( sur WordPress trac (Widget Instance Form Update Bug) ) et j'ai pensé que j'essaierais d'écrire à ce sujet ici aussi. Peut-être que quelqu'un a une meilleure solution à ce problème que moi.
Fondamentalement, le problème est que si vous déposez un widget dans une barre latérale, le formulaire de widget n'est pas mis à jour jusqu'à ce que vous appuyiez manuellement sur Enregistrer (ou recharger la page).
Cela rend inutilisable tout le code de la form()
fonction qui s'appuie sur l'ID d'instance du widget pour faire quelque chose (jusqu'à ce que vous appuyiez sur le bouton Enregistrer). Toutes les choses comme les requêtes ajax, les choses jQuery comme les sélecteurs de couleurs et ainsi de suite ne fonctionneront pas immédiatement, car à partir de cette fonction, il semblerait que l'instance de widget n'a pas encore été initialisée.
Une mauvaise solution serait de déclencher automatiquement le bouton d'enregistrement en utilisant quelque chose comme livequery :
$("#widgets-right .needfix").livequery(function(){
var widget = $(this).closest('div.widget');
wpWidgets.save(widget, 0, 1, 0);
return false;
});
et ajoutez la .needfix
classe form()
si l'instance de widget ne semble pas initialisée:
<div <?php if(!is_numeric($this->number)): ?>class="needfix"<?php endif; ?>
...
</div>
Un inconvénient de cette solution est que si vous avez enregistré de nombreux widgets, le navigateur consommera beaucoup de CPU, car Livequery vérifie les changements DOM chaque seconde (même si je n'ai pas spécifiquement testé cela, c'est juste mon hypothèse :)
Des suggestions pour une meilleure façon de corriger le bogue?
la source
Réponses:
Je me suis récemment battu avec une situation similaire. Ajax dans les widgets n'est pas une blague! Besoin d'écrire du code assez fou pour que les choses fonctionnent entre les instances. Je ne connais pas la requête en direct, mais si vous dites qu'elle vérifie le DOM à chaque seconde, je pourrais avoir une solution moins intense pour vous:
Vous pouvez transmettre à cette fonction un sélecteur ou un objet jQuery et elle renverra l'ID d'instance de l'instance actuelle. Je ne pouvais pas trouver d'autre moyen de contourner ce problème. Heureux d'entendre que je ne suis pas le seul :)
la source
Je n'aime pas répondre à ma propre question, mais je pense que c'est la meilleure solution jusqu'à présent:
Cela déclenchera la requête ajax de sauvegarde de widget, juste après la fin d'une requête de sauvegarde de widget (s'il n'y a pas eu de réponse avec le formulaire html).
Il doit être ajouté dans la
jQuery(document).ready()
fonction.Maintenant, si vous souhaitez rattacher facilement vos fonctions javascript aux nouveaux éléments DOM ajoutés par la fonction de formulaire widget, il suffit de les lier à l'événement "saved_widget":
la source
Ran dans récemment et il semble que dans l'interface traditionnelle "widgets.php" toute initialisation javascript devrait être exécutée directement pour les widgets existants (ceux de la
#widgets-right
div), et indirectement via l'widget-added
événement pour les widgets nouvellement ajoutés; alors que dans l'interface de personnalisation "custom.php", tous les widgets - existants et nouveaux - sont envoyés à l'widget-added
événement et peuvent donc simplement être initialisés à cet endroit. Sur la base de cela, voici une extension de laWP_Widget
classe qui facilite l'ajout de l'initialisation javascript au formulaire d'un widget en remplaçant une fonctionform_javascript_init()
:Un exemple de widget de test utilisant ceci:
la source
Je pense qu'il existe quelque chose dans Wordpress 3.9 qui pourrait vous aider. C'est le rappel mis à jour du widget . Utilisez-le comme ceci (coffeescript):
la source