Where Does WordPress Go From Here?

[Jeffro]

I was listening to episode 18 of the WPCandy WordPress podcast the other night and a small conversation was started that has room for thought and discussion.

http://wpcandy.com/podcasts/episode-18

Ryan Imel asked Otto what he thought the future of WordPress is. Amidst the conversation, Ryan mentioned that it's a difficult question for people to answer these days because for most, WordPress is at a point where it has just about everything the user wants, relatively speaking of course. I've gone months at a time without adding additional plugins to WPTavern.com. After about a year and a half, I've finally reached a point where I'm pretty happy and comfortable with the functionality I have thanks to the theme and plugins in use. Although some of the plugins I have installed are meant to block or alter stupid functionality that was added to core.

So while we can make a decent guess as to the short term future of WordPress (as in the next version number) it's becoming increasingly difficult to put a finger on what will be in store for the platform a year or two from now, let alone 5.

To bring this back into perspective, if many people are quite satisfied with what WordPress offers today out of the box to accomplish their goals, where should the direction of WordPress go? Are we going to start seeing a decline from feature inclusion to more versions of code cleanup along with optimization? Is there still plenty of room for WordPress to grow into a more robust platform while at the same time, keeping it's claim to fame of being extremely usable and for the most part, user friendly?

[greenshady]

Overall, I'm pretty happy with WordPress these days. I actually feel like I'm starting to deactivate too much stuff sometimes though. I just coded a mini plugin to deactivate a bunch of meta boxes that I never use on my personal blog.

The two big things I want to see are:

* A term meta table.
* Finish up the custom post status functionality.

Some other less important things I'd like to see:

* Comment moderation overhaul (capabilities/permissions).
* Extend custom comment types functionality.
* Links turned into a custom post type.
* Better core support of modular templates and templates in sub-folders.
* Some type of meta box class to better standardize custom meta boxes.
* Let users create their own sidebars and themes define "sidebar locations" like how nav menus are handled.

My hope is that WordPress focuses more on developer features, optimization, and code cleanup. Yes, many like to see flashy user features, but that's what plugins are for. The easier you make things for developers, the better features those developers can build into plugins.

Where is it going though? I have no idea. It'll change depending on how users are building and using sites.

[Elpie]

Where is it going to go? Who knows. As far as features go, these days, I spend far more time removing stuff I don't want than adding anything new.

Where I would like it to go is a different story. The codebase isn't good, and suffers greatly from continual building onto legacy code. I'd like the core team to consider how they would build WordPress if they were starting out today. PHP5+/MySQL5+ brings a lot of opportunity. Adding to legacy code or refactoring existing code only goes so far. After being around for so many years, doing a rewrite using good OO principles, focusing on quality, secure code would be a good move.

Doing this would require a feature freeze. Maintenance would still have to go on, and completing unfinished features could still be undertaken. Ultimately though, I think its past time legacy code was retired and the whole lot rebuilt.

[Ryan]

Like the rest of you, I end up removing more stuff than I add. So actually removing some of the junk that's been added to the trunk in recent releases is where I'd like it to go, but I suspect that won't happen.

In particular, a few things I'd like to see ripped out and never returned are the admin bar, custom headers, custom backgrounds and the plugin and theme editor. They all seem like definite plugin material to me. I'm baffled how they ever ended up in core.

Unfortunately, I suspect more and more features will slowly be added. Eventually we will end up with something more akin to Joomla, albeit significantly better.

It seems that the core developers aren't so much interested in rewriting the older code. Although that may change in time. The urge to keep backwards compatibility seems higher than the urge to improve the existing code.

If WordPress does continue along the feature creep bloated approach, I imagine a few forks will eventually pop up. But I wouldn't hold my breathe on them becoming main stream. WordPress itself has too much momentum for forks to have much of a chance IMO.


Oh, and +1 for Justin's idea of cleaning up the custom post-types.

[tnorthcutt]

Ultimately though, I think its past time legacy code was retired and the whole lot rebuilt.

For your reading pleasure: Things You Should Never Do, Part 1.

