Customize Snapshots 0.6 Release

Version 0.6 of our Customize Snapshots plugin has been released; it comes packaged with a set of new features that impact the way the plugin empowers more complex editorial and site management workflows. In short, the plugin provides a UI for managing Customizer changesets, including saving changesets as named drafts, scheduling them for publishing, inspecting them in … Continue reading Customize Snapshots 0.6 Release

Defining “context” in the WP REST API

I got a question from a colleague last week regarding the context parameter in the WP REST API: In which cases would the request be a GET request but the context be edit? I was thinking that perhaps if an object is edited and a child is embedded, then maybe getting that child would be with … Continue reading Defining “context” in the WP REST API

Reducing command line args required for running PHPCS

When you run JSHint, the only thing you need to put on the command line is: jshint. No additional arguments are required to check JS files under the current directory, and it automatically looks for a .jshintrc file for its configuration. For years now when I’ve wanted to similarly run PHP_CodeSniffer to check the adherence of some PHP code against coding standards, … Continue reading Reducing command line args required for running PHPCS

Adding Meta Fields to a Widget Sidebar Section in the Customizer

On the Post Status Slack, an interesting question was raised by Richard Buff: Another customizer question: I’m trying to add a custom control that’s meant to customize the appearance of a specific widget area (like change the background color). Example: And I can do it, by passing the section id of that particular widget area (“sidebar-widgets-front-page-1”) … Continue reading Adding Meta Fields to a Widget Sidebar Section in the Customizer

Previewing Themes with Adaptive Designs in the Customizer

In WordPress 4.5 the customizer introduced device preview buttons for resizing the window to see what the theme looks like in desktop, tablet, and mobile (see #31195): This feature is specifically intended for themes that implement responsive web design (RWD) that applies the device-specific layouts via CSS media queries. Most themes should take this RWD … Continue reading Previewing Themes with Adaptive Designs in the Customizer

Reviewing a Subset of Commits in a GitHub Pull Request

For many years now, GitHub has provided a compare view to see the differences between any two commits, taking the form of: http://github.com/<USER>/<REPO>/compare/[<START>…]<END> This has been useful in the context of long-running pull requests to see just a subset of the changes. But there has been a big problem with this view: you cannot comment on such a compare … Continue reading Reviewing a Subset of Commits in a GitHub Pull Request

Resetting the Customizer to a Blank Slate

Sometimes it is desirable to be able to load the customizer without any of the panels, sections, controls, or settings that would normally be registered by core, themes, or plugins. For instance, in Customize Posts there is the ability to open the customizer via the “Preview” button from the edit post screen. When the customizer … Continue reading Resetting the Customizer to a Blank Slate

Test-driven Development of a Backbone.js App. Part 3.


Please note that you will find all 3 parts of this article as well as the source code of the tutorial in the project’s GitHub repository.


Creating Backbone.js View

In the previous part of the series, we have created our first Backbone.js model using TDD principles.

The third and last part of the article is going to show you a process of developing a Backbone.js view, that will render the markup, handle the user input and reflect model’s state in the UI. Of course, this time we will use the test-driven development principles as well.

Just as it was with the ControlColor model, we will first write some tests in tests/views/control-color.js to make sure our view is defined and possesses Backbone-specific functions in its prototype:

QUnit.module( 'views/control-color.js', function() {
  QUnit.test( 'Color control view exists and is Backbone view', function( assert ) {
     var View = window.ControlColorView;

     assert.ok( ! _.isUndefined( View ), 'View is defined' );
     assert.ok( _.isFunction( View.prototype.setElement ) && _.isFunction( View.prototype.delegateEvents ), 'View is Backbone view' );
  } );
} );

The tests are failing, so we’ll define the ControlColorView in the src/views/control-color.js file like:

window.ControlColorView = Backbone.View.extend( {} );

From the red phase we rapidly moved to the green phase. There’s nothing to refactor so far, so we’ll now take care of rendering the markup based on model’s state.

Continue reading Test-driven Development of a Backbone.js App. Part 3.