J’ai eu l’honneur de donner un nouveau talk sur Gutenberg au WP Tech Lyon. De nombreux talks ont été donnés sur Gutenberg, le pourquoi du comment, ce que ça change pour les utilisateurs mais peu de talks ont abordé les dessous de Gutenberg, son architecture et ce que ça apporte au développeur de thèmes de plugins et aux développeurs JavaScript en général.
Au cours de ce talk, nous avons suivi les différentes étapes pour le développement d’un plugin Gutenberg WordPress en utilisant les différents modules mis à notre disposition.
Le résultat est un plugin plutôt utile qui permet d’insérer des photos Unsplash.com directement depuis la sidebar de Gutenberg.
Drop It Plugin
Télécharger ce plugin depuis le repository WordPress.org et survoler son code source sur GitHub.
Un grand merci aux organisateurs et bénévoles, c’était vraiment un évènement très réussi. 👏🏻
J'ai aussi eu la chance d'animer un atelier sur l'extensibilité de Gutenberg dont voici les slides et le repository GitHub qui contient les exemples exposés.
What are the next battles we should take to improve WordPress technology and workflow? What should we do next?
I've been part of the WordPress community for more than a year now, which is really short in WordPress time, but I truly love this community and I hope to contribute for several more years. This year has been amazing in terms of Development and Workflow evolutions in the WordPress community, partly pushed by Gutenberg. Let's continue modernizing WordPress!
In this very subjective post, I'm going to list some of the battles worth considering for the future of WordPress. No battle is easy, but remember:
we're on a marathon not a sprint and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day.
Git and GitHub
Trac served WordPress very well, it centralizes all discussions and patches in one consistent place, but is it the right tool for a large Open Source project in 2018? Is it time to move to something else?
A new generation of developers works exclusively on Git and GitHub. Casual contributors won't invest time to learn a tool not used in any other place (I'm probably exaggerating a bit here) just to submit a small PR/patch. And often these casual developers evolve to become regular ones.
With Trac, the barrier for the first contribution is huge and projects like the REST API already showed that merging these feature projects into Core (which also means moving from GitHub based workflow into Trac) leads to a big decrease in terms of contributors and contributions.
Yes, this is not easy as Trac holds a big history of conversations and patches, we probably have several processes and scripts based on Trac, but it's definitely worth a battle, WordPress will benefit from the same dynamic/contributions around Gutenberg for all its components.
Deprecation strategy
This is going to be controversial. When it comes to backward compatibility, WordPress is unique. It's the only software where you can skip 9 major versions, update to the last version and your website still works (mostly). While this is huge in term of stability and confidence in the future, this philosophy of "always maintaining backward compatibility" has limits.
First, every version of WordPress comes with some "small" backward compatibility breakage but it's really hard to know where to draw the line. It's not clear which things we can never break in releases and what is an "acceptable" backward compatibility breakage.
Also, this obsession to always maintain backward compatibility is not serving the code base of WordPress. Each new version adds new APIs, duplicating and enhancing some existing APIs but not removing any old API (with some "acceptable" exceptions). This affects badly the performance and the size of WordPress. And gives this feeling of heaviness WordPress suffers from.
Can't we have the best of both worlds? A way to upgrade from old versions safely and a way for developers to deprecate and remove features, APIs from WordPress?
I'm certainly not the first one to propose something like this but I'm curious to know why can't we achieve this "coherent" deprecation strategy:
Plugins should explicitly declare WordPress versions support. There's already the "tested up until" field for Plugins. It should be blocking which means if you have a plugin that does not have a compatible version with the latest WordPress release, you can't upgrade unless you disable this plugin.
Upgrading to the latest version also updates the plugin that needs to be updated to work with this last version.
Transition periods where the old API and the new ones are available at the same time.
Tools and APIs to allow developers to declare "deprecated APIs" to warn plugin authors about the need to update their plugins.
Can we also consider "SemVer" for WordPress and Plugins?
Granted that this will be a fundamental change in WordPress's philosophy, but I think a change like that is necessary for the future of WordPress.
PHP version of course
I believe the work to achieve this has already started but yes we need to update the minimal PHP version required to run WordPress. This will not only improve the developer experience in WordPress Core but improve the security and performance of all WordPress websites.
I'm not heavily aware of the current efforts (as I'm not very engaged their as well). I know a field to require a minimal PHP version has been added to plugins, but we can do the same for WordPress releases. We can disable upgrades if we detect an incompatible PHP version.
I'm optimistic about this specific point, I believe we'll achieve this soon enough. But we should also work on the deprecating and upgrade strategy to allow us to continue doing this (updating the minimal version) in the future.
Stop arguing about Code Style and go standard
Developers in general (and WordPress ones confirming the rule) like to argue about code style and personal preferences. WordPress cares a lot about tabs and spaces around parenthesis and semi-colons… Why? Can't we stop caring and arguing about this, can we just follow a standard and stop talking about this? Let's focus on the code itself, let's add `prettier` to auto-format our code. We'd be consistent across our code and consistent with the outside community.
Languages like Rust, or Go successfully unified the code style using built-in tools and prettier is trying to achieve the same thing for JavaScript and PHP. Hundreds of open source projects are already using it.
WordPress code is not special.
Ifprettier is producing readable and consistent code for millions of developers, it can do so for WordPress developers as well.
Yes, this means huge commits to apply this the first time which may affect the history, but we already did this before using phpcs. Worth a battle!
GraphQL, why not?
Among developers, WordPress is often considered as "oldish technology". What if we change that? What if WordPress becomes this hype technology everyone talks about? For this to happen, the WordPress codebase need to be modernized. In addition to the PHP upgrade, the gradual switch to an SPA, WordPress can improve its "headless" capabilities by adopting `GraphQL`.
WordPress has been slow to adopt the REST API and it's not really a success as its usage has not seen this big increase we hoped for when merging into Core. REST APIs based applications can suffer from performance issues, especially if you want to query a lot of "related" data. How can we fix those?
In the last years, the web saw the rise of GraphQL. A Graph-based query language to provide data through an HTTP server. There are several advantages of this approach and developers in the WordPress community understood this. Plugins like WPGraphQL already do a great work exposing WordPress data though GraphQL with the extensibility expected from any WordPress feature. Can't we merge this (or an alternative) into Core to make it available to everyone?
As we move towards client-side UIs in WP-Admin aswell, this will help us a lot bringing consistency, performance and a good DevX (Declarative components) to our code-base.
Development Workflow
Another controversial point. WordPress has a relatively small group of Core
commiters allowed to commit patches proposed by anyone. This gives a huge responsibility to this
commiters when reviewing patches. This is good, it ensures that only high-quality (hopefully :P) patches get merged. But this has a perverse side-effect: In order to merge your patch, it has to be perfect which means often months of work for small features or bug fixes. I love iterations, I believe we can achieve way more by being a bit more flexible.
Let's merge unpolished features hidden behind feature flags.
Let's be less perfectionist. Better is the enemy of good.
Let's merge unpolished smaller patches. Reviewing several small patches is way more efficient and faster than reviewing one huge patch.
I admit this philosophy can create some unpolished code from time to time but I do believe we have the same problem with the current stricter approach without the benefits of faster iterations.
Documentation
WordPress has a lot of documentation but How hard it is to find what you're looking for? The fact that this documentation is often built in silos (featured plugins or separate teams) and then merged into WordPress.org leads to this situation. If you navigate through the documentation, there are at least three different "styles" of documentation pages you can go through.
I know the documentation team is spending a lot of time trying to improve the experience but often, it's hard to step back and think about the whole picture. I believe the only way to fix the documentation is to rethink it entirely from scratch. Some ideas include:
There are several types of documentation but all of them should merge into a unique experience:
Generated documentation (PHPDoc, JSDoc)
Developer documentation (often written in markdown)
End User documentation
Should we use WordPress to document WordPress? I don't think so, can't we build a WP documentation tool with the following features:
Support markdown.
Documentation as
code (live with the code).
Support i18n.
Coherent
themable stylesheets.
Usable separately by plugins and featured-plugins (which makes merging into Core consistent).
NPM Like plugins/themes registry (CLI based)
Plugins and Themes proposals, reviewals and updates are handled using a centralized SVN repository and a lot of processes (manual or semi-automated).
Themes submissions can take months, plugin submissions weeks. I believe this aspect of the WordPress community can be made more efficient. If we have to rethink the way the repository work today, how can we make it better. What can we automate? What should stay manual? Is the SVN repository a good solution to host plugins and themes in 2017?
Nowadays, most plugins and themes have separate Git repositories and use the SVN repository only to update and tag new versions, this makes the SVN repository useless. What if we build an NPM-like CLI with commands like.
wpr check To check the validity of the theme/plugin (code styles, tide check…)
wpr login To login (required to submit plugin/themes)
wpr publish To submit your plugin/theme to the repository
…
I would love to use such a tool ❤️
Conclusion
This is not an exhaustive list and it's very subjective and there are probably some existing projects addressing some of these issues. I'm just trying to think about the whole picture. And you, what battle do you think we should take?
A special thanks to all WordPress contributors (Documentation, A11y, Plugins, Themes, i18n, Development…) I'm very grateful to be part of this community, I've learned so much during this year among you all.
Developers and web agencies make extensive use of Custom Fields to add structured data to their Custom Post Types (and regular post types as well).
By leveraging the Meta Box API, plugins like ACF, CMB or Pods Framework address this concern. They all work similarly: you define fieldsets, a list of fields with different types and configuration where fields can be text, images, galleries, HTML editors, etc. Once you open the editor's page for the assigned post type, it's initialized with a list of Meta Boxes allowing you to fill the content of these fieldsets.
Gutenberg, the new WordPress Editor, aims to change the way we create content in WordPress. And without a surprise, this could have some impacts on these plugins. Legitimately, developers and users shared their concerns about the way this would impact their existing websites.
How does Gutenberg address this? Will these
MetaBoxes work in Gutenberg?
Short answer: mostly yes!
Long answer: due to the fact that the Meta Box API has no restrictions, plugin authors started using this API in all sort of ways, using selectors to reach DOM nodes displayed in the editor page, relying on DOM events not officially stated as official extensibility APIs etc., which means any change made to the editor's page can break existing Meta Boxes.
So the idea here is to try to limit the breakage as much as we can. Globally, the plugins listed above work in Gutenberg but some of their field types may break, in particular, the field types heavily relying on JavaScript DOM events and/or the TinyMCE API. If you experience a breakage for a specific field type, please open an issue.
Plugin authors might not have the time to update their plugins if there are incompatibilities, so Meta Boxes can also opt out of Gutenberg leading WordPress to fall back to the classic editor.
If you're a plugin author working with Meta Boxes I invite you to take a look at the handbook page describing how to test, convert and maintain these.
Aren't those Custom Fields Meta Boxes just blocks anyway?
The main goal of Gutenberg is not to replace the editor. This was commonly misunderstood, and thus it was hard to see why we'd want to emphasize blocks instead of just relying on existing APIs. But the real goal of Gutenberg is way bigger, it's trying to change the way we create content in WordPress in general around this unique concept of Block. The final user does not have to learn about all these concepts: Shortcodes, Widgets, Menus, TinyMCE, Meta Boxes to understand how to create and edit content in WordPress. It might seem natural to someone already familiar with WordPress but newcomers are struggling to juggle those and often prefer simpler alternatives offered by Wix, Squarespace, and others. (If not convinced, I encourage you to see this talk)
So how can these custom fields relate to blocks? If you think about it, a custom field is nothing more than a block saving its content
to post_meta andthat's already possible in Gutenberg.
And with the new Gutenberg Template Feature, you can provide a Post Type with a list of blocks that will be automatically added when the user creates a new post. Templates can also be "locked" which means the user can't add/remove new blocks or move existing blocks.
With the combination of the blocks saving to post meta and block templates we can pretty easily recreate what the custom fields plugins are offering: a way to structure the post's data.
Demonstration
To demonstrate this, I created a plugin called Gutenberg Custom Fields which offers the exact same experience the plugins listed above provide (an admin page to create and assign fields to a post type) using Gutenberg Native APIs.
Demo of Gutenberg Custom Fields
In fact, I think most of these plugins will certainly upgrade to these new APIs to provide a smooth upgrade path for their existing users.
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,
VueJS VS React VS Preact)
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.
