Previewing Site Responsiveness in the Customizer

Note: This proposal was merged to core in [36532]. Download the latest nightly build and give it a try!

The customizer is a framework for live-previewing changes to WordPress sites. And by now, nearly every WordPress theme/site features responsive designs intended to look good on any device. Previewing site changes is just important on mobile as it is on desktop, to ensure that front-end user experience is exactly as intended.

Bringing these ideas together, #31195 proposes a new feature in the customizer that allows users to quickly preview their site on various device sizes. Here’s a quick walkthrough:


The proposed feature focuses on simplicity. The device previewer is in the customizer controls footer, near the “Collapse” button. Only three options are available by default, and they’re intentionally ambiguous. Rather than looking like specific devices, the intent is to understand what a site may look like on a roughly tablet-sized, portrait-orientation device or a roughly phone-sized device, in addition to the standard desktop view. A further extension in #34051 may allow larger screen sizes to be previewed on smaller devices with forced horizontal scrolling; for now, the feature is only available on larger devices.

For Developers

Along with this feature would come a couple of ways to customize the behavior. Please keep in mind that these are proposed and subject to change.

The new customize_previewable_devices filter lets you customize the devices available for preview. One use case may be to turn off this feature entirely:

add_filter( 'customize_previewable_devices', '__return_empty_array' );

Or, developers can add additional custom device preview buttons. The button element will be rendered and the appropriate JS applied to custom devices when the button is clicked; however, developers need to provide CSS to add an icon to the button and to react to the preview size changing.

In JavaScript, themes and plugins can react to changes in the device size being previewed with:

wp.customize.previewedDevice.bind( function( newDevice ) {
     // Do something to adapt to the new device being previewed.

This is particularly useful if your theme requires a JS trigger for responsive elements to apply, instead of using CSS solely.


Any feedback and testing is much appreciated. Device previews in the Customizer can be tested with the latest patch on #31195.

Comments are welcome on this post, the ticket (#31195), or our continuous chat in #core-customize on Slack.

#customize, #mobile, #needs-testing

Shiny Updates v2

Shiny Updates v2

What is Shiny Updates?

With the stated goal of “Hiding the The Bleak Screen of Sadness”, the shiny updates team is working on bringing a smoother experience for managing plugins and themes to WordPress.

Shiny Updates v2 is an effort to continue the shiny updates effort from WordPress 4.2. The original shiny update feature only includes shiny plugin updates. The new version aims to extend this to all aspects of updates, installs, and deletes for plugins, themes in WordPress.

There are numerous screens in the Admin that allow you to install, update, and delete themes, plugins and WordPress itself. Shiny updates is exploring ways to improve their design and especially to offer a better user experience by improving perceived performance and limiting confusing notifications.

What does it do?

The shiny updates plugin currently enables the following features:

  • Deleting single plugins, bulk updating and bulk deleting plugins from the plugin page.
  • Shiny plugin installs from the plugin install screen: multiple actions can be queued up.
  • Shiny theme installs, updates, and deletes, multiple queue-able, including multisite.

What is still being worked on?

Currently the team is brainstorming a complete rethink of the core updates page (update-core.php), working to improve clarity and enable easier Update All functionality. Work on that is happening here:

How can I help?

Anyone can help by testing the plugin! Download and install the plugin, then test out all the shiny features: try installing, updating, and deleting plug7ins and themes, including bulk actions, on both single and multisite. Does everything work as expected? Are there any jarring flows? Missing notifications?

Please report any issues on the Github repository, or drop in the #feature-shinyupdates channel in Slack to ask questions or give feedback. It’s also where we have our weekly chats, on Tuesdays 19:00 UTC. Thank you!

P.S. Props @adamsilverstein for ghost-writing this post.

#feature-plugins, #needs-testing, #shiny-updates, #upgrade-install

Call for Testing: Customizer Menus

First, thank you so much if you help out by taking the time to test new features!

Customize > Menus will be one of the new features in WordPress 4.3. It is being added in addition to the Appearance > Menus page and the Appearance > Menus page will not be changed as part of the new feature.

How to Setup for Testing

  1. Always backup first or test on a site that was made for testing (see warnings below).
  2. Go to Plugins > Add New and search for “WordPress Beta Tester”
  3. Click the “Install Now” button for the WordPress Beta Tester plugin
  4. Go to Tools > Beta Testing
  5. Select the “Bleeding edge nightlies” option
  6. Click the “Save Changes” button
  7. Go to Dashboard > Updates
  8. Click the “Update Now” button

You should see the a message similar to this in the footer in wp-admin pages:
“You are using a development version (4.3-alpha-123456).”


How to Test Customizer Menus

Test creating menus including adding, removing, and editing menus. You may just poke around and test on your own to see if you can find any bugs, or you can use the following checklist as a guide:

Before you begin:

Sample testing checklist (time estimate: ~20 minutes for new users):

  1. Make sure you have installed the latest nightly WordPress release (see setup steps above).
  2. Go to Appearance > Customize and then click on Menus.
  3. Add a new menu named “Main Menu.”
  4. Add all of the pages already saved on the site to the menu.
  5. Save the changes you’ve made so far, exit the Customizer, then navigate back to the menu you just created in the previous step.
  6. Set the “Main Menu” as the primary menu so it shows in the live preview.
  7. Reverse the order of the menu items.
  8. Add the “Travel” category to the menu.
  9. Move “Travel” so it is a child of the first item in the list.
  10. Add a link to Twitter and make it a submenu item next to Travel.
  11. Move Travel and Twitter from the first item so they are submenu items under the About page. Save changes.
  12. Create a new menu for social media with at least one social media link in it and find a way to make it show up in the live preview on the right.
  13. There is a way to use advanced menu settings to enable descriptions for menu items. Try to find it and add a description for the “About” page.

Other testing ideas:

  1. Test using a very large menu with a lot of items. (Also see #32769.)
  2. Test using a menu that is 10 levels deep.
  3. Test with various themes and other types of menus.
  4. Comment on this post with any other testing ideas!

If you want to dig in deeper and get involved with usability testing with others, that would be so cool! Please comment on this post or in the #core-customize Slack channel if you’re interested in doing more.

What to Look For

Look for blockers! A blocker is a very bad bug that blocks people from using the feature. At this stage, the biggest problems are the top priority and you should look for those first and foremost. Be aware of the known issues (see below).

If you do find a bug, report it in Trac or ask about it in the #core-customize Slack channel.

Known Issues

Here are a few key issues still being worked on:

/cc @jimmysmutek @lisaleague @kevinwhoffman @dinamiko
(because you expressed interest in helping with testing somewhere along the way) 🙂

#call-for-testing, #customize, #menus, #needs-testing