How I discovered faulty code in a WordPress theme

Update: I can’t seem to reproduce the issue anymore. I don’t know what exactly happened.

I have been using Publisher WordPress Theme by Better-Studio for a long time. 5 of my clients uses it. And to be honest this is probably the most advanced wordpress theme I’ve ever used. Seriously it’s really advanced and more importantly everything is optional.

But let’s not dive into that, I’m here to discuss some other topic.

After the release of WordPress 5.0 the Publisher WordPress Theme also got updated to make compatibility with Gutenberg. The latest version of Publisher theme is v7.5.4.

My clients were using Publisher v7.0.2 because it was (or is ?) the most stable version of that theme, so I told my clients not to update the theme without my consent. But after bunch of incremental updates, I thought this is probably the best time to update the theme.

But after updating to Publisher v7.5.4 my clients were facing extremely slow back-end (when logged in as admin). So, I checked and unfortunately it was true. The back-end became extremely slow. I had no idea what’s causing it. After debugging for a while finally I found the culprit.

I’ve used Query Monitor to debug queries. Query Monitor is the developer tools panel for WordPress. It enables debugging of database queries, PHP errors, hooks and actions, block editor blocks, enqueued scripts and stylesheets, HTTP API calls, and much more.

Before I start let’s clear some things first:

  1. The test were made in a staging site with absolutely NO Plugins installed.
  2. WordPress version – 5.0.3
  3. Publisher theme version – 7.5.4

We all know, WordPress relies on database heavily. Each action performed in WordPress is connected directly or indirectly with its database. So, having poorly or faulty coded themes or plugins can give you really hard time.

Let’s make this simpler.

Case 1: Using Twenty Nineteen theme

When we click “All Posts” in WordPress dashboard, we’re selecting/viewing some Posts from the database. As you can the above screenshot, “Database Queries = 30“. That means there are 30 VIEW queries were made to the database. In case you don’t know that’s normal and valid.

Note: If there were no UPDATE queries were made, the plugin will show only total queries. But if UPDATE queries were made, the plugin will explicitly show them.

Keep reading you will understand what I’m trying to say.

Case 2: Using Publisher theme

Now, when I’m using Publisher theme and clicked “All Posts”, the Database Queries were horrifying. Most importantly why the heck there was UPDATE queries when I’m just viewing the posts?

That’s the culprit. That’s the reason WordPress backend became slow like hell. Because everytime I visit “All Posts” pages, the theme VIEW and UPDATE to the the database, where it should only VIEW, not UPDATE.

Now you might be thinking maybe that’s how the Publisher theme works? Let’s just pretend that’s how the theme works, then again you’re wrong.

Case 3: Using Publisher + Classic Editor plugin

Now I’ve installed Classic Editor plugin along with Publisher theme and tested the same thing. And this is the result:

As you can see when Classic Editor plugin installed Publisher theme again started working how it should be. There are no UPDATE queries were made, only VIEW and SELECT queries. And that’s exactly how it’s supposed to work.

Interesting, isn’t it?

TL;DR: In the WordPress 5.0 or later if Classic Editor plugin not installed, Publisher theme behaving abnormally, which causes slow back-end. The problem could be site-wide. I don’t know for sure.

I have also reported this Bug, to the Publisher support team, I hope they patches it ASAP.