Detail- und Originalbilder werden nicht angezeigt, warum?

In der Vergangenheit wurde häufig über das Problem berichtet, dass zwar Thumbnails aber keine Detail-/Originalbilder angezeigt werden. Es sieht dann beispielsweise so aus wie in diesen Screenshots zu sehen:

Detail-Ansicht:

Die Ursache dafür ist meistens ein Konflikt mit einem System-Plugin in Joomla!. Damit sind nicht die mit Joomla! mitgelieferten System-Plugins (Core) gemeint, sondern welche die durch eine Dritterweiterung installiert wurden.
Um das problematische Plugin zu ermitteln, deaktiviert testweise die Drittanbieter System-Plugins und überprüft, ob dann die Detail-/Originalbilder angezeigt werden.

Technischer Hintergrund

Unserer Meinung nach beachten diese Plugins eine bestimmte Eigenschaft von Joomla! nicht, wodurch es zu Problemen kommen kann, wenn eine Seite mit suchmaschinenfreundlichen URLs arbeitet.

Diesen Zusammenhang möchten wir hier erläutern und die Entwickler dieser Plugins dazu aufrufen, ihren Code diesbezüglich zu überprüfen und gegebenenfalls anzupassen.

Zur Erklärung müssen wir leider etwas weiter ausholen: Wie den meisten Entwicklern wahrscheinlich bekannt ist, gibt es in Joomla unter anderem vier System-Plugin-Events, die in folgender Reihenfolge getriggert werden: 'onAfterInitialise', 'onAfterRoute', 'onAfterDispatch' und 'onAfterRender'.

Im Folgenden sind vor allem die Events 'onAfterInitialise' und 'onAfterRoute' wichtig sowie ein Core-Parameter von Joomla namens 'format'. Dieser Parameter, der für gewöhnlich in der URL mit übergeben wird, gibt an, welcher Dokumententyp (siehe $document->getType()) von Joomla gerendert werden soll. Standardmäßig ist das 'html', also wenn eine ganz normale HTML-Seite geladen werden soll. Deshalb wird 'format' auch normalerweise bei HTML-Seiten nicht übergeben (dann wird der Default-Wert 'html' verwendet).
Andere mögliche Werte sind 'error', 'feed', 'pdf' und 'raw' (diese entsprechen den Unterordnernamen des Verzeichnisses 'libraries/src/Document'). Falls man zum Beispiel eine PDF-Datei erstellen und ausgeben möchte, müsste mal also 'format=pdf' explizit in der URL mit angeben, damit Joomla automatisch diesen Dokumententyp rendert.

Das eigentliche Problem kann nur autreten, wenn die suchmaschinenfreundlichen URLs in Joomla aktiviert sind (dabei ist es egal, ob es sich um das Joomla-Core-SEF oder um eine SEF-Komponente handelt). Da sich der 'format'-Parameter jetzt nämlich nicht mehr explizit in der URL befindet (sondern nur noch implizit in der SEF-URL), kann Joomla erst frühestens beim Event 'onAfterRoute' "wissen", dass 'format' nicht gleich 'html' sondern etwas anderes ist: Erst jetzt ist nämlich die SEF-URL geparsed und 'format' steht wieder explizit zur Verfügung.

Dies allein sorgt aber immer noch nicht für das eigentliche Problem. Dieses tritt nämlich erst auf, wenn ein System-Plugin installiert und aktiviert ist, das die folgenden Bedingungen erfüllt:

• Es verwendet das Event 'onAfterInitialise' oder hat Code im Konstruktor.
• Innerhalb einer dieser Funktionen ruft das Plugin die Document-Library von Joomla auf.
  Dies kann direkt geschehen mit:
  
  $document = &JFactory::getDocument();
  
  oder auch indirekt mit Aufrufen wie zum Beispiel:
  
  $mainframe->addCustomHeadTag($html);
  
  

Sind diese Bedingungen erfüllt (was leider bei sehr vielen System-Plugins der Fall ist), wird 'JDocument' geladen, bevor der 'format'-Parameter dem System explizit bekannt ist.

Dadurch legt die Zeile

$instance->setType($ntype);

der Funktion 'getInstance()' in der Datei 'libraries/src/Document/Document.php' den Dokumententyp bereits endgültig auf 'html' fest (dies wird später nicht mehr geändert)!

Eine Erweiterung, die über die URL einen anderen Dokumententyp anfordert (die JoomGallery benötigt beispielsweise bei der Ausgabe eines Bildes 'format=raw'), kann damit nicht mehr korrekt arbeiten.

Zusammenfassung

Da durch diese bestimmten System-Plugins der 'format'-Parameter bereits auf 'html' festgesetzt wird, bevor sicher ist, dass überhaupt 'html' angefordert wurde, sind wir der Meinung, dass diese Plugins für das Problem verantwortlich sind.

Plugins, die den HTML-Output einer Seite verändern wollen, sollten dies erst tun, wenn absolut sicher ist, dass überhaupt eine HTML-Seite ausgegeben werden soll. Dies ist frühestens beim Event 'onAfterRoute' der Fall.

Wir hoffen, dass viele Entwickler diesen Text lesen und versuchen die Plugins, die auf 'JDocument' zugreifen, umzuschreiben, sodass sie nur noch die Events 'onAfterRoute', 'onAfterDispatch' und 'onAfterRender' verwenden.