On WordPress + Git

Can you believe it – we’ve made it through a State of the Word without anybody asking “when is WordPress moving to Git/GitHub?” You may, however, have caught a brief mention of issue trackers in relation to the Triage Team focus for 2019. While it’s very important to make the distinction between Git the version control system (VCS) and GitHub the service, as the answer usually goes, it’s understandably a continued area of interest. Many parts of WordPress have been developed using GitHub as the central tool, along with countless plugins and themes and even the WordPress book.

Here’s the tl;dr (but you should definitely keep reading after this): Changing things up doesn’t just mean “let’s make the GitHub mirror at WordPress/wordpress-develop the canonical and migrate Trac tickets over” – it means imagining what kind of change would be a net benefit to the core development process and eventually the entire .org ecosystem, and then finding the right tools to do it.

To that end, there is a group of people including myself (@helen), @desrosj, and @omarreiss who have been and will continue to be doing more coordinated research and planning around tooling. There is no current planned timeline nor is this a priority on top of the projects already enumerated for 2019, but any potential tooling change is being evaluated as it potentially relates to those projects, especially if it can better support phase 2 of Gutenberg development and the Triage Team.

This is not about chasing the latest and greatest or evangelizing a preference – it’s important to identify the goals we have for the project and what pain points we are experiencing. More specifically than “democratizing publishing”, in the core development process we should be aiming for diverse participation, a faster-but-steady pace of development, predictable and timely feedback cycles, and continuing to build user trust among users of all types. Recent pain points have been merges between branches (especially 5.0 back to trunk), JavaScript package updating, and continued participation when projects move from plugins and GitHub into core and Trac.

Roughly, here are some early thoughts on various moving pieces and potential future improvements.

Repositories and Workflows

  • SVN repositories would need to remain, essentially flipping the mirroring process to go from Git -> SVN, making SVN (and Git) repos on .org read-only
  • Should the core build process continue to be handled as-is or should we move to something like Travis?
  • Integration of more automated testing – visual regression, end-to-end, accessibility, performance
  • Identification of the ideal lifecycle of an issue and process for a pull/merge request – design, docs, review, testing, etc.
  • Identification of contribution workflows (contributor documentation, Git branching methodology, etc.)
  • Security tracking and releasing

Issue Tracker

  • Critical for a Triage Team to review existing issues and to remain active going forward
  • Potential for the bulk triage process to include migration from Trac to another tracker
  • Any issue migration should be determine on a case by case basis by the Triage Team in collaboration with component maintainers; the most automation that should happen is a tool that takes a list of Trac tickets and imports them elsewhere
  • Issue import process needs to take commenter attribution into account
  • Trac would remain in a read-only state
  • How are reports generated and used (i.e. is the built-in filtering capability enough in a given tool or will we need something more robust to support workflows)
  • Is the issue tracker still the best place for feature requests?
  • Implementation of issue templates
  • Identifying existing custom integrations and whether those problems still exist and still need to be solved after a move

Broader Ecosystem (later / bigger question mark)

  • Connectors from GitHub to .org plugin and theme repos (GitHub Actions-powered build+deploy)
  • Automated testing – sniffers, Tide, unit tests, WP and PHP compat testing, Theme Check
  • Aligning plugin and theme review teams

#git, #trac, #triage

9 Projects for 2019

As mentioned in this year’s State of the Word, these are the nine priorities that we should focus on in 2019, in order to make the biggest impact for WordPress users:

  • Creating a block for navigation menus.
  • Porting all existing widgets to blocks.
  • Upgrading the widgets-editing areas in wp-admin/widgets.php and the Customizer to support blocks.
  • Providing a way for themes to visually register content areas, and exposing that in Gutenberg.
  • Merging the site health check plugin into Core, to assist with debugging and encouraging good software hygiene.
  • Providing a way for users to opt-in to automatic plugin and theme updates.
  • Providing a way for users to opt-in to automatic updates of major Core releases.
  • Building a WordPress.org directory for discovering blocks, and a way to seamlessly install them.
  • Forming a Triage team to tackle our 6,500 open issues on Trac.

Updating the Minimum PHP Version

For the millions of sites already running WordPress 5.0, 85% are using PHP 5.6 or above. We’ve also recently observed that showing notifications to encourage users to upgrade their PHP version has been very effective. Yoast SEO experimented with this last year, and found that site owners upgraded their PHP version at twice the rate than before they were showed the notification.

