State of the Word 2016: Mullenweg Pushes Calypso as Future of WordPress’ Interface, Proposes Major Changes to Release Cycle

photo credit: WordCamp US organizing team
photo credit: WordCamp US organizing team

Philadelphia welcomed 1,923 attendees to WordCamp US this weekend with an additional 2,028 enthusiasts watching via live stream. Matt Mullenweg delivered his 11th annual State of the Word address to a rapt audience ready to celebrate WordPress’ progress over the past year and hear the project leader’s vision for 2017.

He began by thanking sponsors and volunteers who made the event possible by covering the bulk of the $516 actual cost per person. Mullenweg said sponsors cover roughly 85-95% of the cost of WordCamps worldwide. In 2016, the events sold a total 36,000 tickets, with costs subsidized by more than 1,000 sponsors.

Mullenweg said meetups are the leading indicator for WordCamps and these events have had the fastest growth the community has seen in five or six years. More than 62,566 people attended a local meetup in 58 countries and roughly one third of those were new members.

WordPress Foundation to Create WordPress Community Support Subsidiary

In order to better accommodate the extraordinary growth of the global community, the WordPress Foundation will be restructuring its management of WordCamps. In 2016 the Foundation took in an estimated $4.3 million, up from $2.8 million in 2015, with 99.9% of those funds related to WordCamps. Mullenweg announced that the 501c nonprofit will move WordCamps to its own company, WordPress Community Support, forming a PBC (Public Benefit Corporation) that is fully owned by the Foundation.

He explained that if certain things happened at WordCamps it could endanger the overall Foundation, so WordCamps will now be managed under their own entity where the events will have a little more flexibility in how they do things. The Foundation plans to support some like-minded nonprofits that are aligned with the overall education mission of the organization, including Hack the Hood, Internet Archive, and Black Girls Code. In 2017 the Foundation will also begin promoting hackathons to help nonprofits and NGO’s.

Internationalization is Driving an Increase in Plugin Usage

Mullenweg shared a few stats about the plugin directory, which will soon be launching a new design with revamped search functionality. This year has seen a 20% increase in active plugin usage and a 34% increase in plugin downloads totaling 1.48 billion, which Mullenweg attributed to a spike in internationalization efforts over the past year. The number of translation contributors has grown from 5,000 in April 2015 to 17,000 as of November 2016.

This year there were 1,598 plugins with language packs (up from 314 last year) and 1224 themes with language packs (up from 641 last year). Mullenweg noted that 2/3 of the world speaks one of 12 languages with native fluency and that WordPress covers all of these and many more. In fact, the 4.6 release shipped with support for 50 available languages. WordPress’ top 10 plugins are now 82% complete in the top 12 languages.

Mullenweg Continues to Push Calypso as the Future of the WordPress Interface

During the 2015 State of the Word, Mullenweg gave attendees a homework assignment to “learn JavaScript deeply” and promised to submit a JavaScript patch before 4.7 came out. He submitted his first pull request to Calypso yesterday, Automattic’s from-scratch rewrite of WP admin using Node and React.

WordPress.com users have widely adopted the new interface for publishing. Mullenweg shared statistics showing that 68% of posts went through Calypso since its launch, 17% via mobile, and 15% through the traditional wp-admin. Mobile app and mobile browser usage are also up. “We now need to start thinking about mobile devices as the primary way people are going to interact with WordPress in the future,” Mullenweg said.

From the time it launched, Mullenweg has said that Calypso, or something like it, would be the future of the WordPress interface. He reiterated this in his 2016 address and has committed some of Automattic’s JavaScript developers from the Calypso team to contribute full-time to core.

If Calypso has a chance at becoming a promising replacement for the WordPress admin, its creators will need to broaden its interoperability with the WordPress plugin ecosystem. Mullenweg announced that Calypso is now plugin aware and is open to plugins with over 1M active sites.

The next step on Calypso’s roadmap is to bring in support for Automattic’s plugins – WooCommerce, Akismet, Jetpack, and VaultPress. Mullenweg said the big focus for 2017 is to make plugins Calypso-aware, starting with a handful of the most popular ones before opening it up to all plugins.

