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

Comments

18 responses to “8 things I’d drop from WordPress core to remove bloat”

1. 

   David Decker

   December 16, 2013

   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.

   Reply
   1. 

      mikejolley

      December 16, 2013

      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.

      Reply
2. 

   digitales

   December 16, 2013

   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 🙂

   Reply
3. 

   Simon Blackbourn

   December 16, 2013

   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.

   Reply
   1. 

      mikejolley

      December 17, 2013

      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.

      Reply
4. 

   Kenth Hagström

   December 16, 2013

   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.

   Reply
   1. 

      mikejolley

      December 18, 2013

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

      Reply
5. 

   Chris Howard

   December 17, 2013

   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)

   Reply
   1. 

      Chris Howard

      December 17, 2013

      Have just mocked up how it might look.

      http://screencast.com/t/uCiGqy99n

      “Other” is for all the third party menus that get created that appear down there.

      I left Dashboard in coz I think the WP guys are really set on it. And I don’t mind it as a landing point, it just still needs a lot of thought

      Reply
      1. 

         mikejolley

         December 18, 2013

         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.

      2. 

         Chris Howard

         December 19, 2013

         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. :/

   2. 

      Chris Howard

      December 17, 2013

      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.

      Reply
6. 

   Devin Walker

   December 17, 2013

   Well at least “Links” are gone… nice post.

   Reply
7. 

   Gemma Wild

   December 21, 2013

   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.

   Reply
8. 

   Jonathan

   December 22, 2013

   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.

   Reply
   1. 

      mikejolley

      December 22, 2013

      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.

      Reply
      1. 

         Jonathan

         December 22, 2013

         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.

      2. 

         mikejolley

         December 22, 2013

         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.

This site uses Akismet to reduce spam. Learn how your comment data is processed.