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.
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.
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).
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.
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.
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.
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.
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.