WordPress core development is kicking off in 2017 with the new focus-based development process that Matt Mullenweg announced during the 2016 State of the Word. The new approach to releases shifts WordPress from the familiar time-based release cycle to one that is more project-based. The idea is that design and user testing will lead the way and upcoming releases will ship when significant user-facing improvements are ready.
Mullenweg, who will serve as the overall product lead for 2017, announced tech and design leads for each of the three focus areas: the REST API, the editor, and the customizer.
“For the REST API we’re going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax,” Mullenweg said. The REST API team nominated Ryan McCue and K.Adam White to take the lead on the objectives Mullenweg outlined, as well as infrastructure and endpoint performance, security, and improvements to authentication options and documentation.
“The editor will endeavor to create a new page and post building experience that makes writing rich posts effortless, and has ‘blocks’ to make it easy what today might take shortcodes, custom HTML, or ‘mystery meat’ embed discovery,” Mullenweg said. Automattic employees Matias Ventura and Joen Asmussen will be taking point on the editor.
The Shortcake UI feature plugin is one attempt at giving the existing shortcodes feature a more user-friendly interface, but contributors are also exploring other ideas for simplifying the experience of adding rich content to posts. Ella Van Dorpe recently posted an idea for using uniform resource identifiers as an alternative to shortcodes in certain use cases. This would work similar to WordPress’ implementation of oEmbed where data is stored elsewhere and embedded in a post using a URL.
Mullenweg’s proposed direction for the customizer team is to “help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization ‘outside of the box’ of post_content, including sidebars and possibly even an entire theme.” Weston Ruter and Mel Choyce will be taking the lead on the customizer focus.
Ruter and contributors have been working on a project called JS Widgets that uses the Customize API to power the next generation of JavaScript-widgets in core. It opens the door for managing widgets via the REST API and ties in nicely with all three focus areas.
A preliminary discussion on upcoming Customizer priorities cropped up in the comments. Nick Halsey, co-maintainer of the customize component, responded to the proposal of having the customizer help out the editor at first. He believes the best approach is to create the new editor within the Customize API, giving it live previews from the start.
“Improving the editor within an ‘admin’ interface that lacks live preview doesn’t address the fundamental problems with the current content editing experience and creates something that still has to be entirely rebuilt and reimagined within a live preview context eventually,” Halsey said. “If the editor is built on the Customize API first, rather than rethinking the editor and then bringing it into the live preview API, the customize and editor contributors would be able to join forces to focus on improving the content editing experience much more effectively.”
It will be interesting to see what direction Mullenweg and the leads decide to take in the foundational task of architecting the new editing experience. Mullenweg made it clear in the State of the Word address that he would like to see Calypso or a similar interface replace wp-admin in the future. However, Calypso was not built using the Customize API, WordPress’ own single page application admin interface that plugins and themes already widely support.
After WordCamp US, I asked Mullenweg about his intentions for Calypso in relationship to WordPress core. He said the application was “designed to be in core someday,” which is one reason they selected the same license and made it open source.
“My real hope is that it is something that is ready for core someday – both Calypso the interface and the concept.” Mullenweg said. “That’s why I said Calypso or something like it. There’s obviously a lot of WordPress.com stuff in Calypso that will never be in core. If we think of a wp-admin replacement, it would be replacing wp-admin with the parts that Calypso does that are the same thing, kind of more of the my sites section of it. But I do believe the future of a great wp-admin experience is JavaScript – probably React, talking to APIs, super fast, and maybe even working offline.”
Automattic is actively recruiting popular plugin authors to make their plugins Calypso-aware. Demonstrating the application’s interoperability with the WordPress plugin ecosystem is a must before Calypso can be considered a promising replacement for the WordPress admin. In the meantime, the foundation for a new page and post building experience is being laid with consideration for how the customizer can improve the editor.
Mullenweg responded to comments on the post indicating that feature plugins or other improvements to WordPress outside of the three focus areas would need to continue on as plugins for the time being. However, performance improvements may be included in minor releases.
“What goes in a minor release will broaden a bit, which I know is something we have to approach carefully, but performance is very important and improvements will be something I will consider for being in a minor release,” Mullenweg said. Contributors are currently working on WordPress 4.7.1, which is planned for release on Tuesday, January 10.
I think one of the goals this year for customizer will be for there to be a unification of the things you can do in the editor (for post content) vs the things you can do in the customizer (outside of post content). My hope is that this proposed next generation of widgets, JS Widgets, can serve as a foundation for powering a common Content Blocks interface that can appear as shortcodes in post content or as widgets in the sidebar. Nav menu items should also be unified with widgets so that whether you have a nav menu location, a dynamic sidebar, or post content—all of these areas are just containers for Content Blocks. This being the case, I think that Content Blocks is an excellent are of overlap between the editor and the customizer which can be worked on concurrently. I think the Shortcake plugin provides an excellent starting point for Content Blocks in the editor, and I want to start integrating JS Widgets as Post Elements so that widgets can seamlessly be used in post content.