“The hope is that Calypso, or something like it, is actually what becomes the interface that drives WordPress,” Mullenweg said. Since no one is currently building anything like Calypso and targeting core, it looks like the technology behind WordPress.com will be driving the evolution of WordPress in 2017.

If Mullenweg’s goal is to make Calypso the primary publishing engine for core WordPress, one of the major challenges will be getting plugin developers on board with building compatibility for what is currently an Automattic product. What are the implications of contributing to greater Calypso adoption? If core brings in the Calypso interface in the future, would Automattic push to include its Reader and other WordPress.com functionality, as it has in the mobile apps? These are questions developers will need to weigh when considering whether to pursue a more application-type experience via the Calypso interface.

WordPress Recommends Hosts Offering PHP 7+ and HTTPS by Default

WordPress core continues to update its recommendations and requirements with the help of hosts who are adopting the latest technologies. The official recommendation for WordPress hosting is now PHP 7 or higher. After WordPress.com switched to be 100% on PHP 7, Mullenweg said the network’s performance doubled and CPU load fell in half. Just 4% of self-hosted sites are on PHP 7, but the new recommendation should help move more hosts towards getting their customers updated.

Beginning in 2017, WordPress will have progressive enhancement for certain features that are only available for encrypted sites. Mullenweg announced that WordPress.org is now tracking HTTPS adoption. So far 11.45% of active WordPress websites are on HTTPS and the project will no longer recommend hosts that do not offer it by default. “We want to bring more of the web to be secure, which is especially important in the post-Snowden era,” he said.

Trying New Things: Major Changes Coming to WordPress’ Core Release Cycle

WordPress 4.7 release lead Helen Hou-Sandí joined Mullenweg on stage to highlight a few of the features and improvements that will be coming in the official release on Tuesday. The release is arguably one of the most exciting and successful updates for WordPress in some time, but Mullenweg has a new strategy for core development in 2017.

“We’re at a junction for WordPress where what got us here wont get us there,” Mullenweg said, after highlighting how the software’s market share has grown from 13.1% to 27.2% in the past five years.

Mullenweg proposed a new structure for WordPress releases where design and user testing will lead the way. “I’m putting back on the ‘product lead’ hat for 2017,” he said. The upcoming year will have no set release schedule. Mullenweg is upending WordPress’ predictable release cycle in favor of tackling some larger items on the to-do list. He said the focus will be on performance and fixes to existing functionality in three main focus areas: WP REST API, the Editor, and the Customizer.

Mullenweg said he is particularly interested in getting first-party usage of the REST API in the admin, in hopes of having it evolve to something the project can use for the next decade. If it doesn’t, he said core will consider bringing it back into a plugin specifically for developers.

Mullenweg said he feels the editor does not represent the core of WordPress publishing, a sentiment that many users agree with. He hopes to steer it toward a more block-based approach that unifies widgets and includes an interface for shortcodes.

Mullenweg’s vision for the Customizer is to see all aspects of WordPress become more instant and provide the same interface and UI affordances as the editor. He announced that Ephox, the company behind TinyMCE, has agreed to work with the project to improve the core editing experience.

Shifting from a time-based release cycle to one that is more project-based is a major departure from WordPress’ previous release philosophy of “Deadlines are not arbitrary.” The project’s philosophy page identifies the practice of delaying releases for one more feature as a “rabbit hole” that has been tested and found to be unpleasant. The new approach to core development makes no guarantee that WordPress will have any releases in 2017.

If the experiment is not a success, the project’s days of frequent and fast iteration may be over for awhile. Mullenweg is willing to risk it in hopes of being able to provide more product-based leadership that will distinguish WordPress from its proprietary competitors.

“I think we’re trying to counter stagnation,” Mullenweg said when asked about the new approach to releases in the Q&A segment. “Even though we’ve had lots of releases, certain parts of WordPress have stagnated and haven’t made the leaps that they could.” He suggested that being part of a feature plugin team will give developers a way to be involved in more active releases and continue to build momentum for eventual inclusion of their projects in core.

Mullenweg plans to identify a tech lead and a design lead and will be working with them as the overall product lead. He envisions that when one area of WordPress gets to the point where the software can ship significant user-facing improvements, a release will be born.

