Roundup of thoughts on what 2011 should hold for WordPress


Jane Wells started a thread on the forum called “What should 2011 hold for WordPress?“. The purpose of the thread is to collect ideas for the upcoming core leadership meetup this month. The thread is being closed on January 4th (that’s today) so you should head over to that thread if you have your own thoughts to share.

Below we’ve collected a few of the more intriguing thoughts. Do you agree with their thoughts? And don’t be shy to share your thoughts with us too: What do you want to see for WordPress in 2011?

Mark Jaquith shared his thoughts:

  • Make one-click updates work for more people. Interactive setup guide instead of just an error message.
  • Drop PHP 4 compat.
  • Simplify taxonomy table structure by merging term and term taxonomy tables.
  • Improve the taxonomy API.
  • Media: faster, simpler, obvious.
  • Unit tests: they’re a mess. We need reliable ones, that run in some hosted environment so that every WordPress contributor can test their patches and see the result.
  • Move Akismet and Hello Dolly out of the core package.

Lance Willet had a few points:

  • Better handling of widgets when switching themes
  • Media improvements
  • Support for child themes in the directory
  • Front-page posting support for any theme

Justin Tadlock shared his ideas:

My suggestions:

  • Continue streamlining code, getting rid of cruft, and improving inline documentation of the code. I woulnd’t mind seeing an entire major release focused solely on this.
  • Put new features to “wow” users in core plugins rather than core itself (example: admin bar) and keep core lightweight.
  • I’d love for dynamic sidebars to behave more like nav menus. Themes register “theme locations” and users assign custom-created sidebars to these locations. This would make things such as contextual/dynamic sidebars much easier and users wouldn’t lose sidebars when switching themes.

+1 to other suggestions:

  • Term meta table or some way to add metadata for terms.
  • Some way to handle post-to-post relationships.
  • Centralized way to handle unit tests.
  • PHP 5.2+.
  • Drop IE6 support.
  • Establish a consistent API for front-end and admin Ajax interactions.
  • Build a better API for plugins to extend the nav menus, specifically adding new menu item types.
  • Finish custom post statuses (#12706).

-1 to other suggestions:

  • Grandchild Themes: If you need these, your theme author is doing it wrong.
  • Post type / meta box UI: These things are custom. A UI will never be able to handle the complexities involved. Improve how meta boxes are done if needed.

Matt Mullenweg popped in with a few ideas:

One of my most important things: better interface for plugins.

Visually two things that spring to mine are icons and custom headers for plugins in the directory.

Changelog support in the updater — what’s new is version X.X and why should I upgrade? (We could probably stand to do this for our own updater.)

When a plugin fails to activate because of a fatal error that should auto-report back to and register in that plugin’s compatibility, so we get better data from beta testers.

Search: what are people looking for, and are they finding it?

A better way for beta and RC testers to report plugin compatibility so as a community we can find and update any stragglers before a major release.

Peter Westwood shared his thoughts:

My wishlist:

  • Language packs for core, plugins, themes – so that the translations are independently installable from the code
  • More and better test suite – run automatically on check-ins
  • Make it even easier to report bugs – e.g. a plugin which adds built-in bug reporting functionality for beta testers
  • Make it easier for a community of people to work together a develop a plugin

Chip Bennett shared his ideas:

Interesting thread. Here are some of my thoughts (in no particular order, and avoiding certain pet peeves about which I’ve voiced my opinion sufficiently):

  1. Uninstall hook for Themes, as per the Plugin uninstall hook
  2. Relative internal linking
  3. bbPress Plugin
  4. More advanced Media Management (see e.g.: NextGen Gallery plugin)
  5. Bulk media import (see e.g.: Add From Server plugin)
  6. Consider Grandchild Themes, or clarify/emphasize proper use of Child Themes. Support Child Themes in the Theme Repository only if Grandchild Themes are implemented; otherwise, Child Themes must be preserved for use by end users.
  7. Support Theme Frameworks in the Theme Repository.
  8. Begin review of WordPress terminology and naming conventions, and create roadmap/timeline for improving. (e.g. “Custom Post Type”: not a *post* at all. Should be “Custom Content Type”. Likewise with template tags, function names, etc.)

There’s probably more, but that’s enough for now.

Andrea Rennick had a nice idea:

I would love to see a release cycle where basically nothing new really gets added, but everything longstanding that needed fixing or revamping gets attention.

Just go through and handle all the stuff we mean to get around to, but never have the time – a huge spring clean if you will. 😉 So much would get attention, it would seem new all around. But, like, *better*.

Ian Stewart said:

A beautiful Twenty Eleven theme elegantly designed to accommodate publishers that want a blog, a tumblelog, or CMS-ish theme.

+1 for Better handling of widgets when switching themes; automatically moving widgets to the first available sidebar when sidebar ids don’t match as opposed to moving them to inactive. It might be neat for themes to also register a “primary” sidebar when the first available sidebar might not be the best spot.

Aaron Jorbin suggested:

  • Media!
  • Links as CPT
  • continue itterating on custom header / background to make it more child theme friendly
  • Front end poster (ala p2)
  • The ability to #blamenacin from the admin
  • Themes should register default widgets that populate a sidebar (assuming that it’s empty), so that first time users aren’t confused as to why adding one widgets removes the entire sidebar contents
  • Move away from KSES and towards a library that is actually maintained

And finally, Jane Wells had thoughts too:

I have an entire huge list of things I want to cover during the meetup, but in the spirit of keeping posts short, I’ll just list a few things that we didn’t accomplish/finish in 2010 that I’d like us to prioritize for 2011:

  • Make media features better
  • Settings UI improvements
  • UI cleanup
  • Core plugins
  • Standardize how plugins deal with settings and navigation
  • New contributor mentorship program
  • Documentation/handbooks/training materials
  • Make better re organizing local groups

What do you think of their ideas? What are yours?

4 thoughts on “Roundup of thoughts on what 2011 should hold for WordPress

  1. Personally, I’d love to have an Add New Post screen where I could resize the actual width of the main content body to suit the width of the theme I’m using. A sort of WYSIWYG approach type of thing. I’ve got a 520 pixel-wide frontpage and single post area, and I spend a lot of time re-formatting copy, going back and forth from the Preview to the Draft far too much at the moment.
    Or unless someone here knows of a plugin that could do the same thing?

  2. Language packs would be a great addition allowing you switch languages with compatible themes / plugins allowing users to run a bilingual or multilingual site with ease.

  3. This one popped up twice in the lists above:

    “I’d love for dynamic sidebars to behave more like nav menus. Themes register “theme locations” and users assign custom-created sidebars to these locations. This would make things such as contextual/dynamic sidebars much easier and users wouldn’t lose sidebars when switching themes.”

    For me this is one of the big limitations of WordPress at the moment stopping it from being a full fledged CMS.

    If memory served correctly, Joomla was/is quite at defining locations for modules(Joomla equivalent of widgets) to displayed.

Comments are closed.