8 things I’d drop from WordPress core to remove bloat

Let’s face it – there are some features in WordPress which are unloved and rarely used. Ever used Press This? I’d love to see WordPress cutting out some bloat to make core lighter, and as a consequence easier to use. Here are my thoughts on what should be killed.

The dashboard

The dashboard has looked pretty similar for several releases now, in fact, I think the first version I ever tried (1.5) had the same widgets on it, albeit fuglier.

Welcome, News, Quick draft, “At a glance”, Activity; do we really need this information each and every time we log in? I don’t. I feel its all unnecessary.

  1. Welcome could easily be a dismissible banner/notice.
  2. News should just be killed. If you care about the information there, its easy to find those blogs directly.
  3. Quick draft is utterly pointless. You’ll have to go to the main post editor anyway, so just post it there.
  4. “At a glance” should be integrated into the main manu, for example showing a post count next to the ‘posts’ menu item.
  5. Activity is the most useful out of all of them, but it still pretty useless in my opinion. Could put it in the admin menu if really wanted.

“Updates” menu item

I’d move this to the admin bar, just a simple counter that only shows when updates are available. No updates = don’t show anything!

Users and Plugins menus

I’d move these top level menu items to settings. Users is rarely used once you’ve done your initial setup, so a top level menu item is probably overkill, and plugins could easily ‘fit’ within the settings section.

Tools

Who honestly uses tools? Does it even make sense to end-users? Isn’t WordPress itself a tool?

Available tools, import, export – these should all be plugins. Do your import/export once and then its no longer needed. I’d do away with this functionality in core.

“Press This”

Press This is a bookmarklet: a little app that runs in your browser and lets you grab bits of the web.

Whoopie. We have a million tools we can use for this, why even bother with this in core. Make it a plugin for the 5 users who use this feature.

Post via e-mail

Another niche feature (do people still use this?). Why you’d have access to email but not wp admin is beyond me. Make this into a plugin.

The plugin/theme editor

I don’t think these should exist in a clean WordPress install – encouraging users to modify files is such a bad idea. One mistake and boom, site is dead. I’d like to see these moved out to a separate plugin(s). This would also allows developers to protect their clients from breaking things.

Niche settings

  • WordPress address/Site address I’d move this to wp-config.php (wp-config already supports these options) I think its dangerous (and pointless) to have it in settings.
  • Default Post Category/format – should be integrated into the post category screens somehow. Maybe just a radio button, or checkbox so that its actually set in context of the taxonomies the setting applies to.
  • “WordPress should correct invalidly nested XHTML automatically” – Do it or don’t do it, don’t have an option. Have a filter to disable it.
  • Update services. I have never used this option. Move it to a filter, or a plugin.

What my un-bloated admin now looks like

2013-12-16 at 10.09

Thats a bit cleaner. I’d like to see WordPress seriously look into removing some niche features in the next few upcoming releases and I definitely feel it fits with the “decisions, not options” mantra WordPress holds.

