A Strategy for Custom Colors in the Customizer

The customizer is a framework for live-previewing any change to a WordPress site, and it is particularly useful for previewing visual changes. It has always shipped with a color control and the ability to preview custom colors with little effort, but the previewing experience has often been a bit slow. This post outlines a strategy for custom color options that leverages instant JS-based previewing in conjunction with selective refresh.

Demo of instant custom color previews in the customizer with the Linework theme.
Demo of instant custom color previews in the customizer with the Linework theme.

Example Plugin: Custom Highlight Color

I’ll leverage the custom highlight color plugin as an example of this approach. I recommend downloading it from WordPress.org to follow along with, and I’ll provide a detailed walkthrough of the code with excerpts here.

This plugin only has one option – the highlight color. However, this approach can easily scale to additional options. As I’ll show later, it’s best to minimize your options and instead rely on code logic to generate or select variations as needed so that users can achieve custom results with minimal effort and decision-making. Finding the right balance of color options is an important step in the product design process, and one where even the past couple of default WordPress themes leaned a bit too far in the direction of options, in my opinion.

Adding Customizer Objects

The first step is to register your color options in the customizer via the PHP API. We can use the colors section provided by core, leaving the setting and control to be registered in your theme or plugin. The transport will be postMessage, indicating that we’ll preview the setting with JavaScript:

function custom_highlight_color_customize( $wp_customize ) {
	$wp_customize->add_setting( 'custom_highlight_color', array(
		'type' => 'option', // Change to theme_mod when using in a theme.
		'default' => '#ff0',
		'sanitize_callback' => 'sanitize_hex_color',
		'transport' => 'postMessage',
	) );

	$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'custom_highlight_color', array(
		'section' => 'colors',
		'label' => __( 'Highlight Color', 'custom-highlight-color' ),
	) ) );
}
add_action( 'customize_register', 'custom_highlight_color_customize' );

The setting will use sanitize_hex_color, ensuring that a single secure hex color code is saved in the database for each option. For themes, you should set the type to theme_mod instead of option, and it’ll be stored with the rest of the theme-specific options automatically.

Color Patterns and Calculations

Next, we need to define the CSS that will display the custom color options. By putting this into a distinct function, the code can be leveraged in multiple preview and output contexts. When there’s a lot of CSS, I prefer to break this into a separate file to make it easier to maintain. You can even split distinct parts of the color CSS into different functions. For a simple example, here’s what Custom Highlight Color does:

function custom_highlight_color_css() {
	require_once( 'color-calculations.php' ); // Load the color calculations library.
	$background = get_option( 'custom_highlight_color', '#ff0' ); // The second argument is the default color when the theme mod is undefined.
	// Set the text color to black or white, whichever provides higher contrast with the highlight color.
	if ( custom_highlight_color_contrast_ratio( $background, '#000' ) > custom_highlight_color_contrast_ratio( $background, '#fff' ) ) {
		$color = '#000';
	} else {
		$color = '#fff';
	}

	$css = '
		::-moz-selection {
			background: ' . $background . ';
			color: ' . $color . ';
		}
		::selection {
			background: ' . $background . ';
			color: ' . $color . ';
		}';
	return $css;
}

You’ll notice that there are some color contrast checks here, which automatically set the text color to ensure that it contrasts with the highlight color. In this case it looks for the higher contrast between two colors, but typically you’ll want to ensure that the contrast is at least 4.5 between background and text colors. These checks leverage the color-calculations.php functions that I originally developed for the Fourteen Colors plugin. Feel free to take this file from the custom highlight color plugin and ship it with your project (make sure you update the function prefixes to match your plugin or theme).

In addition to the contrast check (which is done per the WCAG guidelines), the color calculations library has a handy function to “adjust” a color. You can use this to brighten or darken a color by a numeric amount, generating color variations automatically. The Fourteen Colors plugin uses this technique extensively.

Color Output

Now that our color patterns are defined, it’s easy to display the color CSS within style tags in wp_head. However, in the customizer preview, we also need an easy way to get the current colors in JavaScript. To do that, we’ll conditionally add the colors as data- attributes when is_customize_preview():