In light of that, I’d like to propose that in April 2019, we bump the minimum PHP version requirement to be 5.6. Sites that choose to remain on 5.5 or below will still receive security updates and possibly bug fixes, but would not be able to upgrade to the latest major WordPress version until they upgraded to a supported version of PHP.

Similarly, I’d like to propose that in April 2019, we bump the minimum MySQL version requirement to be 5.5. 98.5% of WordPress 5.0 sites are using MySQL 5.5 and above.

Depending upon feedback and effectiveness, we can follow up by bumping the required PHP version to 7 as early as December 2019.

Gutenberg Phase 2

Phase 1 of Gutenberg was intended to make post and page editing easier and more flexible for users, leveraging blocks as the main mode of interaction offering greater virtuosity, especially for non-technical users. The next phase seeks to expand this idea beyond the post, allowing editing and customizing the rest of a website in WordPress. This process also aims to eliminate the complex obstacles users have to find their way through — like multiple layers of abstraction and navigation — and to reduce the amount of technical knowledge required to customize the overall appearance and functionality of their site. 

The next phase of Gutenberg will take the ease of use that was introduced with block-based editing and extend that capability to the Customizer, starting with widgets, to make it easier for users to customize the rest of their sites.

In the first step of phase 2, we will bring blocks into the Customizer to create a more consistent user experience and give developers a smoother path to upgrading themes to Gutenberg. Longer term, we will expand the current Gutenberg post and page editor to become a full-fledged site editor, bringing everything together into a unified, modern product experience.

If you currently have a site like this and you want to edit any of these widgets that aren’t part of the post content, you have to use an interface like this:

It’s really disconnected from anything you see on the front end of the site, it requires you to sort through a list of widgets on the left and then know how to drag and drop them into these different widget areas on the right. More to the point, if you think about widgets, they kind of represent a really early idea of blocks — they’re discrete areas for content and functionality that you can add to your site. But now with Gutenberg, we have a much more advanced, elegant, and robust concept of blocks and how you interact with them.

The first step for phase 2 will involve upgrading the widgets UI to incorporate a modern block editor that is consistent with how you edit pages and posts in Gutenberg to create a clear, consistent editing experience across different areas of your site.

Widgets

In widgets.php

widgets.php would become something more like this, which is an early sketch, but you can see that all of these widgets are represented as blocks.

In the Customizer

Menus

We’re currently still investigating a number of ways that we might improve the menu management experience. 

In nav-menus.php

Inline

Editing blocks in-context

Once we have converted widgets and other elements like menus into blocks, what we can do in phase 3 (or 2+, depending on how things go) is to bring all of these elements together into a full site editor, where you no longer have to hunt for controls in the customizer menu, but can instead just edit blocks like menus and widgets in place on your site.

Instead you could add blocks wherever you need them to go and see them previewed in context. Once we bring this all together we start to realize a vision of WordPress making the web fully editable in a way that is powerful, flexible, and accessible to everyone from beginners to experts.


To recap, Gutenberg Phase 2 will:

  • Be outside of post_content.
  • Focus on customization.
  • Upgrading themes, widgets, & menus.

Early version of phase 2 will be in the plugin. Be sure to reactivate it!

JavaScript Packages and Interoperability in 5.0 and Beyond

WordPress 5.0 adds a number of new bundled script handles, including many specific to the new editor, as well as a few vendor dependencies. Given that a plugin or theme may already have registered their own copies of these same dependencies, this post is meant to serve as a reference for maximum interoperability. These are tips which could apply for any new dependency added by WordPress in any version, but are more likely than usual to be encountered given the amount of new JavaScript included starting in 5.0.

WordPress-Specific Scripts

All new WordPress-specific JavaScript code is registered using wp- as a prefix for the script handle. These include the following script handles:

  • wp-a11y
  • wp-annotations
  • wp-api-fetch
  • wp-autop
  • wp-blob
  • wp-block-library
  • wp-block-serialization-default-parser
  • wp-blocks
  • wp-components
  • wp-compose
  • wp-core-data
  • wp-data
  • wp-date
  • wp-deprecated
  • wp-dom-ready
  • wp-dom
  • wp-edit-post
  • wp-editor
  • wp-element
  • wp-escape-html
  • wp-format-library
  • wp-hooks
  • wp-html-entities
  • wp-i18n
  • wp-is-shallow-equal
  • wp-keycodes
  • wp-list-reusable-blocks
  • wp-notices
  • wp-nux
  • wp-plugins
  • wp-polyfill-element-closest
  • wp-polyfill-fetch
  • wp-polyfill-formdata
  • wp-polyfill-node-contains
  • wp-polyfill
  • wp-redux-routine
  • wp-rich-text
  • wp-shortcode
  • wp-token-list
  • wp-url
  • wp-viewport
  • wp-wordcount