[Elpie]

For your reading pleasure: Things You Should Never Do, Part 1.

I agree with you when it comes to large-scale commercial software but not when it comes to volunteer, open source projects. WordPress was originally written for PHP 4 (recommended 4.0.6) and MySQL 3 (recommended 3.23.23) as a simple blog publishing platform. It was 268.38 kb back then and has now grown to 2.96Mb. In the past 7 years, users have moved from wanting a simple publishing program to using WordPress as a CMS, demanding more and more functionality. Yet, its still largely constructed as a date-based system.

I personally think WordPress has outgrown its ability to perform well on a typical shared-hosting setup and that a rewrite for modern uses (as opposed to patching together on top of old code) could see significant benefits. Not least of these benefits is creating enthusiasm amongst developers.

It's not exciting to look for ways to crib together new features with old code. But theres nothing stopping reuse of code in a new system and it'd be a lot more fun to do.

But, thats just my opinion, which counts for nothing. Maybe I'm just fed up with looking at WordPress code after so many years and would like some powerful new stuff to work with

[ericmann]

Someone else asked me this same question in an interview earlier this week. I actually have a lot of ambitious hopes for WordPress, though I'm very happy with its current set of features.

Like most of you, I spend a lot of time online. I'm active on Twitter, I sit on IRC for a bit, I check Facebook religiously, I maintain 10 different blogs, I participate in forums and Stack Exchanges ... but I have to go out to those places to participate. And people have to come in to my WordPress sites to interact with me.

I would love to see the day when my WordPress site acts as a kind of hub for my online presence. A single site where I can go, log in, read through all my blog feeds, fill out a Facebook quiz, interact with my Tweeps in Europe, comment on another blog post, and engage my own readers.

There's a lot that has to happen on the Internet as a whole before any one site can tie in all of these external services, but with RESTful APIs for many web services, XML-RPC interfaces, and Open Graph protocols we're getting much closer. I still have to log in to about 30 different sites throughout my day, and I feel that's about 29 too many.

[Idealien]

where should the direction of WordPress go? Are we going to start seeing a decline from feature inclusion to more versions of code cleanup along with optimization? Is there still plenty of room for WordPress to grow into a more robust platform while at the same time, keeping it's claim to fame of being extremely usable and for the most part, user friendly?

The amount of improvement in development process that WP 3.0 brought with its custom post types and menu management tells me there is still a lot more potential to be built into this platform. The challenge will be finding the sweet spot of avoiding "should really be a plugin" scope creep and "what % of sites will use that" standardization.

Ryan touched on the custom headers, custom backgrounds as being strange adds to the core. But I feel like they were good choices b/c it brought standardization to the process which the bulk of themes were doing through a variety of different methods.

Lately I've been thinking about WordPress not so much as a CMS but as a system for designing systems. It has proven itself wholly capable of being a CMS where clients with non-technical skills can manage their own content. I think about all the things that I do to design a site for a client and how I could automate those so that the process of creating the site is as easy for me as it is for my clients to edit content in WordPress.

Pre-WP, I hand edited html files to make a site - and every content change required additional work. Now I do a bunch of customization to give a client a site they can self-manage content with. So only added work is when they want truly new functionality. If this pattern continues, I'd be happy if WordPress could be so awesome that my involvement isn't required to make a site happen beyond the visual design aspects. As each barrier of complexity of communication via web technologies falls, I am able to move farther down the curve of technology and help solve the more challenging problems.

But the process of rolling up a new site still has a lot of iterative or repetitive tasks that it would be nice to see improved or enable automation of. A couple of large(r) items I would like to see some increased conversation or inclusion into core consideration for are:

• Post Type Gallery - aka separate method of designing, import / export, sharing post types that does not involve significant code customization. Post types are a strange mix of plugin functionality with theme design requirements. It would be good if there were a separate way to view, add post types that doesn't get confused with each.
• Post Type Editor - Every post type I customize the wp_insert_post hook to handle the meta boxes data storage for date pickers, dropdowns and other, from a data entry perspective, standard form tools. There are a few plugins out there trying to expose this functionality like Custom Post Types UI but it still has a long way to go.
  
  For comparison, I've been quite a fan of Gravity Forms and use it on many sites. The UI experience for it shares a lot of similarities to the menu management core feature. Being able to design post type interfaces via UI and tweak or cross-populate them between sites without having to know what functions to add, edit, etc would be a huge differentiator.
