Blog, Conductor, Customizer, Developer

Throughout the development of Conductor, we wanted to make sure that we remained parallel with WordPress and the direction that core was headed in. We feel that the Customizer is the future of WordPress, even though it may need an overhaul eventually. In this series we’ll talk about the in’s and out’s of the Customizer functionality Conductor uses. The first bit of tech that we’ll be talking about is how we are able to communicate with the Previewer window within the Customizer.

It is important to note that the following code snippets will function if placed in a child theme, however they are only presented as examples and may not be ready for production environments. If you’re planning on using these examples in a plugin or theme, you’ll want to make the necessary modifications (i.e. prefixing functions and variables, etc…).

The Customizer vs. The Previewer

The Theme Customizer was added to WordPress in version 3.4. It was originally designed to allow users to customize their theme, but it has since evolved to allow for different customizations (i.e. Conductor).

The Previewer is an <iframe> element which exists within the Customizer and displays a preview of your changes on the front-end of your website. It is the window that provides the real-time feedback of your changes and is one of the most important aspects of the Customizer.

Why is There a Need to Communicate?

Whether you’re an avid user of Conductor, or a casual one, you may have noticed our helper buttons in the Previewer. These helper buttons allow users to easily add widgets to a sidebar or edit a specific widget if they’d like.

What you may not know is that once the Previewer has finished loading, we send the current Conductor layout information over to the Customizer behind-the-scenes. This is to ensure the proper Conductor layout is displayed to the user. This is done by triggering an event to send data to the Customizer once the Previewer is “active”.

Let’s get started.

1.) Enqueue the Scripts

First we need to enqueue a couple of scripts. We’re going to enqueue one script on the Customizer and one script on the Previewer using the code below.

In Conductor, we’ve created a custom controller which enqueues the Customizer script on its enqueue() method (more on that in a future post). However in this example we’ll be using the special action that is triggered on the Customizer called customize_controls_enqueue_scripts to load our Customizer script. We’ll also be using a special action that is triggered only on the Previewer window to load the Previewer script. The Previewer action is called customize_preview_init.

2.) Create the Scripts

Now that we have the scripts enqueued, we’re going to create the two assets in our child theme. The first will be named customizer.js located in a /js/ directory within our child theme. This script will receive communications from the Previewer.

The second script is named customizer-previewer.js and should be located in the same directory. This script will be used to send events to the Customizer.

Houston, Do You Read?

Once everything is in place, the scripts can be tested. Upload them to your child theme directory along with the functions.php snippet above and load the Customizer. Once the Previewer window has finished loading a JavaScript alert() should appear letting you know that the custom event was triggered. You can also check the console log window to see the data that was sent over from the Previewer.

That’s All Folks!

We now have an easy way to communicate between the Previewer and the Customizer. In the next post we’ll show you how we added our helper buttons to the Previewer.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.