How WordPress Evolved in 2017

The year 2017 is drawing to a close, and this year WordPress saw 11 public releases, and 11 beta or release candidate versions. Those of us close to the WordPress community may be noticing that the world of WordPress seems bigger and wider, in a way. What happened to WordPress in 2017? Many tiny changes built large milestones in the thought leadership behind WordPress.

Read on to learn how WordPress silently transformed in 2017.

Supporting innovation for the developer

This year WordPress forged two distinct paths of improvements: those for the WordPress developer, and those for the editor. For the developer, the improvements to the REST API have been key. The users of this generation are demanding more and more from websites in terms of speed and agility–more than a site built solely on PHP can provide. And beyond that, there are integrations to consider. Both the eCommerce site that has a mobile app and the magazine that has a presence in print and in online engagement are innovating to create new solutions for their end users. Headless WordPress is on the rise, and that means the heavy use of APIs (the REST API in particular) is rising with it. So what did WordPress do with the REST API this year?

• December 2016 brought REST API endpoints for content in WordPress 4.7 “Vaughan”
• January 2017 brought a security update patching a bug which exposed author information.
• In April 2017 WordPress released improvements to the REST API when fetching multiple terms and users, and for users in other time zones.
• May of 2017 brought fixes which allowed developers to connect to multiple endpoints at once.
• WordPress 4.8 “Evans” introduced a base media widget REST API schema which could be built into more media widgets in June 2017.
• In August 2017 the release of 4.8.1 brought more improvements to the handling of REST API data, images, and tokens.
• And finally, November 2017 brought WordPress 4.9 “Tipton” which introduced many improvements to the Customizer, including the Customizer JS API.

Opening the door for rich content

For the editors and content creators, WordPress has undertaken the largest project since its inception: the Gutenberg editor. Some have described this shift as making up for a technical debt of its past.

I like Matías Ventura’s description of Gutenberg as the Ship of Theseus or the task of fixing the boat as it is sailing. As WordPress continued to grow and innovate, the editor did not. As a result, plugins and themes have grown to depend on a shaky foundation of shortcodes and page builders. The new editor is created with the intention of making the editing process more enjoyable for those who write content. Gutenberg sets out to reconcile the disconnect between back-end editing and front-end appearance, allowing content creators more freedom to create rich, engaging posts.

WordPress has worked with a massive number of community members and contributors in making this new editor, and for good reason. The uses for WordPress these days are so versatile that no matter what changes are made, inevitably some things will break. In particular, shortcodes and page builders may break simply by nature of this drag-and-drop style of editor. The editor is available as a plugin for all to use and review right now, with over 500 downloads per day on average. Before it became available in June of 2017 as a plugin it had already undergone 6 months of development and since then it’s seen 25 updates. Let’s look at that timeline:

• June 16: v0.1.0 – initial release as a WordPress plugin
• June 23: v0.2.0 – Added blocks and various fixes
• June 30: v0.3.0 – More formatting fixes and buttons added
• July 8: v0.4.0 – Further support for APIs and improvements for server-side parsing
• July 14: v0.5.0 – Added functionality and support for multiple browsers and platforms (mobile)
• July 28: v0.6.0 – Additions for further rich content and UI experience
• August 4: v0.7.0 – Accessibility and UI improvements
• August 4: v0.7.1 – Hotfix for Jetpack’s contact form
• August 11: v0.8.0 – New blocks for different media and text types
• August 18: v0.9.0 – Improvements in customization for blocks and colors
• August 29: v1.0.0 – Improvements to drag and drop elements and dropdown menus
• September 5: v1.1.0 – Handful of fixes and improvements for block interactions
• September 27: v1.2.0 – Added word and block counts
• September 27: v1.2.1 – Hotfix for blocks that were unclickable
• October 4: v1.3.0 – Cleanup of appearance and descriptions for blocks
• October 10: v1.4.0 – Initial REST API structure for reusable global blocks
• October 24: v1.5.0 – Added metabox support to support existing metaboxes natively
• October 24: v1.5.1 – Hotfix for Firefox resizing
• October 25: v1.5.2 – Hotfixes for classic editor redirect issues
• October 31: v1.6.0 – Performance fixes as well as support for converting classic blocks to Gutenberg blocks
• November 2: v1.6.1 – Ability to paste shortcodes and auto-transform block
• November 15: v1.7.0 – Improvements for block extensibility with filters and hooks
• November 28: v1.8.0 – Fixes and improvements for shortcode handling
• November 29: v1.8.1 – Added ability to switch published post back to draft status
• December 11: v1.9.0 – Exposing available hooks and reusable global hooks
• December 13: v1.9.1 – Fixes for Firefox and Yoast