add_action( 'wp_head', 'custom_highlight_color' );
function custom_highlight_color() {
	if ( is_customize_preview() ) { 
		$data = 'data-color="' . get_option( 'custom_highlight_color', '#ff0' ) . '"'; 
	} else {
		$data = '';
	}
?>
	<style type="text/css" id="custom-highlight-color" <?php echo $data; ?>>
		<?php echo custom_highlight_color_css(); ?>
	</style>
<?php }

The colors should now display on the front end, but they won’t preview in the customizer just yet.

Instant Custoizer Previews with JavaScript

To preview the color changes instantly in the customizer, we first need to enqueue a JS file to manage color previews (if your theme already loads a customizer JS file, you can add to that in lieu of introducing another one):

function custom_highlight_color_customize_preview_js() {
	wp_enqueue_script( 'custom_highlight_color_customizer', plugins_url( '/customizer.js', __FILE__ ), array( 'customize-preview' ), '20160830', true );
}
add_action( 'customize_preview_init', 'custom_highlight_color_customize_preview_js' );

In that file, we’ll follow the standard customizer preview conventions and bind to changes on our settings. For each of the colors, we’ll search for instances of the original color in the CSS, and replace them with the new color:

( function( $ ) {
	wp.customize( 'custom_highlight_color', function( value ) {
		value.bind( function( to ) {
			// Update custom color CSS
			var style = $( '#custom-highlight-color' ),
			    color = style.data( 'color' ),
			    css = style.html();
			//css = css.replace( color, to );
			css = css.split( color ).join( to ); // equivalent to css.replaceAll.
			style.html( css )
			     .data( 'color', to );
		} );
	} );
} )( jQuery );

You’ll need to bind changes to each of your color settings if you have multiple color options. Now, you’ll be able to preview color changes instantly in the customizer. But what about the colors generated using color calculations in PHP?

Adding Selective Refresh for Secondary Colors

To supplement the instant JS previewing that updates the CSS with a search-and-replace of the color value, we need to add selective refresh support so that the CSS is re-rendered from PHP with our color calculations applied. The color patterns and calculations could be duplicated in JS, but that would become quite difficult to maintain and offers only a slight usability benefit. With selective refresh, we can leverage the existing function in PHP; it’s only a matter of adding a customizer partial that will be refreshed when one of the associated colors changes:

$wp_customize->selective_refresh->add_partial( 'custom_highlight_color', array(
	'selector'        => '#custom-highlight-color',
	'settings'        => array( 'custom_highlight_color' ),
	'render_callback' => 'custom_highlight_color_css',
) );

This code should be added within the same callback to the customize_register action that we added earlier. Multiple settings can be associated with a single partial; add the other setting ids to the array of settings.

Once that’s complete, you should be able to preview all of your custom colors in the customizer, with instant updates to base colors and updates to generated colors happening on a slight delay. Colors are safely stored in the database without the security issues of saving CSS there, and styles are applied on the front end as expected. I’m now leveraging this approach in all of my themes and plugins as I find it to provide a nice balance between user experience and code simplicity.

The custom highlight color plugin is a simple example, built specifically to be an example, but this approach easily scales to more colors as needed. For a more complex example, check out the code for the Fourteen Colors Plugin or the Figure/Ground theme (which runs this site and lets users customize every color).

An Update for Figure/Ground

I’ve updated my Figure/Ground theme on WordPress.org (which also powers this blog) with a few nice enhancements:

  • All options in the customizer are now instantly live-previewed with postMessage.
  • Add support for selective refresh in the customizer for widgets, and generated colors.
  • There is now a social icon menu.
  • Redraw the background canvas when the page is resized to avoid pixelization.
  • Improve keyboard navigation (although this still needs additional work).
  • Update Genericons to version 3.4.1.

The new customization experience is the most notable enhancement. See every color change instantly as you play with it in the color picker, without any delay. Enjoy!

Interactive Geometry Apps

Three years ago, I created several interactive geometry apps while working for Saltire Software. As part of the process, I built the collections functionality for Euclid’s Muse (which I had created the previous year at Saltire), which includes the ability to download a collection of web-based applets as a standalone mobile app that can be processed through PhoneGap and published on app stores. The original intent was to publish a few of these apps on the app store and Google play myself, but I never got around to it. So, I decided to publish them as another site on celloexpressions.com. The five apps are:

