If you're already familiar with WordPress, you're probably used to its content editor based on TinyMCE. Creating content in WordPress did not really change for many years now. But with new competitors gaining more and more attraction like Medium, Ghost, Wix, Squarespace, WordPress decided to build a new Editor called Gutenberg (After Johannes Gutenberg, the inventor of the printing press).
Gutenberg is a big change, it's a completely new way of creating content. Instead of writing inside a unique rich text input, you add blocks of various types (paragraphs, images, videos, embeds, quotes, lists….) to compose your post's content.
The impact of this change on WordPress Users is not negligible. Content creators will have to learn about blocks, plugins authors will create custom blocks and templates, theme authors will style blocks… There are several posts out there talking about these changes and their impact on the users but very few talk about how Gutenberg is changing radically how we develop WordPress itself (aside from the frameworks battle,
1- Developing in Github
Usually WordPress development happens in WordPress Trac, through tickets and patches, while featured plugins usually happen in GitHub, with a separate repository for each Featured Plugin. This repository is removed once merged into Core. Gutenberg is being developed as a featured plugin on Github. While this is not the first time GitHub is being used to develop for WordPress, contributors are starting to question whether GitHub is more suitable for longer-term development and not only for featured plugins.
One of the last featured plugins merged into Core was the WP-API. Contributions to the project diminished a lot once the plugin was merged, and Trac has proven to be a huge barrier at entry for several developers already familiar with GitHub and its niceties.
2- Single Page Application?
WordPress is a classic PHP application where most of the UI rendering is done server-side. JavaScript is mostly used to some DOM interactions to server-side generated HTML.
While It's very unlikely that WordPress becomes a single page application tomorrow (or in the next months), Gutenberg renders its UI in the client (similarly to the Customizer or the media library). It's a Single Page Application built inside a regular WordPress Admin Page. In SPAs, the browser doesn’t reload for every click you make. Interactions feel fluid instead of abrupt. Notably, interactions can feel faster.
Gutenberg also leverages the REST API to fetch Data from the server. It's the first project in WordPress Core using the recently merged REST API. Several other will follow.
3- Modern JavaScript
Despite the fact that WordPress recommends PHP 7, it is still supporting PHP 5.2 and thus being written with PHP 5.2 compatible code. But unlike PHP, JavaScript transpiling is a thing, which means we can still write JavaScript code in the last versions (ES2015+ or more commonly called ESnext) and transpile it to ES5 code compatible with legacy browsers.
Gutenberg is leveraging this possibility and being written in ESnext + JSX which has a big impact on the JavaScript developer Experience. WordPress already has some JavaScript build setup based originally based on Browserify and updated recently to use WebPack (Thanks Adam). Gutenberg takes things further bringing babel compilation (using the babel-env preset) to this setup.
4- UI Framework
We can't talk about modern JavaScript without touching on the UI Framework discussion happening in WordPress. Backbone has been the framework of choice of WordPress for some years now, ever since its introduction with the Media Library. But it has proven hard to maintain and extend.
Pushed by the Gutenberg Project, WordPress contributors are exploring alternatives which include a Framework agnostic approach that could be summed up like this:
- Picking a UI framework for WordPress Core. Gutenberg is using React for now, but this decision is not final yet.
- Provide an abstraction layer allowing Plugin Authors to use the UI framework they are most comfortable with to extend WordPress UI
Good discussions around this have already happened and are still ongoing in the WordPress Core JS meetings, I encourage you to read the meeting recaps if you're interested in the subject.
5- Testing & Linting
Modern Javascript also brings with it its plethora of new tools.
For testing purposes, WordPress followed the jQuery path in using QUnit. While it's still possible to continue using QUnit with ESnext JavaScript code, the setup would be complex and new actors in the market are changing the way we write, run and debug tests making QUnit feel like the stone age of Unit Testing. One of these tools, Jest is being used by Gutenberg.
Linting and formatting are the other aspects of Modern Javascript Development seeing a lot of changes and updates recently. JSHint no longer support ESnext features properly and WordPress is moving to ESlint for this purpose. The Gutenberg Team and the Javascript Core Contributors also talked about using Prettier to format code, but opted to postpone for now. Using prettier could change the JavaScript Style Guidelines drastically.
6- Modularization
Gutenberg is also built with modularization in mind. Instead of writing a single big package, it's being split into smaller packages:
- @wordpress/components: Generic UI components reusable outside of the Gutenberg context
- @wordpress/i18n: Internationalization utilities
- @wordpress/element: Abstraction on top of the UI framework
- @wordpress/date: Date formatting and manipulation utilities
- @wordpress/blocks: Module providing utilities for registering and building blocks
- @wordpress/editor: Module representing the WordPress Editor's page
These modules are being built and proven in Gutenberg for both Gutenberg and WordPress. This approach has resulted in the new WordPress packages repository. The goals for this repository can be summed up as follows:
- Provide WordPress reusable modules for use in several WordPress Core Components and Featured Plugins
- Build autonomous packages reusable outside of the WordPress context
- Engage better with the broad JavaScript community
- Bring consistency across several parts of WordPress by reusing modules (The components module represents a WordPress pattern library)
Also one of the most important aspects of the modularization is the way it improves and eases contributing to WordPress. WordPress is a huge application with thousands of files, it's overwhelming for new contributors and it's very easy to get lost in all these files and components. Using a modular approach addresses this issue by splitting the application into smaller autonomous bits with a clear and well-defined API. It's easier for contributors to chime in and understand specific autonomous modules than it is in a unique huge application.
7- UI and styling
WordPress UI has not been significantly updated in years now. With Gutenberg, this could change. While it's not trying to be a complete UI refresh, it paves the way to other parts of WordPress by providing reusable UI elements to build a lighter, more "modern" UI.
Having a set of well defined UI components can help ensure accessibility stays a priority across all parts of WordPress. If one component is made accessible, this accessibility will then apply wherever the component is reused.
Gutenberg is also leveraging some simple SASS features (variables and mixins) bringing consistency to WordPress styles as well. For instance, if you take a look at WordPress's code base, you'll notice more than 50 shades of gray used and dozens of shades of blue. The same could be said for media queries thresholds. Gutenberg contributors have helped make this consistent by narrowing down a canonical list of colors, and refined list of fewer breakpoints.
Even Icons are being updated. Gutenberg is still using the WordPress Dashicons, but thanks to the recent changes to the browser support for WordPress, Gutenberg is now leveraging SVG icons instead of Icon Fonts.
8- Documentation
While documentation is not a solved problem yet in the project, Gutenberg is trying to bring new ideas to the table, such as Documentation in Code as well as the possibility to use and demo the code right inside the documentation itself. Gutenberg is currently using a self-made documentation tool similar to React Storybook but more customizable to match the WordPress Documentation Styling.
Conclusion
These are exciting times for WordPress with big changes coming to the WordPress Development Experience. We could reasonably argue that these changes are likely to demand some investment in the current WordPress developers, to help them learn new tools but "What bring us here, won't get us there". Most of these changes help modernize WordPress Development, they align with the broader Web development community, and all in all are likely to bring new contributors to WordPress, and lower the barrier to entry.
Thanks Joen Jasmussen for the feedback
This post is brought to you by the new Gutenberg Editor
28 responses to “How Gutenberg is changing WordPress Development?”
It is truly exciting that so much work is being put into bringing modern development practices—even cutting edge ones—into WordPress. But in regards to WordPress moving to a Single Page Application, I want to remind that WordPress has had a single page admin application since WordPress 3.4: the Customizer. It has been evolving and improving a lot over the years, with a rich JS API and some of the most drastic improvements coming in this upcoming 4.9 release. So while I am really excited about the new developments coming with Gutenberg, I don’t want the existence of the Customizer to be overlooked or forgotten (since it wasn’t mentioned in this post). That being said, I am looking forward very much to integrating Gutenberg into a revamped Customizer v2 that builds on top of the solid foundation we already have in this part of WordPress while incorporating the new tools and processes that are being developed with Gutenberg.
Thanks Weston for your comment, and you’re totally right! In addition to the customizer, we could consider the Media Library as an SPA too. Correct me if I’m wrong but, I especially wanted to emphasize the fact that Gutenberg is proving and using the Rest API extensively which has not been done before.
Sorry, not my intention to tarnish the awesome work you all have been doing in the customizer and other different parts of WordPress, just put the light on what’s different with Gutenberg. I’m updating the post to clarify the sentence suggesting Gutenberg is the first SPA in WordPress.
Thanks! I’d consider the Media Library to be a component more than an SPA, but I suppose the distinctions can be fuzzy.
We also have a feature plugin for Customizer endpoints for the REST API, but we haven’t had a chance yet to use it yet. I’m looking forward to moving away from admin-ajax in Customizer v2!
[…] WordPress. If you want to find out more how Gutenberg is changing radically the latter, I recommend the blog post from my teammate Riad […]
Hey Riad,
Great article and thank you for the link to the Gutenberg documentation page!
Hi Riad thanks for this article on gutenberg. As you say ‘Gutenberg is also built with modularization in mind’ I guess we can add our own component and I wonder if it’s working like in react. I mean if I want to create mynavbar component I do :
import React from ‘react’;
import Navbar from ‘react-bootstrap/lib/Navbar’;
export default class MyNavbar extends React.Component {
render(){
return (
…
);
}
} and then I import with import {MyNavbar} from ‘./comp/my-navbar.jsx’; where needed?
Is it so ? or you have create a different way of doing ?
Thank you
Yep, this works. Gutenberg is providing an option layer ‘wp.element’ you can use as a replacement of React (but it’s the exact same thing at the moment) if you want to.
Riad I’ve played a little bit with gutenberg this week and there’s one thing that surprised me.
The array type because when I try this “Saab”, “Volvo”, “BMW” it gives me value:
Array[1]
0:
“\”Saab\”, \”Volvo\”, \”BMW\””
Is it possible to get array of number or names with gutenberg ?
Yes, it should be possible, how did you define this attribute and how did you update it?
I define this attribute like that:
textOne: {
type: ‘array’,
source: ‘children’,
selector: ‘.gfblocks-text-1’,
},
I update it with onChange: function( newText ) {
props.setAttributes( { textOne: newText } );
},
el( blocks.Editable, {
tagName: ‘p’,
className: ‘gfblocks-text-1’,
inline: true,
placeholder: i18n.__( ‘Enter feature text…’ ),
value: attributes.textOne,
onChange: function( newText ) {
props.setAttributes( { textOne: newText } );
},
focus: focusedEditable === ‘textOne’ ? focus : null,
onFocus: function( focus ) {
props.setFocus( _.extend( {}, focus, { editable: ‘textOne’ } ) );
},
} ),
I guess you shouldn’t be using an “Editable” to fill an array supposed to be an array of strings or ints. `Editable` is just un input with a special format for its value to store/edit HTML. It’s a wrapper around TinyMCE.
Use TextControl instead of “Editable” but get the same result
It’s not a drop-in replacement, if you attribute is an array, you need to set it as an array, a text control is just a string. (when you call setAttributes you need to pass an array)
`setAttributes( { myAttributeName: [ ‘a’, ‘b’, ‘c’ ] } );`
In order to build this with your UI you have multiple options, a list of textControl for instance each one updating one element of the array etc…
Thank you Riad for your contributions in the wordpress community.
I wonder if it’s possible to do with gutenberg what some builder plugins do.
Like pre-designed sections or pre-designed templates like that : https://wpbeaveraddons.com/page-templates/
Not in V1 but this is planned for the Gutenberg customization focus (v2).
Hi Riad
Thanks for this post
I have one question on gutenberg babel config
I get a token error for …attributes or …images[ index ].
I use
“babel”: {
“presets”: [
“stage-3”
],
“plugins”: [
“transform-object-rest-spread”
]
} but it fails for your spread.
Could I have your secret recipe to make it work ?
It should work with this setup. But I think the rest spread plugin requires a recent version of babel, so check this.
Merci pour cette article Riad.
Juste deux questions sur le projet gutenberg, je crois que Matthew Mullenweg avait dit que ça sortirai en avril 2018 avec wordpress 5.
C’est une version beta ou est ce que vraiment la première version de gutenberg sera intégré à wordpress dès le mois d’avril ? et puis la seconde question c’est sur cette première version de gutenberg. Est ce qu’il y aura des options de resize et drag and drop pour la première version de gutenberg un peu comme ici : https://strml.github.io/react-grid-layout/examples/0-showcase.html ou est ce que ce sera pour plus tard ?
Bonjour Audrey,
Alors WordPress 5 inclura Gutenberg en version finale et non béta. Si tu veux tester la béta tu peux déjà le faire sous forme de plugin.
Le Drag and Drop de blocs pour les réordonner est prévu mais pas quelque chose comme le grid layout dans cet exemple, ça peut faire un bon bloc container custom.
Merci pour ta réponse.
As tu une idée sur le mois de sortie de WordPress 5 en version final ?
Certain disent vers avril d’autres plutôt vers juin ou juillet
Il n’y a pas de date figée pour la sortie de la 5. Mais disons que c’est prévu vers Avril/Mai pour le moment en sachant qu’en réalité ça attendra le moment ou Gutenberg est finalisé quoi qu’il arrive.
Hello. Great piece of information. I’m working as working executive in a company Best WordPress development company This blog updates me regarding Gutenberg customization. Thanks
Gutenberg seems to be promising but when we enqueue script with enqueue_block_editor_assets or enqueue_block_assets does it enqueue the file only if it’s not already enqueue or does gutenberg block enqueue the same file every time.
If it’s done everytime it could be a problem when we use a block multiple time
If you register and enqueue your script, it’s only loaded once
Hi Riad
Thanks for your work in gutenberg development.
Wish it would be included soon to wordpress. I’ve heard there will be a button in the next release which allow to test gutenberg.
I play with gutenberg these days and I’ve a question
I’ve try to add a block button in order to duplicate blocks but the question is how to relate each new block to inspectorcontrol ? I’ve link you the code here: https://gist.github.com/robbisy/3cd375cc7a326fc8d36822cce640ab89
There’s already a button to duplicate any block in the menu shown at the right of each block. If you want to do the same in a regular block, you can try to use the `insertBlocksAfter` prop you receive in the `edit` function. Not sure I understand the question exactly though.
Is there something like wp_list_categories in gutenberg ?
I’m trying to create a multi select categories using https://github.com/JedWatson/react-select
but I don’t know how to populate the option with the list of categories
https://github.com/JedWatson/react-select#usage
name=”form-field-name”
value={selectedOption}
onChange={this.handleChange}
options={ wp_list_categories}
Yes, you can use the `select( ‘core’ ).getCategories()` selector. Check the README of the data module to see how to use selectors using `withSelect` https://github.com/WordPress/gutenberg/tree/master/data