Documentation for these packages can be found in the Gutenberg Handbook. They are also available for consumption via npm under the @wordpress scope (excluding polyfills).

Each WordPress package above assigns itself to the global scope under the wp namespace. For example, if your theme or plugin enqueues wp-editor, it will be made available at window.wp.editor in your browser. Conversely, you should also make sure that, for any JavaScript in your plugin which references a wp-namespaced library, the associated script handle is defined as a dependency of your script using the third argument of wp_enqueue_script and wp_register_script.

Vendor Dependencies

The following vendor dependencies have been added in WordPress 5.0:

For vendor scripts in particular, there is a chance for conflict if a plugin or theme registers their own copy of the dependency with the same un-prefixed name. There is a greater likelihood if there is a large version mismatch between the registered scripts.

In general, a plugin should seek to avoid naming collisions by following the best practice of “Prefix Everything” as prescribed in the Plugin Handbook. While this can sometimes result in multiple copies of a script being present in a page, it reduces the chance for breakage and grants WordPress the option to use the unprefixed name in the future.

For dependencies which assign themselves to the global window scope, wp_add_inline_script can be used to ensure it is assigned to a global name unique to your plugin or theme. For example, the following snippet demonstrates including React on a page for a plugin without interfering with a core-enqueued copy of React, whether or not it exists:

wp_enqueue_script( 'myplugin-react', 'https://unpkg.com/[email protected]/umd/react.production.min.js' );
wp_add_inline_script( 'myplugin-react', 'window._originalReact = window.React;', 'before' );
wp_add_inline_script( 'myplugin-react', 'window.mypluginReact = window.React; window.React = window._originalReact;' );

With the above snippet, your intended copy of React will be guaranteed to be available at window.mypluginReact . This pattern can be applied to any vendor dependency to ensure compatibility with libraries added to WordPress in the future.

If your plugin or theme registers a script with using one of the above script handles as its registered name, consider taking one of the following steps:

Depending on whether you plan to continue support for versions of WordPress earlier than 5.0…

  • If you are only intending to target 5.0 and newer, verify compatibility between the versions of the library and simply remove your plugin or theme’s registration of the conflicting script handle.
  • If earlier version support is needed, and assuming your script registration occurs after the default scripts are registered (after wp_default_scripts), check for whether the script handle is already registered , then register or enqueue your copy of the script, optionally deregistering the core-registered script. Note that since core code targets a specific version of the vendor dependency, deregistering the script may have adverse effects on screens where it is used (notably the new editor screen).
    • Alternatively, follow the pattern as described above to assign your plugin’s copy of the library to a unique name.

Lodash Global

