Technical overview of Gutenberg integration

To better understand how we can integrate GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ into WordPress, it’s crucial to know how the Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is organized.

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. Packages

The Gutenberg plugin is mostly a JavaScript application composed of several packages. Each one of these packages is:

  • Generic and available as an npm package.
  • The Gutenberg Plugin registers each package as a WordPress script.
  • The Gutenberg Plugin makes the public APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. of each package available in the wp global variable.
  • If a package is dependent on another one, it consumes it as a global variable and adds it as a dependency of the WordPress registered script.
  • A package can have one or multiple CSSCSS Cascading Style Sheets. stylesheets.

For example:

A @wordpress/components npm package is registered in the plugin as a wp-components WordPress script; its API is available in the wp.components global variable; and depends on @wordpress/element.

In turn, @wordpress/element‘s script is wp-element and is consumed by @wordpress/components in the bundled script as wp.element.

Bootstraping the editor’s page

To display the editor’s page we call wp.editPost.initializeEditor from the higher-level wp-edit-post package. This function takes as arguments the post to be edited and some editor settings.

This call is made when loading the edit.php page localizing the required arguments and enqueuing the wp-edit-post script.

REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoints

Once the editor’s page rendered, all the communication with WordPress happens using REST API calls. In addition to the regular REST API endpoints to fetch, update and delete taxonomies, posts, etc., Gutenberg adds new REST API endpoints that include:

  • Autosaving endpoint.
  • Reusable Blocks endpoint.
  • Root endpoint for site settings.

Many other tweaks have been necessary in existing endpoints (taxonomies, embeds, permalinks, post search, etc) and most of these have been merged in the previous 4.9.* releases.

MetaBoxes

To support MetaBoxes, Gutenberg hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. initially render the content of the MetaBoxes in a hidden DOM node rendered using a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 script. We also hook into the post.php call to persist the MetaBoxes save call.

Summary

So, as a high-level picture, the Gutenberg plugin is composed of:

  • JavaScript scripts and styles.
  • A PHP file to bootstrap the editor in edit.php.
  • REST API endpoints.
  • PHP utilities to parse, register and render blocks on the front-end.
  • PHP script to inject the MetaBoxes into the page and hooks to save the MetaBoxes.

Integration Process

In previous JavaScript meetings, we discussed the packages integration approach:

Since the JavaScript scripts are built as reusable npm packages, we’ll consume them in WordPress like any other npm package:

  • Adding a dependency in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s package.json.
  • Exporting the wp.* globals in enqueue scripts inside WordPress Core.
    • Example: wp.components = require( '@wordpress/components' );
  • Moving the script registration corresponding to each package into wp-includes/script-loader.php.

Scripts like wp.shortcodewp.a11y.speakwp.utils.WordCount can be replaced by their corresponding npm packages. This has already been proposed for the shortcode package and should continue for other packages.

The work being done in #core-js meetings to align the JavaScript guidelines (code style) between Gutenberg and Core would result in a formal @wordpress/eslint-preset package that should be used as a replacement for the current JSHint config.

The REST endpoints should be moved to the regular REST endpoints location in WordPress Core wp-includes/rest-api/endpoints.

The PHP utilities and classes should be moved to wp-includes.

Some minor tasks are also left to do in the Gutenberg repository:

  • Drop the Gutenberg name from all the PHP APIs still using it.
  • Finalize the block-library and edit-post packages:
    • HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. and Freeform block to be moved to the npm packages.
    • The creation of the edit-post package.

Test Suite

The e2e tests are crucial to avoid regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. when making updates to WP-Adminadmin (and super admin). The e2e test infrastructure and the tests themselves should be moved to WordPress Core and their stability can be considered a metric for the success of the integration process.

Unit tests, in general, live next the code being tested. For packages, these will stay in the Gutenberg repository and, for the files moved to Core, the tests will follow.

What about the Gutenberg Plugin?

After WordPress 5.0 is released, the Gutenberg plugin will continue to exist. Its purpose will be changed to the development and the maintenance of the WordPress npm packages, including the editor itself, and will also serve to develop the second phase (site customization) of the Gutenberg project. Plugin updates will continue to be released during the 5.0 cycle.

The PHP part of the plugin won’t be needed anymore, as the plugin will just register new versions of the scripts of the packages to replace the ones already registered by Core.