Cancel

Jeff Chandler

The Wow Factor in Major WordPress Releases Is Getting Few and Far Between

WOW Factor Featured Image
photo credit: WOW Air Airbus 321-200 at FRA (TF-DAD) – (license)

WordPress 4.6 is scheduled for release on August 16th. This release streamlines the installation, activation, and update process for plugins, uses native system fonts for the WordPress backend, and improves the post editor. It also includes a number of enhancements under the hood.

Outside of the improvements to the plugin and theme management process, there’s not much else that excites me. In fact, I haven’t been excited about a WordPress release in a long time and I’m not the only one who feels this way.

It’s not the fault of WordPress core developers or the hundreds of people who contribute to the project. WordPress is maturing software that’s 13 years old. In the last 13 years, WordPress has implemented a number of features and the development process has changed as well.

On average, there are three major versions of WordPress released per year. That’s one major version every four months. The amount of time release leads have to work on and merge features into core is about 6-8 weeks. It’s tough to generate a wow factor three times a year with such a short window of opportunity.

Because of WordPress’ maturity and the short development cycle, major features are getting few and far between. By looking at the Beta tab on the WordPress plugin directory, visitors can view projects that may end up in future versions of WordPress. The only project on the page that excites me is the Front-end Editor but based on how long it’s been in development, I’m not holding my breath.

WordPress is used by millions of people across the globe and I realize that the features and enhancements in each new version that don’t excite me are useful and exciting to someone else.

WordPress development takes an iterative approach but the small improvements from release to release are typically not groundbreaking. I wonder if the days of creating and implementing innovative new ways to accomplish tasks in WordPress core are over.

Category:
Tags: , ,
105

