Since the problem discussed in this post is becoming more common and is very critical, we have decided to start this post in reverse. We will first offer a very quick solution, and then we will discuss how we found the problem, and then finally offer a long term solution to the problem.
If you’re seeing one or more of the following errors on your Joomla website…
JLIB_APPLICATION_ERROR_COMPONENT_NOT_LOADING
Error loading component: com_login, 1
Error loading component: com_k2, 1
…then the super quick solution is to clear the Joomla cache, by logging in to the Joomla backend, and then going to Site -> Maintenance -> Clear Cache, and then clicking on the checkbox on the top (to select all cached items) and then clicking on Delete on the top right. This will fix the problem for the short term, but the problem might re-emerge again if the cause has to do with a problem on the server.
Now let us explain what happened yesterday afternoon. A new client called us and told us that only the homepage is working on his Joomla website, all the other links do not work. We thought, that’s a piece of cake; it’s definitely a corrupt .htaccess file, and that it was. But, there was an additional snag, the .htaccess file was hacked, which means that there was more to it. We cleaned up the .htaccess file, and we scanned the website for any other issues, but there were none. We informed the client that the website should be secured to ensure that hack won’t come back again and he authorized the work. Everything worked perfectly, but late at night, we started seeing the JLIB_APPLICATION_ERROR_COMPONENT_NOT_LOADING error everywhere on the site.
We did a quick investigation and we realized that this error is thrown when there is a problem with caching, and so we thought that the cache was corrupt (which was true), so we cleared the cache, and that solved the problem.
However, about an hour later, we started seeing the same problem again. Hmmm… Clearing the cache (again) fixed the problem, but we knew it was only a matter of time until we see the same problem again! And, to our disappointment, we weren’t wrong. We saw the problem about 30 minutes later. What could it be?
We checked Apache’s error log by logging in through ssh to the server (as root) and issuing the following command (note that our client was using WHM):
tail -f error_log
The following line displayed on the console:
[27-May-2014 20:44:19 America/New_York] PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/extensions/no-debug-non-zts-20100525/memcache.so’ – /usr/local/lib/php/extensions/no-debug-non-zts-20100525/memcache.so: cannot open shared object file: No such file or directory in Unknown on line 0
Aha! There was a problem with the MemCache Apache module, and that was causing the corruption in the cache. We immediately informed the hosting company and they took care of the problem by re-compiling the MemCache module.
So, what caused the MemCache module not to work all of a sudden?
It seems that when we told our client that his website was hacked, he informed his hosting company, and what they did was that they performed a PHP update, and some modules, such as the MemCache module, became incompatible with the new PHP version because they weren’t recompiled when PHP was updated.
If you’re having the same problem on your website, then try clearing your cache. If it only fixes the problem temporarily, then the problem might be something with your server. Check your Apache logs and inform your host. You can also contact us and we’ll do the work for you promptly, professionally, and for a very affordable fee.