I also created an index page based on the pseudo-random experiments page. I’m thinking about turning it into a simple WordPress theme with a fun background (animation off by default), anyone interested?

Featured Audio in WordPress

Featured images are native to WordPress core, allowing themes to represent posts and pages with images. But for many users, there are more important content formats than visuals. As a musician, I’ve explored different approaches to integrating WordPress’ audio functionality with post objects, most recently with the Sheet Music Library plugin.

I recently began exploring a new idea — a premium WordPress theme built specifically for musicians and musical groups — and I realized that WordPress needs a generic solution for the broad concept of associating audio files with posts. Post meta associated with specific custom post types or embedding audio directly in posts limits the opportunities for themes to display audio in unique ways and for plugins to create aggregated presentations of audio associated with different posts.

The Plugin

Featured Audio metabox in the editor.
Featured Audio metabox in the editor.

Seeking to introduce a broad solution to the challenges of deeply integrating audio with core WordPress functionality, I’m introducing the Featured Audio plugin. Featured audio is perfect for musicians, podcasters, and anyone who publishes audio content on their site frequently. It works with every theme out of the box by displaying WordPress’ native (mediaelement.js) audio player at the top of the_content. Themes that style the audio player already will offer a customized experience for site visitors using featured audio.

Default featured audio display with the Twenty Fifteen theme.
Default featured audio display with the Twenty Fifteen theme.

I’d love to see more themes designed specifically to make audio a central component of sites’ content. If they all leverage this standardized featured audio plugin, users publishing audio content can get a wide variety of options for displaying their content and the content adapts seamlessly from theme to theme, just like publishers of visual content get with featured images.

The Importance of an API

To make featured audio as broadly extensible as possible, I spent a significant amount of time building public API functions into the plugin that facilitate custom implementations and integrations. Where it makes sense, these functions parallel the post_thumbnail/featured images API in WordPress core. However, the most notable difference is that theme support isn’t required. Taking a similar approach to the Featured Image in Content plugin (but also always showing the admin UI), the content is available regardless of theme support to allow a broader array of themes to be used. Theme support is used to indicate custom implementations, and turns off automatic front-end display of featured audio on a technical level.

A majority of sites probably don’t use audio at all, making the idea of featured audio probably inappropriate for WordPress core. But by building a core-like solution that themes and other plugins can extend, we can provide audio publishers with similar opportunities to publish freely with WordPress. And the development of themes and plugins that extend and customize the experience will further promote publishing audio with WordPress.

Infinite Possibilities

Once the base API is in place via the Featured Audio plugin, there are endless possibilities for themes and plugins to expand the potential of featured audio to offer tools for publishers. Plugins can expand the API to offer additional functions for custom theme display, or other tools such as widgets or shortcodes to aggregate featured audio across posts. The core playlist functionality is especially promising here.

Themes can do anything from moving where featured audio is displayed or adding it to archive views that don’t display the content to showcasing audio in unique and unexpected ways in the front-end UI. We’ve seen featured image headers, so why not featured audio headers, with the ability to set up a default audio file in the customizer. I’m excited to see what theme designers can come up with.

Feadured Audio Playlist widget in the Twenty Fifteen theme.
Feadured Audio Playlist widget in the Twenty Fifteen theme.

To offer a glimpse of the possibilities, I’ve built a few advanced features into the plugin. The API includes arguments for the main the_featured_audio() function to display the title and/or album art (which WordPress automatically pulls from MP3 files that have it) alongside the audio player for easy display of additional information in themes. The plugin also adds a Featured Audio Playlist widget, which displays a playlist with all of the featured audio associated with posts on the current view, such as a blog index, archive, or taxonomy page. The playlist output is also available directly via an API function for custom display in themes outside of the widget context. For example, a playlist could be displayed alongside a taxonomy title and description at the top of a taxonomy archive. Playlists are great because they allow visitors to listen to more of your content without repeated manual interactions, and in this scenario they’re automatically created and organized on-the-fly based on the existing organizational structure of a WordPress site.

