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:
[Wed Sep 17 09:42:59 2014] [error] [client IP address] PHP Fatal error: Call to undefined function get_header() in /home/wp-content/themes/snow-summit/index.php on line 10
[Wed Sep 17 09:43:13 2014] [error] [client IP address] PHP Fatal error: Call to undefined function get_header() in /home/wp-content/themes/snow-summit/index.php on line 10
Tracking the Error
The error pointed to the
Here are the first ten lines of the file:
<?php setlocale(LC_ALL, 'en_US'); ?>
* @package WordPress
* @subpackage Snow Summit
* @since Snow Summit 1.0
Nothing wrong here whatsoever. The error was triggered simply because some hacker probably tried to run the theme’s
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
And there it was, on line 37 of the code an unusual way of linking to the website’s RSS feed:
<link rel="alternate" type="application/rss+xml" title="Site Title" href="http://website.com/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:
<link rel="alternate" type="application/rss+xml" title="Site Title - RSS 0.92 Feed" href="<?php bloginfo('rss_url'); ?>" />
<link rel="alternate" type="application/rss+xml" title="Site Title - RSS 2.0 Feed" href="<?php bloginfo('rss2_url'); ?>" />
<link rel="alternate" type="application/rss+xml" title="Site Title - Atom Feed" href="<?php bloginfo('atom_url'); ?>" />
<link rel="alternate" type="application/rss+xml" title="Site Title - RDF/RSS 1.0 Feed" href="<?php bloginfo('rdf_url'); ?>" />
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: