Front to Back – second iteration – 06

Customizing the Theme Customizer.

Why mess with the UI?

The purpose of the Front to Back plugin is to allow a live, in-browser, page editing user experience.
Beside what’s in it for me as a developer part of the second iteration covers some UI changes to the Theme Customizer to make the editing experience come closer to my will.
What I loved about Perch CMS“) videos was how smooth the user editing experience was.
While I love WordPress editing capabilities those can be overkill and confusing for small projects.

Adding some scripts and styles

The Theme customizer controls area looks a little cramped when the its purpose shifts to content editing functions.
Theme Customizer editing
While there is only so much to be done on small screens wider screen resolutions could really benefit from a larger controls area.
After some little trials I was able to pack (a webpack pun) some small changes to it in the code.
In my ThemeCustomizerSetup service provider I’m hooking in the same script queuing class twice

$customizer_scripts = $this->container->make( 'FTB_Scripts_CustomizerInterface' );

add_action( 'wp_enqueue_scripts', array( $customizer_scripts, 'enqueue_iframe_scripts' ), 11 );
add_action( 'customize_controls_enqueue_scripts', array( $customizer_scripts, 'enqueue_scripts' ), 11 );

The function hooked to the wp_enqueue_scripts action will queue the scripts that will be used in the Theme Customizer preview iframe, while the function hooked to the customize_controls_enqueue_scripts action.
Theme Customizer scripts location
I’m using webpack to queue CSS as well since the Theme Customizer will not work without JavaScript support and I simply love the idea of one file to “rule them all”; the script queued on the controls side is the one below:

// Theme Customizer UI modifications 
require( "customizer-mods.scss" );

// Page Nav styles and scripts

UI modifications

Nothing revolutionary here but for some size wrangling on large screen resolutions; the customizer-mods.scss file modifies just 3 elements:

@import '~breakpoint-sass';

$large : 1350px;
$xlarge : 1600px;

$large-width : 30%;
$xlarge-width : 40%;

@include breakpoint($large, $xlarge) {
  #customize-controls, #customize-footer-actions {
    width : $large-width;
  .wp-full-overlay.expanded {
    margin-left : $large-width;
  .wp-full-overlay.collapsed .wp-full-overlay-sidebar {
    margin-left : -$large-width;

@include breakpoint($xlarge) {
  #customize-controls, #customize-footer-actions {
    width : $xlarge-width;
  .wp-full-overlay.expanded {
    margin-left : $xlarge-width;
  .wp-full-overlay.collapsed .wp-full-overlay-sidebar {
    margin-left : -$xlarge-width;

For a final result that looks like a good first approach to me: no need for separate browser tabs or windows.
A larger editing experience

Quick page navigation

Since the plugin is all about editing pages content from within the Theme Customizer the user should not be forced to rely on the theme navigation menus; to allow for that I’m injecting some markup in the Theme Customizer; the customizer-page-nav.js module reads as follows:

// styles for the new elements
require( "customizer-page-nav.scss" );

var $ = require( 'jQuery' ),
    ftbData = require( 'ftbData' );

$( function () {

    // append the page navigation markup
    if ( ftbData.customizer.page_nav.html ) {
        $( '#customize-info' ).append( ftbData.customizer.page_nav.html );

    // change the previewed page to the desired one on click
    $( '.ftbPageLinks__Link' ).on( 'click', function ( evt ) {

    var url = $( this ).find( 'a' ).data( 'link' );
    $( '#customize-preview iframe' ).attr( 'src', url );
    wp.customize.previewer.previewUrl( url );
    } );
} );

Quick page navigation
That’s not going to win any beauty contest yet it works and fulfills the second iteration scope.

On GitHub

Code actual to this post is on GitHub tagged 0.3.0.


I will plan out the next iteration after some refactoring and code clean-up.

I appreciate your input