• WordPress already has more features than I need at this point. I would love to see a reduction in the constant stream of required security updates. It is a hassle to install these updates, be surprised by a new interface, etc. And there’s a risk that if I don’t update soon enough, I’ll get hacked.

    Updating every 1.5 months sucks. Please, slow down, be more careful, and release solid code that doesn’t require constant patching. I think the list of releases for the past year speaks for itself. Each one of these *9* releases was a required upgrade:

    2.6 July 15
    2.5.1 Apr 25
    2.5 Mar 29
    2.3.3 Feb 5
    2.3.2 Dec 29
    2.3.1 Oct 26
    2.3 Sep 25
    2.2.3 Sep 8
    2.2.2 Aug 5

Viewing 10 replies - 1 through 10 (of 10 total)
  • I agree on slowing down the .1 update part.

    It would be nicer if security was dealt with seperately to functional updates, but that’s probably more complex from a development perspective.

    What I mean is that you can’t really slow down the introduction of patches for security, because the hackers do not adhere to a release schedule. But you could, possibly, keep them seperate to functional updates, so that sec updates are an easier patch/upgrade.

    Thread Starter zovirl

    (@zovirl)

    Yes, I think there are 2 problems here:

    1) Security updates are tied to functional updates, so to keep up to date on security I *have* to keep getting new features. I don’t *want* new features, wordpress already has enough 🙂 I’m dreading updating to 2.6 because honestly, I do not want the wiki-like history. It will just make the database more complicated and it isn’t useful to me.

    2) There are too many holes in wordpress, so there is a constant stream of security fixes that I have to install. I suspect that if less time was spent adding new features and more time was spent improving/double-checking security, this situation would improve. As a developer, though, I totally understand why devs might rather add more features 🙂

    I’m very seriously thinking about downgrading to the long-term support version, 2.0.11. It has been over a year since the last security fix was needed on that branch. I would give up a few features I miss, but oh…the stability…sweet, sweet stability.

    Incidentally you can turn off the revisions functionality.

    Thread Starter zovirl

    (@zovirl)

    Ah, good to know. That makes me less wary 🙂 Thanks.

    Thread Starter zovirl

    (@zovirl)

    Heh, so here’s a good example of what I’m talking about: I just finished re-installing 2.6 after getting hacked, and now 2.6.1 is released. Oh well…back on the treadmill 🙂

    I would love to see a reduction in the constant stream of required security updates

    That would probably mean substantially less response and development, and maybe even a at some point (shudder), a price tag on WordPress.

    Just to offer a different perspective, I see the frequent releases as very positive evidence that the open source nature of WordPress adds to its refinement and security. The community at large is much more likely (and if you spend any time in the forums, you can confirm this), to inspect, detect, report, complain, and on occasion offer constructive revision of WordPress code, as well as supply an ENORMOUS amount of feedback when something is amiss. I have noticed that a large amount of that feedback is related to feature requests. It goes without saying, that anytime you introduce or change a feature, you also introduce the possibility of quirks, bumps, compatibility issues, and yes, possibly new opportunities for attack and exploitation. I suppose it’s a trade off. Huge popularity and a gigantic user base means WordPress has a higher rate of inspection and detection. I see it as a good thing, and the Dev’s seem to respond very quickly.

    I suspect that if less time was spent adding new features and more time was spent improving/double-checking security, this situation would improve. As a developer, though, I totally understand why devs might rather add more features

    I think you hit it right on the head. Every time they do (respond to feature requests, or add new ones), the discovery and refinement process has to start all over again. Long term support projects usually don’t focus on providing a lot of new features. They usually focus on security aspects and refinement and stability of the existing product/program for the length of the life cycle. I like WordPress because everybody has an eye on it, and it responds quickly. Try to get that with most proprietary software (anyone use a “Windows” Operating System?). Sure, WordPress upgrades can be a pain. They bug me too, (and I have biffed a couple of them big-time!), but I consider the reasons and slog through it anyhow.

    …plus, it keeps my learning curve from flattening out!

    Just another opinion.
    Cj

    zovirl
    Member
    Posted 4 hours ago #

    Heh, so here’s a good example of what I’m talking about: I just finished re-installing 2.6 after getting hacked, and now 2.6.1 is released. Oh well…back on the treadmill 🙂

    No need to update to 2.6.1 if your happy with 2.6… don’t you people read the WP Blog?

    With 2.6.1, we’re continuing our trend of releasing a maintenance release shortly after a major release in order to get fixes for the inevitable “dot zero” bugs into your hands without a long wait. If you’re happy with 2.6, however, keep on using it. You need not upgrade to 2.6.1 if 2.6 is getting the job done.

    I update WP anyway, takes what? Five minutes to update for me. I have 5 blogs so that’s about 25 minutes time everytime a new update comes out..

    When WordPress 2.5 came out and the writer’s workspace was broken beyond repair, I began to wonder if there were enough developers interested in forking off 2.3.3. Leave the functionality intact (or, better yet, reduce it; in particular, the WordPress Development Blog and Other WordPress News thingies on the dashboard really need to go), but fix security vulnerabilities (possibly by borrowing from later versions, but also by adding a layer of security by obscurity; for example, xmlrpc.php and wp-trackback.php could be moved into a randomly-named subdirectory) and improve the documentation

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Request: fewer features, more stability & security’ is closed to new replies.