To better understand how we can integrate Gutenberg 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 plugin 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.
- Generic and available as an npm package.
- The Gutenberg Plugin registers each package as a WordPress script.
- The Gutenberg Plugin makes the public API 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 CSS Cascading Style Sheets. stylesheets.
@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‘s script is
wp-element and is consumed by
@wordpress/components in the bundled script as
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
REST 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.
To support MetaBoxes, Gutenberg hooks 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 PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher script. We also hook into the
post.php call to persist the MetaBoxes save call.
So, as a high-level picture, the Gutenberg plugin is composed of:
- A PHP file to bootstrap the editor in
- 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.
- Adding a dependency in Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s
- Exporting the
wp.* globals in enqueue scripts inside WordPress Core.
wp.components = require( '@wordpress/components' );
- Moving the script registration corresponding to each package into
wp.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.
@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
The PHP utilities and classes should be moved to
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
- HTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Block 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
The e2e tests are crucial to avoid regression 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-Admin (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.