WordPress 4.8

We did a ton of work on widgets in the WordPress 4.8 release. Prior to this release there hadn’t been any new widgets introduced for a very long time. Now there are media widgets for images, video, and audio. Additionally, the Text widget finally gets the TinyMCE visual editor just like the post editor has had forever. In 4.8.1 we introduced a dedicated Custom HTML widget for storing arbitrary markup, which the Text widget was formerly used for. Many of these widget changes incorporated ideas from XWP’s JS Widgets plugin, as prior to 4.8 widgets in core lacked any JS-driven functionality at all.

The widget improvements aim to mirror the development of blocks in Gutenberg. If there is a block for something, there should also be a widget for it.The more that block-like widgets are available today, the more users will see a consistency between post content and widget sidebars. After Gutenberg is merged into core, we’ll be working on migrating widgets over to use blocks instead. At that point we’ll be able to abandon many of the hoops we have to go through to make widgets JS-driven when they are fundamentally PHP beasts.

Here are a few of my posts from WordPress 4.8 & 4.8.1 releases on Make/Core:

Media Widgets for Images, Video, and Audio

Addition of TinyMCE to the Text Widget

Fixes to Text widget and introduction of Custom HTML widget in 4.8.1

Customizer Features for WordPress 4.3 Kickoff

Here are the features I have suggested/proposed during the WordPress 4.3 kickoff:

Partial Refresh

This greatly improves performance of previewing changes in the Customizer for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget Customizer feature plugin developed for 3.9. Writeup and feature plugin are available.

Transactions

A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions, and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal.

Concurrency/Locking

This is an important one for a client project I’m involved with, and so I’m having to prioritize it. I’m working on a client site that will have many users in the Customizer at a time, and given the way the Customizer is currently implemented (as with most areas of WP), there is no concurrency/locking support. So I’m working on adding locking at the control/setting level. See #31436.

(Cross-posted in comment.)

WordCamp Sydney talk: Customize all the things!

Today at WordCamp Sydney, I speak on The Customizer:

The Customizer is one of the least known yet most powerful features of WordPress. We need to get past thinking of it as the “Theme Customizer” which only good for tweaking colors and a limited number of settings. No, the Customizer provides a framework for live-previewing any change to WordPress.

In WordPress 3.9 I led development of incorporating Widget management to the Customizer, and I’d like to get on a soapbox to get people excited about developing their own custom controls for the Customizer.

Here’s my presentation:

I’m also happy that we at XWP (X-Team WP) and Stream are among the sponsors of the WordCamp:

Re: Edit WordPress Posts and Postmeta in the Customizer

I couldn’t reply to Jeff’s comment on Sarah’s WP Tavern post because of a Jetpack problem, so I’m posting it here:

With the Front-end Editor using the Customizer as a framework, I wonder if the interface will look similar to this experiment? I hope not.

This plugin is really a prototype to demonstrate how the Customizer can be used to preview changes to posts/postmeta at an architectural level. Hardly any consideration has been given to UI, which Avryl has been doing a great job with in her Front-end editor.

Ultimately, I’m interested to see how the Front-end Editor comes into play when previewing a post or writing a draft post. Will we be able to use it to write a post or will the editor be refrained from use until after a post/page is published?

You can use this Customize Posts plugin to edit drafts as well. Just create a new post post, save a draft, and then click Preview. You can then click Customize in the admin bar to then access that post from the Customizer and you can make changes, including transitioning the post draft to a published post. This relates to a previous prototype I worked on in the Customizer Everywhere plugin, which replaces the “Preview” button with a “Preview & Customize” button.

In this case and as I’ve seen mentioned already, editing should be done inline and not with boxes popping up around the content.

In terms of a prototype which demonstrates how inline editing can be added to the Customizer, see my other prototype: Customize Inline Editing.

Failures related to the WordPress APC Object Cache plugin

On a site for a newer X-Team client, APC was previously chosen as the object cache plugin. This has caused some headaches due to APC not being available while in CLI mode, rendering WP-CLI mostly broken: any commands which change parts of the database which get object-cached won’t appear until the cache gets invalidated, which may not happen anytime soon. For example, plugin (de)activation is broken in WP-CLI with APC Object Cache, as the manifest of activated plugins is cached.

Today I encountered a more serious problem with APC Object Cache.

I was making some widget changes, and I saw that my changes weren’t being reflected on the frontend. Upon reloading the widgets admin page, I also noticed that my changes didn’t seem to get saved. But if I ran wp option get widget_text, I could see my changes had been written to the database (as, of course, WP-CLI here was bypassing the APC object cache). So for some reason, APC was refusing to invalidate widget caches. Doing some more digging, I was shocked to see that the the Text widgets used in the sidebar, had multi-widget instance numbers surpassing 560,000,000. That’s right, 560 million.  The output of wp option get widget_text included:

array (
  /*...*/
  526001242 =>
  array (
    'title' => 'Lorem Ipsum',
    'text' => 'Hello World',
    'filter' => false,
  ),
  '_multiwidget' => 1,
)

Some plugin must have at some time bumped that widget instance number up, because there’s no way there have been millions of Text widgets used on the site. Only a couple dozen Text widget instances are currently present.

In any case, this incredibly-sparse PHP array seemed like a good candidate for what was causing APC cache to fail. I swapped out APC for Memcached Object Cache, and the problem went away. While the Memcached plugin stores arrays as serialized strings, just as they get stored in the options table, the APC plugin is apc_store’ing the array wrapped in an ArrayObject instance:

if ( is_array( $data ) )
    $store_data = new ArrayObject( $data );

While I couldn’t reproduce this problem on VVV or on the site’s staging environment, for some reason on production this array object failed to get stored by APC.

I’ve never had any issues with Memcached Object Cache, so I’m glad I made the switch. Not only did it fix this strange widgets issue, but it’s great to be able to once again rely on WP-CLI!