web-dev-qa-db-fra.com

Nouvelle API WP_Customize - comment ça marche sous le capot?

J'ai remarqué que si vous apportez des modifications via la nouvelle fonctionnalité "Personnaliser", lorsque vous naviguez sur une page différente du document d'aperçu iframe, vos modifications s'appliquent toujours, même si elles ne sont pas enregistrées.

Il semble que WP stocke les modifications temporaires quelque part et les applique sur le site si celui-ci est affiché en mode "personnalisation".

Mais comment le site sait-il qu'il est en mode personnalisation? Parce que je ne vois aucun argument de requête ajouté aux liens ni quoi que ce soit de ce genre.

customizationapitheme-customizer
15
Alex

Il y a quelques bits ici qui s'appliquent, mais en gros c'est ce code dans customize-preview.js:

this.body.on( 'click.preview', 'a', function( event ) {
    event.preventDefault();
    self.send( 'scroll', 0 );
    self.send( 'url', $(this).prop('href') );
});

Event.preventDefault empêche les liens de fonctionner. Le code suivant envoie ensuite un message en remontant vers le haut en lui indiquant: a) de revenir au haut de la page et b) de changer l'URL.

La raison de la messagerie ici est qu'il n'y a pas qu'un iframe, il y en a deux. La page sur laquelle vous avez cliqué est effectivement chargée dans une autre iframe avec les paramètres du personnaliseur qui lui ont été ajoutés (via une variable POST), puis un effet de fondu est utilisé pour fondre l’ancienne et fondre de manière transparente. Cela évite que l’écran devienne blanc, moche et clignote lorsqu’il passe à la nouvelle page.

Élimine également la nécessité de faire du filtrage et autres sur le code de thème et de modifier potentiellement l'aspect de la page. Le thème est donc affiché tel quel, sans modification importante de son contenu.

Un code similaire existe pour empêcher la soumission du formulaire de fonctionner (cela ne fait rien) et ainsi de suite.

Le filtre pour intercepter et gérer les valeurs du personnaliseur est dans class-wp-customize-setting.php. La fonction preview() ajoute les filtres nécessaires pour gérer les valeurs entrantes. La fonction _preview_filter() est ce filtre. Il prend simplement les appels get_option() ou get_theme_mod(), avertit quand elles sont supposées être des options modifiées et renvoie les valeurs modifiées à la place.

9
Otto

Vous remarquerez que lorsque vous cliquez sur un lien dans la fenêtre d'aperçu du personnalisateur, la demande générée est une demande POST, au lieu d'une GET normale. Le personnaliseur semble redéfinir les clics sur les liens et utiliser plutôt POST avec les données de formulaire suivantes:

wp_customize: on
theme: themename
customized: {json-encoded-options-here}
customize_messenger_channel: preview-1

Le champ personnalisé contient les options que vous avez modifiées. Les données sont donc transmises à votre thème. Le code du personnaliseur intercepte ensuite (via un filtre, les options de votre thème à la demande) et les remplace par les valeurs du paramètre personnalisé .

1
Andy Adams