Six Revisions On Missing Features In WordPress

Jacob Gube of has published his take on ten features that are missing from the core of WordPress. According to Jacob, these features should be adopted into the core of WordPress for the benefit of all. I agree with some of his reasoning on moving features into core but it’s a mindset that I’ve been trying to stay away from. First of all, I as an individual user don’t really know what the WordPress userbase deems useful or worthy of being in the core of WordPress. Secondly, apart from the search in WordPress sucking, just about everything else on his list relates to a specific use case of WordPress and since everyone seems to use WordPress in a different way, these features could end up as useless bloat for many people. However, WordPress already has a number of features that I rarely ever use but I don’t want to see any more of them added to the core software.

This is one of the reasons why I now support the idea of core plugins. Keep the core of WordPress light, add hooks, functions, better APIs and let the third parties do the rest. Keep WordPress flexible and modular instead of weighed down. Unfortunately, there are thousands of plugins, multiple ones that perform the same subset of features, some that are outdated, etc. Having those features in core eliminates that worry but at the cost of modularity. As someone brought up in the comments, the idea of WordPress Installation Profiles seems like the answer to this problem as certain branches of the software could either ship with a predefine list of plugins for that use case or have those plugins built in. Those WordPress branches would need to mirror the development of WordPress though which means the core team most likely will not maintain them. The installation profile idea has been brought up on the WP-Hackers mailing list a few times before with the outcome being that will not create and maintain these new branches but nothing stopped anyone else from doing so. Dougal has a few tips and a link that explains how to use the install.php file to create automated WordPress customizations.

The bottom line is, if you think a particular plugin should be added to the core of WordPress for the benefit of all, you’re probably wrong. Think about the big picture before you come to any conclusions.


9 responses to “Six Revisions On Missing Features In WordPress”

  1. Here’s the 10 features:
    1. Web Caching
    2. Pagination with Multi-Page Navigation
    3. Displaying Related Posts
    4. Custom User Role Permissions
    5. Social Media Integration for Popular Web Services
    6. Site Statistics
    7. Web Form Builder
    8. Minification of Source Code
    9. Better Site Search
    10. Content Rating

    Of those, 3 are already there, 6 are better served as plugins, and only a better search should be core code. IMO, of course.

  2. They are completely missing the point. WordPress is designed to be minimalistic and be built upon by plugins. Most of the features they mentioned I don’t want WordPress to implement in the core because there is most likely a plugin that will do the job better.

  3. Given that the post started with a complaint about a new default theme every year, I’m sort of writing the author off as someone who doesn’t know what he’s talking about.

  4. I agree a bit with pagination… Sure there are awesome plugins for that, but I see all the time blogs that don’t bother with that minimal effort and stick with stupid default next/previous setup. Not that complex pagination is desperately needed, but native definitely sucks.

    And of course search is verrrrry strange creature in WP.


    Default theme every year is supposedly a plan for future WP releases. Since 2010 just landed we will see in a year I guess. :)

  5. Search is definitely the main thing that needs improvement. Everything else I think would be best handled by plugins (and in some cases already is).

    I agree that the default WordPress pagination options are rather limited but I think that enhancing this with a plugin (and there are some decent ones already out there) is the better way to go.

    That said, most of the paging options out there require you to tweak your template files so that you can display numbered pagination instead of previous/next. This is usually because the 2 previous/next functions need to be replaced with a single pagination function to provided numbered paging. It would be good to remove this barrier for non-developer users somehow. Maybe it is already possible to do this with the current hooks but I have not seen an example of this or looked into it.

  6. Please define “keep light”. Having tons of multisite files shipping with core while you use it for a single blog is far away from “being a light core”.

    I think what really would help is a build system that is able create packages for the different usage profiles and needs. That build system could bundle core plugins as well – just to show the picture.

    Eg. Classic could ship with hello dolly and akismet for that Matt can sleep at night, there could be multisite package and one package for single site use. Can be something valuable for the current redesign as well. Just to add some ideas.

  7. What Hakre is talking about is actually something Drupal is doing to great aplomb and that I expect to see more in Drupal 7, that is, installation profiles. And I agree that it’s a great idea. I think keep your default package as is, but als let people put together installation profiles that include certain olivine or additions as they see fit. If you wanted to keep some sense of control, require the use of core plugins.
    I know a lot of this stuff was done in the MU era, but it hasn’t taken off in standard Wp installs. It could defnitely be a good thing for getting people more setup out of the box.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: