Gutenberg WordPress Development – If you’re already familiar with WordPress, you’re undoubtedly familiar with the TinyMCE-based content editor. For many years, the process of creating content on WordPress has remained mostly unchanged. However, since new rivals like Medium, Ghost, Wix, and Squarespace have grown in popularity, WordPress decided to create a new editor called Gutenberg (After Johannes Gutenberg, the inventor of the printing press).
Gutenberg is a significant shift; it’s a whole new approach to content creation. Instead of writing in a single rich text input, you create your post’s content using blocks of various sorts (paragraphs, pictures, videos, embeds, quotations, lists, etc.).
This modification has a significant impact on WordPress users. Authors of plugins will develop unique blocks and templates, while theme authors will style blocks… There are numerous blogs out there discussing these changes and their impact on users, but few discuss how Gutenberg is fundamentally altering how we create WordPress (aside from the frameworks battle, VueJS VS React VS Preact).
Developing in GitHub (WordPress Development)
WordPress development is generally done through tickets and patches in WordPress Trac, whereas featured plugins are usually done in GitHub, with a distinct repository for each Featured Plugin. Once integrate into Core, this repository will be delete. On GitHub, Gutenberg is developing as a featured plugin. While this isn’t the first time GitHub has been use to develop for WordPress, some contributors are beginning to wonder if it’s better suited for long-term development rather than just featured plugins.
The WP-API was one of the final feature plugins to be integrate into Core. After the plugin was integrate, contributions to the project dropped dramatically, and Trac has proven to be a significant barrier to entry for numerous engineers who are already familiar with GitHub and its idioms.
Single Page Application?
While it’s doubtful that WordPress will become a single-page application tomorrow (or in the next months), Gutenberg’s user interface is rendere in the client (similarly to the Customizer or the media library). It’s a Single Page Application embeds in the WordPress Admin Page. The browser in SPAs does not reload after each click. Interactions are flowing rather than abrupt. Interactions, in particular, might feel quicker.
The REST API is also use by Gutenberg to retrieve data from the server. It’s the first WordPress Core project to make use of the freshly integrated REST API. There will be a slew of others.
WordPress authors are researching alternatives, including a Framework agnostic approach that might be summarize as follows:
- Choosing a user interface framework for WordPress Core. For the time being, Gutenberg is utilizing React, although this is not a final choice.
- Provide an abstraction layer that allows plugin authors to expand WordPress UI using the UI framework that they are most familiar with.
Testing & Linting (WordPress Development)
Modularization (WordPress Development)
Gutenberg was design with modularization in mind as well. Instead of writing a single large package, it will be broken down into smaller ones:
- @wordpress/components: UI components that may be use outside of the Gutenberg environment.
- @wordpress/i18n: Internationalization utilities
- @wordpress/element: Abstraction on top of the UI framework
- @wordpress/date: Date formatting and manipulation utilities
- @wordpress/blocks: Module that includes utilities for registering and constructing blocks.
- @wordpress/editor: Module representing the WordPress Editor’s page
These Gutenberg modules have been test and confirm in both Gutenberg and WordPress. The new WordPress packages repository is the outcome of this strategy. The following are the objectives of this repository:
- Provide reusable WordPress modules that may be use in a variety of WordPress Core Components and Featured Plugins.
- Create self-contained packages that may be use outside of the WordPress environment.
- By reusing modules, you can provide uniformity to various areas of WordPress (The components module represents a WordPress pattern library).
One of the most essential elements of the modularization is how it enhances and simplifies WordPress contribution. WordPress is a large application with thousands of files; for novice contributors, it may be daunting, and it’s easy to get lost among all of these files and components. By dividing the application into smaller independent pieces with a clear and well-defined API, a modular approach tackles this issue. Contributors may more easily chime in and comprehend particular autonomous modules than they can in a single large application.
UI and styling
The WordPress user interface hasn’t been change in years. This may change with the introduction of Gutenberg. While it isn’t attempting to be a total UI update, it does open the way for lighter, more “modern” UI in other sections of WordPress by offering reusable UI elements.
Having a set of well-defined UI components may assist guarantee that accessibility is prioritized across WordPress. If one component is made accessible, that accessibility will be applied to all subsequent uses of that component.
Gutenberg also makes use of certain basic SASS capabilities (variables and mixins) to ensure that WordPress styles are consistent. Take a peek at WordPress’s codebase, for example, and you’ll see more than 50 colors of grey and dozens of shades of blue. Thresholds for media inquiries are the same way. Contributors to Gutenberg have worked to make this more uniform by narrowing down a standard color palette and a revised list of breakpoints.
Icons are also being updated. Gutenberg still uses WordPress Dashicons, however, due to recent changes in browser compatibility for WordPress, Gutenberg now uses SVG icons rather than Icon Fonts.
While documentation is not yet a solved problem in the project, Gutenberg is attempting to include new concepts such as Documentation in Code and the ability to utilize and demo code from within the documentation. Gutenberg presently uses a bespoke documentation tool that is similar to React Storybook but more configurable to meet the WordPress Documentation Styling.
With major improvements coming to the WordPress Development Experience, these are exciting times for WordPress. We may argue that these changes will necessitate some investment in current WordPress developers in order to assist them to learn new technologies, but “what got us here won’t get us there.” The majority of these improvements assist modernize WordPress development, aligning with the larger Web development community, and, in general, are likely to attract new contributors to WordPress by lowering the entrance barrier.