18 thoughts on “8 things I’d drop from WordPress core to remove bloat

  1. Some of your suggestions/ ideas are really good. However, with some I don’t agree:
    “Users” + “Plugins” in “Settings” is bad. Has nothing to do with settings.
    Removing “Tools” may be ok, but at least “Export” should be kept in core, so exports could be done fast and easily, for example for custom post types.

    “Dashboard” is debateable for me. At least it should be some setting to activate/deactivate on a per user basis for example. For a lot of plugins and also for clients it’s a great way to get some overview of things, stats etc.

    The plugin “Editor” should go, absolutely, as plugins are auto updated and changes are always gone! The theme “Editor” should be kept as it is used by more devs, admins, webmasters that you might imagine. This was discussed a lot of times already in .org forums, trac and elsewhere. I don’t see it go very soon, though. It’s very useable for me personally and for clients etc. it’s really easy to disable. So no reason the theme editor should be eliminated.

    Like

    1. Regarding the dashboard, you tell me one bit of information on there which couldn’t be incorporated into the main menus. I think you’ll struggle.

      Users and plugins is debatable – choosing which plugins you have installed and which users have access are technically settings. Are they really that useful as a top level item? I’d disagree. Most of the time one they are “set up” thats it – no need to go back to those settings if the site is finished.

      Export again, how often do you export? I’d hazard a guess only during migrations – in which case, installing an ‘exporter’ plugin would be a small hurdle, and worth it if its one less item in core slowing things down.

      Like

  2. Some great ideas, although with the flexibility that WordPress offers, the milage may vary of some of the features.

    For example post via email can be useful when using the WordPress in a corporate environment where they block access to the admin system to only internal IP addresses (we currently need to VPN to the office to access the admin side of a WordPress install – it seems silly). Disclaimer – we don’t use the post via email functionality and it could be a plugin.

    We use Tools for the Regen. thumbnails plugin, but then that might be better to sit in the Media menu.

    The dashboard is useful for e-commerce sites using something like Shopp plugin or Woo-commerce. Or even Mandrill for emails, it gives a good visual overview of the activity of the site. These are all plugins.

    Mostly the Users menu is unused, although one of our sites has registered 6222 users. So it’s a fairly we used admin destination.

    Hopefully the move to features of plugins could lead to a much leaner core, but with every feature people want or need.

    What amazes me is the level of backwards compatibility the devs maintain with WordPress (v1 plugins may still work in v3.8). There was a day’s session on WordPress architecture aiming to map the dependancies and that may lead to a leaner core and optimised load times 🙂

    Like

  3. Pretty much agree with all of that except moving Users into Settings: it probably makes sense for a single user site, but for a CMS or membership site it really should be top level. Many of my clients use an editor level account for day-to-day site admin, which can involve fairly frequent user management. I’ve set things up for them so they can manage users but not edit settings.

    Like

    1. Can’t satisfy everyone of course. Would be 1 extra click for them in this case. It could probably work like WooCommerce where if the top level item is disabled (due to permissions) a sub level will be moved to top level if that makes sense.

      Like

  4. I agree about the admin being bloated by stuff not needed. But a lot of things is really good in the new design. The one thing that annoys me the most is that the menu dividers are invisible by default, the first thing I did was to create an admin color theme of my own to fix it.

    Like

    1. They are indeed invisible, but I still notice the subtle gap they make between sections. This one doesn’t bother me.

      Like

  5. Oh so agree on Quick Draft!! It was bad enough as Quick Post, but now who out there is creating so many drafts they need a quick way to do it?

    Reading Steve Jobs bio and can’t help but be impressed with his obsession simplicity. It makes a lot of sense.

    The back end of WP should fire up by default to a way to start writing (but with overrides in settings) but not totally cut down like Quick Post (which didn’t even have categories!).

    That would be a quick post function, but much more sensible than previously.

    It should be an editor that provides big buttons to quickly switch between post types (posts, pages, cpt). It also should have another button to quickly access editing.

    Good software is task focused.

    Users think in tasks, not components and functions like Posts, Pages, Media, Tools, Plugins, Appearance etc

    Re-imagine the side menu for tasks. e.g. Write, Design, Manage

    (Interestingly the wp admin is already organised into those three sections. Now they just need to make it clear with maybe an accordion layout with only one section open at a time)

    Like

      1. Tasks would work for posts and pages, but could be tricky for plugins which add types such as products for example as they include *a lot* of custom data and write panels.

        Design would just be a rename by the sounds of it – appearance encompasses everything design related so probably not needed.

        Like

      2. Yeah, plugins devs would have to get smarter and separate the writing tasks from the managing tasks. Bur if WP had a clear standard – and even rejected plugins that didn’t follow it – that would help.

        The key of Write, Design, Manage is they are all verbs. It’s implies the question “What do you want to do?” “Appearance” doesn’t ask that question, hence the rename. Plus Design encompasses plugin install but Appearance doesn’t necessarily.

        I did knock up a quick plugin to add those section headings, but hacking the menu to make them collapsible is a whole nother can of pain. :/

        Like

    1. Think my last comment got rejected coz it contained a link. So here it is again, with attached example of how it could look.

      “Other” is for third party menu items that appear down there.

      I left Dashboard in coz I think it has potential, just needs more thought.

      Like

  6. I’ve been working with WordPress for several years and to this day have never used ‘Links’. Would love to see this removed in favour of downloading a plugin to do the job.

    Like

  7. Mike, one thing that strikes me about WC as compared to WP is stability of maintstay features and code structures. Notice that WP rarely breaks a site. With millions of WP users, the core WP devs go a long way towards making sure that any update has minimal impact of a huge based of themes and plugins.

    This is something all the devs of WC should take careful note of. As a glaring example, WC 2.1 will break a lot of plugins. I know this to be fact our company has developer dozens upon dozens of custom plugins for WC for our customers. We probably have to modify about 40 of them, simply because you guys decide to move files around in the core tree and no other reason.

    This is seriously bad practice and really ought to stop now.

    Sure, the WP devs have learned a ton of over the years. And they can look at the core code tree and core code structures and see a load of stuff that can be done better or more efficiently. But they don’t take that lightly because well over 70 million sites use WP, and there are hundreds of thousands of themes and plugins that rely on the fact the overall the core remains stable in terms of things “just working”.

    If you want people to keep recommending WooCommerce over other solutions then you really ought to stop moving stuff around – quick. Because as it stands right now a lot of us developers wind up defending WC to customers when they get seriously pissed off when their site breaks over a simple upgrade. And frankly, based on conversations with other WC solution builders, many are getting frustrated with a moving target and WC 2.1 is only going to exasperate that frustration.

    At some point a developer has to set aside their person ideologies and philosophies and just leave well enough alone in favor of what is best for the user base. ( As does the WP core dev team ). A perfect example is deciding to remove the “classes” subdir in favor of “includes” dir. Great. But it’s simply an ideological / philosophical tree structure decision that makes no difference in the overall operation of the software – but DOES make a huge difference for many, many, many sites that have built custom solutions around core class files that need to be loaded for whatever reason at what point in the site operation. That’s one of many examples I could cite.

    Take a lesson from the core WP devs where stability of architecture remains relatively problem free as long as developers adhere to common standards long established in the WP community.

    I point this out because apparently you don’t see why the Tools menu, Plugin and Theme editors, URL edit field, etc are still in the core code. Apparently you don’t work on many customer sites, otherwise you’d realize why the WP team has left well enough alone there. The same holds true for core WC stuff – restructuring the setting menus willy nilly. Countless users of WC will be totally dumbfounded and get pissed off when it takes them 4 times as long because they can’t find the correct setting area any more.

    Most people that operate a Web site are basically tech idiots. And that’s Ok. WP takes great care not to baffle them from version to version. WC devs ought to do the same.

    Like

    1. Ignoring the fact this post had zero to do with WC, I’m sorry but if moving class files around (something within the core plugin) breaks your customisations, *you* must be doing something wrong. If you are doing anything with those core classes directly THAT is bad practice and you should stop now.

      The changes in 2.1 are not site breaking – the very worst you’ll see is deprecated notices (if debugging is enabled). If you have a live site, this shouldn’t affect you. We take care to deprecate functions and methods to give developers a chance to catch up.

      Lets also remember, it’s early days for WC – structure changes are going to be much more common than with WP which is mature and relatively stable at it’s heart. I’m sure that wasn’t the case going from WP 1 to 2 to 3 however, so why should WC be any different?

      Regarding features in WP, giving “tech idiots” access to, for one example, Plugin and Theme editors is dangerous. They shouldn’t have that power, and that was the basis of my comment.

      Like

      1. For clarity’s sake, forget versions and think user base. 2 million downloads of WC so far. That’s a lot of people using it.

        Yes you post wasn’t about WC. My response was to draw a comparison to why the WP features you cite are there, in an effort to help point out why WC should take note of how the WP core dev team makes decisions. Every decision centers around how it will impact the community as a whole.

        About moving “classes” to “includes” and why this can break things – because sometimes customers want unconventional operational behavior that requires loading a class because it isn’t loaded yet by WC itself. This is never a problem with WP because the file locations have remained consistent for nearly a decade. So, we load a class when necessary, and as result of us being to do that we can then tell the customer “Ya we can build that solution for you no problem and you need to head over to WooThemes and buy these 8 other plugins….” – and they do. And you all benefit tremendously.

        Just saying, don’t take things so lightly. Try to step back and look at the bigger picture keeping in mind there have been over 2 million downloads of WC so far. One tiny change can have a gigantic impact.

        As such, you see the things in WP cited in your article. Because messing with that stuff would have a huge impact overall. And moving them or removing them is simply ideology and philosophy – for the most part.

        Like

      2. I cannot think of any cases you’d need to do that. Most of the classes are auto-loaded, and of course you can ‘hook in’ your functionality later, when the class is loaded.

        If you did find a case where that wasn’t possible, suggest a solution on github and get core changed. Thats 100 times better than a hack (which lets face it, including classes manually outside of the core plugin is a hack) and helps you and everyone else who wants to do the same thing.

        Getting back on topic, about the core dev team’s decision making – removing bloat like the things I’ve pointed out has been done in the past. Remember the ‘links’ section? Gone. I’m sure that was used by many users, but it was taken out because it’s not a ‘core’ feature. I think my suggestions are in line with that.

        Like

Comments are closed.