Ok, das ist doch schon mal ein viel versprechender Statusbericht - dann wollen wir mal ein bisschen Starthilfe geben ;-)
In solchen Fällen (irgendwelche (Formular-)Daten "kommen nicht an") bietet es sich immer an, mal zu schauen, wie die Übermittelten Daten ankommen, um die Ursache des "Nicht-Funktionierens ausfindig machen zu können (Habe ich mir nach peinlichen Fehlbenennungen von HTML-Fehlern u.Ä. als erste Debugging Maßnahme angewöhnt):
Die wichtigsten Hilfsmittel hier sind die Funktionen
var_dump() und
print_r(). Die Funkionen selbst kennen die meisten, da sie die angenehme Eigenschaft haben, auch Arrays und Objekte ganz aus zu geben. Um die mit LotgD vernünftig nutzbar zu machen, kann man als zweiten Parameter "true" angeben, dann wird das Ergebnis nicht direkt ausgegeben, sondern als String geliefert den man dann - ganz genau - mit
output über das LotgD-System ausgeben kann, ohne gleich probleme mit "headers allready sent"-Meldungen zu bekommen.
Das ganze angewandt: An stellen, die Formulardaten empfangen und verarbeiten einfach folgenden Ausdruck setzen und schauen, was dabei heraus kommt: $this->bbcode_second_pass_code('', 'output(print_r($_POST,true));') Wenig Code, viel Gewinn - wie oben erwähnt fallen hier häufig schon fehlende oder falsch benannte Felder als Folge von Fehlern im HTML auf.
Das dürfte womöglich schon ein ganzes Stück bei deinem ersten Problem (Chat aus Area 1 kommt nicht an) helfen.
Sollte das nicht der Fall sein, sie bietet es sich auch an, einmal auf der anderen Seite nach zu schauen. Dazu lässt man das Script einfach den betreffenden SQL-Query ausgeben. Auch hier fällt nach genauerem Hinsehen oft der Fehler auf - beim Chat könnte beispielsweise die
section falsch angegeben sein, weswegen die Comments im Nirvana zu verschwinden scheinen. An dieser Stelle ist dann auch klar, ob der Fehler beim Schreiben der Comments in die Datenbank oder beim Lesen auftaucht. Somit steht also auch gleich der nächste Ort für die Fehlersuche fest: Wenn die Daten korrekt geschrieben werden, hast du hier nicht mehr zu tun und solltest dir die Ausgabe (also hier: viewcommentary) genauer ansehen. Sollte der Query allerdings Fehler enthalten, so musst du diesen Fehler nun nur noch zu seinem Ursprung zurück verfolgen - zum Beispiel so:
Nun gilt es den Code von unten nach oben, ausgehend vom absenden des Querys durch zu checken. Je nach dem, wie der Query gebaut wird geht das mal schneller und mal langsamer. Wenn du Glück hast, wird der Query erst am Ende aus seinen Einzelteilen zusammengebaut (z.B. per
sprintf()) - hier suchst du dir einfach die Variable mit dem fehlerhaften Teil (beispielsweise so etwas wie $section) heraus und verfolgst sie weiter nach oben, bis zu dem Punkt, so sie verändert oder definiert wird. Spätestens an dieser Stelle sollte der Fehler klar werden. Wie er letztendlich geartet ist, kann man natürlich nicht pauschal sagen (abgesehen von Tippfehlern etc) - aber du weißt nun, wo du ansetzen musst und wie du die Ergebnisse deiner Änderungen nach verfolgen kannst.
Und falls es dir partout nicht einfällt, kannst du immer noch den freundlichen Supportern hier im Forum einen genauen Codeauszug samt Fehlerbeschreibung liefern - was die Geschwindigkeit und Effizienz der Antworten gewaltig erhöhen dürfte ;-)
Eine Anmerkung noch: Wenn du dich jetzt für dumm gehalten fühlst, so sei bitte nicht beleidigt. Ich habe extra sehr simple Techniken gewählt, damit auch andere Einsteiger etwas davon haben und hier (leider) nur (erschreckend) wenige vernünftig nach Fehlern suchen.
Viele Grüße und Gute Nacht,
Auric,
der demnächst womöglich noch ein komplettes Debug-Howto schreibt
Anmelden
FAQ
Suche
Portal
Album
Nu wird gequestet!