Photo by Annie Spratt on Unsplash

I’ve been working with the Wordpress for about 10 years. I’ve started by tweaking the CSS, HTML and JS in default or downloaded themes, then I started to created my own themes and getting deeper and deeper. As I came from the OOP background, I started to dislike some practice within this CMS.

Don’t get me wrong, it is still the preferred choice for most of my projects — small business websites, because it is easy to get the project up and running and it has some advantages (for example quite good UI) over other choices. But still, I find that the target groups are users they need to have website running within few clicks and developers who create generic themes.

So what I hate about this CMS?

1. Absolute urls

I don’t really get why it has to store absolute urls in database. It just adds one step of complexity when setting up, changing environment, deploying, changing domain. Wouldn’t be enough to have only the site url as the only occurrence of the absolute url inside the database? Plus, I think even that could be eliminated and have no absolute urls at all.

Why it is pain in the ass?

When you’re developing on localhost with a local url http://localhost:82 and then you want push the website to the live server, you need to make sure that all urls are replaced by the production ones.

Either you can export database as sql, open it in a text/code editor and do replace all. But this could cause a problem in the case the sql file is a big and your editor could crash. Another thing — some of plugins use json objects to store the content, which contains also the length of object. So if your domain length doesn’t match length of “https://localhost:82” it won’t work.

Or you can use wp-cli — really great tool for Wordpress — and run command

wp search-replace "http://localhost:82" "https://my-cool-domain.com"

Yes I know, there are plugins they can do it for you, but less plugin = better.

2. Most of plugins are frontend+backend

I am sure you’ve already installed a plugin like a gallery, which had all fields you needed for images, titles, alt attribute… And as well it generated the front-end with a bunch of styles and javascripts, with possibility to have it as a lightbox, slider, masonry, with arrows, pagination, with load more, infinite scrolling…

It works perfectly out of the box, so easy to quickly add a fancy gallery to the website. Unless you want to customise it! Then you need to override CSS rules, tweak javascript or the worst scenario — you go to the folder plugin and modify the source code directly 😱

Why we can’t have plugins to only create fields within the admin and give the possibility to simply output raw data? And the whole templating, css, javascript will be up to you?!

Very good example is Yoast Seo Plugin, which works great, it is very helpful except it is not easy to retrieve meta value. If you want to dynamically modified your meta description — good luck with that.

3. Database structure

Almost everything is either in wp_posts table or wp_postmeta! Pages, posts, custom posts, Acf_fields, navigation items, revisions, attachments… Everything is inside wp_post. And the wp_postmeta basically contains every additional information for rows in wp_posts as an individual row.

Why the DB structure couldn’t be managed in better way? Why each post_type couldn’t have its own table with its fields? It was a rhetorical question, because I know that it would also bring some complexity in the code. But it doesn’t mean, that putting everything in one table, is the best solution to store data.

Another thing — Wordpress recommends to use MySQL or MariaDB, which are structure databases. But we’re storing unstructured data in kind-a structured way. All non-default post data are stored either inside the table wp_postmeta as one file per 1 or 2 rows, or as a JSON object inside the column post_content thanks to Gutenberg.

4. Users first, developers second

Since the beginning Wordpress was meant forend-users, to create their blogs as easy and fast as possible. And they’ve done a good job with that, because not many of most current populars CMS/Frameworks looks like we’re in 21st century yet.

However they are forgetting about developers. It is not only a blogging platform anymore, lot of really big websites and apps are built on it, but the core doesn’t received as much attentions as the UI. They’re slowly approaching WIX-like platform, where the whole building of website will be just matter of few clicks.

What exactly I’d like to have in Wordpress?

  • environment settings — I’m using https://github.com/vlucas/phpdotenv, but this is something what I consider as a standard

  • installing dependencies/plugins via composer — I know it’s possible, just not out of the box

  • to don’t have global and environment settings inside the database — or at least have an option to configure them in wp-config.php for example, so it would be easier to version, synchronise and deploy it.

