Akeeba Backup 5.5.0 and a fatal error accessing your site's administrator

07 August 2017 Last updated on 08 August 2017

A small minority of Joomla! sites which use the MijoShop extension may experience a PHP Fatal Error, white page or Internal Server Error 500 when trying to access the site's administrator backend after installing Akeeba Backup 5.5.0. This usually manifests itself as the PHP error message PHP Fatal error: Call to a member function addStyleDeclaration() on null.

* Update August 8th *

This issue

  • affects you only if you have MijoShop installed; and
  • it will happen only in the backend of your site (NOT the front-end); and
  • it will happen instantly, not after seconds, hours or days. 

In any other case (i.e. MijoShop not installed and / or the issue is in the frontend of the site and / or it happened several seconds, hours or days after installing Akeeba Backup) your site's issue is unrelated to Akeeba Backup. Please take a look at your server's error logs for further clues.

Addressing this issue

  • Delete the folder plugins/system/backuponupdate
  • Edit the broken, third party "System - MijoShop jQuery" and set "Only if MijoShop" to No. Alternatively, you may disable the "System - Backup on Update" plugin.
  • Install Akeeba Backup 5.5.1 or later

Technical information

Below you will find more technical information about the nature of the issue and the workarounds we applied. You do not need this information to address the issue on your site. All you need to address the issue can be found above. The technical information is provided in the spirit of radical transparency and because, let's face it, many of our clients are technical and curious enough to enjoy such a write-up. :)

Why does it happen? (Updated August 8th)

A new feature was intriduced in the System - Backup on Update plugin in Akeeba Backup 5.5.0. This feature displays the status of the plugin in Joomla's status bar (the footer of the administrator page). The same status icon allows you to enable / disable the plugin.

For this feature to display correctly we need to add a bit of CSS to the page. We do that using the official Joomla! JDocument API for that and only when the output type is set to HTML. We do that since we know that adding CSS only works for HTML output and we don't want our plugin to break your sites.

Apparently some third party extensions mess up with Joomla's internals and force Joomla to use a custom application object which doesn't return a JDocument API object. This is equivalent to a core hack... and quite simply we didn't anticipate that extension developers would do something that evil in production code.

* Update August 8th *

After thorough investigation we have discovered why this issue occurs and why it persists after upgrading to Akeeba Backup 5.5.1. We have concluded that this issue is not actually a bug in Akeeba Backup itself but a bug in MijoShop.

More specifically, their plgSystemMijoshopJquery plugin -whose only purpose is load some jQuery- uses the wrong event handler (onAfterInitialise instead of onBeforeRender). The major difference is that their code runs before Joomla! has the chance to set up its core API objects, including the JDocument object (which is what they should be using to load Javascript, if they knew how Joomla! works).

On top of using the wrong event handler and the wrong method for initializing the document object (instead of letting Joomla! do this), they are also using JModuleHelper. This has the side effect of loading modules prematurely. This breaks plain HTML plugins which use content tags, among other things. It also breaks our plugin which tries to inject a module into the site's footer. However, the problem here is that Mijo is loading modules prematurely. Had they used the correct event handler this wouldn't be an issue.

This issue does not come from our code. It happens because of badly written, third party code. Moreover it is isolated to one specific third party extension with a very limited market share. Furthermore, we now have a viable workaround. As a result we will not publish another emergency update to address it. A workaround will be included as a low priority fix in Akeeba Backup 5.5.2, whenever it is released. As a temporary solution we recommend editing the "System - MijoShop jQuery" and setting "Only if MijoShop" to No. Alternatively, you may disable the "System - Backup on Update" plugin. Even better, please ask MijoShop developers to fix their bad code. This article has been edited to reflect the availability of this conclusive information.

How was it fixed?

Akeeba Backup 5.5.1 works around this issue by anticipating this kind of core hacks. If such a core hack is detected it will first try to use a legacy method for inserting CSS to the generated page, one that will go away in the not-so-distant future. If that method is not available or fails for any other reason we will simply not make available the new feature of the Backup on Update plugin.

* Update August 8th *

Akeeba Backup 5.5.1 missed a second place where we access the same core API. If you are interested in a manual fix, edit plugins/system/backuponupdate/tmpl/default.html.php and replace the following line (found around line 36 of the file):

JFactory::getApplication()->getDocument()->addScriptDeclaration($js);

with the following block

$document = JFactory::getApplication()->getDocument();

if (empty($document))
{
   $document = JFactory::getDocument();
}

if (empty($document))
{
   return;
}

$document->addScriptDeclaration($js);

This is the workaround which will be included in Akeeba Backup 5.5.2.