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 de iframe, sus cambios aún se aplican, incluso si no están guardados.
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 de personalización? Porque no veo ningún argumento de consulta adjunto a los enlaces ni nada de eso.
Aquí hay algunos bits que se aplican, pero lo que falta 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') );
});
El evento.preventDefault evita que los enlaces funcionen realmente. El siguiente código luego envía un mensaje hacia arriba indicando que a) se desplaza a la parte superior de la página yb) cambia la URL.
El motivo de la mensajería aquí es porque no hay solo un iframe, hay dos. La página en la que hizo clic se carga realmente dentro de otro iframe con las configuraciones del personalizador agregadas a ella (a través de POST de hecho), luego se usa un efecto de fundido para desvanecer el antiguo y desaparecer en el nuevo sin problemas. Esto evita que la pantalla se vuelva blanca y fea y parpadee cuando cambia a la nueva página.
También elimina la necesidad de realizar un filtrado y tal en el código del tema y, potencialmente, modificar el aspecto de la página. Por lo tanto, el tema se muestra como está, sin cambios significativos en el contenido del mismo.
Existe un código similar allí para evitar que el envío del formulario 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 función preview() agrega los filtros necesarios para manejar los valores entrantes, la función _preview_filter() es ese filtro. Simplemente toma las llamadas get_option() o get_theme_mod() , avisa cuando se supone que deben ser opciones modificadas y 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 solicitud POST , en lugar de un GET normal. El personalizador parece estar anulando los clics de enlace y haciendo POST en su lugar, 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 lo que contiene las opciones que ha modificado, por lo que es donde los datos se transfieren a su tema. El código del personalizador luego intercepta (a través de un filtro, no estoy seguro de cuál es exactamente) las opciones de su tema cuando se solicitan, y las reemplaza con los valores en el parámetro personalizado .
Lea otras preguntas en las etiquetas customization api theme-customizer