“We’re at the point now where the steps WordPress needs to take are more significant to get the other 73% of the web it doesn’t have yet,” Mullenweg said.

In a return to WordPress’ poetic roots, he concluded by reading a poem called Praise Song for the Day by Elizabeth Alexander.

The video of the State of the Word address will soon be available on WordPress’ new YouTube channel.

49 Comments


  1. Despite various criticism of Matt, one must admit his legal prowess; insulating the WP Foundation from, say, the drunk after-parties at a WordCamp event in India (etc) only makes sense.

    Perhaps what doesn’t make sense is obsessing over the current “page builder” phenomenon that has overtaken WordPress as they compare themselves to the likes of Shopify, Medium, or Wix.

    One of the most common sentiments I hear from business owners who have ditched i.e. Shopify for WooCommerce is “wow, it’s so much easier to customize things how we want them.” And of course the way they are customizing things is with a developer(s) who inputs the perfectly optimized PHP, JS, CSS (etc) code to achieve the desired functionality. In a world with ludicrous investor-backed projects like “The Grid… AI-powered web design” whose homepage is a whopping 32MB of auto-generated code… there is a reason why WordPress continues to grow, WITHOUT a “forced” Calypso…

    https://tools.pingdom.com/#!/eemQKP/https://thegrid.io/

    I’m no authority on the matter, and by all means perhaps Calypso is the future of WordPress, but it would behoove the community to remember why this reliable CMS is king in the first place.

    Report


  2. I think we should work to eliminate the distinction between wp-admin/Calypso and the customizer. Live preview & staging of changes should be everywhere. For that matter, let’s also eliminate the separation between the frontend and the customizer. Let customize.php fade away.

    Report


    1. +1
      Hi Weston,
      Yes, this sounds interesting. My concern would be how to transition from the current customizer, server and js panel side, to this new paradigm. Could the changeset implementation be a first step toward it ?

      Report


    2. I never understood why customize.php was used at all. If something is going to be on the frontend, I can’t see why it shouldn’t be properly on the frontend.

      Report


  3. “Even though we’ve had lots of releases, certain parts of WordPress have stagnated and haven’t made the leaps that they could.”

    Quite a few people have been saying for some time that the project appears to be lacking in overall direction: that we only plan release by release; that there is no broader published roadmap; that we only build stuff that the people who turn up want which may not be what the project actually needs.

    So it no surprise that parts of WordPress have stagnated. That’s a direct result of the model we’ve been using.

    I’m therefore very encouraged by the fact we’ll be experimenting with how development is lead, especially if Matt does put on the Product Lead hat and become involved in the overview of where things are going.

    Not that I’m particularly happy or unhappy that it’s Matt. That’d be great, but it could be anyone (I’d be happy for it to be Helen actually). The key point is that there is someone with oversight of everything (more than a single release) looking at the bigger picture.

    Report


    1. Very well put. The development cycle announcement was the major bomb drop imo. It has the potential to make a huge impact and I was/am really excited to see the community’s interpretation and speculation. This is spot on.

      Report


  4. A hybrid between Calypso and the Customizer would be interesting.

    Report


      1. I wandered lonely as a cloud
        That floats on high o’er vales and hills,
        When all at once I saw a crowd,
        A host, of golden daffodils;
        Beside the lake, beneath the trees,
        Fluttering and dancing in the breeze.

        Report


  5. Really love the new release cycle. Excited to see where it takes Core. Particularly with regards to the editor.

    Report


  6. *sigh* Changing things, fixing what’s not broken, mobile-centric. Well crap. Again.
    I still just want something kept secure, lightweight and stable (which, again as I keep saying, may well be a WordPress Lite or Basic or Still or however you’d want to name it, so the main build could still go at the pace desired by others). And by stable I mean both no bugs, crashes, conflicts, and not changing the stuff I use. For my purposes the last useful change was autosaving, however many years ago (9?) that was. Been dreading major updates since 2.7 if I remember right.

    The one good thing I see here is helping with the push towards HTTPS everywhere though.

    Report


  7. Does that mean 4.7 will basically be a LTS release then?

    More specifically, will there be 4.7 security/bug releases during the potentially extended development cycle in 2017?

    Report


    1. All releases from 3.7 and up have had security fixes released and, by default, automatically applied.

      Anything new now that indicates this will not continue, at least for 4.7 and the nearest releases before this one?

      Report


      1. You have very wierd definition of LTS. By this definition windows XP was an LTS release up to about a years ago.

        LTS is about more than having security patches somewhere, it is also about the ease of installing them, and in the case of wordpress it is just hard and you probably have to do it manually. More then that LTS releases in linux world have also a repository from which you can download programs that will work with your release, something that is not even a pipe dream in the case of wordpress.

        Report


    2. Based on what was said, I don’t think it needs to be an LTS. It can just use the same system as WordPress uses now. When 4.8 comes out, 4.7 would be deprecated.

      Report


      1. Makes sense. Just feels weird not knowing when the next major release will be out…

        Report


      2. I’d like to see WordPress switch to a rolling release system eventually, like how Chrome and some OS distributions work.

        WordPress seems ideal for that, as it’s so stable.

        Report


  8. Thanks for the interesting write-up. I’m not sure at all if pushing Calypso so hard is that great an idea – but I guess action will largely depend on the “new” JS credo adoption by plugin programmers.

    Block-based editing has definitely become quite huge. And an update for the editor is long overdue. Feels like the most ancient part of WP these days.

    Report


    1. Calypso being used in WooCommerce will be very interesting.

      Report


  9. “…… WordPress’ new YouTube channel…..” ???

    Just really curious why do they need YouTube channel since they have https://wordpress.tv/

    Report


  10. I’ve been working for a year on a plugin which auto-creates entire websites in a multisite environment. Part of this is a 100% wrapper around existing admin. No core code touched and very little jQuery DOM element suppression…and it works very well, giving the user a seamless experience between front-end and back-end.

    Does Calypso mean that my efforts are now already obsolete (and will be deprecated) ?

    Report


    1. That sort of thing was always bound to fail eventually.

      A better approach IMO, would be to try to rebuild the admin interface entirely, like how Calypso did. Otherwise you end up with a serious risk of your plugin failing spectacularly when WordPress core is updated.

      Report


      1. Ryan, that’s sad to hear. I used 100% “end user” function calls or hooks to do this, with just a few DOM manipulations (which I agree, I own if WP changes). If I had to redo the Admin entirely then I might as well have started this project without WP. If filter calls like:

        add_action( ‘admin_init’, array( &$this, ‘register_settings’ ) );

        end up going away then I think Matt is going to have a lot of forked (or frozen) versions of WP out there, eventually…

        Report


      2. Hooks like you mentioned above can be migrated to a new system, so I don’t think that particular example would matter much.

        I may have misunderstood what you wrote yesterday though. You mentioned DOM manipulation, so I thought you meant you did a bunch of modifications via JavaScript. But if it’s all done smartly via action hooks, then I’d guess that much of it would keep working even after migration to a new system.

        The main problems I see with migration to alternative admin system, are that we often rely on query vars and PHP file names to work out where in the admin we are. Those would all break in a new system, unless it replicated all of those (which I don’t think it should, since they’re mostly shitty legacy things).

        Report


  11. I’m super excited about the php 7 and performance improvements. Moving everything to ssl will also help with http/2.

    Report


    1. no plugin or theme developer is going to do anything with that before it will be possible to charge 200$ per license.

      The user is going to get stuck with somethings that are possible only on web admin and some workflows that are possible only with calypso. Fun times ahead.

      Calypso is just a distraction, an attempt to avoid fixing the core problems by trying to cover them with nice UI and buzzwords

      Report


  12. I’m really not comfortable with Calypso until it can be detached from Jetpack. The beauty of WordPress lies in the fact that it runs standalone. The dependency that Calypso creates, on Jetpack and wordpress.com, a for-profit entity, does not enthuse me, in the least.

    The join between the two looks completely arbitrary to me – it exists only to make users of WordPress, into wordpress.com users. The first is free and open source, the latter a commercial entity.

    If your connection with wordpress.com goes t*ts up, or your account there gets hosed, or your account there gets compromised, Calypso management of your site(s) will cease to work. Sure, you can fall back on the ‘old way’ of doing things via wp-admin, but it appears that the long-game here is to make this a second-class citizen.

    Surely you should be able to join your sites to an admin server that you run, without needing an account on a 3rd party service. Doesn’t seem to be any sort of priority tho.

    Report


  13. So, I read between lines Shortcake Shortcode UI is finally making its way to the core.

    Report


      1. Development has recently picked up again. A new version of the plugin was released a few weeks ago.

        Report


  14. The json API might a game changer but why is there so much love for the custmiser?

    It’s just another interface guys, it is cool for sure but so what!!

    If the time spent on customiser was spent on new apis, eg a post relationship model (similar to the posts 2 posts) plugin or a queue system to replace wp cron, or fixing the post status API, or proper oop code in core WordPress could actually be a proper cms.

    Instead of trying to make wp easier the core guys should just make it better and empower developers to make it awesome for everyone.

    Report


    1. The customizer is not just another interface. Fundamentally the customize API is a framework for live previewing and staging changes. That makes it a very powerful foundation to build admin experiences that are devoid of the “Save & Surprise” experience that users largely get when making changes via the current wp-admin.

      Report


      1. Good point, but it is still an interface (albeit a very good and useful one).

        It’s a great enhancement but hardly a game changer.

        Report


  15. No matter what, as long as the interface smooth and make more convenient, I would ?

    Report


  16. Since no one is currently building anything like Calypso and targeting core, it looks like the technology behind WordPress.com will be driving the evolution of WordPress in 2017.

    I’d argue that this is is what we have in mind for the customizer, or at least a future iteration of the customizer.

    Report


    1. Agreed; especially since 4.1 the customizer is really a JS-driven framework in terms of UI and can accordingly provide the fast single-page-app experience that users are coming to expect. The customizer is also natively built around the concept of comprehensive extensibility, which Calypso seems to lack currently.

      The bigger benefit of the customize API is that live preview is built in and it’s (increasingly) a frontend-based interface. Calypso is missing contextual live previews and isn’t particularly exciting to me as an end user as a result.

      Report


    1. So do you mean static and object caching in core, as well as CDN integration in core?

      Report


  17. Calypso is interesting, but I won’t find it compelling until it drops it’s dependence on JetPack’s API in favor of the WP API.

    Don’t get me wrong, I love JetPack, but I don’t want it on a LOT of sites.

    There is a long way still to go for that but until then I can’t imagine investing the energy in supporting it directly in plugins or themes.

    Report


  18. Does this mean we’ll finally get an easy way to re-order Pages? There used to be a twee note on one of the Admin screens saying that it wasn’t very elegant and would be worked on (I’m paraphrasing) but the note was removed and nothing done…

    Report


  19. As someone who runs a WordPress-powered non-blog site outside of the wordpress.com cloud, here is my experience of the JS and release cycle issues:

    In the old/current release model, disruptive (or even harmful) changes are arbitrarily bundled with bug-fix releases, the moment e.g. 4.6 came out, no further bugfixes were made for 4.5-based sites. As cleaning up and adapting to disruptive changes takes time, this prevents timely deployment of bugfixes. I would much rather see something like the Linux kernel model, where some “LTS” major releases get a steady stream of bugfixes long after later majors are released, with a healthy overlap between the release of a new LTS and the end of bugfixes for the previous LTS (during which time, sites and plugins can migrate to the new LTS at their own pace).

    As for JS, JSON, XML-RPC and other APIs for app-based editors, I find those to be among the disruptive/dangerous/harmful elements that I strip out. Security-wise, I don’t want to expose unused and unknown APIs to random attackers. And privacy-wise, I don’t want to expose my users to logging or other stuff from random 3rd parties such as wp.org, gravatar.com, so each element from such sites needs to be removed or replaced by a local copy. Neither of these security measures are made particularly easy by the current WordPress code and release cycle, as I often have to trawl through the pages and files to find and fix these one by one. Like having to add extra PHP code to remove the new emoji-mapping scripts that load images from an external site in 4.6 . Restricting wp-admin and equivalent access to specific ways of accessing the web server required even more invasive work, and seems especially badly affected by the constant adding of new features.

    In short, every new or old feature needs an effective and easy off-switch. Anything that is loaded implicitly from 3rd party sites needs an easy way to switch it to local hosting.

    Report

Comments are closed.