What Should 2011 Hold for WordPress?

I would like WordPress to stop inserting its own CSS in wp_head, also class names for functions like wp_list_pages could include the slug, that would be incredibly helpful.

I know there’s a ton more stuff, I’ve just forgotten it all. I will start keeping a list.

At this point I’m pretty happy with WordPress so all the features people mention would be great but few if any stand out as a lot more than any others to me.

However, may I ask some of the others to elaborate on some of the things they suggested? I’m unclear on some requests (maybe others are unclear too?) Can the people who suggested these please elaborate? Thanks in advance:

• Standard Pagination (what specifically?)
• Improve the Taxonomy API (how?)
• Simplify the Taxonomy Table Structure (that scares me; how do you envision this?)
• Improve the Import/Export System (what do you envision here?)
• More Intuitive Menu System (how? what (about it) is not currently intuitive?)

Again thanks in advance to everyone for helping me (and others) understand what these requests mean.

BTW Jane, if I had to pick I think you should have 3.2 be the version that is “All-about-Media”. I know it’s been something you’ve wanted for several years. Why not go ahead and focus all effort on a world-class revamp of the media handling in WordPress for the next version after this one?

JMTCW.

-Mike

+1 for Core Plugins. I want my WordPress to be my lightweight blog system, not my media management console…

WordPress is reaching a level of maturity now where even novice end users are using it to create lightweight business websites. Often a web designer will do the setup, and then hand off the keys to business owners.

The problem is that the admin interface, as good as it already is for the advanced user (typically a web designer or computer-savvy person), still has too much for the novice user that just needs to perform less than 10 functions.

I would love to see an even simpler interface for the admin system. I know plugins and themes exist, but they tend to fail or conflict whenever WordPress is updated.

Hi,
I am expecting a few things that may need much work :P.

1. It should go full OOP!
2. review system for plugins
3. centralize bug reporting (using trac) for plugins! I mean we can report bugs for any plugins on plugin repository rather than third party site or support forum!

Thanks

Ability to store custom fields in wp_post table and functionality to store, recall or display them.

I am working on a project which will have 10,000,000+ posts (which makes around 30,000,000+ entries in wp_postmeta table) assuming if each post requires a minimum of 3 custom fields.

I believe that many people are looking for this type of functionality.

+1 for this from mrjonwhite:
A significant simplification (e.g., with some built-in, ready-to-go GUI/front-end elements) of the functions.php protocol for creating, and CPT-associating, Custom Fields meta boxes, of various types. Right now it’s so easy, and so lean, to hand-register Custom Post Types and Custom Taxonomies. The third piece of that WordPress-as-CMS trinity — meta keys/values — are still too prohibitively verbose & cumbersome to write, practically, without the help of a Plugin (like Verve or MagicFields). At the end of the day, no one’s using CPTs without also the need to throw at least one (or twenty) custom fields at it, too. Custom Taxes can only cover so much.

Also:
I would love the ability to have content type single page templates. Meaning that we should have the ability to create post templates or custom post templates much the same way that we can create page templates. This is especially true for custom post types.

I would like to see some sort of meta box system for custom fields. Perhaps that can be defined similar to custom post types and custom taxonomies. This would help making WordPress into a great CMS.

@rajuru There is a Trac for plugins. Problem is that very low number of developers are using it.

Summarizing stuff I have proposed elsewere:

—A better approach to post formats, like something that actually simplifies the UI with only the needed fields instead of letting the theme do calculations of how interpret it, as I explained better here: https://www.ads-software.com/extend/ideas/topic/a-better-approach-to-post-formats
—Add a ‘question’ post format. This is very nit-picky, yet I suggest it because post formats are a fixed thing by now and it’s actually used in some micro-blogging systems. I try to explain it better here (including replies) https://www.ads-software.com/extend/ideas/topic/add-a-question-post-format
—Consider upgrading the Blicki plugin.
—Consider upgrading the self-hosted VideoPress framework (I think is considered for the 3.2 release, but still).
—Convert the links feature into a custom post type. By now it looks like something like a plugin should do, so instead of removing it, it could be better make a post type to harmonize better with the rest of the system and maintaining all the current features.
—Allow the taxonomies to hold metadata. This by itself may solve a lot of problems that by now have to resort to proprietary workarounds.
—Fix a great bunch of bugs with the shortcode API that are still waiting in the trac.
—In general, instead of adding to many nitpicky stuff for each release that’s hardly extensible for the users, try to make the API even more flexible and trying to get an approach similar to CCK in Drupal. Drupal has the problem of having a ridiculous learning curve, but it actually much more flexible in terms of how can you play with fields, views and stuff. For example, you may allow to put some of the default metaboxes more than once in a custom post type (if that’s already possible, don’t worry), and give more flexibility to the options of the default metaboxes, even if they aren’t used in core by default (something like, allowing something like a “post thumbnail” metabox that can hold any kind of file from the library, not just images and maybe more than one per page).

@mikeschinkel I made the comment about “Improve the Import/Export System” because recent versions of WordPress moved this out of core and into something akin to a plugin (e.g. that you install it), but the quality of the exports broke. It no longer works as well as it used to, and some with multi-site have complained about its functionality. I’d like it to work once again, plus offer some better options for importing (ex: ability to select specific posts, versus editing the XML manually, etc.).

@jane One core feature would be the ability to queue posts, but only there is interest in stealing thunder from Tumblr (which Custom Post Types somewhat do).

+1 on Andres’s suggestion for simpler Custom Post UI OOTB

I’d like to see a continuation of the process of introducing new features then seeing if/how they’re used by developers before they get fully developed (as was done with custom post types). This is a great way to democratise the development process, prevent unneeded bloat and minimise UI revisions.

There has been (very) partial support for custom post statuses up until now, I’d love to see more support for these so developers can start to use them: Trac ticket 12706.

A taxonomy meta system (as mentioned by @andrésSanhueza above) would be great too. There’s currently the possibility to add fields to taxonomies in the UI, but no standard system for saving them in the database.

hi,
everyone else has already spoken about main features in details.

my short and quick thought is
1. simplify the use of custom field
2. by default custom field grouping/duplicating/recalling
3. read more/view all link for category and tag (display first xx followed by the link same as “Read More”
4. default search option for search by post/post_type/tag/category etc

thanks

I’d love to see WP in OOP!
I know this is a lot of work, there’ll be compatibility issues with Plugins ans Themes, but think of all the great possibilities with oo code in place (not to mention grandchild-, great-grandchild-themes etc.)
You could skip a release cycle or two (or three), like you did for www.ads-software.com and REALLY be poetic! ??

P.S. Until you’re there: Core Plugins would be awesome!

All plugin activities in one place

The mirrored listing of compatible WordPress plugins on BuddyPress.org is very handy. The fact that BuddyPress.org members can interact with any “mirage” by voting, reviewing and even discussing is plain wrong, since it splits activity. Figure out where you want the plugin’s activity to go down and make every “mirage” nothing more than a reference to the real thing.

Looking at how BuddyPress deals with plugins, I’d say it would easily make the perfect plugin directory (by applying BP to wp.org). One great feature yet to be utilized is RSS feeds. By allowing plugin authors to add their own RSS feeds to their plugin listings, users would have a much easier time keeping up with external blog- and forum posts. The only thing missing is a proper bbPress integration which would allow for more flexible use of forums, the same way www.ads-software.com currently uses them.