Content Ownership and Hosting

One of my personal goals with featured audio is to encourage publishers to host their own audio content directly in their WordPress site. Third-party services such as Soundcloud offer advantages in distribution but when it comes to displaying content on sites, I frequently get the impression that users don’t realize that they can host and publish their audio content directly. WordPress is about democratizing publishing, and part of that mission is to give users complete control over their content. With better resources for publishing audio directly in WordPress, fewer users will feel a need to turn to third-party services. Long term, it would be awesome to see third party social and aggregation sources for audio content pulling data out of WordPress sites rather than the other way around, as it is currently.

Next Steps

Now that the plugin is live on the repository, publishers can start using featured audio with the basic experience on any theme out of the box. But the really exciting opportunities come with plugins and themes that extend the basic experience, and it’s up to you to start designing and building those projects. I’m hoping to build a premium musician-oriented theme that integrates with featured audio eventually, but the beauty of open source software is that anyone can create free or premium products that build on this functionality. I’m excited to see what the community can do together to improve the experience of publishing audio content with WordPress.

The Customizer is the Future for Themes and Theme Options

There has been a lot of backlash from the WordPress community recently over the theme review team’s decision to require theme options to be implemented in the Customizer. But this decision really is in everyone’s best interest.

WordPress 4.2 shipped with the ability to switch themes in the Customizer. When theme-installation is incorporated in a future release, the entire theme selection and customization process will be streamlined to a seamless workflow in which the user never enters the WordPress admin. This functionality is specifically targeted to users that leverage free WordPress.org themes, so it just makes sense for all themes hosted there to be Customizer-optimized. But the real win is the ability to live-preview changes before publishing them. With the Customizer, users know exactly what their site will look like when they publish their changes, a critical feature for anyone who cares what their site looks like when it’s publicly available.

Many people have been critical of the user-oriented nature of the Customizer. But its power is much stronger than most realize; one of my favorite use-cases for the customizer is custom CSS. This is the easiest way for users who want to go further to get into coding and offers a seamless experience that is infinitely better than the easy-to-kill-your-site-or-lose-your-changes-with code editor in the admin. In fact, I’d love to see a customizer-based custom CSS functionality in core as a replacement for the code editor, although I have a feeling that proposal may be too political to advance to an implementation. Bottom line, the customizer lowers the barrier to entry into WordPress development, contrary to many people’s thinking.

Yes, free themes requiring use of the Customizer will lead to a similar movement for client themes and premium themes. And that’s okay. In fact, by having everyone using the same underlying framework, users know where to look for options and have the confidence that live previewing provides. And WordPress will provide a more consistent visual experience for users as well.

You can really build any functionality into the Customizer. Theme-switching, widgets, and menus were all built as plugins first and continue to use the publicly available customizer API to run. So if you must, you can still create ridiculously complicated UI elements that no one will be able to figure out how to use, but you really don’t need to.

And complaints about the amount of screen real estate available and the 300px default width show a lack of creativity and resistance for the sake of resistance to change. Start by removing all of the ads, external links, unnecessary branding, unnecessary options, and general clutter. Make your options self-explanatory – if you need a paragraph to describe what it does, it probably shouldn’t be a user-facing option. Do you still have so much UI that the experience is completely unusable? Try an outside-the-box solution, like utilizing the core media modal (header images and core media controls use it), a custom modal (theme details modal in core), or a slide-out panel (widgets in core and eventually menus in core as well).

No, the customizer isn’t perfect. But it’s time to give it the respect it deserves as a significant part of WordPress. After three years of slow adoption, the theme review team’s decision to enforce its use is a welcome sign for users and a positive decision for the WordPress community as a whole. I’m excited to see what developers do with the Customizer’s amazingly powerful API and what core contributors come up with to improve its design and usability.

twenty-fifteen-no-sidebar

Twenty Fifteen, no sidebar

Twenty Fifteen is another great default theme that can be easily customized. I recently had to put up a quick site for my new themes site on halsey.co. I only wanted one or two pages, with a super simple layout.

I decided to just remove the sidebar (remove the widgets first) and center the content area. On mobile, all we need to do is remove the header. This also removes the “proudly powered by WordPress” footer, as there’re better ways to display that in this context if you want it. Here’s the CSS:

