Joomla 404 Pages Causing Load and Memory Issues – How to Fix

Note: The solution presented in this post consists of a core modification, since it addresses a Joomla bug. Proceed at your own risk and always backup your Joomla website before modifying core files. Oh, and don’t forget that future Joomla updates may wipe out your changes (so you may need to redo them after each update).

Another note: Just after finishing this post, we discovered that we have written something very similar here. Oh well!

A problem that is inherent to Joomla, and that most people do not know about, is the 404 page, and it’s not because most Joomla websites do not handle it properly, it’s because the load and memory issues it can cause on large websites. “Load issues”, we hear you ask? What possibly can a 404 page have anything to do with the load on the server? It should be the quickest page to load on the whole website? Right?

Well, wrong! You see there is a bug in Joomla that makes the 404 page the heaviest page on large websites. The problem is that Joomla processes the 404 page as a category page with no catid (category ID) and with no limit. In other words, each time Joomla encounters a 404 page, it gets all the content items from the database for all the categories! Take a look at this query generated by a 404 page on a Joomla website just before we fixed it:

# Time: 160426 11:49:30
# User@Host: database_user[database_user] @ localhost []
# Query_time: 8.090585 Lock_time: 0.000784 Rows_sent: 76795 Rows_examined: 438986
SET timestamp=1461685770;
SELECT a.id, a.title, a.alias, a.introtext, a.fulltext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = '0000-00-00 00:00:00' THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits,a.state AS state,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias,c.published, c.published AS parents_published
FROM #__content AS a
LEFT JOIN #__categories AS c ON c.id = a.catid
LEFT JOIN #__users AS ua ON ua.id = a.created_by
LEFT JOIN #__users AS uam ON uam.id = a.modified_by
LEFT JOIN #__categories as parent ON parent.id = c.parent_id
WHERE a.state = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2016-04-26 15:49:29') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2016-04-26 15:49:29')
ORDER BY CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END DESC , a.created;

Not only the query above was causing a huge load issue, but it was also exhausting the maximum memory allocated to each PHP page. So, the 404 page was actually showing the following (instead of, well, a 404 page):

Allowed memory size of 536870912 bytes exhausted (tried to allocate 231 bytes) in /home/[user]/public_html/libraries/joomla/database/driver/mysqli.php on line 811

Of course, when you notice that the above query returned almost 77,000 rows from the database, you start putting things into perspective, and you won’t be surprised by the fact that the whole 512 MB allocated were completely exhausted (by the way, just out of curiosity, we increased the maximum memory in a local php.ini to 2 GB, but still we had the same problem).

So, how do we solve the problem?

Well, fixing this problem is not that hard; you only have to do the following:

  • Open the file category.php located under the components/com_content/models folder.

  • Just after this line:

    $limit = $this->getState('list.limit');

    Add the following lines:

    if (!isset($limit) || empty($limit))
    return array();

  • Save the file and upload it back.

  • That’s it!

As you can see, the whole fix consists of a minor modification to a core file (the modification ensures that Joomla doesn’t query the database if the limit field is not specified), but we understand that some Joomla administrators out there may not want to do this themselves. If you’re one of them, then please contact us, we will do it for you in not time, for an excellent price, and you’ll gain genuine friends and a reliable supplier!

No comments yet.

Leave a comment