• Site Pre-Configurations - The 5-minute install is fantastic for a baseline blog / site. But there is a lot of standard customizations that I make when starting a site - permalink structure, plugins, post types, etc. This might be the direction the core plugins concept is going towards, akin to where jQuery UI (http://jqueryui.com/download) offers you the ability to customize your download for the features of most interest to you or taking the vanilla "get everything" download.

[mmuro]

There's plenty left to do.

I, for one, would like to see an improved media upload and better Page menu handling (per page sidebar is a biggie).

How many more 'tent pole' features do you need before you just say enough's enough?

[dgwyer]

I, for one, would like to see an improved media upload and better Page menu handling (per page sidebar is a biggie).

+1 to media overhaul and per post/page sidebars.

For us, using WordPress as a CMS is our prime goal.

Fundamental things like core support for per post/page column layout (1,2,3 columns), and per post/page sidebars gives users a huge amount of flexibility and power in how they organise their site structure.

In ALL of our themes we decided to implement a custom solution for per post/page column layout and per post/page sidebar features (the combination of the two is awesome!). We also decided to completely widgetize the front-page.php template to give maximum flexibility so users can easily swap out any part of the home page with different components (i.e. swap content sliders for video players etc.). This is in preference to the usual approach of supplying multiple home page templates, and try to guess what each user wants (which is pretty futile).

One side effect of this is (as our widgets get more complex) the difficulty in enqueueing scripts so they are used ONLY on the particular post/page that the widget is rendered on. Currently, WordPress knows nothing about what widget areas are added to which page(s) when all registered scripts are enqueued. The only recommended method at the moment seems to be referencing the JS files manually inside the widget code which is an inelegant solution.

It would be cool if the Widget API was extended so you could manually register a widget area with a particular theme page template(s) (and automatically have this widget area registered to a specific post/page ID when using the per post/page sidebar feature). I know this isn't going to happen any time soon (but I can dream!), so we will probably look into implementing this feature ourselves for our themes soon - which won't be a too hard with the way we have things setup.

I would also be in favour of overhauling the widgets.php page. I don't know about anyone else but we are using an ever increasing amount of widget areas to increase theme flexibility, and the current single long list of widget areas down the right hand side is becoming cumbersome. A nice way to sidestep this would be to have user defined 'groups' of widget areas such as 'header', 'footer', 'front page' etc.

Outside of this the single biggest change I would like to see is a big overhaul of user groups to be closer to other popular CMS. The system in WordPress has not changed a huge amount over the last few years and could well do with some serious TLC.

Finally, maybe this is just me but I find switching back and forth between Visual/HTML editor a nightmare. I made the decision some time ago to stick to the HTML editor to prevent code from being stripped out. It seems most people seem to stick with one or the other, but new users find this a bit confusing and annoying! I find it almost embarrassing to tell clients about this after selling how good WordPress is (which it is!).

The thing is, with a decent editor.css defined in a theme the Visual editor is a sheer pleasure to use, so I 'want' to use it but don't really want to risk using it. Even if I want to use it on a post that has relatively low custom tags etc. if I save the post and then go to a post that DOES have some custom tags/attributes that will get stripped I want to scream as the Visual editor is left on by default from the previous post I was just editing (anyone else have this happen too).

I think that this should be addressed as soon as possible, just getting used to this and living with it is just not an option any more. Either WordPress should look at other editors, and maintain TinyMCE as a legacy editor, or try to address the amount of code stripped when switching editor modes. Ideally, for maximum flexibility NO html should be stripped when switching, and it be left to the user. Or a simple check box in the writing settings page could let the user decide to leave it the way it is, or prevent ANY code stripping when switching editors!