body:before,
#sidebar,
#colophon,
.entry-footer {
	display:none;
}

.site-content {
	margin: 0 auto;
	float: none;
	width: 100%;
	max-width: 1200px;
}

If you’re not familiar with CSS, the easiest way to implement this is to install & activate the Modular Custom CSS plugin, then go to the Customizer and add the above CSS to the “Custom Theme CSS” field.

Cello Expressions Sheet Music Library 1-6-2014

New Sheet Music Library: The Story

After nearly two years of planning, false starts, and development, I finally launched a new sheet music library. In this post, I’ll discuss the development and implementation process, design decisions, and how I created this project in a way that the source code will be available for anyone to use for free.

History

I started posting my cello ensemble compositions and arrangements online in early 2012, when I first set up celloexpressions.com as the website for my high school cello quartet, Cello Expressions. When I transitioned the site to be the home for my projects in August of that year, I created a series of separate WordPress installs for my different sites, moving the original site to the music subdirectory and building a new system to display sheet music in a more structured way. Because I had spent the summer developing Euclid’s Muse, basing the code off of a horribly-written BuddyPress plugin, I thought that the best approach would be to create a custom database table, querying it directly. I didn’t have the time to build a posting or editing UI, so I decided I would just make edits directly in the database with PHPMyAdmin. That worked for a few months, and in November 2012, I redesigned the site’s theme (poorly). But I would last post a new piece in January 2013. It was clear that I needed an entirely different system, and that I would probably need to migrate all of my existing content (now 60 pieces) manually.

Cello Expressions Sheet Music Library, from January 2013 to December 2014.
Cello Expressions Sheet Music Library, from January 2013 to December 2014.

Goals

My primary goal for the sheet music library is to make free music, primarily for cello-oriented ensembles, widely available and accessible. I also want to get my works out there for people to play.

But my goals for making the sheet music library easy to use were much harder to accomplish with the old system. All pieces needed to have PDF downloads, preferably with the ability to have separate score and parts PDFs. I needed to display previews of the PDFs in a browser-agnostic way, rather than hoping that it would work to put a PDF in an iframe. Pieces needed to have a way to upload and display recordings, both via MP3s and via YouTube videos. Pieces needed to have fields for composers, difficulties, genres, and instrumentations, and values should cross-link between different pieces. And most importantly, I needed everything to be searchable, both internally and via search engines.

A Plugin

One of my first decisions was to build the sheet music library functionality in a plugin. That way I could use an existing WordPress theme and redesign much more easily. Over time, additional benefits became clear – others could use this plugin as well. The Boulder Cello Project will be using it, plus an add-on plugin, to power their internal members site, where they post sheet music for their meetups for members to practice in advance. The plugin will be released on WordPress.org once the initial implementation for the Cello Expressions Sheet Music Library is complete.

Custom Post Type & Taxonomies

It also became clear that I should create a sheet music custom post type, with custom taxonomies providing relationships between pieces. Composers, instrumentations, difficulties, and genres are each custom taxonomies for the sheet_music post type. PDFs for the score and parts and audio file uploads would be stored as attachments, with the attachment post ids stored as post meta in sheet_music posts. YouTube videos are stored by their URLs as post meta as well.

PDFs to Images

The solution to displaying PDF previews in a reusable way ended up being surprisingly simple. By converting the first page of the score PDF to an image, the front-end and admin can display an image preview of the PDF pretty easily. Converting PDFs to images is actually pretty simple in most modern server environments with WordPress’ image editor.

Diving briefly into code, WP_Image_Editor’s ImageMagick implementation makes it incredibly easy to convert PDFs to Images:

/**
 * When a PDF is uploaded, generate a thumbnail image and save it in the attachment meta.
 */
