The Case of the Slow WordPress Dashboard


Today I received a request for help from one of my readers. She noticed that her WordPress dashboard slowed down considerably in the last few days and asked me if I could take a quick look at the problem.

Looking for Errors

I have learned a long time ago that any computer problem can have many different reasons. Therefore there is no simple if-this-then-that approach to solving computer problems. It’s a form of art as much as it is technical knowledge and scientific reasoning.

In this case I had a fully functioning website that’s WordPress dashboard was loading excruciatingly slowly. But at the same time the website’s pages were loading fast and without any problems. This fact alone made me focus on the back-end, i.e. the behavior of WordPress and its plugins on the hosting server.

I connected to the hosting server via FTP and started browsing around. Luckily, servers create automatic logs for all errors that their programs come across. That’s a good place to start digging. The most current error log file contained this data:

Tracking the Error

The error pointed to the index.php file of the website’s active WordPress theme. The error occurred at line 10 of this file.

Here are the first ten lines of the file:

Nothing wrong here whatsoever. The error was triggered simply because some hacker probably tried to run the theme’s index.php file directly. The client IP address (not shown in the excerpt above) pointed to South Africa.

When run directly, the get_header() function is not recognized, because the server isn’t aware at that point that the file is calling upon a WordPress function — get_header() being part of WordPress itself.

Although the server logged this event as an error, it was part of a primitive and unsuccessful attack and nothing else.


Out of curiosity I opened the header.php file of the theme as the next step. The get_header() function, when recognized as part of WordPress, looks for this file too.

And there it was, on line 37 of the code an unusual way of linking to the website’s RSS feed:

There are two problems with the above line. First, there shouldn’t be a forward slash at the end of the feed’s URL. Second, it’s better to use WordPress’ built-in feed tags instead of linking to the feeds directly.

I deleted this line of code and replaced it with the following four lines of code:

I saved the changes and sure enough, WordPress dashboard started to load lightning fast again. The problem started soon after the website’s WordPress installation was upgraded to the current 4.0 version. This might have somehow triggered the slow dashboard problem.

Liked this post?

Subscribe to our newsletter to receive early notification of new posts and deals:
[mc4wp_form id=”45″]

Next Post »« Previous Post