Der übliche Browser-Kampf …

Zugegeben, ich sollte meine CSS-Geschichten vielleicht langsam mal mit einem etwas aktuelleren Arsenal an “SchrottBrowsern” testen - Aber erfahrungsgemäß wird alles, was mit Internet-Explorer 5.01, 5.5, 6.0, Netscape 6 und 7, Opera 8 und Firefox (noch der 1.5er) läuft, auf so ziemlich allen Systemen fehlerfrei dargestellt. Und manchmal dauert es ein wenig, bis meine “Software-Opas” nicht mehr herumzicken und die Seiten überall exakt gleich angezeigt werden …

Meistens sind es Darstellungs-Probleme, mit denen man sich herumärgert. Und (so sehr auch immer auf den Internet-Explorer geschimpft wird) - Die “IE-Macken” hat man immer ziemlich schnell im Griff. Mit ein bisschen Übung weiß man schon beim Schreiben des Quellcodes, welchem Element man beispielsweise das “Padding” und welchem “Margin” geben sollte, welche Elemente eine Größen-Angabe brauchen, damit sie beim Scrollen nicht verschwinden - etc. …

Wirklich hartnäckig und viel schwieriger zu umgehen sind hingegen einige Netscape-Bugs:

• Eingabefelder, die aus einem Element via “position: relative” herausgeschoben worden sind, kann man manchmal schlichtweg nicht benutzen. Auch wenn sie nicht durch irgendwelche z-index-Werte “unter” andere Bereiche gerutscht sind.
• Manchmal vergisst der Netscape die gute Sitte, “position: absolute”-Anweisungen relativ zum letzten “positionierten” Element aus zu rechnen. Der vergisst teilweise sogar alle umschließenden Positions-Anweisungen - In Listen mit “Product-Teasern” kann’s z.B. gut passieren, dass alle “Preisschilder” plötzlich ganz oben links im Bildschirmfenster kleben.
• Urplötzlich auftauchende Pinkfarbene Bereiche bei transparenten Gif-Hintergründen
• Unpraktisch, dass Netscape nach label-Tags immer “umbricht” - display: inline ist ihm völlig egal.
• Netscape6 erkennt Klassennamen mit Unterstrichen nicht - Ärgerlich, denn in vielen CMS sind wirklich viele Klassen so benannt …

To be continued … Es gibt noch unzählige andere Fehler, die einen oft zu dem zwingen, weswegen eigentlich der Internet-Explorer “verschrien” ist: Quellcode umschreiben oder lauter Hilfs-Divs einbauen.

Aber auch mit dem Opera kann man “sehr viel Zeit verbringen” …

“Vorgeschichte:” Die Mehrfach-Suche

Für ein xt:Commerce-Projekt war ein “Mehrfach-Suchformular” mit “filternder” Funktion umzusetzen …

1. Aus Platzgründen steht die Beschriftung innerhalb der Suchfelder - Sobald man eines anklickt, verschwindet der Text und man kann seinen Suchbegriff eintragen (JavaScript-Lösung)
2. Alle Felder befinden sich innerhalb eines Formulars - Daher muss (bevor die Suche ausgeführt wird) dafür gesorgt werden, dass der Beschriftungs-Text nicht für einen Suchbegriff gehalten wird.
3. Wenn eine Suche ausgeführt worden ist, bleibt der gewählte Suchbegriff im Formular erhalten, so dass angezeigte Produkt-Liste immer weiter “verfeinert” / “verkleinert” werden kann.
4. Der Übersichtlichkeit halber werden alle eigenen Eingaben rot markiert, damit sie sich besser von den vorgegebenen Beschriftungen abheben

Der ScreenShot sollte zeigen, wie das Formular arbeitet:

Screenshot - Erweitertes Suchformular für xt:Commerce
Eingabefelder arbeiten untereinander mit “Und-Verknüpfung”:
Je mehr Angaben, desto kürzer die Trefferliste.

Alles in allem also eine etwas komplizierte Geschichte, da lauter redirect-Anweisungen bei unterschiedlichen Bedingungen unterschiedlich reagieren müssen, wobei manche $_GET-Parameter mal übergeben und mal nicht übergeben werden dürfen. Wer schon einmal Ähnliches mit xt:Commerce umgesetzt hat, wird das ganze Hin- und Her mit den redirects sicherlich kennen.

Besonders “hilfreich” war dabei wieder mal das komplette Fehlen jeglicher Dokumentation der Funktionen xtc_redirect(); oder xtc_get_all_get_params(); und xtc_parse_search_string();und wie sie alle heißen … Fröhliches “Trial-and-Error”, bis schließlich doch endlich alles klappt.

Warenkorb kaputt?

Eigentlich hatte ich gedacht, ich sei fertig, denn die Suche hat funktioniert wie gewünscht: Fehlermeldungen gab’s keine mehr, Endlos-Schleifen ebenfalls nicht - Auch leer abgeschickte Suchformulare haben (anders als normal) keine Suche mehr ausgelöst - “Prima, also nur noch Browser-Check und Ende” - Das dachte ich jedenfalls …

… bis mein alter “Opa-Opera” an der Reihe war. Und mit dem sind gar merkwürdige Dinge passiert. Beziehungsweise gar normale Dinge sind nicht passiert. Nichts ist passiert.

Normalerweise kann man ja in der “shopping_cart.php” Produkte aus seiner Bestellung löschen, einzelne Bestellmengen ändern etc. - und eben das konnte man mit dem Opera plötzlich nicht mehr. Die Seite hat sich jedes Mal aufgehängt - die übliche “Endlos-Schleife” mit Sanduhr-Bildchen.