add_filter( 'wp_generate_attachment_metadata', 'prefix_generate_pdf_thumbnail_metadata', 10, 2 );
function prefix_generate_pdf_thumbnail_metadata( $metadata, $attachment_id ) {
	$attachment = get_post( $attachment_id );
	if ( 'application/pdf' === get_post_mime_type( $attachment ) ) {
		// Create a png from the pdf.
		$file = get_attached_file( $attachment_id );
		$pdf = wp_get_image_editor( $file );
		if ( ! is_wp_error( $pdf ) ) { // Most likely cause for error is that ImageMagick is not available.
			$filename = $pdf->generate_filename( 'image', null, 'png' );
			$uploaded = $pdf->save( $filename, 'image/png' );
			if ( ! is_wp_error( $uploaded ) ) {
				$upload_dir = wp_upload_dir();
				update_post_meta( $attachment_id, 'pdf_thumbnail_url', $upload_dir['url'] . '/' . $uploaded['file'] );
			}
		}
	}
	return $metadata;
}

Unfortunately, not all servers have ImageMagick installed. I don’t have it installed locally, and when I went to test on the celloexpressions.com server (hosted by GoDaddy for historical reasons), it wasn’t there. I contacted support and they said I had to upgrade to a newer account, which would involve manually migrating everything (or they could do it for a fee). I’d been wanting to get off of that server for a while anyway, so I took to opportunity to move everything onto one of my existing Bluehost accounts, cleaning up some old stuff that was living on celloexpressions.com in the process. Once I switched the domain over to the new server, everything worked exactly how I had wanted.

Realizing how straightforward it is to create images from PDFs in PHP, and how much room for improvement WordPress has with regards to PDF uploads (both in terms of administration and presentation), I’m going to propose some improvements there for core once I finish this project.

Media & Embeds

In addition to digging into the intricacies of WordPress’ handling of PDFs, I spent some time working on my JavaScript skills to implement previews of uploaded audio and linked videos in the admin. Since I knew I’d be using the plugin at large scale, it was important that the admin UI was as functional and efficient as possible. Audio and video previewing was implemented based on the media wpviews in the main editor. While the result is somewhat hacky and buggy, most of the integration relies on core functions rather than extensive custom logic, and I rarely encountered the bugs in my workflows.

On the front-end, wp_audio|video_shortcode( array( ‘src’ => $url ) ); gives browser-compatible HTML5 audio and video via MediaElement.js. That also gives us a skinned player for YouTube videos that matches the audio player, can be customized with CSS, and seems to reduce the volume of ads. WordPress 4.2 will also add support for skinned Vimeo embeds, and the sheet music library plugin won’t require any changes to support Vimeo and YouTube equally.

In a future update, I plan to explore the possibilities with creating a “collection” of PDFs with the media library, similarly to galleries, audio playlists, and video playlists. If I’m successful with that, it could be used to offer separate files for each part of a piece, instead of requiring all of the parts to be in one PDF (which I manually merge the separate parts into before upload). That could also concievably provide an automated merged PDF file that’s created in PHP, if ImageMagick supports something like that.

Templates

While a custom post type with several custom fields and taxonomies would normally work best with custom theme templates, I wanted the sheet music library to be as theme-compatible as possible. So I implemented default templates for single and archive views by filtering the_content. It works pretty well on a lot of themes, and could look just fine on pretty much any theme with a little custom CSS. For more advanced implementations, custom templates and adding theme support for ‘sheet_music_library’ will do the trick. I also created a shortcode that outputs the table view that I use on the homepage.

Search, taxonomies, archives, etc. all work well with the content filtering. The sheet music post type also supports featured images, so using the theme’s templates ensures that images are still used as intended. In my case, I only use images on a few pieces, and they really stand out in search, taxonomies, and post navigation.

Themes & Design

The plan all along was to go with a WordPress.org theme for the initial roll-out, then come back and do a custom theme specifically for use with the sheet music library plugin. But after exploring tons of potential theme options (while testing the theme compatibility of the plugin), I ended up going with Twenty Fifteen. And I’m liking it so much that I may not even do a child theme (I currently have some custom CSS, but that’s it). While I’m not happy with every component of the theme, the biggest things that made it my choice are its strong, scalable typography and its sticky sidebar functionality. CelloExpressions.com has a global header that’s displayed on all sites in the network, and by having no header and a minimal sidebar for the theme, I was able to keep things simple while still providing means for navigating throughout the site. In fact, I ended up with no menu for the music library, leaving navigation and discovery to search and a widget for each custom taxonomy.

