Resolving the Dreaded “Call to a member function getDocument() on a non-object” Error on a Joomla Website

A client called us yesterday and told us that his website was displaying the following error after a manual upgrade of his Joomla 3.1.1 website to Joomla 3.5.1:

Fatal error: Call to a member function getDocument() on a non-object in plugins/system/sef/sef.php on line 36

We then asked him, what do you mean exactly by a manual update? He said that he just downloaded Joomla 3.5.1 and then extracted it to the main directory of his Joomla 3.1.1 website. Hmmm… Typically, such an update can cause problems because Joomla’s 3.5.1 file structure is slightly different (actually “slightly” is not the right word, it’s slightly more than slightly) than that of Joomla 3.1.1.

Naturally, the first thing that we did (after asking the client if he had a backup of the full website before updating, which unfortunately he didn’t have) was that we opened the sef.php located under the plugins/system/sef folder, and we looked for the error line (39), which was this one:

$doc = $this->app->getDocument();

We did some printouts, and we discovered that $this contained a lot of data, but not $app, which was curious, since $app was a protected attribute, which meant that the parent class, JPlugin, must have it defined somewhere.

So we opened the file plugin.php, which was located under the libraries/cms/plugin folder, and we checked what was going there. We saw that it was defining $app under certain conditions, in the following code:

if (property_exists($this, 'app'))
{
	$reflection = new ReflectionClass($this);
	$appProperty = $reflection->getProperty('app');

	if ($appProperty->isPrivate() === false && is_null($this->app))
	{
		$this->app = JFactory::getApplication();
	}
}

So, in order to see if the above conditions were met, we added a die(‘in condition…’); just after the first condition, but that didn’t print out. So we added die(‘in file…’); at the beginning of the plugin.php file, but that didn’t print out either, we still saw the same issue, which essentially meant that the plugin.php file wasn’t even loaded at all! Curious and curiouser… How can a child class run without loading the parent class first? That’s practically impossible!

The next logical step was to confirm that the aforementioned plugin.php file was not loaded by Joomla (to make sure that we are not running into insane caching issues). In order to do that, we added the following code in the sef.php file immediately before the problematic line:

$arr = get_included_files();
print_r($arr);
die();

We then checked the website, which had a list of all the files that were loaded by the Joomla application to serve that page. We particularly searched for the file plugin.php, and we found it being loaded from this location:

libraries/joomla/plugin/

But, the file should be loaded from here:

libraries/cms/plugin

A quick check in the Joomla 3.5.1 default directory revealed that the folder libraries/joomla/plugin doesn’t even exist anymore, and that that folder was ported over from the previous Joomla installation. So, the problem was that Joomla was loading the JPlugin file from the old directory, and not from the new directory.

So, how did we fix the problem?

Fixing the problem consisted simply of deleting the folder libraries/joomla/plugin. But, we had other problems after fixing this problem, which we resolved by removing the following folders:

• libraries/joomla/html
• libraries/joomla/pagination
• libraries/joomla/registry

We then had to repair the database (twice).

As you can see, fixing a botched Joomla update is not that hard (once you know how), but again, it’s always a good idea to update Joomla using the standard, recommended method (as other methods are pretty much advanced because they entail fixing fatal errors).

If you are seeing the much dreaded Call to a member function getDocument() on a non-object then most likely you are left with a folder (or a few folders) from a previous Joomla install. If you need help finding these folders, then please contact us. We will find these folders, delete them, make sure that your website works again, and we will do that for a very affordable fee!