Getting your site ready for Gutenberg

Still need guidance getting your site ready for Gutenberg?

On Tuesday, June 5th at 10 am PT, I’m heading up a webinar with Pantheon to cover how you can get your site ready. More specifically, we’ll cover:

But wait, there’s more! The webinar is just one in a series of five, including Mel Choyce and Josh Pollock. You should sign up so Tessa and I aren’t terribly lonely on June 5th.

Gutenberg and the REST API, early May

This post originally appeared on make.wordpress/core.

Since I last wrote two weeks ago, we’re making progress! Key achievements for Gutenberg and the REST API include:

  • Support for who=authors was added to GET wp/v2/users, making it possible to accurately query for authors. WordPress, for better or for worse, defines an author as user_level!=0. See WordPress/gutenberg#6361 for the context on why we can’t add this logic client-side (#42202 for WordPress 4.9.6).
  • Improved performance for the _fields= query parameter (e.g. GET wp/v2/pages?_fields=id,title) by ensuring WordPress core will only process the fields requested for the response. Notably, this helps us avoid running the_content when we don’t need to be (#43874 for WordPress 4.9.7).
  • Minor enhancements to reflect existing WordPress behaviors:

The “Merge Proposal: REST API” GitHub milestone represents the distance we still need to close. Slowly, steadily, we’re bridging the gap, but we could use your help. Here are some of the issues we’re still working through:

  • To ensure all necessary data is available to Gutenberg, we’ve settled upon permitting unbounded per_page=-1 REST API requests for authorized users. This landed for GET wp/v2/users (WordPress/gutenberg#6627), is in-progress for GET wp/v2/(pages|blocks) (WordPress/gutenberg#6657), and needs to be addressed for categories, tags, and custom taxonomies. We also need to patch core with this enhancement (#43998 for WordPress 4.9.7?)
  • Capabilities can’t be processed directly client-side (WordPress/gutenberg#6361), so we’ve introduced a new targetSchema concept to communicate which actions a user can perform. See it in action with wp:action-sticky (WordPress/gutenberg#6529) and wp:action-assign-author (WordPress/gutenberg#6630). There are a few other actions we will need to work out, and then we’ll need to patch core (no ticket yet).
  • Adam is putting together an improved autosaves implementation (WordPress/gutenberg#6257) that I literally cannot wait to see complete. I’m sure he could use some help testing in the near future.
  • Felix is implementing a WP_REST_Search_Controller endpoint (WordPress/gutenberg#6489) to power the link search UI.

Join us tomorrow, Thursday, May 10 at 17:00 UTC in #core-restapi office hours if you’d like to chat through any questions you have.

Your help wanted: Gutenberg Migration Guide

This post originally appeared on make.wordpress/core.

Happy Thursday 🙂

I’ve started a new crowdsourcing project, the Gutenberg Migration Guide, to document WordPress Classic Editor customization points and their Gutenberg equivalents (if such exist).

For example, the media_buttons action is a common way to add a button atop the editor:

Its Gutenberg-equivalent is the Block Inserter. Converting a media button to the Block Inserter requires registering a block type. And now we have a corresponding page for developers to reference.

media_buttons is only one of the many ways the Classic Editor can be customized. Wouldn’t it be great if there was a database covering all of them?

This is where you come in! Take a look through the Gutenberg Migration Guide. For each action, filter, and so on, we’d like to document real-world examples of how they’ve been used. Then, for each of those real-world examples, identify how the feature might be replicated in Gutenberg.

Have a new hook to suggest or question to ask? Please open a new GitHub issue and we’ll get it sorted.

Summary of Gutenberg Plugin Compatibility Database results to date

A quick run-through of where we’re currently at with the Gutenberg Plugin Compatibility Database.

Since announcing the database on March 1st, 70 people have been granted testing status. However, of 5000 total plugins, we’re still at 4139 untested plugins. No companies have stepped up to contribute a significant amount of person-hours.

Of the 861 tested plugins:

  • 219 (25.44%) are compatible.
  • 518 (60.16%) are likely compatible.
  • 25 (2.9%) are likely not compatible.
  • 39 (4.53%) are not compatible.
  • 60 (6.97%) are in “testing”, which means someone started test and abandoned the process.

Notably, this data is largely biased by the “likely compatible” results. For the most part, these are plugins I pre-screened (e.g. caching plugins) prior to March.

In the original data set, 18 (28.125%) of the 64 incompatible and likely incompatible plugins were updated in the four weeks prior to March 1st. This means the majority are on slower development cycles.

Of the 64 incompatible and likely incompatible plugins, the reasons include:

  • Missing Add Media and TinyMCE buttons (NextGen, WPForms, Formidable, FooGallery, Page Scroll to ID and others).
  • Missing QuickTag buttons (Quick AdSense).
  • Meta box doesn’t display at all (Page Links To, Revision Control).
  • Semi-live preview of SEO title doesn’t work in Gutenberg (All In One SEO).
  • Custom Short or Long Product Description fields don’t appear at all (WooCommerce).
  • Featured thumbnail previews aren’t being generated (Auto Post Thumbnail).Whitescreen of death (qTranslate X, CKEditor).
  • Registers a CPT with editor support that doesn’t include show_in_rest=>true (Portfolio Post Type)
  • Adds section to Media Library that isn’t displayed in Gutenberg (Add From Server).
  • Access restriction from plugin not applied in Gutenberg (Advanced Access Manager).
  • Specifying custom gallery image links isn’t applied in Gutenberg (WP Gallery Custom Links).
  • Doesn’t log changes made in Gutenberg (WP Security Audit Log).

Next steps are to be determined. “Try Gutenberg” represents an opportunity to generate more data (out of support forum requests). However, we need a workflow for capturing that data.

Gutenbergen

Thanks to the generosity of WP Engine and DreamHost, I now have a good amount of time to dedicate to Gutenberg over the next few months.

Of particular interest: using automated systems to ensure an exceptional day one (and two and three) user experience.

Lots of problems to solve between now and then — looking forward to diving in!

Introducing the Gutenberg Plugin Compatibility Database

This post originally appeared on make.wordpress.org/core.

Ideally, the majority of WordPress users should be able to use Gutenberg on the day WordPress 5.0 is released. They'll hit "Update WordPress", navigate back to the editor, and continue publishing in Gutenberg with all of the functionality they expect in the Classic Editor.

But plugins! If any one of their active plugins are incompatible with Gutenberg, the WordPress user is likely to experience pain, misery, and bad fortune. Many WordPress installations have a dozen or more active plugins, so WordPress plugins are a significant risk vector for Gutenberg incompatibility.

Enter the Gutenberg Plugin Compatibility Database. The goal for this crowdsourcing tool is to identify whether or not WordPress.org plugins are compatible with Gutenberg. With this data set, we'll be able to:

  • Know the most likely causes of incompatibility.
  • Focus developer outreach on the highest impact problems.
  • Proactively educate WordPress users on whether or not their WordPress installation is ready for Gutenberg.

The only gotcha: we need lots and lots of person-hours for testing. If each plugin takes roughly 1 minute to test, we'll need ~75 person-hours to get through the remaining ~4500 plugins in the database.

Check out the project README.md for a more complete introduction to what's involved. This includes a definition for "Gutenberg-compatible", explanation for why only 5000 plugins are in the database, and other design decisions.

Do you or someone you know have access to lots of person-hours (e.g. WordCamp contributor day, hosting support team, etc.)? I'd love to chat! Feel free to leave a comment, ping me on WordPress.org Slack (I'm 'danielbachhuber'), or get in touch however most convenient.

Fields middleware for Gutenberg

At the moment, registering fields for your Gutenberg block requires a bunch of repetitive code to produce similar UI.

For instance, to produce a text control, you need to do something like this:

el( wp.blocks.InspectorControls.TextControl, {
	value: url,
	onChange: function( newVal ) {
		props.setAttributes({
			url: newVal
		});
	},
	placeholder: __( 'Enter a GitHub Gist URL' ),
} );

See? A lot of boilerplate that you need to repeat for each text control.

For the simple UI, this boilerplate shouldn't be necessary. I'd much rather define a field type when registering the attribute:

attributes: {
	url: {
		type: 'string',
		field: 'text',
	}
},

It sure would be awesome if this existed as middleware!

Switch Laravel Valet from .dev to .test in three easy steps

Chrome and Safari began forcing https for the .dev domain because someone apparently thought it was a good idea to register as a public TLD. Laravel Valet only produces self-signed SSL certificates though, so I want to keep my local installations served as http. Guess it's time to switch TLDs!

Oh, and don't try to use .local on a Mac because it conflicts with Bonjour local networking. I discovered this with 30 minutes of wasted effort. .test is the way to go.

First, run:

valet domain test

Switch Valet to using the .test domain, which will also update dnsmasq accordingly. Don't try to edit dnsmasq configuration on your own — there are too many ways to go wrong.

Second, run:

wp package install wp-cli/find-command

Install wp-cli/find-command to find all WordPress installs in your Laravel project directory. It's convenient for running one WP-CLI command against all WordPress installs.

Third, run:

wp find ~/projects --field=wp_path | xargs -I % wp --path=% search-replace '.dev' '.test' --all-tables

Run wp search-replace against all WordPress installs to replace instances of '.dev' with '.test'. ~/projects is my Valet project directory, and --all-tables ensures the procedure is run against all database tables.

Et voila! You've switched Laravel Valet from .dev to .test in three easy steps.