web-dev-qa-db-fra.com

Manipulation de post méta dans le personnaliseur

Je travaille sur un plug-in pour les champs personnalisés de l'administrateur et j'essaie de créer autant d'emplacements que possible pour les champs. Jusqu'à présent, je le fais avec succès pour plusieurs de ces endroits:

  1. Types de poste
  2. Taxonomies
  3. Commentaires
  4. Utilisateurs
  5. Options (pages)
  6. Widgets
  7. Articles de menu
  8. Les pièces jointes
  9. Shortcodes
  10. Le personnalisateur (en quelque sorte)

Naturellement, pour chacun de mes emplacements, j'essaie d'utiliser l'API WordPress appropriée: * _post_meta, * _term_meta, etc., et tout fonctionne assez bien.

Pour les emplacements, associés à un élément ayant une URL (principalement les 4 premiers, même si les pièces jointes ont également des URL), j'ai des formulaires frontaux, qui permettraient aux utilisateurs de modifier l'élément actuel et d'enregistrer ses champs personnalisés. Je le fais via une seule balise function/template, qui ne nécessite aucun argument - tous les groupes de champs associés à l'élément sont automatiquement affichés.

Le dernier élément que je souhaite avoir, avant de considérer mon concept (preuve de succès) comme réussi, est la prise en charge du personnaliseur. L'utilisation de l'API par défaut me permet de travailler avec des options/mods de thème assez facilement et je suis arrivé à un point où l'emplacement de "personnalisation" est assez fonctionnel. Le seul inconvénient de mon implémentation semble être que je présente le groupe entier avec des champs en tant que contrôle unique. Cela me permet d’avoir des onglets, une logique conditionnelle et une validation appropriée (qui dépend de la logique conditionnelle). Néanmoins, j'utilise différents paramètres (comme dans WP_Customize_Setting), donc postMessage et tout le reste fonctionnent correctement sans avoir à pirater autre chose.

Ce que je souhaite cependant, c’est de permettre aux mêmes emplacements, qui ont des URL et peuvent avoir des formulaires frontaux, de s’ajouter facilement au personnaliseur. Un développeur peut créer un méta-groupe de messages, qui apparaîtra comme une boîte aux lettres normale sur l'écran d'édition. Mon objectif est de lui permettre d'appeler quelque chose comme -> show_in_customizer () afin de permettre à ce groupe d'y être utilisé également.

Je sais que de nombreuses personnes déconseillent de modifier les publications dans le personnaliseur et je suis d'accord avec elles à plusieurs reprises. Cependant, s'il existe un paramètre de disposition par publication, des options de couleur ou même quelque chose d'aussi simple que l'image sélectionnée, j'aimerais que cette porte reste ouverte.

Pour aller droit au but, cela semble être une tâche difficile, car elle nécessite au moins les éléments suivants:

  1. Déterminer si la section responsable doit être affichée dans le personnaliseur. C'est assez facile grâce à la propriété "active_callback" des sections.
  2. Introduire des données dans le personnaliseur: celui-ci est légèrement délicat. Même si vous cliquez sur le bouton "Personnaliser" lors de la prévisualisation d'une page, le personnalisateur est chargé à partir du contexte de l'administrateur et je n'ai pas d'accès direct à la chose affichée. Ce que je fais est de rassembler toutes les données dont j'ai besoin dans le pied de page et de les envoyer au personnalisateur via parent.someFunction lors du chargement de la page. Ce n’est pas idéal, mais fonctionne assez bien. Je ne récupère/envoie aucune valeur plus d’une fois, donc je suis heureux. Dans un monde parfait, cette fonctionnalité, associée au active_callback, permettrait aux utilisateurs de modifier une page, de cliquer sur un lien vers une autre page et de modifier immédiatement la page nouvellement chargée. Cependant, lorsque cela est fait, la nouvelle page ne reçoit ni paramètres de requête, ni en-têtes. Elle agit donc plutôt si elle ne figurait pas dans le personnalisateur, ce qui ne fonctionne donc pas pour moi.
  3. Écrasement du résultat de get_*_meta avec les valeurs du personnalisateur lors d'une requête normale (non postMessage). Cette partie est très simple.
  4. Sauvegarde des données: Voici où ma mise en œuvre échoue :(

Lorsque le bouton "Enregistrer et publier" est cliqué, le personnalisateur effectue une demande wp_ajax. La demande inclut toujours le JSON customized normal, en tant qu'actualisation lorsqu'une valeur est modifiée, mais étant donné que le script utilise admin-ajax, je ne peux pas savoir ce qui est réellement enregistré.

La seule idée que j'ai à présent est de remplacer la fonction JavaScript wp.customize.previewer.query par quelque chose qui se trouve dans les lignes de:

var query = wp.customize.previewer.query;
wp.customize.previewer.query = function( options ) {
    args = query.call( wp.customize.previewer, options );
    args.my_plugin_name_current_object = 'post_10';
    return args;
}

Cependant, à ce stade, je dois faire très attention lorsque j'ajoute le paramètre et, globalement, la mise en œuvre commence à devenir trop sale.

Enfin, ma question: Quelqu'un at-il réussi à obtenir une fonctionnalité similaire dans le personnaliseur? Pourriez-vous me conseiller sur une approche appropriée pour finir cette chose?

Jusqu'à présent, je n'ai pas essayé de développer quoi que ce soit sur mesure pour le client et (bien que je ne veuille offenser personne), je suis surpris de voir à quel point certaines parties de la personnalisation semblent trop compliquées ou sur-conçues, alors que certains aspects assez fondamentaux semblent extrêmement complexes. -cuit.

Je sais que je n'inclus pas d'extraits de code particuliers, mais la question semble être suffisamment générale, du moins pour moi.

Merci d'avance!

3
Radoslav Georgiev

S'il vous plaît voir le Personnaliser les messages plugin. Il a WP_Customize_Post_Setting et WP_Customize_Postmeta_Setting pour représenter les posts et postmeta dans le personnaliseur, respectivement.

2
Weston Ruter