Work on WordPress 3.4 alpha has already begun


Shortly after the release of WordPress 3.3 “Sonny”, WordPress Lead Developer Ryan Boren committed the changeset to make WordPress trunk 3.4 alpha, rather than 3.3 final. There’s no project schedule or planned features yet, of course, but we can probably count on a 2012 release and that a few of these tickets marked for future release will show up in it.

Of course WordPress 3.3 has only been out for a couple of days now, but what the heck: what specifically would you like to see make it on to the roadmap for WordPress 3.4?

19 thoughts on “Work on WordPress 3.4 alpha has already begun

  1. WordPress 3.3 was the least important WordPress release in last couple of years considering features added. The only really useful additions are uploader with drag’n’drop, editor API and few core changes.

    Focus for next release should be to make robust management for posts, taxonomies and terms (current one is completely useless and very slow if you have a lot of posts and terms), to add relations between posts (only thing missing for full CMS capability) and to add database meta table for terms. I know that all this will take some time to do, but we don’t need 2 WP releases next year, 3.4 released in October or November would ensure longer time to develop and to avoid delays like this year) and to test things and not to get release that is mostly cosmetic in nature.

    But, I will not hold my breath for that to happen, we will again have 2 versions out, again with at least 50% changes related to UI.

    • I know that all this will take some time to do, but we don’t need 2 WP releases next year

      For what it’s worth, I agree with this, I’d like to take a holiday for the next 3-6months, infact, everyone on the development team should! That’ll leave just enough time for 1 release next year 🙂

  2. I for one would like to see better Press This functionality in 3.4, including the ability to detect additional post metaboxes from the default post type and add them to the Press This form. This feature would make press this a far more useful application for wordpress tumblr like blog owners. We have post formats at submission so why not allow detection of post metaboxes too?

    Also updating the youtube and vimeo embed code to the iframe versions in place of the current object code press this uses in the press-this.php at the moment would be nice.

  3. I use WordPress as a CMS. It’s a fantastic tool – I love it’s flexibility. But what is lacking the most in WordPress now is a complete user access management system. In opposite to WordPress in general it’s completely inflexible. All those steps made by Justin Tadlock when developing Members plugin, to make it better, is just not enough.

      • Question: Are there plugins out there that do the job well?

        Put it this way, Many people complain there aren’t any decent plugins for it, or the plugins don’t do it the way they want it.. This is why I don’t want one in core, because everyone else seems to want to do it differently, and potentially confusing.

        If the primary reason for wanting it in core is “I want a better experience” then that’s a call for “We need a decent plugin that does the job well! (and looks good too!)”.. and that should be a prerequisite for it being considered for core.

        I have never had a need for such a plugin, I know plenty of people who have wanted it however, but certainly a small portion of users too, which would also fall outside of a “80:20 rule” for what to include

    • I agree.

      The existing user access management plugins (the biggest being role scoper) offer a horrible user experience and are so clunky they drive load times way up for our editors. The more elegant ones (Members) don’t offer enough.

      WordPress needs better user management features to be seen as a respectable CMS (and I’m a big lover of it as a CMS, so keep that in perspective).

  4. The reason for putting it in core is for plugins and themes to have an API to call and register their admin screens.

    Plugins cannot possibly check if different access control plugins are active and play by their different APIs to register their functions.

    You would need an access control feature if you were the IT guy of a large site with different admins, editors and writers.

  5. I see four things that NEED to be addressed inside WordPress to make it the ultimate system
    1) Eliminate the term posts for something more universal like node (for custom node types) because there can only, as of now, be only custom page, or custom post types. Why not a universal term that can be expanded?
    2.) Taxonomy. Drupal has WordPress pinned to the ground when it comes to taxonomy
    3.) User Access Control. Make it all easily changable through a universal interface. Drupal has WordPress pinned on this one too.
    4.) Better Media Management. More things like detecting metadata inside images, mp3s, and videos along with a whole new gallery implementation as the current default one is, well, not to be touched by most people.
    Optionally, in a galaxy far far away, wordpress should add the following:
    1.) Front end control. Should be able to easily drag widgets on the front end, create content, and maybe (a very big maybe) have a universal standard for editing simple styles like text color, header images, etc (things that make the advanced WordPress frameworks shine)
    2.) A code editor with live syntax highlighting never hurt anyone 😀

      • It’s all about trade-offs. The amount of Drupal modules, configuration, and training it would take to make a system like WordPress is to high.

        • Yeah i understood your point (i was kind of stirring), but i think you could run the risk of making the core too bloated and alienating uses who don’t need WordPress to be infinitely configureable out of the box if they overhauled the post/page paradigm or made access control a chore by being too granular, you have to remember that the install base of WordPress is staggering and (i don’t have data to back this up) but i’m sure the vast majority of those installs would be actually as blogs.

          Most of the pain points you mentioned i think exist because they haven’t been solved by killer plugins the way forms, SEO, e-commerce etc have been. A better code editor would be superb though just for quick changes on the fly from anywhere, i’m behind you there, buddy.

      • The point is to make WordPress better, not to change it to other system. Comments like that don’t push things further.

  6. This is a small thing but I would love to be able to label widgets that don’t have titles. I don’t think it would be difficult to code either. Just an extra optional field really. A plugin would be fine too. (Must get out my php book again.)

  7. It’s really interesting to read what features people want worked on for future releases of WordPress. Also Dion makes good points about the 80:20 rule, and how do you go about including a piece of functionality that everyone seems to want done differently?

    I’m certainly interested to see what future releases hold, and hopefully even to participate in them myself. Ultimately in open source software if you want a feature why not get down to building it yourself? Or at least get involved in the discussion so you understand any reasons it may not be included.

  8. If you wish that wordpress should stay as a blogtool then 80:20 rule is ok but if you want to see wp as a cms you need to be a bit more visionary.

    Before custom post types and the integration of woo-themes menu we only used wordpress when someone payed us to set up a blog. Now we tend to use WP more and more but still there is a perception in the industry that if you want to have somthing running quickly its ok to use wordpress but if you want to do something more advanced you go with something else.

    As pointed out WP needs better User Access Control and it should be in the core not in a “killer plugin”. At the moment we need to do alot of custom coding to get plugins to work nicely together and a User Access Control. Alot of time is spent on things that should work out of the box in a cms when it comes to User Access Control. A good solution would not bloat the core and nor would it be more complex for users with less advanced needs.

    Other stuff that is needed in core for wordpress to be seen and used as a cms:
    Admin settings for custom post types, taxonomies and custom fields

  9. All I want is for custom post types to support all core WordPress functions. For instance, right now there is no good way to make a list of date archives for a custom post type. Finish implementing your old features before adding new ones please!

Comments are closed.