These releases signify a massive community effort in making Gutenberg all it should be. Around the community, there is agreement that an improved editor is highly needed, but the discussion surrounding how it should be implemented is highly divided.

An interesting quandary

What strikes me as most interesting between the two paths WordPress has forged is, they haven’t quite found a way to reconcile both paths. As Chris Lema points out, “Didn’t we want to tell the world that WordPress was more than just for bloggers?” Many echo this sentiment, saying this massive redesign of the editor is in stark contrast to the path that the REST API paved out for developers. The REST API allows developers to compete in an ever-innovating, mobile-driven world. And yet, Gutenberg doesn’t really play nice with the REST API, at least not yet.

Gutenberg-generated pages include CSS and JavaScript, and that means developers either have to include the Gutenberg CSS on their JavaScript front-end or write their own CSS to match the Gutenberg styles. Some suggest that including the CSS inline would be the ideal, REST API friendly way to resolve these conflicts. What we do know is that the Gutenberg team does intend to resolve these roadblocks. Their GitHub page specifically says, “Looking at the full editor screen also gives us the opportunity to drastically modernize the foundation, and take steps towards a more fluid and JavaScript-powered future that fully leverages the WordPress REST API.”

Team players

The other marked shift that struck me this year was the great efforts being made (for both the developer and editor) to enable team workflows. As WordPress has grown to power 29 percent of the entire web and 54 of the top 100 websites, there has been a clear need for WordPress to be friendly to teams of developers, editors, and decision makers for sites.

WordPress 4.9 brought some very beneficial changes for teams, like the ability to save design changes as drafts, and error checking for code changes. And, the REST API brought opportunities for teams to extend the normal WordPress capabilities by branching out into Headless WordPress sites or Progressive Web Apps.

Marked maturity

If you’ve been watching the WordPress core developers, you might have also noticed that the release schedule has matured over the last couple years. Of 22 total WordPress releases in 2017, 11 of them were beta and/or release candidate versions for developers. The team releases security and maintenance updates quickly and without issue, in partnership with HackerOne. And they release the functional updates when they know the community is ready for them, dropping two or more beta release candidates before the update is released to the public.

It used to be that rain or shine, whatever could be pushed out would be pushed at the predetermined date and time. The maturity of the WordPress core team’s release schedule speaks to the maturity of the open-source software itself and its capable developers.

What does the future hold?

The future of WordPress seems ripe with opportunity. At every turn, changes are made with the interest of supporting the future of digital experiences. Making team workflows easier has piqued the interest of more and more enterprise-level businesses, and the REST API and Gutenberg have opened the door for a wider audience of users across the web.

The State of the Word 2017 brought announcements of project Tide, with automated tests for every plugin and theme in the WordPress directory. And there was also mention of their partnership with HackerOne, a network of hackers finding and reporting vulnerabilities for the greater good.

In the future, I also anticipate more REST API endpoints, ease of use for authors to create rich and engaging content, and more innovations toward engaging experiences for mobile and tablet users. I expect to see the disconnect between Gutenberg pages and the REST API resolved before WordPress version 5 is released. And last, I expect WordPress to extend its core codebase for extended baked-in functionality–functionality for which users previously had to add plugins and shortcodes. Yes, the future of WordPress is rich with potential. I can’t wait to see what comes next.