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

J'ai remarqué que si vous apportez des modifications via la nouvelle fonctionnalité de "personnalisation", lorsque vous naviguez sur une page différente dans le 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 le site est affiché en mode "personnaliser".

Mais comment le site sait-il qu'il est en mode de personnalisation? Parce que je ne vois aucun argument de requête ajouté aux liens ou quelque chose comme ça.

Il y a quelques bits ici qui s'appliquent, mais le plus court 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') );
});

Le fichier event.preventDefault empêche les liens de fonctionner réellement. Le code suivant envoie ensuite un message vers le haut lui disant de a) faire défiler vers le haut de la page et b) changer l'URL.

La raison du message ici est qu'il n'y a pas qu'un seul iframe, il y en a deux. La page sur laquelle vous avez cliqué est en fait chargée dans un autre iframe avec les paramètres du personnalisateur qui y sont ajoutés (via un POSTeffet), puis un effet de fondu est utilisé pour faire disparaître l'ancien et fondre dans le nouveau de manière transparente. Cela empêche l'écran de devenir blanc et laid et de clignoter lorsqu'il passe à la nouvelle page.

Élimine également la nécessité de filtrer et autres sur le code du thème et potentiellement de modifier l'apparence de la page. Le thème est ainsi affiché tel quel, sans modifications significatives de son contenu.

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

Le filtre d'interception et de gestion des valeurs du personnalisateur est disponible class-wp-customize-setting.php. La preview()fonction ajoute les filtres nécessaires pour gérer les valeurs entrantes, la _preview_filter()fonction est ce filtre. Il prend simplement les appels get_option()ou get_theme_mod(), remarque quand ils sont censés être des options modifiées et renvoie les valeurs modifiées à la place.

Vous remarquerez que lorsque vous cliquez sur un lien dans la fenêtre d'aperçu du personnalisateur, la demande qui est générée est une POSTdemande, au lieu d'une normale GET. Le personnaliseur semble POSTremplacer tous les clics sur le lien et faire à la place, 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é est celui qui contient les options que vous avez modifiées, c'est donc là que les données sont transmises à votre thème. Le code de personnalisation intercepte ensuite (via un filtre, je ne sais pas exactement lequel) les options de votre thème lorsqu'elles sont demandées, et les remplace par les valeurs du paramètre personnalisé .