My biggest problems with Twenty Fifteen were lack of color contrast, and excessive whitespace/inefficient use of space in places. For a while I had planned to use Twenty Fourteen, since it provides so much space for navigation and is very space-efficient. But upon further investigation, the only part of the sheet music library requiring more horizontal space is the table view on the homepage, so I just dropped some margins there. The contrast issues were a quick fix with Twenty Fifteen’s custom color options, combined with the dark “global” Cello Expressions header.

I also designed a new logo for myself and Cello Expressions as part of this process. I started out on paper, from doodles that had been done while trying to stay awake during class. As I learn more about graphic design, I’m pleased with my final result, and it works great in vector format. Currently, I’m using it in the header and as the site icon. I’ll use it elsewhere as opportunities arise.

Cello Expressions Logo

Migration & New Content

Once the new plugin was finally complete and I’d settled on using Twenty Fifteen at least initially, I was ready to migrate the 60+ pieces from the old site to the new site and add all of the music from the past two years that never made it into the old system.

Because the old implementation was so bad, and most of the old fields wouldn’t translate cleanly to the new taxonomies for composers, instruments, difficulties, and genres, I had to manually migrate all of the content. This also gave me the opportunity to remove some pieces that weren’t up to my current standards.

I started by moving the entire contents of my old server to the new Bluehost server, renaming the /music/ directory to /music-archive/. Then, once I moved the nameservers, I created a new site in the celloexpressions.com multisite network, at /music/. After putting some text in the homepage and setting up my plugins, I started migrating content.

In the end it took nearly two weeks and countless hours, but I now have 104 pieces in my new sheet music library. About half were migrated from the old library, and the other half are newly-published. At a rough estimate, two-thirds have an audio or video recording, or both. They all have scores, terms in four taxonomies, and publication dates back-dated to when they were created. While it required a colossal effort that’s still not quite complete, this project was very much worth it. And the best part is that all of the work, from the software powering it to the music it contains, is free for anyone to use, in the spirit of open source.

Proposed WordPress Customizer Theme-Switching UX

This is a proposal for how theme-switching and theme-installation could be incorporated into WordPress’ Customizer. This will eventually be attempted in some form as a feature-plugin to later be merged into WordPress core. The goal is to soften the distinction between themes and theme options and to make theme switching a fast, streamlined experience built-in with other Customization options in a unified interface.

Themes is a panel, but with backwards-sliding, coming in from the left instead of the right. This implies a new layer of hierarchy above the top-level controls. Switching contexts to the theme-browser is just like switching contexts to a panel, but to exit the themes context, you select a theme. The currently active/currently previewed theme is selected and has an arrow back to the right, to slide back to the top-level controls. All of this sliding can also be triggered by swiping on touch devices.

When a different theme is selected from the theme browser, it instantly slides back to the main panel of top-level controls, but now reflects the controls available in the new theme. This is accomplished by rendering the controls specific to the new theme via ajax and the new customizer sections/panels JS API, and then deleting the controls that were specific to the old theme. This should be doable in a back-compatible way by working some trickery with the existing customizer APIs, caching stuff, and/or leveraging WP-API.

The preview would instantly need to switch to a loading indicator until the front-end re-rendered with the new theme, but that shouldn’t take too long and is unavoidable regardless of the implementation here.

In the theme browser, the add-new-theme functionality would be present via a + new theme tile matching the one in the current interface, and bring up a modal containing the 3.9 pieces of THX. From there, the theme-installer previewer (also containing the theme details) would need to either remain in the (almost-full-screen) modal or open in a new tab that closed on install/close-button-click (or, do a full-screen iframe on top of the customizer and modal with the theme-install-preview, although that might get a bit crazy).

We would need a solution for unsaved changes in previewed themes that are not activated, as theme-specific controls are hidden/removed when previewing another theme.

Prerequisites:

  • JS API for adding and deleting panels, sections, settings, and controls, to complement the existing controls API.
  • Distinction/ability to save changes without publishing and/or the ability to save without activating a new theme. Although, not distinguishing between saving and saving and activating would probably make more sense here.