Verzweiflung?

Natürlich sucht man dann zuerst den Fehler bei den neu hinzugekommenen Funktionen. Erste “Sofort-Erfolge” haben mich zusätzlich auf völlig falsche Spuren geschickt …So kann man wirklich lange suchen. Und Versuchen. Im Endeffekt habe ich die Mehrfachsuche quasi zweimal geschrieben.

Überraschungs-Erfolg: Dass letztlich bloß eine (mir bislang total unbekannte) Art von CSS-Bug “schuld” war - Darauf wäre ich ohne “Freund Zufall” nie und nimmer gekommen. Eigentlich war es ja ein Versehen, dass ich ein paar Zeilen mit “CSS-styling” gelöscht hatte. Das Layout sah deshalb nach dem üblichen “F5″ auch komplett verschoben aus - Aber siehe da - Die Warenkorb-Aktion, die vorhin noch in einer Endlosschleife “festhing”, war ausgeführt.

Freudiges Erstaunen. Und: Ja, auch alle anderen Funktionen wollten wieder.

Des Rätsels Lösung

Um beim nächsten Mal nicht wieder auf solche versehentlichen Erfolge warten zu müssen, hab ich ein bisschen weiter herum experimentiert. Man will ja schon wissen, woran genau es gelegen hat.

Die Ursache scheint in den class-Hinweisen zu liegen: Auch wenn der Quellcode sonst korrekt ist - Sobald ein Element aus einem Formular dieselbe CSS-Klasse wie irgendein anderes Element aus einem anderen Formular hat, werden beim Abschicken die Eingaben beider Formulare “zusammengezogen”.

So in etwa sah der HTML-Quelltext im Shop aus - Und der hat dem Opera 8 ernste Schwierigkeiten bereitet:

<form class="clearfix" id="MultiSearch" action="http://testshop.de/multi_search_result.php" method="get">
<p class="Search">
<input class="TextFeld" type="text" name="keywords" size="24" maxlength="30" value="..." />
...... gekürzt .....
<input class="TextFeld" type="text" name="label" size="24" maxlength="30" value="..." />
<input class="Abschicken" type="image" src="http://testshop.de/.../images/Button_MultiSearch.gif" alt="Abschicken" />
</p>
<p class="Details"><a href="http://testshop.de/advanced_search.php">Detailsuche</a></p>
</form>

...... gekürzt .....

<form id="cart_quantity" action="http://testshop.de/shopping_cart.php?action=update_product" method="post">

<table id="ShoppingCart">
<tr>
<th>Abbildung</th><th>Anzahl</th><th>Artikel</th>
<th>Einzelpreis</th><th>Summe</th><th>Entfernen</th>
</tr>
<tr>
<td><img src="...Bild" alt="Artikelname" /></td>
<td><input type="text" name="cart_quantity[]" value="11" size="2" />
<input type="hidden" name="products_id[]" value="546012" />
<input type="hidden" name="old_qty[]" value="11" /></td>
<td><strong><a href="...Link">Artikelname</a></strong> <br />Lieferzeit: 3-4 Tage</td>
<td> 3,50 EUR</td><td> 38,50 EUR</td>
<td><input type="checkbox" name="cart_delete[]" value="546012" /></td>
</tr>

</table>

<p class="ButtonSet clearfix">
<input type="image" src=".....button_update_cart.gif" alt="Warenkorb aktualisieren" title=" Warenkorb aktualisieren " />
<a href="http://testshop.de/checkout_shipping.php"><img src=".....button_checkout.gif" alt="Kasse" title="Kasse"  /></a></p>

</form>
	

Hier noch einmal die “relevanten Stellen”

<form class="clearfix" id="MultiSearch" action="http://testshop.de/multi_search_result.php" method="get">
...... gekürzt .....
</form>

...... gekürzt .....

<form id="cart_quantity" action="http://testshop.de/shopping_cart.php?action=update_product" method="post">
...... gekürzt .....
<p class="ButtonSet clearfix">
<input type="image" src=".....button_update_cart.gif" alt="Warenkorb aktualisieren" title=" Warenkorb aktualisieren " />
...... gekürzt .....</p>

</form>
	

Was daran falsch ist? Eigentlich nichts. Nur die Klasse “clearfix” - die einmal für das Suchformular gilt und zusätzlich noch einmal für die Zeile “ButtonSet” festgelegt ist - Die wird vom Opera vermutlich ähnlich wie “name” interpretiert. Sogar, wenn sie nur indirekt auf Formular-Elemente wirkt.

Bei solchen Konstruktionen macht der Opera 8* aus zwei Formularen gewissermaßen eines - Aha. Gut zu wissen. Plötzlich war jedenfalls klar, wieso sich der Shop dauernd in irgendwelchen unerwarteten Fehlern verrannt hat.

Lösung: Einfach dafür sorgen, dass kein Klassenbezeichner in mehreren Formularen gleichzeitig benutzt wird.

Nur darauf muss man erst einmal kommen …

Fazit

Daher also mein Tipp: Sollten bei Ihnen auch irgendwann einmal überraschend irgendwelche Fehlfunktionen bei Formular-Eingaben auftreten - Nicht in den PHP-Funktionen herumsuchen - Lieber erst einmal alle CSS-Bezeichnungen aus den Formularen entfernen.

Vermutlich reicht das schon …

*System: Opera 8.02 “Build 7680″, “Plattform Win32″ auf Windows 2000 Professional