Once I discovered WordPress, I never looked back. Yes, I’m a WordPress fanboy. I will sing it’s praises until my throat is sore. Still, with the recent barrage of WordPress bashing, it has me thinking. How could WordPress be even better? Well, in this post I’ll speak my mind on what I think are some shortcomings and areas that could use some significant improvement in WordPress.
Not Just a Blog
If you know anything about the history of WordPress you’ll know that it is a fork of a really old the blogging platform p2. Because of this WordPress was conceived as another blog platform. Well, 12 years later you, me , and anyone else that uses or develops for WordPress knows that it’s not just a blog anymore. It’s a CMS. I used to preach “It’s a blog platform that can be used as a CMS”, but I’ve taken a 360 view on that. It’s a CMS whether you like it or not.
This is the approach I’d like WordPress to take in the years to come. I’d like to see the core WordPress dev team to approach WordPress development as a CMS, not a blogging platform. For instance, the main index.php page is setup to automatically list the basic Posts.
I don’t think this really needed to be the default any more. Right now, if you want to make a front page that isn’t a list of blog posts. You have to create a special “Home” page, and configure the settings to use this page for your front page.That’s kinda of a pain, not hard to do, just annoying.
WordPress powers over 20% of all the websites on the interwebs. How many of those site are just a blog? How many are using WordPress as a full on CMS? I feel like the sites that use WordPress as a CMS, not just a blog, are being ignored. If WordPress development was approached as a CMS and not just a blog, then we would get a more robust and well rounded platform to build great websites with.
Stop the Bloat, Stop the Bloat Baby
WordPress is getting pretty bloated as of late, and it shows no signs of trimming down anytime soon. On the contrary, there’s plans to add even more. Don’t get me wrong I love new features as much as the next geek, but where does it stop? Do all these features need to be in the WordPress core?
Take Image Cropper for instance. The very first one on the list. Right next to the name it says “Image cropper (not used in core, see jcrop)”. Then why is it there? Why would there be an other image cropping library when most users will just end up using the one that is used by core media functionality? Don’t get me wrong. I’m not bashing Image Cropper. I just don’t see the need for this to be included in the WordPress core. It’s just making WordPress fat.
Should I Plug This?
This part goes hand in hand with the previous section about bloat. I really feel that some of the newer features and soon to be features could be best served as plugins. Rather than sticking them in core.
Some that come to mind are the Distraction Free Writing, Front End Editing, and the Customizer. Yes, The customizer has been getting rave reviews and many devs have been championing it, but does this really need to be in core?
I mainly work for agencies that provide websites for business clients. Rule one for building a site for business that is trying to promote it’s brand is: Never let them have the ability to change the design. Ever!
It’s not nice to say, but most clients are pretty dumb. They make really bad choices when it comes to web design. If we allowed clients to do everything they wanted. The web would be full of websites like this (OMG there’s music now!).
In that respect, the customizer is all but useless. I’ve experimented in adding non-design settings to the customizer. Like Google Analytics ID or other arbitrary settings, but the clients got confused. They didn’t understand why there’s a preview of the site when nothing they do changes it. They also found it a bit hard to navigate the customizer with everything stacked all together in one column. It worked out a lot better to place these settings in another custom area all together.
Now, if you are developing WordPress themes to be sold to the masses. Then yes, by all means use the customizer. Give your customers the ability to build the site they want.
With so many commercial theme developers already packaging plugins with their themes. Then why can’t a customizer plugin be included with that. Why does it have to be in core?
My felling is that unless a feature is bring something that would be beneficial by all or most WordPress users. Then make it a plugin. Keep the bloat down. I know the core WordPress dev teams like to think they’re making improvements that would be beneficial to all, but even if features are popular should they really be in core, or as a plugin.
Post Meta API
This was announced in November 2013. When I read this, I did a silly little jig in my chair. I have to say, the thing I hate the most in WordPress development is making custom meta boxes and option fields. That’s why I use ACF, but would rather have a system like CMB or Redux built into core. When I heard they were developing a core API for this. Well, I couldn’t have been more stoked.
Well, over a year later and the development really has gone much further than the original commits. There hasn’t been any progress in three months at the time of this post.
I could really care less about front end editing. It doesn’t impress me at all as a developer, but a built in API for custom fields. Yeah, baby. That’s the stuff. No more relying on plugins or third party scripts. No more frustration in writing the same functions over and over again. But… nothing.
Oh, WordPress core devs, please push this one out. This should be easy peasy stuff. Heck you could just make a few tweaks to CMB add that to core, and call it a day. Why is an API that could really improve the quality of WordPress theme and plugin development being pushed aside for a feature that’s more gimmick that helpful? Arrrrg! Get Er’ Done!
Out With the Old
Lastly, I’d like to address the overall quality of code in the WordPress core. I think it’s really great that backwards compatibility is very important to the core developers, but where do you draw the line?
My thinking is this. We all know it’s very important to keep WordPress and plugins up to date. Especially from a security prospective, so if updating is this important why are we holding onto extremely outdated and poor quality code? Supporting themes and plugins that aren’t fresh out of the gate is important, but shouldn’t there be a cut off?
As I stated in the beginning of this post. There’s been a lot of WordPress bashing going on lately. One of the things that is pointed out over and over again, is how badly coded WordPress is. Well, I have to admit it’s true. It’s sad to say, but WordPress core if filled with a mix of procedural and OOP code all mangled together. With DRY coding being the standard now a days, WordPress is as WET as a dog out in the rain in the middle of a lake being spayed with a firehose.
What kills me, is that the excuse for this is backwards compatibility, but that’s not how it should work. When you want to support backwards compatibility. You just don’t leave the code as is and work around that. You refactor the code to the current standards and make sure that it is still accessible from an outdated approach. For a certain amount of time, then you depreciate that old nasty code.
There is no reason that the WordPress core couldn’t be refactored to a MVC OOP model, or something alike. All this old code is just straight procedural functions. You can take the components needed from an OOP model and wrap them in functions, so it’s still backwards compatible and easy to implement in themes and plugins.
Yeah, it would take a lot of man hours, it would be hard, and it would take time away from new features, but the overall rewards would so be worth it. WordPress would be more stream line, easier to customize, and it’s life span would be greatly lengthened.
There was a question going around not to long ago asking “What could kill WordPress”? Well, I think this is it. If the core team doesn’t come to the realization that the base code they’re working on is, well let’s face it, old and out of date with current standards. Then sooner than later, WordPress will be left in the dust by some young devs who make the next big CMS.
Adapt or die. There quite a few of us that have seen the next big thing come and go on the internet in it’s short existence. How many of you laugh now about having a MySpace page, going to chat rooms, or having a GeoCities site?
I don’t want WordPress to die. I love WordPress. I love developing for WordPress. I love telling people how great of a CMS WordPress is. It would be a sad day when I have to give up on WordPress because it’s just not relevant anymore.
Well, that’s a but a few of items on my WordPress wish list. You may not agree with me, but take as you will. I’m just one dev with my opinion, but I would love to hear what you’d like to see what WordPress bring in the future.