Matt Mullenweg Announces Tech and Design Leads for New Focus-Based Development Cycle

photo credit: Angelina Litvin

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.

28 Comments


  1. 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.

    Report


  2. He believes the best approach is to create the new editor within the Customize API, giving it live previews from the start.

    I think that Nick isn’t saying we need a new editor but rather a new editor experience. I interpret this to mean that I think that the more we can treat “the Editor” as a component rather than the admin screen the better. We should be able to instantiate a TinyMCE editor anywhere to manipulate content and content blocks, whether this be on the admin screen or in the customizer. For example since Shortcake integrates with the TinyMCE editor then the Post Elements interfaces it provides then (mostly) automatically become available to the TinyMCE editor embedded in the customizer via the Customize Posts plugin.

    So the Editor component should be appear on the admin screen and on the frontend (with customizer bootstrapped). When you do “Preview” from the edit post screen this should take you to the frontend with the customizer bootstrapped so that not only can you preview the changes you made on the edit post screen but you can also continue to edit changes in that context and see the additional changes live. This is implemented today in Customize Posts.

    Report


    1. 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. …“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”

      As I’ve written before, the customizer is already a modern JavaScript single-page application. We can definitely iterate on the customizer UI to make use of React but this would be an incremental (2x) improvement over the current customizer, whereas the technical improvements of Calypso over the WP Admin are much greater (likely on an order of magnitude). In either case, however, I think that the future admin should be built on top of the Customize API so that every change can be previewed, drafted, batched with other changes, and scheduled. Building on top of the Customize API certainly doesn’t exclude building on top of the REST API. In fact, as of 4.7 the two are designed to work together so that you can apply the customized state to REST API responses. And as demonstrated in Bridging the Customizer and the WP REST API, REST API schemas make it possible to automatically add new resources to be edited and previewed in the customizer for free.

      Report


      1. Perhaps WP should not put all their eggs in the React basket when Vue.js gained huge momentum in 2016 and it’s set to overtake React this year. This is an interesting report

        Report


    2. Correct. If the editor itself is more modular and built in a way that it can work within the frontend context, it would be easier to include in places like the customize preview and integrate with the customize API that way. I’d certainly use a live-preview-based editor much more than something in a distinct “admin” context, but it’s probably necessary to keep both at least in the near future.

      Report


      1. Listen to Nick Halsey y’all. Building a new editor around the customize API is the best way to get instant previews, modularize the system, and finally adopt an editor that’s built for WP.

        Report


      2. but it’s probably necessary to keep both at least in the near future.

        I think it’s DEFINITELY necessary to keep both and probably forever. If both are available, WP users will use what works for them.

        Report


  3. So basically they are turning away from a predictable Ubuntu like release cycle to a Debian like cycle. I am not sure this will be a good thing at all

    Report


  4. Seriously WordPress core has screwed priorities.

    Instead of building a better engine they are trying to improve the dashboard.

    Report


    1. What makes you think that, Pete? What would “building a better” engine look like to you?

      Report


    2. Isn’t improving the engine what the REST API was ultimately trying to improve?

      Like, since that is now in core: it’s time to fix the user experience?

      Maybe I’m interpreting it wrong.

      Report


    3. It would seem odd for me to have a content management system run an engine, but if WordPress can be used for weapons systems, I guess it could be used for anything.

      Report


  5. Some “engine” based improvements would include:

    Improve db schema, make widgets posts (maybe this has been done), custom post statuses, post to post relationships, custom email statuses, user taxonomy support, a messenging queue, better cron, and that is just a start.

    Report


    1. A new iteration on widgets is a top priority for me in 2017. This includes the work to store widgets in a custom post type instead of options (see #35669), and also to provide REST API endpoints for widgets (see #35574 and #28093).

      Report


      1. It will break backward compatibility so I don’t expect it to happen.

        Anyway, (almost) anything will be better than what is there today, but widgets are not content and don’t belong into the posts table. Anew table or two are needed for widgets and sidebars.. There is no reason to make content retrieval slower because someone added a widget.

        Report


      2. @mark It needn’t break back-compat. The feature plugin (Customize Widgets Plus) that implements Widget Posts maintains back-compat.

        Also, there’s nothing that says that “content” is reserved for the posts table (though I’m not sure what content means)—the posts table is an objects table. Nav menu items are in the posts table and widgets are conceptually very similar. In 4.7 new post types were created for custom CSS and customize changesets.

        Lastly I’m sure that we can store widgets in posts without a degredation to performance if we employ caching.

        Report


      3. @weston since accessing the options directly to have access to some of the widgets information was a necessity, moving that information to another place will break all the code that assume the data is in the options. How many sites will be impacted? from my personal knowledge at least 40k.

        As for posts table being used for non content… well maybe it is time to start treating it like it should be treated and just create new tables if options are bad place for the data.
        In the post table, since there is no autoloading, assuming you have two sidebars, you will need extra 2 (probably 3) DB queries per page load.

        This will bring wordpress into “must have some caching on by default” which should have been part of core long time ago, but it should be implemented before having an architecture which will increase the number of requests.

        Report


      4. @mark k.

        Impact on performance is negligible if non-existent (vs splitting into separate tables). Widgets can share many features that (custom) posts have such as authorship, edit lock, status, scheduling, revisions, api actions etc. As long as the objects take advantage of the same kinds of features, there’s no reason not to use the posts table.

        Built-in caching negates the database query performance penalty. Same should happen for menu items and menus.

        Report


      5. @peter, this discussion is about “should any hack be used till it reaches its useful limit before proper restructuring is done”.

        The idea of using the post tables for all CPTs proven to be non scalable, especially where meta is concerned. In retrospect each CPT should have had its own table and than build views or stored procedures or whatever to handle cross CPT queries. Putting more data into what is already a non scalable place is just a bad idea…. you are likely to just shift the scalability problem from one place to another.

        As for caching, hopefully you are not referring to transients as this will basically pollute the options table and you will end with the same problem you wanted to avoid.

        Report


      6. @mark If you look at the Widget Posts module of the Customize Widgets Plus plugin you can see that the way it works is by hooking into the options API to swap out where the data is coming from. As such, if you call get_option( ‘widget_text’ ) the return value will be sourced from posts and not from options, and plugins that filter options should still apply as expected.

        Report


      7. @weston, Yes I saw it, and it is a hack that should not be in core. get_option is defined to get data from the option table, if it doesn’t, it makes the code harder to read. Tools that have expectations about the actual data structure in the DB will fail.

        More hidden failures will obviously be performance related, as the change is “transparent” code wise, plugin and theme developers will not know that those APIs might be more expensive to use, and will have no reason to fix bad code. (how many queries will be required to do is_active_widget?).

        When speaking about backward compatibility there is a lot to learn from microsoft. For them backward compatibility means that you keep the bugs as well, and if you don’t want them you don’t claim BC.

        You think the current implementation suck? I mostly agree, but the way forward is by deprecating the old code base as it has some core design problems and letting developers to opt in into the new implementation. Current APIs can be extended to support both models, and people that want to access the DB directly will get access to only part of the widgets.

        Report


  6. I am not saying that the customizer and editor don’t need resources. Just they would not be my priority.

    One point though is that given the current goals are mainly front end in theory they should not block back end work being done concurrently

    Report


  7. 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.

    Thank you.

    Report


  8. Regarding where to store widgets (Options, Posts, or a new table): This looks like a good opportunity to use an Object Relational Mapping (ORM) pattern to forever hide these low level schema alternatives from higher level code.

    When the schema and/or higher level object model changes, the Object Relational Mapper(s) would be updated. By this changes in the schema or object models don’t affect the other — but only the mapper in between needs to be updated, thereby greatly localizing (potentially) breaking changes.

    While there are fancy/high price ORM packages, I’ve had great success just hard coding the mappers. While it might be a bit more manual (grunt) work, it’s easy, and the mapping remains performant.

    Report


    1. Actually, no. ORM is not a solution as anything that requires knowledge of a schema is just wrong. There should just be a set of good APIs which eliminate the need for such knowledge from anyone which is not a DB admin or need to figure out obscure scaling problem.

      Report


      1. WC will have CRUD classes in core, so in that use case customers, orders and products can use custom db tables. Then you remove the issue at scale since it is not using posts, postmeta, users and usermeta.

        Report


      2. That is very good news. hopefully this means that wordpress.com VIP no longer objects to creating new tables and will eliminate the need of EDD to store data as comments (I asked Pippin once about it and he gave wordpress.com limitations as the reason)

        Report


  9. I would like to see the ability to delete posts across the network that have the same name. It would also be nice to be able to change other elements like category and possibly content within post.
    Is any of these features especially the first mentioned a possibility within the WPMU platform?

    Report

Comments are closed.