A screenshot of the Twenty Fourteen theme with the Fourteen Colors plugin, featuring a light gray contrast color and a light blue accent color

Custom Colors in Twenty Fourteen

Twenty Fourteen is WordPress’ shiny new default theme, released Thursday alongside WordPress 3.8. I worked with the Twenty Fourteen development team throughout the cycle, doing everything from proposing features to removing features to proposing design tweaks, fixing bugs, and testing the theme everywhere.

Screenshot of the Twenty Fourteen WordPress theme, taken from the demo site on WordPress.com

Twenty Fourteen features black, white, and green as its primary colors. In September, I introduced an “Accent Color” feature that allowed users to change the green color to any color of their choosing. With a lot of help from the rest of the Twenty Fourteen development team, the feature made it into the theme and was improved through the duration of the development cycle.

But just over a week before the theme was set to debut to millions of self-hosted WordPress users–and after the theme had debuted on WordPress.com–the accent color feature was removed.

There are several reasons for the feature’s removal. For one, it was possible to pick any color, which meant that users could select low-contrast colors rendering portions of their site unusable. Additionally, two alternate shades of the user’s choice of color were generated behind the scenes, meaning that the feature was code-heavy. The default WordPress themes seek to be as code-simple as possible, to aid beginning developers and to make the default themes good candidates for use as starter or parent themes.

Because of the short development cycle for WordPress 3.8 (the cycle actually overlapped 3.7, but there was very little time devoted exclusively to 3.8 after 3.7 came out), it was clear that there wasn’t time to develop an alternative or improved accent color implementation in the theme, and the feature was removed.

However, I moved the feature to a plugin while it was removed from the core theme. I also added a new “Contrast Color” option. Over the past week, I’ve built out this new plugin, entitled Fourteen Colors, and I pushed a polished version 1.0 just as WordPress 3.8 was released.

A screenshot of the Twenty Fourteen theme, with a gray contrast color and a yellow accent color applied

In just a couple of days, the response to Fourteen Colors has been amazing. I knew that it was well-done both inside the code and to the end user, but I never expected such a positive response from developers and casual users alike. Check it out now, review it, spread the word. And let me know if you find any bugs, maybe-bugs, ideas for enhancements, or anything else. Fourteen Colors is off to a great start, and I’d like to keep the momentum going! One of the most significant things that helping develop Twenty Fourteen taught me is the power of the community: the more we collaborate and help each other towards common goals, the more successful we are in our individual pursuits are as well.

Thirteen or Fourteen Colors

You may have noticed that I’ve added my eighth plugin to WordPress.org: Fourteen Colors. It adds color customization to the new Twenty Fourteen default WordPress theme, half of which was developed in the core theme before being removed yesterday, just over a week before the theme’s release (broader explanation coming soon).

In the next week, I’ll build out Fourteen Colors, creating what I hope is my most polished plugin yet, inside and out. I already know that I’ll be further utilizing the function that generates color variants, which I wrote when the feature was developed for the core theme, to ensure the highest color contrast possible given various contexts within the theme.

I also created a plugin to customize the (much bolder and more varied) colors of the Twenty Thirteen theme, entitled Thirteen Colors (that plugin is much less elegant than I hope Fourteen Colors will be). I’m starting to wonder why WordPress’ default themes don’t place an emphasis on built-in visual customization. Twenty Eleven was the last to have comprehensive color customization options, or even a link color option, for that matter.

The reasons that the custom accent color was removed from Twenty Fourteen seem referable to the broader lack of customization available in default themes. Hopefully, Fourteen Colors can successfully provide an answer to the concerns over giving users the power to make “bad” color choices, at least in terms of readability if not in terms of beauty. As for code complexity, maybe it’s time to consider customization as a component worthy of adding some weight, like featured content is in Twenty Fourteen. At the end of the day, these themes are the first thing users encounter when getting started with WordPress, and it seems wrong not to showcase the power and flexibility of the platform in the first-run experience (the ability to easily browse for new themes is also critical here).

Maybe Twenty Fifteen will bring the power of native visual customization back to the end user. After all, we have a wonderful Theme Customizer that works excellently for visual customizations. I’d love not to create a “Fifteen Colors” plugin next year.