An article I read:


While developing and supporting JoomGallery 1.5.5 we detected a problem which is related to very many third party system plugins.

In our opinion, these plugins don't respect a certain attribute of Joomla by what problems may occur if the site uses search engine friendly URLs.

We want to explain this correlation here and ask the developers of these plugins to check their code concerning this matter and to fix it where appropriate.

For illustration we will have to go into greater detail: As probably known by many developers there are four system plugin events in Joomla at the moment which are triggered in the following order: 'onAfterInitialise', 'onAfterRoute', 'onAfterDispatch' and 'onAfterRender'.

In the following primarily the events 'onAfterInitialise' and 'onAfterRoute' are important as well as a core parameter of Joomla called 'format'. This parameter, which usually is delivered within a URL, determines which document type (see $document->getType()) of Joomla shall be rendered. By default, this is 'html', thus an ordinary HTML page. Because of that 'format' isn't usually delivered for HTML pages (the default value 'html' is used then).
Other possible values are 'error', 'feed', 'pdf' and 'raw' (they match with the sub-directory names of folder 'libraries/joomla/document'). For example, if you want to create a PDF file and output it you will have to use 'format=pdf' explicitly in the URL so that Joomla renders this document type automatically.

The actual problem can only occur if search engine friendly URLs are enabled in Joomla (it doesn't matter whether it's the Joomla Core SEF or a third party SEF component). Since 'format' isn't explicitly in the URL anymore now (but implicitly in the SEF URL), Joomla isn't able to "know" that another document type than 'html' is requested until event 'onAfterRoute': Only now the SEF URL was parsed and 'format' is available explicitly again.

However, this alone still isn't responsible for the actual problem. That one occurs not until a system plugin is installed and enabled which fulfils the following conditions:

It uses the event 'onAfterInitialise' or the constructor.
In at least one of these, it calls the document library of Joomla.
This may happen directly with:

$document =& JFactory::getDocument();

or also indirectly with e.g.:

$mainframe->addCustomHeadTag($html);

If these conditions are fulfilled (which happens with very many system plugins unfortunately), 'JDocument' is loaded before 'format' is known explicitly to the system.

Thus the line

$instance->setType($ntype);

of function 'getInstance()' in file 'libraries/joomla/document/document.php' irrevocably determines the document type of the current request with 'html' (this cannot be changed later on)!

An extension which requests another document type (e.g. JoomGallery requires 'format=raw' for displaying a single image) cannot work correctly anymore with that.

Conclusion

Since 'format=html' is determined afore it's sure that definitly 'html' is requested because of these certain system plugins we think that these plugins are responsible for the problem.

Plugins which want to change the HTML output of a page shouldn't do that until it's definitly sure that an HTML page is actually requested. This is the case at event 'onAfterRoute' at the earliest.

We hope that many developers among you read this text und try to rewrite the plugins which call 'JDocument' in order to let them only use the events 'onAfterRoute', 'onAfterDispatch' and 'onAfterRender'. Tests on our site have shown that this is mostly practicable without much effort.

Thank you for reading this very theoretical text!