By default, Lodash will assign itself on the global scope using the _ name. Since WordPress will continue to bundle Underscore for the foreseeable future (see #43733), the core-registered Lodash adopts an approach similar to the enqueuing of jQuery to avoid naming conflicts. It does so using Lodash’s _.noConflict, assigning Lodash to the global scope as window.lodash

For this reason, if your plugin or theme uses Lodash as a dependency, you should make sure to not cause _.noConflict to be called multiple times in conflict with the core-registered script.

  • When using the copy of Lodash registered by core, your code should reference it by the window.lodash global.
  • When enqueuing your own copy of Lodash, you should only call Lodash’s _.noConflict under the condition that window.lodash is not already assigned and that the core-registered Lodash will not be included on the page.

In general, the _ global should be used only to reference Underscore.

React and wp-element

When extending the new editor interface, you should use the new wp-element script handle, rather than React directly. The element package is a thin abstraction over the React interface, and implements most all of the same functionality. Targeting wp-element will ensure the greatest compatibility for your plugin as new versions of WordPress are released.

Refer to the wp-element package documentation and React website for more information. 

#5-0, #dev-notes, #javascript

WordPress 5.0 Field Guide

WordPress 5.0 is officially the best WordPress 2018 has seen!  Users will be empowered with new and exciting tools to create to create truly unique sites while developers can to take advantage of 10 enhancements and features added.  Let’s look at the many improvements coming in 5.0…

Heard of Gutenberg?

Not much has changed since 4.9.8, except this thing we lovingly call Gutenberg.  The Gutes.  Guten-all-the-things.  The Block Editor.  Want to build Gutenblocks?  We’ve got details on filters in the new block editor.  We’ve got compatibility flags you can set when adding a meta box to load the block editor or to fall back to the classic editor. There is also designer and developer documentation in the handbook.

JavaScript 🌐 and 🗣️

We’re bringing the internationalization capabilities that have existed in PHP for years to the world of JavaScript.  You can also translate strings in JavaScript files and distribute them via https://translate.wordpress.org.  The long-wished-for JavaScript actions and filters are now also available in core.

Default Themes

With all the excitement of the new block editor there is some exciting news on the default themes front. First, WordPress 5.0 welcomes the newest default theme to the family, Twenty Nineteen.

But, preexisting default themes have not been left behind! All preexisting default themes have been updated to be fully compatible with the new editor.

Media WYSIWYG

5.0 brings a new way to interact with media within the editor, getting us to the world of a truly “what you see is what you get” experience.  Some things have moved around, some new methods have been added, and new features abound; read below for details.

✉️🏷️s (Post Labels)

Five additional labels have been made available for custom post types, but you’ll have to click through below to learn more.  I dare you, click through.  Do it.

REST API

The 5.0 release brings a handful of great new REST API endpoints with it to power the new block editor. In addition to the new endpoints, there are a handful of other REST API changes to be aware of.

But Wait, There is More!

Over 26 bugs, 8 enhancements, 2 feature requests, and 6 blessed tasks have been marked as fixed in WordPress 5.0. Some additional ones to highlight include:

  • Add CSS URL sanitization to kses (#45067): Authors & Contributors can now use CSS in the post_content with a URL value, such as background-image. Used to get stripped out.

Please, test your code. Fixing issues helps you and helps millions of WordPress sites.


Update (2018-12-06): Added “JavaScript Packages and Interoperability in 5.0 and Beyond

#5-0, #field-guide

The REST API in WordPress 5.0

WordPress 5.0 contains several additions to the REST API that help provide the new block based editor with all the data it needs. Let’s talk about them!

New Core Endpoints

Several new endpoints have been added to help supply the new block based editor with the data it needs. They all have been built on the existing REST API infrastructure, so the same action and filter hooks throughout can be used to modify requests and responses.

Autosaves

An Autosaves endpoint has been added and registered for all post types except attachment (but including custom post types). The endpoint utilizes the WP_REST_Autosaves_Controller class which extends WP_REST_Revisions_Controller. Registering the endpoint for all post types, and not just those with revisions, was an intentional design decision because all post types need the ability to autosave whether or not revisions are enabled.

Only id, title, post_content and excerpt are saved on this endpoint, but a full, updated post object is returned in the response. It also returns the preview_link, which drives the Post Preview button in the new editor. 

Note: This endpoint requires requests to be authenticated.

Ticket #43316

Search

In order to facilitate searching across multiple post types, a new WP_REST_Search_Controller class was added which registers a /wp/v2/search endpoint. This endpoint is used by the link inserter in the new editor. 

Search types are handled by extending WP_REST_Search_Handler. The default search type is WP_REST_Post_Search_Handler, but this can be filtered by plugins or a theme by using the wp_rest_search_handlers filter.

Ticket #39965

Block Type

A new hidden post type of wp_block has been added for storing reusable blocks. Information about the post type is available at wp/v2/types/wp_block, including the labels and the capabilities required in order to read and create reusable blocks.

Ticket #45098

Blocks

The individual reusable blocks can be retrieved from wp/v2/blocks. This uses the standard post controller to return post objects containing the rendered content and associated data of each reusable block. 

Note: This endpoint requires requests to be authenticated.

Ticket #45098

Block Renderer

All dynamic blocks with server-side rendering, such as the latest comments or archives, can be accessed at wp/v2/block-renderer/<name>. Names have to be structured as namespace/block-name, where namespace is the name of your plugin or theme. An example core endpoint would be wp/v2/block-renderer/core/archives.

All registered attributes for the block being rendered are accepted as GET parameters. These are validated against the schema matching what was declared in register_block_type().

Note: This endpoint requires requests to be authenticated.

Ticket #45098

Themes

A minimal wp/v2/themes themes endpoint has been introduced to inform the new block-based editor of the features that the active theme supports. This allows the correct panels, features, and UI elements to be shown or hidden for the user.

This will currently only return data about the active theme. This endpoint must also be accompanied by the status parameter with a value of active. For example: wp/v2/themes?status=active

The current data included in the response is:

  • A list of post formats supported.
  • Post thumbnail support details.
  • Whether responsive embeds are supported.

In the future the themes endpoint can be expanded, but this was the minimum required information for the new block editor to have all the data it needs to work correctly.

Note: This endpoint requires requests to be authenticated.

Ticket #45016

Additional Changes of Note

In addition to the new endpoints, there are a number of changes to REST API responses developers should be aware of.

  • All custom taxonomies must have show_in_rest set to true in order to appear in the new editor.
  • A new function wp_is_json_request() has been added to determine if the request is expecting a JSON response, and if so, silence PHP warnings and errors. [43730]
  • In order for clients to present permalink previews, the REST API must share the computed results of get_sample_permalink(). These values are now exposed as permalink_template and generated_slug for public, viewable post types, but only for context=edit. [43720]
  • Any fields registered with register_rest_field() now respect the ?_fields= filter parameter in the request URL. [43736]
  • Users with read_private_posts capability can now query for private posts on the posts endpoint. [43694]
  • The unfiltered_html capability is now declared using JSON Hyper Schema targetSchema. [43682]
  • block_version value is added to the post object to denote whether post contains blocks and of what version. At this point there is only one version, but if the block format has backwards compatibility breaking changes in the future, we can increment this value as needed. [43770]
  • New rest_after_* action hooks have been added that fire after all write operations have completed. [42864]

View all REST API tickets in the 5.0 release milestone »

#5-0, #dev-notes

Media 5.0 Guide

The block editor in WordPress 5.0 brings a much needed refresh to how we interact with media in the editor. 5.0 has provided new features designed to make complex content easier to create, and is built in a way that is now truly “what you see is what you get”! There are some big changes to where things are, new methods of accessing `classic` functionality, as well as new features you may not even know about. Let’s highlight a few of those!

Where is the add media button?

If you are looking for the add media button for any reason, this can be found in the classic block TinyMCE toolbar labeled “add media”. This button will trigger the media modal.

Gallery Block:

We have improved the Gallery experience with a new block that gives users a truly real time interactive Gallery.

If you need to utilize dynamic galleries that are based on post ID, or if you need to use the `post_gallery` filter, this can still be achieved using the `add media` button located in the classic block TinyMCE toolbar.

Wide Alignment Theme Support:

Some blocks, such as the image block, have the ability to define a “wide” or “full” alignment in the new editor. This is accomplished by adding the `.alignwide` or `.alignfull` classes, respectively, to the image’s wrapper element. A theme can opt-in for this feature by calling: 

add_theme_support( 'align-wide' );.

For more information on Wide Alignment, or if you would like to explore the potential markup of images in this context, the documentation has more details.

#5-0 #dev-notes

#media

WordPress 5.0 Release Day!

Welcome to the WordPress 5.0 release day, everyone! It’s currently a chilly -2°C here in Nashville, we’re going to keep everyone toasty and warm with a shiny WordPress release, and a new jazz artist to dance along to!

The current plan is to start the release process at December 6th, 2018 at 17:00 UTC, in the #core channel in the Making WordPress Slack.

The major version release process can take a bit more time than the betas or RCs did, particularly if we run into any last minute issues that need to be addressed.

The Release Process

We’ll be working through the Major Version Release process, for anyone who wants to follow along.

I ran through the Dry Run steps last night, there were no changes needed.

Where the documentation refers to “report 40”, we’ll instead be using this Trac query, which looks at tickets reported against 5.0, rather than `trunk`.

How You Can Help

A key part of the release process is checking that the zip packages work on all the different server configurations available. If you have some of the less commonly used servers available for testing (IIS, in particular), that’d be super helpful. Servers running older versions of PHP and MySQL will also need testing.

You can even start this early, by running the WordPress 5.0 RC3 packages, which are built using the same method as the final packages will be.

#5-0

5.0 / Gutenberg Status Update – Dec 6

Current PRs for review:

Open issues in 5.0.0: 1 (=)
Open issues in 5.0.1: 28 (-1)
Open issues in 5.0.x (fast follow): 123 (+1)
5.0 status: RC3, released December 4.
Current plugin: 4.6, released November 30.
Next 5.0 milestone: WordPress 5.0, to be released December 6

In Trac:

  • Ready to commit:
    • N/A
  • Has patch, needs review:
    • N/A
  • Opened bugs:
    • N/A
  • Opened tasks:

#core-editor, #editor, #gutenberg