5. plugins — quantity over quality

I don’t need to say it, everybody already knows it. There are so many plugins, for each feature that you want to implement, you can find at least 20 of them. I am sure you’ve already search in google for a solution/documentation of some feature and first 10 results were plugins.

The quantity wouldn’t be the main problem, but the quality of code, support and maintenance is in most case very poor.

What should be improved?

  • Consistency between different plugins, every developer has its own approach to development.

  • Focusing on one single feature and doing it properly, instead of trying to do everything and do it poorly.

  • Consistency in their UX.

  • Not allowing to contain ads all over the wp-admin.

6. functions.php

This file is evil! Every tutorial, how-to, solution to a problem starts with copy this code to the fuctions.php. And most of projects then have fuctions.php with few thousands lines of code, which is not unmaintainable and definitely not portable among projects.

7. Missing structure

Linking to the previous point —Wordpress theme is structure-less, without any good practice, recommendation, requirements..

The theme required only three parts:

  • index.php

  • functions.php

  • style.css

The rest is up to you, you can create folders, files as you wish. This is is great, or isn’t it?

The freedom is great, but something having some rules or defined good practice could lead to better results. Because this way every developer (including myself) creates his/her own structure, what is in his/her opinion the best. Someone puts everything in the functions.php, other creates 3 levels folders and subfolders with PHP files to include etc.

8. Templates

I definitely miss a separations of the php logic and view part (yes I’m coming from MVC world). In general in Wordpress you can everything inside the template file — DB queries, methods, filters, includes and among all this some html code, which quite often has opening tag in file and closing in another.

In one word — mess!

I am a huge fan of Twig and it’s adaptation for Wordpress Timber, I wouldn’t start a WP project without this plugin anymore, so I would really appreciate to have it natively or optionally in the CMS. That would be amazing.

Or if not a real templating system, why not to have separate code into “controllers” and “views” files? It would make maintenance of code much more easier and enjoyable

9. Wordpress has its own PHP standards

In the world where most of frameworks and CMS’s take advantage of the OOP, Wordpress relies on half functional half OOP approach. Sometimes you work with instances objects, sometimes only functions, sometimes static methods and most of the time with hooks, actions and filters.

There is not much occasions to leverage OOP while creating templates, it is used mostly in the core. However you can find classes there, other “signs” of OOP like abstraction, inheritance, polymorphism, encapsulations are present very lightly or not at all. And We definitely can’t talk about SOLID principles.

We can only dream about dependency injections…

PHP world tries to standardise development for example https://www.php-fig.org, but Wordpress keeps its own standards. Even things as simple as the naming convention for methods — Wordpress uses snake_case vs. camelCase rest of the PHP world.

For/Foreach syntax it’s also very Wordpress specific:

if($query->have_posts()):
    while($query->have_posts()):
        $query->the_post();
        echo the_title()
    endwhile;
endif;

Instead of getters and setters Wordpress has filters:

// get value
$value = apply_filters( 'hook', $value, $arg2, $arg3 );

// set value
function example_callback() {
    ...
    return 'some value';
}
add_filter( 'hook', 'example_callback' );

and so on…

10. It tries to be and do everything

This is not a “fault” of Wordpress itself as of us — developers. Just because we can write plain PHP (and JS) with which we can do basically whatever this language is capable of, doesn’t mean we should do it.

Wordpress, as I mentioned before, was build as a blogging platform, where you can create quite easy a simple blog/website. The idea behind it wasn’t to build a framework or e-commerce platform, there are other much more appropriate solutions for that. But even though we use it to build sometimes very large web apps.

Conclusion

However there are many things I don’t like about it and I bet you could find some as well, it’s a great platform. It has its negatives what may or may not be changed, but it has also its positives what reflect on statistics of usage.

My goal wasn’t to show how bad it is, but rather to show that there are things they could be improved by us — the way we use it or by Wordpress contributors in future.

Did you find some points where you didn’t agree with me? Or something I’ve totally missed?