Historical article . References to tools and versions reflect the time of publication.
The improvements appeared to fall into two main categories: those for developers and those for editors.
Let's take a detailed look at what happened with WordPress in 2017, specifically for both development directions:
Improvements for Developers
In 2017, improvements seem to have followed two paths. The first makes life easier for developers and the second for editors. For developers, REST API improvements were crucial. These days, users increasingly expect speed and agility from the sites they visit. 'Headless WordPress' has already begun to trend, making the REST API increasingly important too. Let's examine the REST API improvements over the past year in detail:
- December 2016 – WordPress7 “Vaughan” now comes with REST API endpoints for posts, terms, users, meta and settings.
- January 2017 – The launch of security update which fixes an issue relating to author information
- April 2017 – NewREST API improvements for searches involving multiple terms and users, as well as users in different time zones.
- May 2017 – Fixes that allow developers to connect to multiple endpoints at the same time.
- WordPress8 “Evans” release, which also includes a base media widget that uses the REST API schema
- August 2017 – Release of version 4.8.1 withseveral improvements to the way REST API data, photos and tokens are handled.
- November 2017 – WordPress9 “Tipton” release, with several Customizer improvements, including the brand-newCustomizer JS API.
Improvements for Editors
The biggest undertaking since the founding of WordPress is here, and its name is project Gutenberg.
Matias's description of project Gutenberg includes a Greek reference, comparing it to the ship of Theseus.
Project Gutenberg set out to fill a major gap in WordPress for editors. The truth is that while WordPress continued to develop and innovate, its editor did not. As a result, plugins and themes proliferated and became dependent on shortcodes or, even worse, required intervention from the website's creator for simple tasks.
Gutenberg was created to make editing text more enjoyable for those writing content. It aims to bridge the gap between backend editing and frontend appearance, giving content creators more freedom to produce better content.
Creating it required collaboration with a huge number of community members and countless contributors. Gutenberg is available as a plugin for everyone to use, with over 500 downloads a day. Before becoming available as a plugin in June 2017, it had already undergone 6 months of development, and since then it has received 25 major updates. Let's look at them in detail below:
- 16 June: v1.0 – Initial release as a plugin 23 June: v0.2.0 – Addition of blocks
- 30 June: v3.0 – More formatting fixes and addition of buttons
- 8 July: v4.0 – Server-side fixes and additional API support
- 14 July: v5.0 – Support for multiple browsers and mobile platforms
- 28 July: v6.0 – Additions relating to content and user experience
- 4 August: v7.0 – Accessibility and UI improvements
- 4 August: v7.1 – Hotfix for the Jetpack contact form
- 11 August: v8.0 – New blocks for different media and text types
- 18 August: v9.0 – Improvements to block and colour customisation
- 29 August: v0.0 – Improvements to drag and drop and dropdown menus
- 5 September: v1.0 – Fixes and improvements to block interactions
- 27 September: v2.0 – Addition of a word and block counter
- 27 September: v2.1 – Hotfix for unclickable blocks
- 4 October: v3.0 – Cleanup of block appearance and descriptions
- 10 October: v1.4.0 – Initial REST API structure for reusable global blocks
- 24 October: v1.5.0 – Native support for metaboxes in existing metaboxes
- 24 October: v5.1 – Hotfix for screen resizing in Firefox
- 25 October: v5.2 – Hotfixes for classic content editor redirection issues
- 31 October: v6.0 – Performance fixes and support for converting classic blocks into Gutenberg blocks
- 2 November: v6.1 – Ability to paste shortcodes and automatically convert blocks
- 15 November: v7.0 – Improvements to block extensibility with filters and hooks
- 28 November: v8.0 – Fixes and improvements to shortcode handling
- 29 November: v8.1 – Added the ability to change a published post to draft status
- 11 December: v1.9.0 – Hooks and reusable global hooks
- 13 December: v9.1 – Fixes for Firefox and the Yoast SEO plugin
The releases above resulted from an enormous community effort to make Gutenberg what it is today. The only dark spot is that, although the whole community broadly agrees that an improved editor is needed, there is no such agreement on how it should be implemented.
What this approach to development produces
It is remarkable that no way has been found to reconcile these two development directions. During the year, Chris Lema asked, “Didn't we want to tell the world that WordPress was more than a platform for bloggers?” Many argue that the focus on redesigning the content editor stands in direct opposition to the path the REST API opened for developers.
The REST API gives developers the opportunity to create more and more innovations in a mobile-first world, theoretically the world of tomorrow, yet Gutenberg is not fully compatible with the REST API, at least so far.
Pages created by Gutenberg include CSS and JavaScript, meaning developers must either include Gutenberg CSS in their JavaScript frontend or write their own CSS to match Gutenberg's styles. Several people argue that including inline CSS would be the best, most REST API-friendly way to solve this problem. What we know is that the Gutenberg team intends to resolve these development roadblocks, but they remain unresolved so far.
As one team
Another noteworthy aspect of the past year is the substantial effort made to make workflows easier for both developers and content editors. Since WordPress powers 29% of the entire web and is behind 54 of the top 100 websites, there is a clear need for it to be friendly to development teams and editors. Once again, the community worked as one large, united team.
WordPress 4.9 brought very useful changes for both groups, such as saving design changes as drafts and error checking for code changes. The REST API, in turn, gave these teams opportunities to turn a normal WordPress installation into a Headless WordPress website / Progressive Web App.
With maturity
If you follow the WordPress core developers, you may also have noticed that the release schedule has matured over the past two years. Of the 22 total WordPress releases in 2017, 11 were beta and/or developer releases. The development team launches security or maintenance updates promptly and without problems, in collaboration with the HackerOne. They release updates when the community is ready for them, always preceded by 2–3 beta releases.
The future
The future of WordPress clearly looks mature. At every opportunity, changes are made to support future technologies and forward-looking digital experiences. Easier team workflows make it increasingly interesting at enterprise level, while the REST API and Gutenberg have opened the door to a broader range of uses.
The State of the Word 2017 recently announced something equally interesting for the future: the project Tide, which will use automated testing for every plugin and theme in the WordPress repository. A partnership was also officially announced with HackerOne – a network of hackers that will try to make WordPress bulletproof.
Our personal hopes for the future include more REST API endpoints and more innovations in the experiences offered to mobile and tablet users. Naturally, we expect the gap between Gutenberg and the REST API to be resolved before WordPress version 5.
Finally, we would like to see WordPress incorporate many third-party functions, currently provided through plugins and so on, into its core functionality, offering extensive capabilities from the first moment without dependencies.
One thing is certain: we are all looking forward to a wonderful 2018, with amazing surprises in our favourite CMS.