105 responses to “The Wow Factor in Major WordPress Releases Is Getting Few and Far Between”

    • Yeah, some releases have way more than others depending on whether the feature plugin/project is ready to be merged into core or not. I use WordPress in a very limited scope so there’s a lot of things in each release that I don’t use or don’t apply to my use case. I was simply thinking back to the days of WordPress 2.3-3.0 where so many versions were crammed with cool stuff.

      Create forum topic from comment
      Reply

  4. I totally agree Jeff. And considering that there is the danger of breaking themes and plugins with each update, maybe it would be best to spread the updates to maybe once or twice a year. I have to admit though that the last few years fewer things get broken with a core update, but nevertheless, the possibility is always there.

    As a theme developer, my anxiety levels increase exponentially when a beta version gets released, and I frantically test every single function and feature just to make sure that I won’t have any nasty surprises… it’s a never ending cycle (as it should), but the quiet time in between version is extremely small. I’m not going to mention the fact that some of the things added have very little value, or are useless and not working well (at least for me), … smilies, emojis and distraction free writing anyone, just to mention a few?

    Since I’m on a roll, (and out of topic, but)… can we replace the Dashicons with Font Awesome, since nearly all plugins are using this font, so we won’t have each plugin loading it and slowing things down?

    As usual, good post, you just know how to get me to rant – again !

    Create forum topic from comment
    Reply

  5. Different strokes for different folks perhaps. I look at that beta plugin list with excitement for a day when core has the Rest API fully baked, served up wih a side of shortcake shortcodes and option to manage content via either front-end editor OR customizer. Tack on the Fields API which is making quiet but steady progress that will give core foundation for capabilities like ACF / CMB2 and there is lots that could dramatically shift the user experience and improve the work lives of many developers.

    If all of that were to land in 1 release, that would be as chock full as my high water mark for epic features with WP 3.0 merging WPMU, menu mgmt, custom headers + backgrounds and big improvements to (but not original implementation of) custom post types. Especially since it had 6 months to build over WP 2.9.

    Create forum topic from comment
    Reply

    • Different strokes for different folks perhaps.

      Exactly. I’m in tune enough with WordPress to know when that stuff arrives in core, there will be plugins and themes created that use those APIs that will make WordPress exciting to use again. Something I’m looking forward too is alternative publishing interfaces powered by the REST API.

      The saying goes, good things come to those who wait. I’m not going anywhere so I’ll wait, trudge through the boring stuff to get to the good stuff. :)

      Create forum topic from comment
      Reply

  6. Customizer :)

    I know it is controversial, but personally I think Customize Posts has a ton of wow factor. This is really another iteration on the Front-end Editor, and it really does provide an innovative new way to accomplish tasks in WordPress. Now, if it can be added to core, that will involve a lot of debate.

    Beyond Customize Posts, there is also Transactions which is currently being implemented in the Customize Snapshots plugin. It allows you to batch multiple changes into a single changeset to apply at a given time, including the publishing of multiple posts/pages (via Customize Posts), widgets, and nav menu items, and any other Customizer settings. This “changeset” (snapshot) can be drafted and iterated on, shared with stakeholders for review which they can see on the frontend before it goes live, and the changeset can also be scheduled for going live at a future time: you could create a whole new section of your site to go live at once. In this way, the Customizer with snapshots/transactions really takes over the role that a traditional staging site would fill, except it’s not a separate WP instance and so there aren’t the same pains of data migration between environments. Snapshots also allows for the Customizer to to preview changes on applications that make use of the REST API.

    I hope to do a fuller writeup of these new Customizer architectural improvements, but if the merge proposals are accepted and they get community backing, I wanted to share how I see that these could end up being your wow factor in a future release.

    Create forum topic from comment
    Reply

    • It is nice that you have so much passion about what you develop but customizer is a badly defined project that right now suffers from feature creep. Please compare the editing experience on medium to the one you want to do with it.

      As for being a replacement for staging? As long as you can’t undo changes after they were applied, it will never be.

      In addition no point in talking about complex transactions before DB access is transactional, which will never happen because it requires php 5.5. Without transactional DB access you just open yourself to DB corruption.

      Create forum topic from comment
      Reply

      • Mark: Badly defined, how so? There is a roadmap and a core purpose. And I’m not sure about feature creep. How so? On the flip side, I also recall complaints when new features are added to the Customizer that they only add aspects of what can be done in the WP admin (e.g. widgets or menus) without ways for users to accomplish other tasks when in the Customizer (e.g. adding a post), leaving them at dead ends blocking them from finishing their tasks when in the Customizer interface. It took Automattic about 2 years to develop a new WP admin that adds new UIs for most existing functionality. But there are not enough developers contributing to the Customizer for all site management to be added in a single release, so features creep in release by release. Also it’s by no means a community consensus that the Customizer even should be the new JS-driven single-page application for the WP admin. But features that make most sense for live preview have been added in recent releases.

        As for the editing experience, the Customize Posts plugin fully embeds the WP editor and it supports Shortcake, so you can create posts with post elements (like content blocks) and other user-friendly features but with live preview.

        Also, Customizer transactions aren’t MySQL transactions. You can read the details in the proposal. Customizer transactions are at the application layer, not the database layer. As for undoing changes, this would indeed be possible using transactions. With each published committed transaction, we can store the previous values for the settings being updated so that a transaction revert could be created. There is an issue in Snapshots proposing this.

        Create forum topic from comment
        Reply

        • @weston, it was badly defined from day one as it doesn’t really define what is it you are supposed to customize with it. A user which do not know the internals have no way to know if what he is changing have a global site impact (site name), it is localized to the current theme (color scheme), or some other random subset of the site’s functionality.

          Example, What is it exactly that you change when you change the site logo? You would assume it is like a site name, a global setting, but obviously there is theme related space requirement, so is it a theme specific?. A user just can’t know.
          Adding post editing into it will just make the confusion bigger.

          As for the post editing extension…. sad to say but it actually exposes the antique technology the customizer depends on. Iframes? seriously? are they even still in the HTML standard? Ok, joking aside the UX just looks so so bad, and I don’t think you can get anything better as long as you don’t go to full AJAX.

          Yes customizer transactions can be at application level, which is what is wrong. Imagine a transaction failing half way. What is the recovery plan? Transactions by definitions should not fail half way, either it is black or white. Obviously this is a low level core problem as customizer is not unique in its need to perform transaction, every post edit should be treated as a transaction, because many times there is no point in having the saved text without the associated meta.
          The problem is not as obscure as you might think and I saw at least one ticket about an object cache getting wrong values.
          Right now core doesn’t have the infrastructure for actions and filters to properly handle transactions whether they are DB based or app based, so using a customizer as a staging type of tool is just a pipe dream for anyone that doesn’t enjoy living on the edge.

          Create forum topic from comment
          Reply

        • @mark.k:

          it doesn’t really define what is it you are supposed to customize with it. A user which do not know the internals have no way to know if what he is changing have a global site impact (site name), it is localized to the current theme (color scheme), or some other random subset of the site’s functionality.

          That’s right, as it is a framework for live previewing changes. That is its purpose. It’s up to core, themes, and plugins to implement the interfaces for what should be customized.

          A user which do not know the internals have no way to know if what he is changing have a global site impact (site name), it is localized to the current theme (color scheme), or some other random subset of the site’s functionality.

          Yeah, but this could be improved merely with some descriptive text or some indicator to show which controls are manipulating theme mods vs settings which are not theme-specific.

          As for the post editing extension…. sad to say but it actually exposes the antique technology the customizer depends on. Iframes? seriously? are they even still in the HTML standard? Ok, joking aside the UX just looks so so bad, and I don’t think you can get anything better as long as you don’t go to full AJAX.

          Not sure I fully understand the point here. An iframe is used for the Customizer preview. The interfaces for manipulating the content are separated from the previewed content itself for theme compatibility reasons, inline editing has a lot of additional complications and special considerations. That being said, there are definitely opportunities for bootstrapping the Customizer framework onto the frontend without ever navigating to customize.php and entering into an iframe. This is a large reason for why the Selective Refresh framework was introduced, so that we can get away from doing the full-page refreshes that necessitated the iframe in the first place.

          Yes customizer transactions can be at application level, which is what is wrong. Imagine a transaction failing half way. What is the recovery plan? Transactions by definitions should not fail half way, either it is black or white. Obviously this is a low level core problem as customizer is not unique in its need to perform transaction, every post edit should be treated as a transaction, because many times there is no point in having the saved text without the associated meta.

          This is why the setting validation model was introduced in this current release (4.6) to provide a mechanism to block saving any settings if just one of the settings is invalid. In the Customize Posts plugin, validation constraints are added for post locking and also for post conflicts, so attempting to save changes will be blocked until the conflicts are resolved or the lock us released.

          Right now core doesn’t have the infrastructure for actions and filters to properly handle transactions whether they are DB based or app based, so using a customizer as a staging type of tool is just a pipe dream for anyone that doesn’t enjoy living on the edge.

          I disagree. Customizer settings provide the interface for previewing a set of changes on top of the site’s current state, and then to persist those changes transactionally via the validation API. We’re actively using the Customize Snapshots plugin to use this app-based transaction concept powered by the Customizer today.

          Create forum topic from comment
          Reply

        • @Andreas Nurbo: you are completely right. As regarding its interface i personally could not imagine any worse solution. There is 5 cm space to set the options and each row is really high. So you hardly have space for the input elements and you have to scroll a lot.
          While there were so many themes that had their own options screen where even dummies could set far more details…and many of these themes got just broken by customizer.

          People who can not code at least a bit and still want to run an own site will always have to ask for help of people who can code. Period. WP can not change that, just make it even for devs harder to get the job done by oversimplifying the graphical UI as that way there is just more that has to be done by coding.

          Create forum topic from comment
          Reply

        • @weston, sorry for not reading all, but mentioning the setting validation is enough. It is nice attempt but obviously a waste of your time. Theme and plugin authors should know how to handle “corrupted” DB as many people can change settings at any time and not all of them are going to be via the customizer. The end result might be garbage even if there is no notice being displayed. More then that, plugin authors might not be able to asses the failures introduced from interacting with other plugins and therefor it will be just impossible to give a notice for all “failed” conditions.

          You just create a false sense of “it should work” with that feature, and more work for theme and plugin authors as users will demand notifications for things that are beyond the author’s control.

          The point of front end editing is that the user sees what happens. Who knows, maybe in some situations two wrongs will actually result in something positive.

          Create forum topic from comment
          Reply

        • What are your ideal changes? Being that it is mostly JS, there’s a lot of flexibility to change things around and maintain backwards-compatibility. In terms of a single-page application for WordPress, the Customizer has the most widespread support since all themes already should include at least some integrations. So using the Customizer as a base seems more feasible than throwing the whole thing out and starting from scratch, which as you know isn’t a very WordPressy way of doing things.

          Create forum topic from comment
          Reply

        • The Customizer is a PITA, a nasty unresponsive behemoth and a total, utter failure. Documentation is next to non-existant, its nasty tendencies to discard settings when switching themes – and us theme and plugin developers taking the brunt-force of enraged users – AND THE continued ignorance of said developers by the folks who push this .. thing .. forward, no matter the consequences … led me to give up on it completely. Which happened in May 2015.

          If there is gonna be something like a “lets replace the WP Editor with the Customizer” thingy in the Core, and the WP API is NOT ready or not as reliable when that happens .. I seriously consider a big fat fork. Worked with b2/cafelog, too :P

          cu, w0lf.

          Create forum topic from comment
          Reply

        • What are your ideal changes?

          I think that the Customizer workflow is great for small tweaks for configuration, but horrible for day-to-day entry of new content.

          Being that it is mostly JS, there’s a lot of flexibility to change things around and maintain backwards-compatibility.

          I was referring to the PHP side of things. The hooks and objects implemented are non-trivial.

          In terms of a single-page application for WordPress, the Customizer has the most widespread support since all themes already should include at least some integrations. So using the Customizer as a base seems more feasible than throwing the whole thing out and starting from scratch, which as you know isn’t a very WordPressy way of doing things.

          Which is the shame of it all. Which brings us full circle to my comment about “so much complexity baked-in that I don’t see how it would be realistic without breaking backward compatibility.”

          I feel really bad saying this to you personally because I know the Customizer is your baby, just like if you were to say bad things about WPLib I would not like it. But then I have not managed to get WPLib baked into WordPress core, so there is that. :-(

          Create forum topic from comment
          Reply

        • @weston, no personal insult intended, but “well architected” is something that only external observer can say.

          Two simple fact that show it isn’t
          1. it introduces new globals.
          2. it uses the wp_loaded hook although by definition https://codex.wordpress.org/Plugin_API/Action_Reference/wp_loaded at that stage WP core components should have already be fully initialized.
          3. (ok, more of an annouyance then actuall architecture problem) z-index of 50000. Not only an undocumented magic number, but also so high people that might guess they need to use z-index to solve issue, might never figure they need to go so high.

          It might be “well architected” by wordpress core software development standards, but that is really a low bar to pass.

          Create forum topic from comment
          Reply

        • @mark.k: I said “I think” it is fundamentally a well-architected component in WP. So yes, it is well-architected by WP core standards, but WP is an iterative project that builds on features with each release as opposed to introducing radical new components and interfaces with each major release. As such, the Customizer seems to me to be the best existing foundation in core today to build on to implement the administrative experiences we need. As for your specific points:

          1. it introduces new globals.

          How many globals does the Customizer introduce? Are there any others than $wp_customize? With this one global you have access to the entire Customizer API by traversing relationships between related objects. Every component in WP has at least one global somewhere. Most components in WP have dozens of globals they rely on. I can only recall the Customizer using one.

          2. it uses the wp_loaded hook although by definition at that stage WP core components should have already be fully initialized.

          Exactly. It needs to wait for all components to be loaded before it completes initialization because it needs to wait until all of the components have been loaded so that they can add hooks to register themselves with the Customizer so that it will be aware of them when it registers settings and adds filters to preview changes.I don’t see how it making use of wp_loaded should count against it.

          3. z-index of 50000.

          I agree. This should be fixed.

          Create forum topic from comment
          Reply

        • @weston,
          1. in the first year of any semi respectable CS degree you learn not to use globals. not seldom, not rarely, just simply not to use them. At the very worst case when it just can not be avoided you at least use a singleton pattern.

          Ignoring the theoretical benefits of not doing that, this decision basically forces that there is only one session in any time, a limitation that there is no reason to have. I might want to customize the logo while my co-admin wants to change some widgets. This is not a big issue today but the more you force people into using the customizer and the more you will encourage them to have long transaction the bigger the problem will be.

          2. It is defined like that in the fucking codex!!!!!!!!!!!! It was defined like that when @Nacin added it to avoid the inability to know when initialization was finished, and the customizer went and cluttered that black/white easy to understand definition. Now no one actually knows when core (and therefor plugins and themes) had finished to initialize and obviously other core features like fields API just copy pasting that code making the problem bigger

          Create forum topic from comment
          Reply

    • I have not used the Customize Posts plugin so I can’t comment on it but if it’s an iteration on the Front End editor plugin, you’ve got my attention and I’ll look into it. I’m also going to look into and test the Customize Snapshots plugin. If Matt believes an entire release could be dedicated to the Customizer, there’s gotta be something to it.

      There are a ton of things to be excited about if you’re a WordPress developer.

      Create forum topic from comment
      Reply

  7. One man’s wow factor is another man’s “WTF just happened?” Baby steps, small changes that are noticeable but only barely, and little iterations that change behavior without users even realizing it seem like winners to me.

    As a WordPress developer, I’d love to see better everything around WordPress, not least of which is its openness to more game-changing ideas.

    As a WordPress user, it makes me feel super-stable and at ease knowing that a release isn’t going to blow my site up and that everything will be okay.

    I’m 50/50 with you on this. Who wants to develop or use exciting software?

    Or who wants to be confused and shaken by wow factor stuff for the sake of its wow factorness every several months?

    Create forum topic from comment
    Reply

    • One man’s wow factor is another man’s “WTF just happened?”

      Agreed. Stable is boring but stable is good. Polishing a turd doesn’t make it any better. What keeps me interested in WordPress is the third-party ecosystem of theme and plugin authors who have the freedom to think outside the box. I’m hopeful that the REST API and other developer centric features being worked on makes it easier for developers to try out wacky and possibly innovative ideas.

      Create forum topic from comment
      Reply

      • Yes. The only thing that keeps WP alive is plugins and themes. Simply beacause WP core is a piece of undefineable code. I mean it is not a blogging platform nor is it a real CMS. I have the impression even core has lost focus. As a dev it tends to become frustrating that even for a blog i need 3-4 plugins (security&social related), not to speak about a simple website.

        Actually REST API is not a big stuff either. That way one can use API syntax instead of calling wp functions in the template files. For a limited selection of wp functions. API is not bad but there is nothing more you could do with rest api as without it.

        The bad is we never seem to get better media organisation, decent search options, content delivery in multiple languages, etc. Instead of such useful improvements we always get tons of marginal stuff like shiny updates, bacon emoji, etc.

        Create forum topic from comment
        Reply

  8. I have said this before for many years. too many versions come out in a year. Look at PHPBB for example, they don’t just release for the sake of releasing, which I think it is happening with WordPress.

    Imagine if you have a dog that you keep inside your house, you let it out only once a day to go pee…that dog will run out of the house faster than the USS Enterprise at Warp 10. Now if you let the dog out 3-5 times a day, every day and take it out for a long 1 hour walk every day, then the wow factor of outside will be…meh, whatever.

    Like Idealin said…Different strokes for different folks perhaps.

    For people lime myself, Jeff Chandler, Otto42, Ryan Hellyer, Matt Mullenweg and so forth. We love every update. We are there on the exact date that we were promised the update.

    Most “regular” people don’t give a fudge/flying fudge/etc… in fact most people barely update.

    If there was two updates a year, or even just one then the people working on WordPress would have more time, less stress and so forth.

    Obviously security updates like 4.6.x or 4.5.x and so forth are exemption to this rule.

    When an update comes, I read the tweets, read the blog post at WPTavern, Bob Dunn’s updates and the “usual suspects”. The updates are so common, I don’t get this “wow factor”.

    Create forum topic from comment
    Reply

  9. This is not maturity, it is monopolistic stagnation. When you are a de-facto monopoly in PHP based CMSs you just don’t see the point of making any real effort to improve.

    Points in case: You still need to install 5 plugins just to bring a wordpress site to minimal expected level in terms of security and integration with other web services. Tumblr like editing interface was just abandoned 10 releases ago mainly because “it is hard”, Front end editing is not even on the discussion as again it is hard.

    It doesn’t help that core development is still managed like a hobby project which if it can not be completed in a week it is “too hard”. I see that @Helen is trying to change that culture and wish her good luck with that but I am skeptical that she will succeed.

    Create forum topic from comment
    Reply

      • Let me reply here as above there is no reply button for me:
        Even in case a simple blog i need 1 plugin for security, 1 for SEO, 1 for social integration. For these i would not name any exact plugins as there are several options for each…
        But somehow it is strange that you need plugins for these fundamental things, is not it?
        Then i almost always install WP DB Driver plugin as WP still uses mysql connection instead of the more secure mysqli becuase they always fear of any change.
        And we did not even speak about caching to improve WP’s not so bright site performance. There is simply too much lacking out of core even if we consider WP as just a blogging platform.

        Meanwhile WP wants to be considered as a CMS.

        Create forum topic from comment
        Reply

        • Would hardly categorise social integrations as a fundamental. Not every site owner wants social buttons, widgets, etc. but I hear and understand your overall point.

          There are fundamental features that are plugins that really should be developed by the core team. Features such as SEO, caching, (better) custom fields (arguable), etc.

          The ridiculous thing is there are already highly used plugins that do this so there isn’t much development work required to “fork”/move them into core. It would also prevent update issues as many experience through plugins such as Yoast SEO, ACF Pro, etc.

          Beyond those, better focus on security features is of the utmost importance. Makes no sense one has to use a, plugin to harden their security as that in itself introduces further insecurities to one’s site.

          A different, possibly better, approach is having one plugin à la JetPack, that has a bunch of features that are popular but can be opt-out.

          Have the plugin as a default (I’m looking at you Hello Dolly!) but give site owners the ability to not use some or all of the features in the default plugin. Think it’s bloated? Don’t use it but if you would rather have the basics covered, such as SEO, security, caching, etc. install one plugin and be done with it. This also presents better updates as the code will be handled by fewer people.

          PS: I don’t buy the JetPack bloat argument and I use about 4 – 5 modules on sites I work on.

          Create forum topic from comment
          Reply

      • @Larry, specific plugins are not important, it is the functionality that it is. Out of the box you need a plugins for caching, SEO, contact form, backup, and most people will say security. And this is just to cover the minimal infrastructure requirements of just having a site before even going into what the site should do.

        Create forum topic from comment
        Reply

  10. I’ll get excited the day WordPress supports something other than MySQL as the database server. It would be great if SQLite could be supported. Outside of shared hosting, not everyone can afford gigabytes of memory.

    MySQL 5.7 is a resource-sucking monster and I couldn’t even keep a one-gig VPS running with it installed – I had to revert to 5.6. In the future, we’ll have to use drop-in-replacements like MariaDB when Oracle stops supporting anything older than 5.7.

    Create forum topic from comment
    Reply

  13. For me it seems, WP is going further away from a content management system to a website construction kit. There are so many features which are useless for professionals and on the other hand professional core features do not have an UI in core, such as custom post types, custom taxonomies, custom fields like solved in ACF and the User/Role system.

    There is missing a native syntax highlighting for every code editor in the system and a UI like in the “Add Quicktag” plugin should also be in core, as well as the function from “Limit Login Attempts”, which is a scandal, that it’s not in.

    Functions from plugins like Yoast SEO, Antispam Bee or a caching function, native support für CSS preprocessors, Javascript compression, a phpinfo Page in the Backend, everything is missing and has to be solved with plugins and every plugin installation increases the dependencies from the plugin authors.

    When you are making money from selling WordPress websites, it is too dangerous to promise to your customer, that the website will work and remains update save.

    Create forum topic from comment
    Reply

      • I use it for my own projects and I like it. But I wouldn’t run a business from selling WP websites again. I quit it. Too many customers that couldn’t understand that a WP website needs a continuous maintenance. Because on the first sight everything seems to be so easy. But it is not.

        Create forum topic from comment
        Reply

      • Except if WP autoupdates it’s core and your old plugins just do not work on it. Or your plugins simply get abandoned. Or your site just gets hacked because you never update to avoid breaking it because of the above mentioned problems. All in all it gets really frustrating to use WP even as a dev. Now imagine someone who is running his/her blog on their own and can not tweak it as we devs can.

        Seriously imagine any platform without decent SEO and search options in core. You would just laugh about it if it was not called WP. So there is a lot to improve on WP that should be done in huge steps and can be done without breaking anything. I really do not mean bacon emojis by saying that :-)

        Create forum topic from comment
        Reply

    • Even though I won’t develop or directly use the REST API or the Fields API, I can certainly see how it would enable developers to create things that would make WordPress exciting to use. There’s a lot of effort and work going towards all these developer oriented things which is not my cup of tea. But I know without them, it will be more difficult to try new ideas that benefit from those APIs in WordPress.

      Create forum topic from comment
      Reply

  15. Too many complex features into a version would also mean that people would not get used to the new version quickly until another version comes up.

    Also core WordPress contributors have to take care of backwards compatibility.

    So i would say little increments is good rather than cramming too much for everyone to gulp in one go…

    Create forum topic from comment
    Reply

  18. I would probably be considered by most to be a hardcore WordPress fanboy, but I agree 100% with you. I could also play the devil’s advocate on the topic as well. I like that recent updates haven’t broken any of my websites. I also like that certain features aren’t built into the core because I can choose from from a selection of plugins rather than being stuck with a half-baked solution in the WordPress core (of course a full-baked solution in the core would be ideal but then we have to worry about bloat to make everyone happy, right?). I have about 20-30 plugins that I install on every website that I develop and there are features that I wish were built into the core—like SEO tools (why can’t we have Yoast SEO functionality as part of core?). And why can’t we have something like Advanced Custom Fields as part of the core? And tools like Better Search Replace, a better commenting system (like wpDiscuz) with more control over commenting (email notifications, ability to easily turn comments off, etc.), a WYSIWYG widget (duh!), more user control over assigning sidebars and widgets to specific pages/templates/categories, better image handling (WPThumb and Imsanity), an interface to create custom post types, a better search system and search options (Relevanssi), responsive videos, drag-and-drop page and category/taxonomy ordering, more security features (Wordfence), better spam control (Zero Spam). Why oh why do I have to use plugins for these things? Bring the WOW back WordPress core developers. Give us the things we need! We love you!

    Create forum topic from comment
    Reply

    • When you have software that powers 1/4 of the Internet, it’s a dangerous position as a developer to straddle.

      WordPress Core seems to think WP is simply a blogging platform. They don’t want to add features that make things harder for amateurs getting started or risk blowing up the DIY market.

      Hardcore WP developers seem to think WP can “do it all” and want things like Advanced Custom Fields/Pods or Yoast SEO, etc. right in the Core.

      I can see it from both sides. Most of my websites don’t use WP anymore but it can be still relevant for the 5 pages and a blog site. Majority of my work is in client services, i.e. building websites for businesses.

      On bigger installations, WordPress’ simplistic nature tends to break down pretty quickly when you have more than a few content types. You can add plugins that make it more CMS-like but ultimately, we’re chasing after several different plugins to provide the functionality that other CMS offer right out of the box, from one developer. It’s not even close to a cohesive solution.

      I don’t need comments, I don’t need XML-RPC, I need more than one content (post) type. And I absolutely need more than one field (body) for content editing. These are things that Core doesn’t seem to want to solve at all for me. And ultimately you need plugins or custom code on every build to make it happen. That multiplies the risk/maintenance factor with every plugin you add.

      Devs love to point out that huge players use WordPress and that if they can do it, WordPress has plenty of power for your SMB website as well… but neglect the fact those teams often have dozens of developers on them to actually support the installation.

      Why do developers continue to use WP if it doesn’t really meet their needs? I still use WP when it makes sense but in a developer/client relationship, most of the time it does not.

      Create forum topic from comment
      Reply

  19. Would love to see an experimental fork that would keep the old WOW factor going at speed. Ran by some sort of a WordPress R&D group whose goal would be to make sure WordPress stays ahead of the field.

    Would expect lot of things breaking, but lots of excitement with each new release, like in the old days. Not for the faint hearted definitely.

    Create forum topic from comment
    Reply

      • Ryan,

        Vladimir has a great idea. Merge with my idea above of parallel versions in development; short cycle and long cycle releases.

        There are things that cannot be accomplished without changes in core, and by definition it would be these things where Vladimir’s idea make most sense. I am constantly running into these issues; just look at my Trac tickets to see a list of them.

        One great example would be a rewrite admin console complete with a front controller.

        Create forum topic from comment
        Reply

    • I agree with Vladimir.

      A forward looking, fuck backwards-compatibility, version with a minimum recommendation of the latest scripts and tech stack is an interesting new world for WordPress. Without much thought, I can envision a WP version much like Ghost but with a CMS-focused mandate. So pages, custom post types, ecommerce, etc. Much of WP’s woes come from the insistence on backwards compatibility. Catering to people who either don’t know how to maintain their sites or refuse to is holding us back!

      With the advent of social media and the big F eating up the world’s traffic, it has become quite clear that in order to succeed on the web, you need to know your shit! Pandering to clueless end users is not doing WP any good.

      Remember when WooThemes broke backwards compatibility? Pretty sure some of the new and exciting stuff they are working on now would not be possible if WooCommerce was lugging around all that legacy code.

      All this Rest API/Calypso/JavaScript/SPA talk wouldn’t be as necessary if WP was centred around keeping abreast with the latest technologies and not placing too much emphasis on supporting outdated technologies!

      Sure, WP does not have to be at the bleeding edge of web technology use. I for one have no problem with WP being a PHP reliant CMS; see PHP sucks but such nonsense as supporting a PHP version that has been EOLed makes me wonder why one would want to invest in WP for their business. Yes, I can use the latest version but all that legacy code affects my site regardless of how polished and up to date my server and WP instance is.

      Create forum topic from comment
      Reply

  21. Forgive me if this exists, but a quick look at make.wordpress.org didn’t reveal it… but is there a medium term vision for WP? I don’t mean 10 years out, but 2. At first, the API was due to land in 4.5 or 4.6. Now? As a casual observer of what’s going on in core, I don’t actually know when it’s due to be baked in (and yes, I know about the plugins). The other day there was a post about the Posts To Posts plugins and how that can’t be added to core because the taxonomy situation wasn’t settled… in 2013. Well, it’s 2016 now. What still needs to be done on that?

    I know, I know… release notes. But it would be good to have a roadmap and especially some summaries of the major features like taxonomy redo and the API.

    I also feel that we’d benefit by moving to a 2x per year release schedule. Longer cycles allow for more dev time per cycle and less “Oh this won’t fit… ” reactions and frankly, I don’t know that end users of WP benefit from 4x per year releases.

    Create forum topic from comment
    Reply

  22. The only project on the page that excites me is the Front-end Editor but based on how long it’s been in development, I’m not holding my breath.

    You should seriously look at the upcoming version of Divi from Elegant Themes.

    They are light years ahead of anyone out there when it comes to a front-end editor the second the new version drops (30 days or so I believe).

    I’m not trying to start a debate about Divi and code bloat, minimalist vs awesome, and paid vs free here. Just throwing out something that will very likely revolutionize WP for a LOT of people. :)

    Create forum topic from comment
    Reply

  23. A really exciting thing would be replacing archaic templating system with some more modern templating language like Twig. I use Timber library plugin and it makes template development much faster and much more enjoyable (while still compatible with traditional wp templates).
    And multilanguage content supported in core is another thing we are waiting for.
    Unfortunatelly it seems that wp developers pays more attention to small tweaks in Customizer and a few occasional (but useful) additions to wp_query. Delayed REST API is also good thing, but still not exciting for wider audience.

    Create forum topic from comment
    Reply

  25. I think a project the size of WordPress should not really try to impress or wow anyone in a new release. WordPress is an established piece of software, does things in a certain way, and does most of them well. People are used to a workflow they are familiar with.

    To me it’s perfectly fine if WP goes along this route and provides incremental improvements over time, without trying to impress anyone, but consistently keep it well positioned in the world of database-driven PHP CMS. It’s winning in this market because of reasons which are completely unrelated to the realm of innovating or wow.

    There are tons of projects that try to innovate in the field of CMS, we can mention Grav (https://getgrav.org), PageKit (https://pagekit.com) and others too.

    They can take more innovative and refreshing approaches because they have a much lighter userbase, and they are not afraid to move fast (but keep things running, as Zuck used to say), a thing that WordPress cannot do any more due to its enormous ecosystem of plugins and themes.

    Create forum topic from comment
    Reply

    • Are you trying to tell all popular software must lack such basic features their userbase regularly needs for the purpose the software was designed for…just because the software is popular and has too many users?

      Or were you about telling there should not be any core implementation for caching for example just because there are already done plugins for that? (Same for SEO, etc.)

      Sorry i just can not find any logic or i miss something.

      Create forum topic from comment
      Reply

      • Which “basic features” is WP missing? Sure one can argue there are tons of little features it could have more, but as long as they are provided by plugins, it’s fine. It cannot incorporate every possible feature out there. Software needs to be light, simple and extensible, just like WP.

        It does not have to “wow” anyone, it does its job perfectly, “wowing” at this point would mean satisfy one little percentage of the users, while disappointing all the others, as surprises are not much encouraged except by the early adopters. My point is WP cannot move fast any more.

        Create forum topic from comment
        Reply

        • For starters:

          SEO
          Security
          Backup
          Cache

          Nobody could possibly intelligently argue that any of those should be considered anything but “basic features”.

          Possibly Image Optimization and CSS/Javascript Optimization as well.

          Plugin bloat is the worst thing IMO that you can do to a WP site.

          Create forum topic from comment
          Reply

        • @Albert: Do you make websites for your own use on localhost or are your sites facing any size of publicity? Or has just the web evolved and you forgot to follow trends?

          Your arguments just lack ANY logic:
          Bloating WP core with completely needless and unwanted stuff (like bacon emoji) or with stuff of marginal importance but no actual use (shiny updates, REST API) or with the customizer (that broke so many themes just because WP never wants to break anything) or with… well…the not so bright idea of a computing-intensive link checker that actually does not check the link for its validity does not matter as such features will keep WP core “light” for ever.

          While implementation of basic features (ones that you can not afford to lack if your site is for the public) into core as optional modules would make WP “heavy”, while adding the same basic features by plugins will keep your WP installation “light”.

          Create forum topic from comment
          Reply

  27. As a developer, every major release in recent memory has had a plethora of both major and excellent additions that I believe are necessary to push forward the future of WordPress. In many cases they are also necessary to provide the framework for the front end wow factor, unfortunately these under the hood updates don’t often mean much to the average.

    Create forum topic from comment
    Reply

  28. I’d love an update that focussed on nothing but speed. WordPress can definitely scale but it takes a lot of effort and is nightmare for the casual user. Being able to concatinate the majority of the style sheets and scripts would be a huge step forward. I’m also hoping that php7 helps in a big way.

    Create forum topic from comment
    Reply

  29. They say the true sign of a leader is to inspire people to be leaders themselves. Another sign of true leadership is putting your team in the best position to suceed.

    With that said: Core should focus on core. It should provide the hooks, docs, etc. that allow plugin devs and theme devs to suceed (read: add value to WP core.)

    The mindset that core needs to be the kitchen sink is dangerous, unnecessary and dated. Ultimately, the market is VERY diverse. WP should think less about being a hammer and everything being a nail, and more about being a tool box that makes more devs more successful.

    Put another way, there’s a reason we have the plugin (and theme) architecture. If that’s broken, then let’s fix it already. Because the fact is, feature bloat has killed plenty of products.

    Create forum topic from comment
    Reply

    • Well that’s really what it comes down to… what is WordPress? Is it a blogging platform? Is it a CMS? And where does core draw the line at functionality? WP has always been a blogging platform first and foremost.

      I’ve used many platforms over the years and WP seems to be moving further and further away from developers and more into the DIY/SquareSpace market. They try to keep developers entertained with things like the Rest API but ultimately it ends up satisfying huge players instead of the middle ground that a lot of developers need.

      Create forum topic from comment
      Reply

  31. Pretty much completely disagree with this. WordPress is one of the most frequently updated and maintained products I have seen, including features large and small.

    WordPress has become a platform used in many different ways – from stores to blogs to advanced integrated data solution sites.

    With the ecosystem of plugins and huge install base, the primary goal must be to provide a stable and extensible platform which is exactly what automattic is providing through RPC, plugin revamp etc.

    Create forum topic from comment
    Reply

  32. With browsers and sites like GitHub moving to even shorter release cycles, I can’t see what advantage a longer release cycle (such as twice per year) for WordPress would achieve.

    The feature plugin approach means development can be done irrespective of the release cycle. The fact that some feel that these feature plugins aren’t “wow” is a different issue to the release cycle.

    It is an old platform, and while it may not have some things folks would consider to be basic (i.e. SEO), it’s not necessarily advantageous to have that in core – if Google and friends announce a big change, just after a WP release, then either everyone is getting it wrong for the next 4 or 6 months, or a plugin is needed to fix things in the meantime. Plugins, naturally, have a shorter reaction time to external influences.

    Personally, I don’t need “wow”. “Wow” means shiny and new, and more often than not, new bugs. As of just now, there are 1956 bugs (of 3767) listed on Trac that I’d rather see addressed long before any significant new features are added. I’m also loving the work to objectify existing code (though there are some questionable OOP decisions). Stability in WP core allows plugins to provide the actual features I need.

    I’d love to see alternative releases that purely focused on fixing bugs, like Nacin did for one release a few years ago, until those numbers are reduced to below a threshold – that would set a user expectation so misguided folks don’t expect a visual or functionality “wow” on every release.

    Create forum topic from comment
    Reply

    • if Google and friends announce a big change

      This is somewhat silly. The internet is in a constant change and core always adopts to changes in browsers, PHP, javascript, html and many external libraries. You may claim that SEO should not be part of core, but that is a very weak reason.

      Create forum topic from comment
      Reply

  33. While I understand what you’re saying, I don’t know that there really needs to be a “wow” factor with every release. I think the platform is already very mature and has a clearly defined job to do, which it does it well. It’s been doing it well for years. Also at three releases a year, incremental improvements rapidly add up, so that when you look back the gains have been significant, they just may not jump out at yeah on a version by version basis. A post on my company blog got into this a bit more, linked to in my profile if interested.

    Create forum topic from comment
    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading