Cancel

Jeff Chandler

Matt Mullenweg Addresses Concerns That WordPress is Moving Too Fast

RoadRunner Featured Image
photo credit: steevithak – cc

There are at least three major releases of WordPress per year where users can expect new features and major bug fixes about every four months. While this is great for users, some companies, plugin, and theme developers are struggling to keep up.

We recently received the following email from a reader concerned with WordPress’ release strategy:

As the pace of WordPress releases grows, plugin and theme developers have to constantly update their products. This is leading to a real and growing problem among WordPress site owners and companies like mine that handle website maintenance and updating.

This pace is leading to an almost daily need to fix problems, caused by these updates. Plugin updates tend to break things, even though we primarily use professional, paid plugins for the idea of support and generally better quality products.

I get that it’s important to patch security issues, but we’re also seeing a lot of new functionality, moving plugins into core, and other changes. These cause theme developers to push out updates with great frequency and they make mistakes.

I’m worried that the pace of core updates is driving the larger ecosystem toward failure. Everyone is scrambling to keep things patched, then new conflicts arise and things break down. The person on the end ‘companies maintaining their sites, responsibly, or services like mine’ face a constant flow of updates, then testing, then trying to fix things that have broken.

Matt Mullenweg, Co-founder of the WordPress open source software project, specifically addressed this issue during the Q&A session of the 2015 State of the Word at WordCamp US. Mika Epstein, who voluntarily reviews and approves plugins for the WordPress plugin directory, voiced the concerns shared by developers who are struggling to keep up.

With the myriad of technologies developers have to learn, including the REST API and JavaScript, Epstein asked Mullenweg if WordPress is moving too fast and if the number of releases per year should decrease by one.

Mullenweg answered the question by saying improvements can be made to the plugin directory so that users can share the burden in the testing process. He also said that the speed of WordPress development will increase instead of decrease. Meanwhile, the development team will continue to release three major versions per year.

He then describes a future where developers may be able to lessen their support burden by using the REST API that’s slated for WordPress 4.5. He also cites how large webhosting companies, such as Bluehost, have automatically upgraded most of the WordPress sites on their network to the latest stable version. Mullenweg ends his response by apologizing to those who feel WordPress is moving too fast but says its worked so far.

How Do You Keep Up With WordPress?

While we do a great job of keeping users and developers informed, plugin and theme authors should subscribe to the Make Plugins and Make Themes sites respectively. Anyone involved with maintaining WordPress sites should subscribe to the Make Core site where important information related to core is published.

We know that the release strategy isn’t going to change so whether you’re a developer or someone in charge of maintaining sites, how are you keeping up with WordPress?

Category:
Tags: ,
113

113 responses to “Matt Mullenweg Addresses Concerns That WordPress is Moving Too Fast”

  1. I feel that these releases are starting to get so fast that random things start slipping through that aren’t even all that necessary – like removing the “View Page” button from page edit screens. Who was complaining about that?

    Because that button was removed, I got about 20 extra support requests with people wondering where that button went. I had to re-film tutorial videos which now say to click the permalink instead of the “View Page” button.

    This is only one small example of random changes made to core that don’t seem necessary – and the rate of updates makes it hard to catch all these little things and protest them in time.

    I’m not sure if slowing them down is the solution – but it is creating a hectic, “put out fires all day” feeling every time a new update comes out for sure.

    Create forum topic from comment

      • Totally. With something like removing a “View Page” button, it seems obvious to click on the permalink to developers. But to users, they are following along with tutorials that say to click “View Page” and when they don’t see it, they are totally lost.
        It would seem Core developers are too far detached from that level of user to understand the ramifications of a tiny change like this – let alone bigger changes. Unfortunately, faster/frequent updates mean less communication time to hash out these types of ramifications.

        I’m not opposed to frequent updates or moving the “train” forward. I just think that the direction you move the train is just as important as the speed it goes.

        Create forum topic from comment

        • Also wanted to quote Phil’s statement! “It would seem Core developers are too far detached from that level of user to understand the ramifications of a tiny change like this.”

          To me this points to the need for the WP core developers, and the community in general, to pay more attention to people like us who work directly with WordPress users — AND know quite a bit about WordPress under the hood as well.

          Already today *I* lost a few seconds, two different times, while looking for that button. Not a biggie — there’s another one up there in an awkward place — but still puzzling.

          Create forum topic from comment

      • Went right through that ticket and looked at the reference ticket. No one made any compelling argument for change.

        One person made a very good suggestion of an alternative but was told “Let’s leave bigger UX changes to another ticket“. Ironic considering how much the change they made affected UX.

        What stood out was some devs without consideration of real end-users, decided they didn’t like it because “buttons should be actions, not links”.

        That may be fairly valid from a pedant’s point of view, but the amount of time and effort spent on it, and the lack of real user consultation, was ridiculous.

        And in the end, the project owner said “I would still like to run more tests, especially with non-WP users… However, I am going to commit this now, as that also attracts more eyes and I won’t be hurt if we have to revert this. I just want this to be resolved one way or another.”

        As the backlash from real users suggests, this was a non-issue that didn’t need fixing.

        This is a classical example of the other side of what bad UX is all about.

        UX isn’t just about usability. Supposedly improving a UI can cause bad UX for those used to the old UI.

        There’s an old saying I like to rephrase a little…

        “If it ain’t broke enough don’t fix it.”

        Create forum topic from comment

        • My issue isn’t really with the “View Page” button specifically – but rather the philosophy (or lack thereof) which allowed this change to be made at all. The “View Page” button is sort of like a canary in a coal mine to me.

          It wasn’t broken, it wasn’t a bug, a majority didn’t want it changed, there was no compelling reason to change it, it didn’t fit into WordPress’s stated future goals/plans/roadmap (or lack thereof), and, most importantly, the ramifications to end-users was not considered.

          After all, end-users are who WordPress is for right? As a coder I don’t NEED WordPress to make a website or an App. WordPress’s purpose is to make owning your content and publishing easy for the average end-user. To me, every decision should consider how this affects them.

          I’m not trying to complain here – just having a conversation about the direction we point our fast-moving train before we shoot it off in the wrong direction (to use Matt’s analogy).

          Create forum topic from comment

        • What stood out was some devs without consideration of real end-users, decided they didn’t like it because “buttons should be actions, not links”.

          “Buttons should be actions, not links” is an accessibility concern. A myriad of similar changes have been happening throughout the admin interface for the last 5 or 6 releases.

          That aside, I wonder if you could define a “real user” of WordPress. Core developer are users too, daily users in fact. When the change was made, we all had to adjust to the new workflow just as much as the next user, power (user) or not.

          I do think we could have vastly lessened confusion from the button being removed by displaying an admin pointer explaining the change — a tool that has been leveraged less and less the last few releases, unfortunately.

          Create forum topic from comment

        • Hey Drew. Thanks for the clarification on the buttons. That’s a fairly sound explanation.

          But why did so many users not know why this change had happened? And where could they find the reason – besides the trac? (I see Helen says on this site, which is hardly the ideal place for average users to find info.)

          That really sums up the problem WP has with communication. It’s sparse and in the wrong place.

          I really don’t think WP crew live in the real world. They just seem to assume that everyone is on the same page as them.

          When you question “why” you more often than not get told to look the trac ticket.

          When you raise an issue, you get told to submit it on trac.

          So Joe Average user goes to the trac and it’s nerd nirvana. He feels way out of his league. So he doesn’t read the ticket, or submit.

          WP/Automattic acts all uber responsible and thoughtful – still supporting ancient layout techniques and PHP 5.2 – yet when they release an update, information is scarce and hard to find except for major features. I can’t find the 4.4 changelog link, and the 4.4.1 one takes you to the trac and a list of tickets, which I can then change to show the 1016 tickets affected. All very user friendly, not.

          My impressions is, and always has been, WP don’t eat their own dog food. Too many things in WP where you think “Does whoever made this, really use this??!!”

          e.g: Lack of media categories still, despite major overhaul of media library, and despite being one of the most requested features when a call is made for feature requests.

          e.g. 2: A colour picker layout that is different to every design software’s default layout (the vertical slider should be colour, not saturation).

          As you could guess, I do have a love-hate relationship with WordPress. It’s mostly love, but there’s enough to hate to make me tear my hair out sometimes! :D

          Create forum topic from comment

        • What stood out was some devs without consideration of real end-users, decided they didn’t like it because “buttons should be actions, not links”.

          This is not pedantry, but conformance to both the HTML spec and the W3C guidelines, although in the case of the view page button, it could have been made an actual button element, as opposed to a link that looks like a button.

          Create forum topic from comment

    • A little off-track from the originating topic of speed of development: interestingly, this particular change is an example of something that I put significant deliberate effort into communicating clearly as well as actively seeking feedback both from testers and from the more vocal parts of the community. There was an entire post about it right here on WP Tavern with a lot of comments, including some very good critical ones: https://wptavern.com/wordpress-4-4-removes-the-view-post-and-get-shortlink-buttons-from-the-post-editor

      When looking at the totality of effects and feedback, the good/positive outweighed the not-so-good, so the change was kept. It’s very easy to only see a subset of feedback; this applies both to only seeing backlash as well as only seeing praise. UI removal is not done lightly nor randomly nor without recognition of such factors as habits and training – I am not sure that my saying that will be believed or trusted, but I would like to state that clearly.

      It’s important to remember that there is an audience we inherently don’t represent ourselves: new users coming to WordPress. For them, this is not a removal, but rather a first experience that is less likely to confuse and more clearly communicates what action a user would or should take in a given area. There are also considerations like the growth of small-screened device usage, which still have valuable screen real estate taken up by minor actions all around the admin. Core’s general movement has been to make such changes incrementally – sometimes I think it takes so long we’ve all forgotten the original intent.

      I’m personally going to keep building a habit of this kind of communication and feedback collection. However, I think it’s understandable that not everybody wants to put themselves out there and invest effort into either soliciting or giving feedback when hard work is so easily dismissed, so we frequently end up in a cycle where contributions are one-dimensional, and users and developers alike are left feeling frustrated and unheard. It’s unclear to me if this is a solvable problem, but I’d like to believe it can get better, at least.

      Create forum topic from comment

      • Id claim most WordPress users has never heard of WPTavern an even lesser amount has ever visited any of the make blogs. Heck I think fewer and fewer end users will visits .org and just search for themes and plugins directly in WP Admin as time goes on.

        Perhaps some alternate means of communication could be brainstormed so that the affected users are reached in advance of changes. Heck graphical change suggestions could be part earlier releases. So you can “preview” changes that are coming.

        Create forum topic from comment

      • I dunno. Trust a woman to introduce a note of total sanity, just when us guys are about to get down to a good old knock-down drag-out, about not very much at all.

        Thank you Helen.

        And just as an aside: I watched a thought provoking video on Ted today from Halla Tomasdottir of Audur Capital about Iceland’s financial meltdown, a few years back.

        I think it serves to illustrate what I am getting at, very well, and probably colored my thinking too.

        OK, back to the know-down drag-out.

        Create forum topic from comment

  2. Ugggg

    I’m now down to 1 last issue I need to fix with the latest version that rolled out. I had a ton and now it’s like 1 issue I hope. Who knows when I fix it… will there be more.

    Will the next update roll out when my blog is bug free and cause more headaches. I do use premium plugins as there support is top notch but a few other plugins I have you wait like a week for a response from the plugin author. lol

    Create forum topic from comment

      • Matt made a very good point in response to Mika’s question. Paraphrasing he said something like ~ most human beings tend to overreact to change. Some more so than others.

        And why shouldn’t they have some way of maintaining their comfort level, if possible, like those plugins that put stuff back in, which the devs just took out?

        It might be whimsical to you and me, but it can be the difference between satisfaction and total frustration to somebody else.

        Create forum topic from comment

  3. The issue is, something that was working fine for years breaks all of a sudden. Flickr embed code, such a simple thing, now breaks the formatting of my posts when I use more than one image per post. Not sure where the mistake lies but I generally follow the mantra: “Don’t fix something unless its broken.”

    Create forum topic from comment

  4. I agree with Phil. I’m an end user, not a code wonk. I don’t have time to be a coder…I’m running two tiny businesses and helping expand two more. I loved the basic functionality of WordPress back when I first built my blog in 2012: I could update my blog easily and quickly. If I were starting from scratch now, knowing that I’d have serious site failures in four of the last six upgrades, I’m not sure I’d make that choice again. I’m still short on $$, so it’s not like I can hire a FT webmaster to do it all for me.

    This quote strikes me as a good example of the Core developers’ attitude toward end users: “Mullenweg answered the question by saying improvements can be made to the plugin directory so that users can share the burden in the testing process.”

    I’d love to help play in your playground. But I don’t know enough to be a good partner yet, and I’m only sleeping four-and-a-half hours a night as it is.

    Create forum topic from comment

    • The quote is a small sample of the reply. I encourage you to watch the video to hear the full response to the question as it may change your perspective. You don’t need to know much to be a good partner. It’s as simple as using a test version of the plugin and if it’s broken, report it to the author.

      Create forum topic from comment

        • To be absolutely clear, empathy is a good thing. I can understand how Crane is already under the gun finding some work/life balance.

          But how exactly is this a WordPress problem to solve? There is zero data in his statement other than he’s struggling to startup not one, but two separate businesses. This would be a struggle for anyone, so I am not bashing Crane. I imagine that many of us, from various walks of life, can relate in one way or another.

          I just cannot see how this is even pertinent to the conversation other than recognizing that for ‘folks under stress’ — any change to WP from now till forever will be in invitation for regurgitated frustration.

          How is that helpful?

          Create forum topic from comment

      • I won’t answer Crane’s question directly, because I don’t want him to think I am on his case, so I will answer Toby’s instead.

        How is that helpful? Its a personally felt viewpoint. And all viewpoints are helpful. OK, some more than others.

        If I asked Crane, should he be lucky enough to buy a new car, would he expect it to look like, have the same technology, and gas mileage, and be as out of sync with modern roads as the car in which he passed his driving test?

        And he’d probably answer, no, of course not.

        So, his viewpoint is not the whole picture and a universal statement for all time. Its just how he responded in the moment, probably under stress.

        We all do it. At least I know I do.

        Anyway, what I am saying is, cut the guy some slack and just take his complaint for what it was.

        Create forum topic from comment

  5. Besides that wordpress is moving to fast and on fixing existing bugs they are moving to slow. There are bugs in wordpress which have been open for more then 2 years now. Moreover look what happened at 4.2.1. We got a email to test stuff and after two days it was released already. But the pagination in static homepages did not work anymore. A new bug was introduced. To me it looks like a loose canon going all directions creating a lot of issues as sometimes consensus is lacking in the core team.

    Create forum topic from comment

    • Have you reported the bug on the WordPress.org support forums? I’ve had the pleasure of reading the dev chats which anyone can do and It’s apparent that the team has a consensus when they make a decision. They can’t discover edge cases although they try their hardest.

      Create forum topic from comment

  6. With almost 5 years of WP development experience, I find WP is the most reliable web application when it comes to updating /upgrading. For me, in most websites, updating won’t cause any issues, until some function get deprecated, just in 4.4 I encountered a core (already reported) bug when I needed pagination in a static front page.
    If you choose your plugins and themes wisely, and follow WP coding standards, you would like to see more new releases of WP because you know it will just work :)

    Create forum topic from comment

    • Google Chrome doesn’t move too fast. They release often instead with incremental changes.
      Mozilla Firefox is adapting something similar with running four branches of development (release, beta, aurora and trunk) at once where branch content is promoted every 6 weeks.
      It actually works well in our day where the actual version numbering doesn’t represent much.
      The old habit was to break ABIs with major version numbers 3.xx -> 4.xx.

      Create forum topic from comment

      • Google Chrome has been cited as an example in the last few years of where WordPress development is likely heading. That is, version numbers become non-important and WordPress iteration happens rapidly instead of major versions released every four months. We see this a little bit in the point releases but not in the major versions yet.

        Create forum topic from comment

        • but wordpress is not a browser. when your browser fail, you can simply use another browser.
          when your site fail you cannot simply change to another cms.

          but “I get it”. and I’m sure most people here probably get it too.

          it’s just probably not the direction we want.

          and I also get that wp core team and matt is not asking for permission or even suggestion.
          they simply announcing it.

          this CMS is no longer ours.
          pretty much closed source in “spirit” just like google chrome.

          Create forum topic from comment

      • If I were asked, I would prefer the Apple model for OSX, one major release per year, the rest of the time only security patches.
        You can even choose to stay in an older version and anyway keep up with security patches. I see all the time people running Mavericks without any trouble.

        Create forum topic from comment

    • lets see, when chrome breaks, I can use instead FF or IE or safari or Opera and the switch takes minutes. What exactly should I replace WP with when it breaks?

      Chrome is not essential to any one which is the reason why they can release tards that break the WP admin and get away with it. OTOH people rely on wordpress to generate income and for some it is the main source of income. Unlike with chrome a WP fail will cost them actually money.

      You are also confusing release cycle with release versions. Looking into FF development which is more transparent, the work on version 43 released on 2015-12-14 started at 2015-08-10 (https://wiki.mozilla.org/RapidRelease/Calendar) therefor a release development cycle was 4 months, not 6 weeks as people tend to assume and the same most likely applies to chrome. Taking into account the “after release” breaks core development takes, each wordpress release probably being developed faster then that.

      Create forum topic from comment

  8. I’ve built and maintained a lot of WordPress powered sites. I have never had a well implemented WordPress site fail during an upgrade. The sites which fail during an upgrade, have always used some nasty looking code which was bound to fail at some point.

    So the solution is … don’t use crap code. Problem solved :)

    Create forum topic from comment

    • I’m in the same boat with you, I haven’t really had any issues with sites breaking except when they are using some obscure plugin that doesn’t follow proper standards.

      That being said, I do think that “*crap*” code is acceptable depending on how stinky it is. We’ve all written our fair share of code that we regret, even WP core has some things in it that is there for reasons that matter and can’t be removed.

      As long as it is secure, doesn’t cause performance issues, and doesn’t conflict with other plugins, it doesn’t have to be perfect.

      Create forum topic from comment

    • The same experience here.
      Someone who opens admin once a month without much technical knowledge can not expect the same result as some programmer or someone who paid for some service for this or at least as someone who open that dashboard several times per day :)

      It would be great if more people can see differences, that one website can be done almost for free while similar site can cost thousands of $ or hundreds of invested hours. The difference is somewhere there, not just these hours or dollars.

      Create forum topic from comment

      • Terence, it is not a problem. The same applies to cars, computers, health, financial. It is ok, they just can not expect the same results as car-mechanic, accountant …
        Nowhere it works well, that you just search in google, pick first fancy tool and everything works excellent.
        If they invest their time or money, they can do some things or be supported by someone.

        Why some agencies charge 20k$ for a website which is similar to student’s “50$ package”? Bc. There is a difference.

        Many users just think, they will download WP, buy 0.99$ “unlimited” hosting, download everything free and then blame, that something is moving fast or moving to other direction that their stories.

        I don’t know why some users think, that they can one-clicked 20 installations of plugins, and they already achieve 1st in google :)

        How you wrote, “they don’t understand WP, theme, plugin.” The result of this is adequate.

        Create forum topic from comment

  10. I think that there is enough time to test and update plugins and themes once WordPress enters Beta for each new version. I have more than 40 plugins to maintain and update, and it takes me 1 day to test all plugins and usually 1 or 2 days to update what is needed. With some WordPress versions there is no need for any updates.

    To minimize time I need to update, my plugins use shared code library that is used for each plugin core and admin interface. So, most changes are done to that library and all plugins get the update, and that is a big help when updating for some important WordPress core change.

    Sometimes it happens that breaking changes are introduces during WordPress Release Candidate stages and that is what usually creates problem. RC stage is only for fixing bugs, no changes should be added into WordPress at that point, and that is something core developers must try to do better in the future. This happened with WordPress 4.4 and shortcodes parsing (and they reveresed that in 4.4.1), but I wasted more than one day to update my bbPress related plugins.

    WordPress core team needs to follow development stages rules better, and avoid to break things after Beta stage. That will save a lot of update time for plugin/theme developers and avoid nasty surprises when WordPress final release is out.

    Create forum topic from comment

    • 40 plugins tested in one day? sorry but I call BS. 12 minutes to test one plugin on average is not enough, just setting up the testing enviroment for each plugin and familiarizing yourself again with what it does takes more time. The only way it can take a day is if you are not testing properly.

      I guess you didn’t intend too, but your post basically says that all other plugin developers are total amatures, which is just not right.

      As for RC…. obviously if a bug that needs to be fixed requires a functionality change, then the change has do be done even if some people already tested things against the RC. That is why it is called an RC and not an R and plugins need to be retested against the release itself especially since many areas of the wordpress core code is a low quality globals ridden code.

      Create forum topic from comment

      • I have testing environments prepared on 3 test servers (local machines in the same office space) and total of 15 WordPress installations (5 are multisites) and different PHP version on each server, so I can test things in parallel, and these are used for WordPress testing only, once new Beta is out it is auto updated to all servers and websites. And these are tests only, fixing things usually takes few days after that (or even more).

        Testing one plugin can take 20 minutes up to 2 hour depending on the plugin, in a very intense 10-12 hours day with 3-4 plugins tested in the same time with some automated tests and some manual testing.

        For WordPress 4.4 I had only one serious bug slip into plugin after 4.4 was out. I am doing this for last 3 years now, and it worked fine for me so far.

        The only way to do it this fast is to have testing environment only for testing, and good thing about my environement is that it is never build from scratch, it is update upon update, just like normal website is.

        WordPress breaking plugin is very, very rare if the plugin is well maintained with previous WordPress versions. Testing plugin that was made for WP 3.0 and skiping all WP versions striaght to 4.4 will break a lot of things., but plugins should be updated for every WordPress version.

        Create forum topic from comment

        • +1 to great organization, but most plugin developers do not have access to this kinds of resources.which also require investment of time in setup.

          This brings back the issue of people expecting free plugins to be properly maintained without sending any money in the direction of the developer to enable him to have the time for that.

          Create forum topic from comment

        • Most of my plugins are not free, and I can invest money in the resources needed. And I completely understand how hard it is to follow WordPress development cycle for free plugins developers.

          @Chris Howard, I want to do that, but I plan to make some updates to the system using RasberyPi machines for servers (current system is very bulky, and takes a lot of space). Maybe later this year I can do that.

          Create forum topic from comment

  11. The issue with wordpress is not the fast cycle, it is the poor automated testing that results from badly written code. Someone estimated that function like canonical_redirect that is responsible for breaking the pagination in 4.4 is written so badly it just can not be tested in any reasonable time.

    The bigger your code base becomes the more automated testing you need to have in order to be able to release fast while retaining backward compatibility, and we don’t see any effort in any release to fix the situation. For example sidebars and widgets are almost not tested at all.

    Create forum topic from comment

  12. I have no problem with the update rate – my issue is that WordPress now is a different animal to what it was. A lot of my knowledge from even two years ago is out of date, from technologies to template tags.

    WordPress was ideal for the hobbyist like me, who wanted to go beyond wordpress.com but not become a fully-fledged coder/ programmer. It feels a little more opaque now.

    I’m not saying I’d like to go back to those days – a lot of good work has gone on under the hood. Although, there still isn’t an easy way to reorder lots of Pages (there used to be a twee note about this on the relevant screen, now gone)!

    Create forum topic from comment

  13. Been too fast for a while already, and all over the place, and pressing auto updates more and more just makes it worse. Of course it’s like juggling an ever increasing number of objects, be it for developers, those who do maintenance or the end users.

    Saying again, should have security and bug fixes asap whenever a problem is identified of course, maybe some occasional security enhancements if they’re optional, at least until included in the next major release, so people will be able to have all fixes while skipping on enhancements they may have concerns over, and every few to several years a long term support version built specifically for stability, that will continue to get security and bug fixes and maybe also the optional security enhancements for many years to come for those who want to stick to the tried and true. Alternately, go down to one major release per year and continue to maintain the past few releases in terms of fixes to get a sort of similar effect, but I’d still prefer the formal LTS route, which would also still allow the fast development for those who want that.
    And also saying again, may be a good idea to have some sort of WordPress Lite, for those who still just want to use it for simple blogs, just post something every so often, as the full version is also usable as a CMS and for commercial sites and what not and there’s just too much there.

    Create forum topic from comment

  14. The fast WP movement makes me think of a different place for WP. If you are a small site owner on your own hosting, it’s hard to keep up. On the other hand, WP.com and other big hosters can amortize upgrading across thousands of sites. So maybe WP is moving to a more SAAS-like setup with continuous upgrades.
    That will change the ecosystem quite a lot.

    Create forum topic from comment

  15. Is WordPress moving too fast? Look at WordPress repository- 12 weeks for Theme Approval time- Fast enough?

    Automation? Theme Directory improvement? A year old irony.

    May be another year to look forward for improving WordPress.org (be that Theme/Plugin Directory or the Docs/Codex)- not just pushing a few things here or there to make a nice “List of improvements”- but the actual improvements that would mark the progress with effectiveness.

    The problem w/ WordPress.org isn’t lack of volunteers- spending enough time around, as far as I’ve understood the issue is lack of focus-

    While the full-energy spent on WordPress the software, not-enough energy are spending for the experience around it to help people moving along.

    My 2 cents.

    Create forum topic from comment

    • You are correct, but the nice thing about technology ~ its like water. It finds the course of least resistance, and then flows round the obstruction.

      If the repository remains, lets say “suboptimal”, for long enough, it will become patently ~ even to die-hards~ irrelevant to people’s needs, and another way will be found to provide the end-user with the visibility of what’s available in the ecosystem, to download or buy.

      Create forum topic from comment

      • Absolutely- :)

        And then, there might be more things going on than what we see- may be the rapid changes on WordPress the software- getting somewhere so fast that it doesn’t make sense to optimize decade old things on WordPress.org- may be tons of things are already became so obsolete that the whole needs a make over.

        The best of the echo-system is that, like you’ve said, the community will find one way or another- to get it right, at the right time- ;)

        Create forum topic from comment

  16. Updating, managing, support is what we do, everyday. So it being moving too fast is actually an advantage for agencies/designers/developers that channel their clients to us. While it ultimately becomes our problem now, we deal with the issues of “Where did that View Page” link go quite easily since we support numerous of sites and things are made for the masses.

    For me, what is more concerning is that with all these new releases — is ensuring the plugin and theme developers are keeping up. Because one of the biggest issues we’ve encountered is that themes and plugins break sometimes after core has been updated, or better yet, forced to be updated. This is great practice in theory, but in reality, plugin and theme developers must be kept up.

    How do you balance that?

    I think it would be extremely beneficially to the WP community IF WordPress core updates were released as a “beta” – upgrade if you want, and not have a final push until at least 14-21 days later.. which will give theme / plugin developers ample time to fix any errors or have reports of errors come in and release an immediate patch.

    Create forum topic from comment

    • This testing period is already baked into every major release cycle – usually spanning 5-6 weeks’ time. Case in point, there are 4 betas and at least one release candidate scheduled for the 4.5 release, slated for April.

      Betas are released and announced on the WordPress.org News blog weekly. The amount of time that passes between the first beta and final release is more than a month, so I’m not sure what you’re suggesting that isn’t already happening.

      I think it’s telling, however, that despite having such a golden opportunity to test and report/fix bugs, many plugin and theme authors still don’t take advantage of the testing window that every major release affords.

      Create forum topic from comment

  17. I don’t see this as being an issue. However, what I would like for the team at WordPress to focus on is keeping pace with some of the other theme developers. I think if we could potentially see WordPress developing its own version of a page builder that works within the majority of themes, this would be a huge victory to those who rely upon WordPress to deliver amazing content.

    I would rather focus on a theme that appealed to my senses and content, versus having to choose on that limits my ability based on the ease-of-use of any given page builder.

    Let’s face it, the majority of page builders out there utilize the same type of content type blocks. Why not provide that as a benefit to using WordPress being built-in to its core level and possibly even attracting a greater level of users to come on board.

    Create forum topic from comment

  19. I am not a programmer and in the current state of WordPress and its ecosystem (plugins, themes, code snippets, tutorials, documentation, blogs) I am able to build cool and profitable websites on my own.

    I am thankful for that. I really appreciate this big opportunity for me to get revenue from on-line business. This is incredible, drink a coffee at home, listen to good music and do a business in the same time in front of my Mac.

    I am not sure if there is one feature or something that I will ask to add/remove to/from WordPress. Anything that I imagine, I can do with some plugins and theme. I don’t feel any limitation there.

    Sure there are some small changes what I like to add/remove, but these depend more on actual work I do with a website, and it changes all the time.

    I see how WordPress evolves, what developers, designers, contributors do. I can read their thoughts on their blogs or Twitter. I know, they are so talented and smart, they work a lot … I don’t fear while these amazing people are there. (As I am not a progammer, I need them to stay so smart and as hard workers)

    Also, I can clearly see the difference between WP, plugins, themes one year ago and now. All of these are better, more powerful, flexible.

    My thoughts are that technology at all and WordPress don’t run too fast, some people are just slower, but it is not an issue with changing technology. The majority of people don’t like any changes and prefer something stable working forever, but it’s not how life is done.

    If php7 is out, it helps my website, I want to use it, I want a better website, I don’t want to wait, bc. some other people/businesses need one year for implement something somewhere :) I don’t have to it, I change hosting/plugin/whole system if I am not able to use the best :)

    Btw. If somebody don’t like the speed of WP, there is something called Joomla ;) Yes, it’s still almost alive :), there you don’ need to worry about speed od development, there is just maintenance for years.

    Create forum topic from comment

  20. I’ve been pretty happy with the release cycle and have been impressed with the number of things accomplished during those intervals.

    I’ve followed a few of the discussions on Make Core and it has seemed to me that core developers make a great effort to understand and consider the ramifications of changes. No one is perfect, but the effort is truly there .

    Remember the major debates about the theme customizer and not allowing alternative options pages bundled in themes? At this point I think the core and theme review teams deserve a nod for their foresight and determination despite the firestorm. It was a tough journey that is not finished yet, but the improvement is real.

    Create forum topic from comment

  21. Having spent the last while enjoying the various development blogs and such, I have come to the conclusion that WP isn’t moving too fast, rather it’s moving in the wrong direction, which is the inclusion of more and more things into the core.

    I hate to harp on Emojis, but they are the perfect example. There is absolutely no reason to have them as part of the core. They are perfect plug in material. The core should support the ability for a plug in to add this time of capability, but it should be part of the core.

    Adding featuring to the core such as this creates a situation where it’s not the users deciding that they need a feature or which features are the best, and rather we have that pre-chosen for us. Yes, you can in theory override much of it, but it’s a lot of work just to strip away functionality that you don’t need.

    The core should provide the basic services and the platform by which others can be added. Sticking more and more functions into the core build which are not really “core” to wordpress is it’s own hell.

    The developers often seem a little out of touch with the user reality on these thing. Reading the development blog and wading through TRAC is really sad, annoying stuff. It’s proven to me that the gap between the end user / webmaster and the developers is growing, and I would say that Matt’s own attitude in this seems to be a big driver here.

    Create forum topic from comment

    • I hate to harp on Emojis, but they are the perfect example. There is absolutely no reason to have them as part of the core.

      To be fair, adding emoji put a face (no pun intended) on the wider feature of adding better Unicode support to WordPress. Unicode covers vastly more than funny smiley faces. It covers character sets for many non-English languages, and in a time where non-English downloads of WordPress now surpass English downloads, that’s an important improvement.

      For what it’s worth, I agree with you that core could be leaner in a lot of ways. Continually adding new functionality without some kind of sunset plan on removing old, outdated, and deprecated functionality is unsustainable.

      Create forum topic from comment

    • When you speak of emoji, you are likely referring to the twemoji shim that is loaded on the front-end of sites. It’s inclusion is really just a bug fix for the fact that some browsers don’t support emoji. Visitors to sites shouldn’t see ? (an empty square box) when ? (nail care) is what the author of the post expects them to see. Emoji is not now, nor was it ever a feature.

      As Drew mentioned, emoji is a part of unicode and full unicode support in WordPress is a HUGE feature. The ability for users around the world to write in there native language inside WordPress is incredibly important as a part of the mission to democratize publishing.

      Create forum topic from comment

      • Aaron, I understand – but the question is simple: Is it CORE, or is it a feature that could best be served as a plug in, add on, or optional module?

        For me, CORE should be the core functionality on which everything else is built. WordPress, because of the way it was built originally, doesn’t really have a core. Rather, it’s an all in one package that has been written in a manner that is hard to break up.

        It’s sort of hard to explain the concept of the difference between functionality and usage. Can you imagine a situation where everything from the admin panel to the posting page was defined as a plug in or add on, which could be removed, replaced, or otherwise modified without touching core? The admin panel is, in the end, the usage of admin functions. It’s not the functions themselves.

        I doubt WP would ever go down this road, because it would require a serious re-write to get there. But safe to say, I am all for minimizing the core and what is shipped in the default package. The true power of wordpress is in the customization, the plug ins, and so on. The more you can define yourself, the more the product becomes personal and usable.

        Create forum topic from comment

      • This is what is so annoying in this feature, nowhere else that I can think of wordpress core tries to do things that browsers do not support, you should always aim to the lower common feature set of browsers or at least leave it to themes.. What happens with the shim when JS is disabled?

        By the time the wordpress release was out chrome got proper support for emoji and it was not needed any more. now it is just a peace of junk code slowing down 25% of the internet for no real reason, and now that it is not needed there is no plan on when it will be removed.

        Create forum topic from comment

        • Do you have any stats that show “this peace(sic) of junk code slowing down 25% of the internet for no real reason”? What makes this code junk in your eyes?

          Are you arguing that ???????????????? filling up a page is a better experience? Since not having the polyfill as a bug fix would cause this experience to be provided.

          Create forum topic from comment

          • You are asking for stats as if avoidable needless waste is acceptable if it is not too bad.

            The code itself is idiotic because it assumes that browsers will always use a specific filler that can be detected because we know there are no other browsers in the world and there will never be and those that exist will never change their error behavior. That code is a very stupid way to do browser feature detection.

            why only emoji, why not to add similar code so that people that don’t have hebrew fonts installed on their cpmputer will not get some weird characters when reading my hebrew blog? There are probably more people that post in hebrew then people that post with emojis.

            Now lets get to how it makes the internet slower 1. Obviously the JS has to be executed on each page load and the detection is done using canvas which is an expensive operation. For a wordpress site with 40M pageviews a month a delay of 1ms means a waste of 1000 seconds a day, about 16 minute. Now that site is just about 4k in alexa so multiply by whatever factor you like, and we talk only about daily waste of time.

            2. The less obvious way is by making html size bigger which means that the zipping of each page takes longer and makes the server work harder and be less responsive, and then if you are unlukcy it will mean that you will need additional TCP packet to deliver the HTML and in addition to making the page slower you create more network congestion.

            This kind of stupid things is expected from plugin and theme authors, it is a shocking surprise when it comes from core. After all, the core development moto is “decisions, not options”, but in order to be able to say it in a straight face the decisions has to be perfect and this one was light years from perfect.

            With 20k active users for this plugin https://wordpress.org/plugins/disable-emojis/ how can core developers says that they actually communicate with the community when the community is voting against that feature but it doesn’t seem like anyone in core cares about the feedback. Maybe someone should nominate it to be a featured plugin for 4.5

            Create forum topic from comment

          • Ryen, your correction accepted, but why do wordpress try to polyfill emoji and not srcset? If a major (biggest?) browser do not feel like it should put effort into proper support of the feature why do a much smaller organization try to educate it? Never in IE6 days wordpress had added a shim for proper alpha channel support for png images so what changed?

            Create forum topic from comment

        • Twemoji loads only when needed and does so asynchronously, meaning it loads and runs in parallel with content. The assertion it slows down a site is just incorrect.

          I’ve seen it suggested the inline code be moved to an external file. This would require:
          * an extra http request in the header
          * the external script would block rendering
          * a request header of up to 5K, depending on browser config & cookies.
          * a http response header, somewhere between 0.2 and 8Kb.
          * the additional delay of making an extra request – call it 100ms to be generous.

          All this to load a 1500 byte script. Moving it to an external file really would slow down 25% of the internet.

          Create forum topic from comment

          • @Reter, please familiarize yourself with the emoji code before commenting on its impact.The shim itself is 1.5k and you also have a style. It makes the browser work harder in parsing JS and CSS and css style matching might become slower, or do you think browsers use zero effort magic for that?
            And this is for all site pages whether they use or do not use emoji in any way.

            There is no improvement that needs to be done here, this is an obvious plugin feature that should have never got into core, core has no business emitting JS and CSS, this should have been left to themes and plugins.

            As I said in another comment forcing a proper emoji display on the whole internet is as logical as forcing a proper display of hebrew on the whole internet. People that want to see emoji characters can use IE or FF or safari if it is important for them.

            Create forum topic from comment

      • Do you think emoji’s will still be around in ten years? I don’t. If code to read emojis is slowing things down I’d be happy to get rid of it and not see them. Most of them are too small for me to see anyway and I seldom know what they mean. It would help if each of them had alt text to explain what they are. But, wasn’t support for that taken out of WordPress recently?

        Create forum topic from comment

  22. If you follow WordPress best practices when you write your software, you shouldn’t have issues. I have themes that were written back when 3.2 was released that are still ticking along just fine with no issues because they followed the API to the T and did exactly what the documentation said they could.

    The only issue I’ve had was with the changes to the shortcode API, and the only reason that I ran into issues with that was due to third party plugins that didn’t follow the original documentation completely and exploited unintended functionality to do something shortcodes were never meant to do. (I inherited this site so its clear and the plugins in question are https://wp-types.com/ they’re using shortcodes to create templates and were surprised when it broke)

    WordPress is doing fine when it comes to development and they are following there mission to a T. It’s not there fault that developers are exploiting unintended functionality instead of doing it right.

    Create forum topic from comment

    • Hi Robert

      This is Juan, lead developer on Views, part of Toolset. I do not want to open fire again about this, but I wanted to add my 2 cents about this.

      First, the change that broke our shortcode was merged merely hours before it got released, so I do not think it is a god example on how developers and site admins should betatest WordPress upcoming versions. BTW, we always develop over the latests release and the latest nightly build, and we foresee deprecations and changes in time. It can not happen when a breaking hotfix, which was indeed needed (security goes first) gets released and automatically updated without proper prior notice.

      Second, this is indeed the only example I can remember of WordPress releasing an update with some breaking changes without proper notice. And I’ve been around fore some years now. Credit where it is due.

      Thirds, we were not doing anything against best practices, standards, Codex guidelines or even code spirit. “intended functionality” is not something one can easily define. INtended by whom and for what? Shorcodes are placeholders based on attributes (meaning, variables). What you do with them is up to you, and of course we used them for templating. We also use them for other things that also got broken, BTW.

      Back to topic, as developer I would love to see WordPress moving even faster, if you ask me, and knowing that backwards compatibility is a must ensures the right path. But that is not always the case: there have been several proposals for a new syntax for shortcodes that got rejected by the core team besides a whole affected-team of developers, meeting in an official room in the Slack channel, agreeing in it.

      Regards.

      Create forum topic from comment

  23. I understand the release schedule and like that it is more of a reliable schedule than before. And I don’t think slowing down the release schedule is the answer. But what if we stopped pushing major updates down users’ throats and increased backwards support?

    We could define major, minor, and security releases, and establish what belongs in each. Significant UX changes, for example, belong only in major updates.

    Create forum topic from comment

  24. I have noticed that its not the WP updates that break my client sites but their plugins and themes. It doesn’t matter how often WP is updated, what matters is the quality of the plugins and theme a site is using. Badly written plugins and themes will break eventually so WP users should focus on creating a backup prior any update and use only trustworthy WP themes and plugins.

    While I don’t complain about WP moving too fast I know that some of my to-be clients stopped using WP because of that.

    Create forum topic from comment

  25. As a plugin developer and plugin business owner, I had very little trouble with compatibility between new WordPress versions and our plugins.

    Simply put, the effort put into backwards compatibility is exemplary. Take the old media upload api functionality. If I’m not mistaken you can still use it if you want to in your plugins or themes. That was replaced by the current media library system 3 years ago, in WordPress 3.5. That gave us plenty of time to move to the new API and we didn’t feel one bit pressured because we know we could do it at our own pace.

    In the past years, the most issues we had were with our own code or compatibility issues with other plugins and themes, not new WordPress versions.

    Create forum topic from comment

  26. At the risk of sounding like a stuck record, the three changes I argue for:

    1. Move core to Github.

    2. Significantly increase number of bug/maintenance updates releases for fixes a la Chrome.

    3. Reserve major changes on features and design to quarterly releases.

    I agree with @photomatt that more incremental releases, and use of REST API is the best way move WP forward.

    I swear, I’ll work on core contribs if we just get #1 done ?

    Create forum topic from comment

    • 1. Move core to Github.

      Is it simply that you’d want to contribute to core via git, or are you particularly tied to the system GitHub has in place? I ask because contributing with git is already possible via the official git mirror. Yes, you still have to contribute patches via Trac, but more on that below.

      If it’s specifically GitHub that you’re after, there are a myriad of logistical stumbling blocks that stand in the way of such a move, many of which have been discussed ad nauseam. The biggest one, in my opinion, being that GitHub’s current toolset is not well-suited to managing a project of WordPress’ size and complexity.

      Create forum topic from comment

      • I meant Github. I know about git mirror. In fairness though, when you say the toolset is not well suited to managing a project based on size and complexity, I am curious about specifics because node.js, jquery, ruby on rails, are pretty large projects and they are on Github.

        It may be a matter of cleaning up the mess, so to speak, and such, but that could be a good thing. But I’d be interested to here specific points on the argument against Github. I am certainly open to changing my mind on that request.

        Create forum topic from comment

        • Standout issues that come to mind are:

          1. Multiple users can’t collaborate on a single PR unless they each have write access to each other’s forks.

          2. The decentralized nature of git actually hinders contribution in a project of WordPress’ size. When you clone WordPress, you get the entire history which can be prohibitively large. We have more than 35,000 changesets and counting — that’s a lot of history to download.

          3. The tagging system in PRs and issues is pretty barebones. Especially when you consider the depth and breadth of the WordPress codebase. I don’t have a current count, but I think we have something like ~300k lines of code spread across 50+ components on Core Trac right now. This is almost unmanageable as-is, and yet with self-hosted Trac and SVN we have a lot more control over availability of tooling because we can create our own tools as we continue to scale. Moving to GitHub largely hinders the ability to scale from an organizational perspective.

          Create forum topic from comment

    • I agree with #2 personally. Chrome runs better than Firefox or Opera but seems to have more trouble with software glitches and things it won’t work with. Web Unity (I don’t think I’m remember the name right) won’t work with Chrome but does with the other web browsers. The other two tend to freeze up. I always think that is such an old problem from the days of dial up. Chrome almost never freezes for me.

      Create forum topic from comment

  27. Having been in and out of WordPress and Drupal development for a decade, there is no perfect approach or methodology for a good ecosystem that minimizes hassle.

    In the last year Drupal.org got a polished continuous integration system set up so that git patches are pushed through testing on several different sql & PHP versions. I think a major push to modernize wordpress.org plugin support thread management and introducing CI ( meshing this with github or a free software equivalent if necessary) would help plugin maintainers deal with API changes much more effectively. It’s not possible to attach patches through the threads and that should change, first of all. [after all, has it really changed in a decade? Does anyone benefit from threads that get locked quickly, when the same problems recur year after year etc?]

    Also in Drupal world the community is the ultimate steward of the fate of modules while in WordPress the authors have more exhaustive control. When authors abandon their plugins, if others could claim plugins that are idle this would result in fewer, better plugins. Drupal modules are not allowed to promote their author’s wares either, which might be worth considering, although perhaps this pesky internal advertising system helps keeps more devs afloat. It’s quite a contrast to Drupal.

    Also as complexity increased Drupal forked off into Backdrop CMS, which is a lightweight, slightly modified for performance and easier maintainability with static files. WordPress Lite with a smaller API and mostly similar theme layer could work well as the core expands into trickier areas like REST implementation.

    Lastly I think that the Dependency Injection / Service Container system pioneered by Symfony and implemented in Drupal 8 would be good for WordPress to look at. It would let people knock out the code areas that they need for very custom apps (i.e. Buddypress) while still maintaining a lean core API. It would be great in the long run if WordPress 5 or whatever were totally rewritten to have a more modern structure than it has now… but only with good CI would the ecosystem keep up.

    Create forum topic from comment

    • Interesting that you mentioned Drupal. I was looking at Drupal this week, considering setting up one site on it instead of WordPress. I’m still deciding whether or not to do it. Mainly, I’m curious about Drupal and what it can do differently from WordPress.

      Maybe with the 15th anniversary of Drupal someone on WP Tavern will give it a write up to compare the two.

      Create forum topic from comment

      • You can spin up Drupal 8 sites on Pantheon.io for free (very modest service level). Also Acquia Dev Desktop is a local environment you can run to experiment with it. Drupal is versatile but difficult learning curve, and has nice mature features like Form API which aren’t in WordPress core. There are plenty of advantages in both directions

        Create forum topic from comment

  28. My reaction to the headline was, frequency of releases is not a problem.

    But when I read the counter issue, I though, heck yeah, maybe they’re right!

    When you consider the number of plugins sites run, there is a risk for site owners, which adds a layer of work for them to verify updates and roll back if there’s a problem (assuming too of course they have a good backup and restore system in place).

    On an aside, I do think WP should provide an easy method to roll back to the previous version of a plugin.

    As a plugin dev, I do all my dev work on WPMS and on the WP alpha. The only drawback I’ve found in that is sometimes the alpha breaks other plugins I’m using. :P

    Personally, I haven’t had too many problems with WP releases breaking my plugins. v4 was the last time I needed to make any major changes and still have problems after its release. And 4.4.1’s changes to query vars offset broke pagination in one of my older, discontinued plugins.

    So the release speed hasn’t been a problem for me, but sometimes I do wish they’d slow down so I could have time to learn all the stuff I still don’t know, and the new stuff.

    Like probably most plugin devs, it’s not my full time occupation, so time is always an issue.

    As a plugin dev, I also know you do what you gotta do. So how does WP slow down? There’d be so much on their todo list! Though I don’t really want them to speed either. :D

    Create forum topic from comment

    • I’ve been trying to run fewer plugins. It is so tempting and automatic to plugin shop and try a plugin for just about everything and the kitchen sink. But, the more plugins you use the more likely you are to have glitches come up. At times odd glitches which make no sense and you can only track them down by deactivating (sometimes uninstalling completely) every plugin you use.

      So using less plugins is a good thing. I’ve been narrowing down plugins, deciding which I really need and which I just want to need. I’ve noticed a difference in how my sites run. But, better than that, I’ve got more time to actually write for my sites rather than maintain them.

      That doesn’t mean I don’t still plugin shop/ browse. It’s too much fun to pass up!

      Create forum topic from comment

  29. One more comment… Plugin and theme devs are not only trying to keep up with WordPress, but all the latest design trends and changes to CSS, HTML, PHP, and Javascript.

    I met a theme designer who said the life expectancy of a theme is about six months, so he needs to be releasing something new every six months. Throw on top of that keeping up with WP, and I can understand him being very busy.

    Create forum topic from comment

  30. I don’t run any one’s sites except my own. So I’m a WP user, not a developer. But, I do everything on my own for my sites, updates, fixes, maintenance, etc.

    WP does not seem moving too fast for me. I keep up with updates. Usually the same day because I check my sites everyday. I like the new plugin update feature which links from WordPress.com (I know it has a name I just don’t remember it right now).

    For me it works. Most of the changes I make are due to my own restlessness. When I need to fix something I find help online, after I’ve mucked around myself. Most of the time I figure things out without help.

    However, I do have sympathy for those who work for clients (though you do get paid for the time). I have more sympathy for those who are getting swamped with freebie work to keep up and then end up neglecting some of their paying work.

    The solution may be educating more WordPress users. Of course, this means they have to actually take action. To be honest, if they want point and click sites they should stick with WP.com or Blogger or some of the others which don’t require as much extra learning to customize and keep them updated.

    Well, that’s my nickles worth. (I’d say two cents but we don’t have pennies here any more).

    Create forum topic from comment

  31. I spent 25 years in mainstream IT before going it alone 8 years ago. I’ve always been in ‘support’ not ‘development’. It’s been my job (from lowly analyst to IT director) to see the IT service from the users’ point of view.

    Apart from not giving them the additional functionality they ask for (whether they need it or not!), the worse thing the IT department can do to the users is to change the way their systems look and work.

    Developers (almost) never see or understand this – generally, they don’t have to pick up the pieces or placate the angry hordes (unless they have to fix a new bug they’ve introduced).

    If something breaks, it’s generally relatively easy to sort out, even it it involves a full or partial roll-back, and doesn’t lose a user/business much time.

    If the way a system looks and works changes, there are huge implications because of the frustration it causes, and the retraining required (not to mention changed documentation).

    As the IT director of a 600-seat organisation, I had to choose if upgrading all the desktops from Win-XP was a good idea. The business management thought we should have the latest (and safest) version. When I presented the hardware and software upgrade costs, plus the retraining and documentation costs … they were entirely happy to stay with XP. The cost of the licenses was nothing.

    Now I build WordPress sites (far less stress than corporate IT). There are about 30 we host, of which half a dozen are family sites (who want everything for free). I’ve been able to persuade less than 20% of my clients to pay for a maintenance service. Most of the others are small one-man businesses or hobby businesses, and they tell me they can’t afford the £220 per year.

    £220 buys them two premium plugins (backup and security), offsite cloud storage for the backups, plus time to upgrade sites three times a year (always after the first WP maintenance release to avoid the bugs). I check the Change Log and latest Reviews, hoping to spot problems before I update each plugin. I use UpdraftPlus so I can roll-back if something causes a major problem (done this once so far this year, removing WP4.4.1). There are often small tweaks needed when the theme or plugins have changed. Paid-for plugins can be just as troublesome as free ones.

    This all takes time, and what’s left of the £220 doesn’t go far when spread over three updates a year. It also has to cover phone support … “where’s the ‘x’ thing gone?”. And I have to keep track of what I’m doing, issue monthly invoices (most don’t want to pay the whole amount upfront), and what might be coming in the next core/theme/plugin updates.

    I’m not fazed by the visual and functionality changes, but do get cross if something I’ve been using is taken away (padding for images?). I can fix problems, so long as they don’t require coding. I’m tech-savvy.

    My clients don’t edit their sites every day. It wouldn’t occur to them to read blogs about WordPress – it’s just a tool to them. It isn’t their business.

    I suggest all developers should be familiar with ‘change fatigue’. It’s normally associated with organisational change, but I’ve seen it caused by IT changes too. It’s demotivating.

    So, Matt old buddy, don’t increase the frequency of changes. Don’t change things for the sake of it, and for god’s sake don’t just rely on developers’ feedback.

    Create forum topic from comment

  33. I agree with the quote in this article – it is a struggle for many website owners to keep up to date with the latest versions and do any redevelopment work that it’s needed as a result. However this isn’t the result of WordPress moving too fast, it’s a side-effect of the fact that WordPress websites are built by combining third party themes and plugins that aren’t necessarily designed to work together. Clients love this because it reduces development costs, but don’t realise the hidden cost that this brings in terms of ongoing maintenance. You can’t blame WordPress, it’s just the nature of this sort of website. WordPress professionals need to educate their clients about the issues so they can make informed decisions about how complex to make their website in the initial development process. If they don’t have much budget for future maintenance, they need to keep things simple from the outset. We have spent a lot of time figuring out the best way to help our clients keep their websites up to date and fully tested, you might be interested to read my blog post ‘How we’re helping all our clients to keep their websites regularly maintained’.

    Create forum topic from comment

    • Well said I Katie K.

      ” WordPress professionals need to educate their clients about the issues so they can make informed decisions about how complex to make their website…..If they don’t have much budget for future maintenance, they need to keep things simple from the outset. “

      Although I been creating WP websites for 5 years, only the last year and a half I been working as a freelancer with small and mid companies, and now that I read what Katie stated so well this is the path I been going, keep it simple with WP and more complex functionalities go some place else, because for people like me Its hard to spend a lot o some (daily) time to see coming changes and to figure it out what implications may have in which website that I have created, and check if the client was informed, . . .and so on . . .

      I look forward for improvements with security issues and performance, because this has always been the criticism people have made. I love WP and the hole community its awesome!! . . . but Im afraid that for designers like me more than a incentive is becoming an uncertainty and a stress point.

      Create forum topic from comment

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.