Mootools kommt mit Contao-URLs offenbar nicht klar. Weiß jemand einen Ausweg?

Hi,

scheinbar gibt es ein Problem mit Mootools und den suchmaschinenfreundlichen Contao-URLs im Stil von http://irgendwas.de/index.php/startseite/parameter1/wert1/parameter2/wert2.html, der dazu führt, dass der Browser mehrfach fälschlicherweise die Contao-Seite abruft. Ich habe auf der Seite eine aufwändige Suchroutine und durch solche mehrfache Aufrufe dadurch große Performance-Probleme.

Wichtige Anmerkung gleich vorweg: Bindet man Mootools gar nicht ein bzw. deaktiviert man JavaScript, tritt das gesamte genannte Problem überhaupt nicht auf. Natürlich ist das aber keine Lösung!

Folgendes Verhalten habe ich festgestellt:

Ruft man eine mit einer URL ohne GET-Parameter auf (also z. B. http://irgendwas.de/index.php/startseite.html), so liefert das Firefox-Plugin "Live HTTP Headers" folgenden Mitschnitt der Kommunikation mit dem Server:

Code:

---

GET /index.php/startseite.html
GET /system/contao.css
GET /plugins/formcheck/theme/classic/formcheck.css
GET /tl_files/system/css/reset.css
GET /tl_files/system/css/default.css
GET /tl_files/system/css/styles01.css
GET /plugins/mootools/mootools-core.js?1.2.5
GET /plugins/mootools/mootools-more.js?1.2.5.1
GET /tl_files/system/layoutImages/logo.gif
GET /tl_files/system/layoutImages/banner.gif

---

Das ist so natürlich richtig und funktioniert.

Jetzt kommt das erstaunliche: Ruft man die selbe Seite mit übergebenen GET-Parametern auf (also z. B. http://irgendwas.de/index.php/startseite/parameter1/wert1/parameter2/wert2.html), so werden folgende HTTP-Header mitgeschnitten:

Code:

---

GET /index.php/startseite/parameter1/wert1/parameter2/wert2.html
GET /system/contao.css
GET /plugins/formcheck/theme/classic/formcheck.css
GET /tl_files/system/css/default.css
GET /tl_files/system/css/reset.css
GET /tl_files/system/css/styles01.css
GET /plugins/mootools/mootools-core.js?1.2.5
GET /index.php/startseite/parameter1/wert1/parameter2/plugins/mootools/mootools-more.js?1.2.5.1
GET /plugins/mootools/mootools-more.js?1.2.5.1
GET /index.php/startseite/parameter1/wert1/parameter2/tl_files/system/layoutImages/logo.gif
GET /index.php/startseite/parameter1/wert1/parameter2/tl_files/system/layoutImages/banner.gif

---

Interessant sind hierbei die letzten 4 GET-Headers. Da wird vom Server zunächst das Mootools-More-Script angefragt, allerdings mit einer URL, die so ja gar nicht funktionieren kann, da sie das "index.php"-Fragment enthält und daher nicht das Skript sondern die Contao-Seite zurückgibt. Dann folgt seltsamerweise nochmal die korrekte Anfrage des Mootools-More-Scripts und dann noch zwei Anfragen für Bilder, die auch eine falsche URL haben.

Das ist jetzt nur ein Ausschnitt. Tatsächlich werden ALLE Bilder, die irgendwo im HTML-Code per <img>-Tag eingebunden sind, mit dieser falschen URL angefragt. Daraus resultiert natürlich, dass Contao jedes Mal die Seite generiert (was man natürlich nicht zu sehen bekommt) und dadurch enthaltene Routinen wie z. B. Suchfunktionen mehrfach ausführt. In meinem Fall speichere ich z. B. auch die per GET übertragenen Parameter in der Session, was aber natürlich auch zum Scheitern verurteilt ist, da bei den seltsamen Bild-Aufrufen die auszuwertenden Parameter falsch sind.

Der Aufruf von "/index.php/startseite/parameter1/wert1/parameter2/tl_files/system/layoutImages/logo.gif" ergibt ja logischerweise in Contao das Generieren der Seite "startseite" und Contao wertet die restliche URL als GET-Parameter folgendermaßen aus:

$_GET:
'parameter1' => 'wert1'
'parameter2' => 'tl_files'
'system' => 'layoutImages'
'logo' => ''

Ich hoffe, das Problem kommt verständlich rüber. Ich habe jetzt schon einen vollen Tag gebraucht, um es soweit analysieren zu können...

Hat irgendjemand einen Ansatz, wie man das korrigieren kann? Ich bin mir recht sicher, dass das Problem nicht auftritt, wenn man in Contao nicht mit Aliasen und stattdessen mit gewöhnlichen URLs im Stil von "http://irgendwas.de/index.php?paremter1=wert1&parameter2=wert2" arbeitet, aber das ist für mich keine Lösung, da ich die suchmaschinenfreundlichen URLs benötige!

Vielen Dank schonmal im Voraus für jeden noch so kleinen Tipp!

Okay, ich bin jetzt drauf gekommen, woran es lag und ich bin tatsächlich völlig erstaunt, dass so etwas passieren kann:

Ich habe mir zum Test eine SQL-Abfrage ausgeben lassen. Einfach mal so irgendwo im Code mit echo. Im Quelltext, der beim Browser ankam, landete diese Testausgabe natürlich ÜBER dem öffnenden HTML-Tag. Dass das nicht valide ist, ist klar, aber für ne Testausgabe geht das ja.

Tatsächlich tritt dann genau das von mir beschriebene Phänomen auf! Offensichtlich macht Mootools irgendwas, was ich nicht nachvollziehen kann, wenn vor dem öffnenden HTML-Tag bzw. vor der Doctype-Definition irgendetwas steht.

Schon toll, die ganzen Testausgaben, die ich gemacht habe, um das Problem einzugrenzen, haben es tatsächlich immer schön am Leben gehalten ;-)

Übrigens ist damit auch der Thread http://www.contao-community.de/showt...755#post107755 erledigt, da - was mir jetzt erst klar ist - dort genau das gleiche Problem zu Grunde liegt!

Das Problem liegt nicht an Mootools, sondern deinem Browser ;)
Der versucht die Mootools Scripte einfach von der falschen URL zu laden, weil er den base Tag nicht berücksichtigt. ;)

