CONTENIDO Forum

Hi, das hier gehört zu dem Thread unter "Bugs":
http://forum.contenido.org/viewtopic.php?t=22990

Zu der vorgeschlagenen Lösung von Timo Trautmann folgende Fragen:
1. Meinst du "am Anfang der Datei" oder "... der Funktion"?
2. wenn $db_str2 innerhalb der Funktion strNextDeeperAll() instanziiert wird, wozu wird's dann global deklariert?
3. wenn's hingegen global instanziiert wird, sehe ich nicht den Unterschied zur Ausgangssituation - was passiert im nicht implementierten else{} der Lösung, d.h. bei nicht bekannter Klassendef. von DB_Contenido, die ja wahrscheinl. auch Ursache des ursprüngl. Fehlers ist? - Außerhalb von Funktionen ist auch die global-Dekl. überflüssig.
4. Falls ein gesicherter Fix für diesen Fehler existiert, wär's evtl. möglich, den in nachvollziehbarer Form zu publizieren - evtl. sogar das korrigierte File zum Download anzubieten?

Eine Anmerkung: Ich bin _wirklich_ erschüttert, dass so ein GAU den Weg in eine Release findet. Das ist ja kein neues experimentelles Feature, sondern eine absolute Kernfunktion, die schon lange zuverlässig funktioniert hat. Auch bei OSS sollten doch solche Features _immer_ soweit getestet sein, dass nicht ein Klick eine ganze Site in den Orkus reisst.
Mir sind daduch mehrere Tage Arbeit verlorengegangen, verursacht durch den simplen Versuch, eine Kategorie eine Pos. zu verschieben. Wär die Site bereits produktiv gewesen - bye bye contenido forever, trotz vieler überzeugender Konzepte und Features.
Mir persönlich liegt nicht nur nix an neuen SubSubReleases alle paar Wochen - ich finde das kontraproduktiv und ärgerlich. Mir wäre eine solide Software wichtiger, die nach klassischen Prinzipien und Zyklen entwickelt und getestet wurde:
Entwicklung -> FEATURE FREEZE! -> (interne) Alpha-Testphase -> Bugfixing -> Beta-Testphase -> Bugfixing -> Release

thorn hat geschrieben:Mir persönlich liegt nicht nur nix an neuen SubSubReleases alle paar Wochen - ich finde das kontraproduktiv und ärgerlich. Mir wäre eine solide Software wichtiger, die nach klassischen Prinzipien und Zyklen entwickelt und getestet wurde:
Entwicklung -> FEATURE FREEZE! -> (interne) Alpha-Testphase -> Bugfixing -> Beta-Testphase -> Bugfixing -> Release

Da kann ich nur zustimmen

Gruß aus Franken

Ortwin

Der Bug ist in der 4.8.10 behoben, so wie andere Bugs der 4.8.9.
Da es in der Version viele Umbaumaßnahmen gab, sind trotz intensiver Tests einige Dinge unentdeckt geblieben.
Das hier beschriebene Problem war ein Caching Bug. Das heißt, dass der Baum nicht mehr aufgebaut wurde, es jedoch keinerlei Schaden an den eigentlichen zentralen Daten der Kategorien gab.
Wie gesagt es empfiehlt sich generell ein Update auf die Version 4.8.10

Lieber Timo, liebes 4fb Team,

ich möchte definitiv keinem ans Bein pinkeln wg. Bugs in der Software - bin selbst Entwickler und weiß, wie schnell das zustande kommt: in diesem Fall wurde wahrscheinl. eine Änderung nur unter den Bedingungen getestet, bei denen der Fehler ursprüngl. auftrat, nicht jedoch in allen Anwendungsfällen, bei denen die Funktion strNextDeeperAll() verwendet wird.
Ich bin im Gegenteil einigermaßen begeisterter Contenido-Anwender, speziell wg. Insite Editing und des Modul-/Template-Konzepts und der damit verbundenen Freiheit für Webdesigner und Entwickler.
Es gibt aber auch Dinge, die mich verzweifeln lassen, und dieser Fehler ist die Krönung dessen. Zu den angezeigten Vorsichtsmaßnahmen z.B. bei einem Update zählt m.W. nicht die Anweisung "Bitte prüfen Sie JEDE Funktion des Systems auf Herz&Nieren vor produktiver Nutzung". Die angezeigten Standardmaßnahmen - Backup DB + Webspace - hätten in diesem Fall nicht verhindert, dass einer meiner Kunden 3 Wochen später mal auf die Idee kommt, eine Kat zu verschieben - und schwupps ist die Site quasi weg, ohne Möglichkeit eines Rollback.
Wenn Testspezifikation bzw. Testprotokoll für euch keine Fremdworte sind, sollte dort auch ein Task "Kategorie verschieben" auftauchen - um den Fehler dann zu bemerken, ist keine besondere Intensität der Tests notwendig, es reicht ein Klick. Ohne Spezifikation+Protokoll hingegen sind Tests nur erratisches Herumgeklicke, dass auch durch mehr Intensität nicht an Zuverlässigkeit gewinnt. Und die seeehr selektive Wahrnehmung von Entwicklertests wird mit dem fehlgeschlagenen Hotfixes schön demonstriert.
Bis zur Version 4.4.x hattet ihr den Releases noch das Label "stable" (oder eben nicht) angeheftet. Ich würde sehr begrüßen, wenn diese gute Sitte wieder aufgenommen wird, um dem Anwender zu signalisieren, ob die Version für den produktiven Einsatz oder als Feld-Betatest gedacht ist. Die 4.8.9 war offensichtlich letzteres, und ich bin einigermaßen verärgert, so viel Zeit darin investiert zu haben.

Viele Grüße, verbunden mit dem festen Glauben an stetige Verbesserung ...