Nueva API WP_Customize: ¿cómo funciona bajo el capó?

Noté que si realiza cambios a través de la nueva función "personalizar", cuando navega en una página diferente dentro del documento de vista previa del iframe, sus cambios aún se aplican, incluso si no se guardan.

Parece que WP está almacenando los cambios temporales en algún lugar, y los aplica en el sitio si el sitio se ve en modo "personalizar".

Pero, ¿cómo sabe el sitio que está en modo personalizado? Porque no veo ningún argumento de consulta agregado a los enlaces ni nada por el estilo.

Hay algunos bits aquí que se aplican, pero en resumen es este código en 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 impide que los enlaces funcionen realmente. El siguiente código luego envía un mensaje hacia arriba diciéndole que a) se desplace hacia la parte superior de la página yb) cambie la URL.

La razón del mensaje aquí es porque no hay un solo iframe, hay dos. La página en la que hizo clic se carga realmente dentro de otro iframe con la configuración del personalizador agregada (a través de un POSThecho), luego se usa un efecto de desvanecimiento para desvanecer el antiguo y desvanecerse en el nuevo sin problemas. Esto evita que la pantalla se ponga blanca, fea y parpadee cuando cambia a la nueva página.

También elimina la necesidad de filtrar y tal en el código del tema y potencialmente modificar el aspecto de la página. El tema se muestra como está, sin cambios significativos en el contenido del mismo.

Existe un código similar para evitar que el envío de formularios funcione (simplemente no hace nada) y así sucesivamente.

El filtro para interceptar y manejar los valores del personalizador está en class-wp-customize-setting.php. La preview()función agrega los filtros necesarios para manejar los valores entrantes, la _preview_filter()función es ese filtro. Simplemente toma las llamadas get_option()o get_theme_mod(), los avisos cuando se supone que son opciones modificadas y en su lugar devuelve los valores modificados.

Notará que cuando hace clic en un enlace en la ventana de vista previa del personalizador, la solicitud que se genera es una POSTsolicitud, en lugar de una normal GET. El personalizador parece estar anulando cualquier clic de enlace y haciendo lo POSTcontrario, con los siguientes datos de formulario:

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

El campo personalizado es el que contiene las opciones que ha modificado, de modo que es donde se pasan los datos a su tema. El código del personalizador intercepta (a través de un filtro, no estoy seguro cuál) exactamente las opciones de su tema cuando se solicitan, y las reemplaza con los valores en el parámetro personalizado .