Aber warum versucht der Browser nur dann auch alle Bilder von der falschen URL zu laden, wenn Mootools eingebunden ist, nicht aber wenn Mootools nicht eingebunden ist? Wenn der Browser den Base-Tag nicht berücksichtigt, sollte er das doch immer nicht machen und nicht nur dann nicht, wenn Mootools eingebunden ist, oder?!?

Darüberhinaus lädt er das erste Mootools-Script (Core) ja trotz allem von der richtigen URL (da berücksichtigt er den Base-Tag also noch) und erst wenn er den Mootools-Core geladen hat, werden die anderen URLs versaut.

Die Details dieses Phänomens zu verstehen wäre irgendwie schon ganz interessant, aber komplett hat es sich mir noch nicht erschlossen ...

Aslo ich kann mir nicht wirklich vorstellen, dass dies an Mootools liegt.

Welchen Browser verwendest du? IE (und auch gewisse andere Browser) fallen in den Quirks-Mode wenn die erste Zeile nicht der Doctype ist (sondern deine Debug-Ausgabe. Gut möglich dass dadurch der base-Tag nicht mehr berücksichtigt wird. Ausserdem funktioniert Mootools auch nicht im Quirks-Modus, das könnte ein weiterer Grund sein.

Aufgefallen ist mir das Ganze im Firefox 3.6. Den Bezug zu Mootools vermute ich halt einfach deshalb, weil das alles ohne Mootools nicht passiert. Der Browser selbst verhält sich normal, wenn man die Einbindung des Mootools-Scripts entfernt. Gar nicht erklären kann ich mir aber ohnehin, wo und wie die URLs der Bild-Anfragen an den Server verändert werden. Der src-Wert der img-Tags wird scheinbar nicht verändert, sonst müsste ich das ja mit Firebug erkennen können. Zunächst hatte ich daher einen Ajax-Request im Hintergrund vermutet, aber auch das ist es nicht, denn auch ein solcher Request müsste in Firebug zu sehen sein und außerdem müssten dann in Live HTTP Headers zunächst ja wohl die regulären Bild-Anfragen auftauchen...

Wenn man weiß, welch seltsame Auswirkung eine solche Testausgabe vor der Doctype-Definition hat, ist das ja alles eh kein Problem mehr. Schlimm ist es halt nur, wenn man es nicht weiß und so wie ich in den letzten Tagen einem Phantom hinterher jagt.