BackboneConf 2013 Recap

Last week, along with a few other developers from Automattic, I attended the BackboneConf 2013 at the Microsoft NERD center organized by the fine folks at Bocoup. The enjoyable two-day conference provided me with a better sense of the bigger javascript trends and gave me a bunch of practical tidbits.

The big theme was modules and how to best structure code so that dependencies are minimized, concerns are well separated, and unit testing is easier. With the inclusion of modules in ECMAScript 6 and the maturation of nodejs and AMD/UMD/CommonJS, modules are ready for prime time. Now I just need to figure out the best way to incorporate modules into WordPress, which already has a file-based javascript dependency management system.


  1. Underscore has lots of super elegant bits that I should take remember to use:
    // Set default key/value pairs if not included in the passed object (options)
    options = options || {};
    _.defaults(options, {
      showFollows: true,
      showLikes: true
    // take certain options and copy the properties to the destination object (in this case this)
    _.extend(this, _.pick(options, methodArray));
  2. Use an event bus and postMessage() to simplify messaging between parent document and iframe with embedded Backbone App.See
  3. Use requestanimationframe() and _.debounce() to avoid blocking the UI when doing expensive looping operations by chunking the work.
  4. Even when using Backbone, it can be very useful to store visual state in the DOM through using classes. It seems obvious in retrospect, but when in a Model-View-Whatever state-of-mind, it is easy to forget to take advantage of the DOM to store view state. This is especially useful for changing the visibility of certain child views in a collection view.
  5. Q seemed to be the preferred library for promises.
  6. Mocha, chai, and sinon seemed to be the preferred set of tools for writing javascript unit tests.
  7. Use promises to fetch data, templates, and any other dependencies in parallel when building up a page in a single-page app to improve the load time of pages.
  8. FastClick is a neat library for improving the responsiveness of click events on mobile if you don’t have any double-click events.
  9. IndexDB allows a client side app to store much more data than local storage


More About the Two Workflow Plugins that BU is Developing

I posted the following on BU’s Developers vs. Designers blog:

After almost 4 years building the BU CMS on WordPress MultiSite, the BU WebTeam, which consists of staff from IS&T and Interactive Design, has decided to release some of our plugins to the broader WordPress community. The first two plugins planned for release tackle some of the workflow limitations that content editors have been asking us to address for a few years.

The Problem

The BU CMS contains quite a few large websites. In most cases, the bulk of the content comprises of pages (the “page” post_type), so a significant percentage of the day-to-day content modifications are updates to published content. Unfortunately, WordPress does not provide any controls for restricting the editing of published content or limiting what content a particular user is allowed to publish, so if a user has the capability to edit one page, they can edit all pages. For sites that have more than 50 editors and over 1,000 pages, the primary site administrators worry that ill-advised changes will be made to prominent content by an editor with less experience or without the authority to make the change. In addition to cracking that nut, we wanted to provide a mechanism for staging an edit to a published page so that the change could be worked on directly (with its own revision history), reviewed, previewed, and scheduled for publication.

After reviewing some of the existing plugins that provide this sort of functionality, we decided to write two plugins to address these problems. Both plugins will be released under the GPL.

Design Goals

  • Blend naturally into the existing WordPress admin UI
  • Simple to use
  • Manage permissions with a full view of all post content
  • Perform well on sites with more than 2,000 pages
  • Support custom post types

BU Section Editing

The BU Section Editing plugin creates a new role: Section Editor and adds screens for managing groups of Section Editors. Each group is granted access to publish and edit published content for individual pages.


The group editor borrows UI elements from the post and menu editors.
section-editing-membersSection editors are easily added/removed from a single screen. By using the group model, editors can be added/removed without having to worry about the permissions.
Controlling the group’s permissions is handled from a single view of all content.
section-editing-perms-allowedPermissions are automatically applied to children for hierarchical post types.

BU Versions

The BU Versions plugin adds functionality for creating an alternate version of pages, posts, or any public custom post type. After cloning the post, editors are able to make and preview changes. When the changes are ready to be published, the user simply clicks “Replace Original” or schedules the replacement. Users that do not have the “publish_posts” capability are able to create and edit an alternate version, which makes an edit, review, then publish workflow possible even when modifying published posts.

versions-pagesUsers choose whether to edit or clone from the list view.
Editing an alternate version is distinguished visually from the normal post editor.

We really want to get feedback from other folks using WordPress on large sites, so don’t hesitate to leave a comment on the original post.