CONTENIDO Forum

Fips hat geschrieben:Gibt es dafür schon eine Lösung oder heißt dies ich muss zurück auf die 4.8.12?

Schau mal ein paar Posts weiter oben.

Hast du den Fix von Dodger77 am 17.09.2010 16:16:30 schon ausprobiert?

Fips hat geschrieben:Hallo,
bei mir sieht das genau so aus. Nach dem Update auf die 4.8.13 waren die Kategoriebäume ok.
Ich habe dann einen Baum unter Kategorie verschoben und dann waren die Kategorien durcheinander, aber nur unter den Bereich Kategorien!
In der Baumdarstellung unter Artikel ist es so, wie ich eigentlich haben wollte. Doch im Frontend werden die verschobenen Kategorien nicht angezeigt.

Gibt es dafür schon eine Lösung oder heißt dies ich muss zurück auf die 4.8.12?

Danke Fips

Lies
Beitrag von Dodger77 » 17. Sep 2010, 15:16

Der Fehler tritt bei uns leider reproduzierbar auch nach Einspielen des Patches auf.

Ich habe eine Contenido-Standardinstallation mit AMR, diese wurde von mir vorherige Woche von 4.6.8 auf die 4.8.13 geupdated. Bei einem von 4 Mandanten hat heute der Kunde eine neue Kategorie angelegt, danach ist der komplette Root-Baum unter Content -> Kategorie weg, unter Artikel sieht man ihn noch. Das FrontEnd wird dabei allerdings ebenfalls geschrottet.

Mit dem DB-Dump von gestern Nacht kann ich das ganze leider auch nach Einspielen des Patches reproduzieren.

Ich leite grade eine ungeplante Nachtschicht ein und versuch das zu fixen.

Sollte noch jemand online sein, der die Lösung kennt: Ich wäre ihm sehr dankbar

Nachtrag:

Server Betriebssystem Apache/2.2.16
PHP Datenbankerweiterung mysql
Datenbankserver-Version 5.1.45-log
Installierte PHP-Version 5.2.11
safe_mode Deaktiviert
magic_quotes_gpc Aktiviert
magic_quotes_runtime Deaktiviert
gpc_order
memory_limit 500M
max_execution_time 90
Deaktivierte Funktionen nichts deaktiviert
Gettext Erweiterung geladen
sql.safe_mode Deaktiviert

Code: Alles auswählen

[12-Oct-2010 16:31:20] /deutsch/xxx/ MySQL error 1054: Unknown column 'b.idcat' in 'on clause'

                SELECT count(*) AS anzahl
                FROM con_cat AS a,
                     con_cat AS b,
                     con_cat AS c
                LEFT JOIN con_cat_art AS d ON b.idcat = d.idcat
                LEFT JOIN con_art_lang AS e ON d.idart = e.idart
                WHERE
                    (
                        (
                            c.idcat = b.idcat
                            AND b.idcat = a.idcat
                        )
                    )
                    AND a.idcat = 233
                    AND e.online = 1
                    AND e.redirect = 0
                    AND e.external_redirect = 0
                    AND d.is_start = 0
                
[12-Oct-2010 16:31:20] /deutsch/xxx/ next_record called with no query pending in Module ID 116.
[12-Oct-2010 16:53:09] /deutsch/xxx/ MySQL error 1054: Unknown column 'b.idcat' in 'on clause'

                SELECT count(*) AS anzahl
                FROM con_cat AS a,
                     con_cat AS b,
                     con_cat AS c
                LEFT JOIN con_cat_art AS d ON b.idcat = d.idcat
                LEFT JOIN con_art_lang AS e ON d.idart = e.idart
                WHERE
                    (
                        (
                            c.idcat = b.idcat
                            AND b.idcat = a.idcat
                        )
                    )
                    AND a.idcat = 233
                    AND e.online = 1
                    AND e.redirect = 0
                    AND e.external_redirect = 0
                    AND d.is_start = 0
                
[12-Oct-2010 16:53:09] /deutsch/xxx/ next_record called with no query pending in Module ID 116.
[12-Oct-2010 18:21:04] /deutsch/xxx/xxx/ MySQL error 1054: Unknown column 'b.idcat' in 'on clause'

                SELECT count(*) AS anzahl
                FROM con_cat AS a,
                     con_cat AS b,
                     con_cat AS c
                LEFT JOIN con_cat_art AS d ON b.idcat = d.idcat
                LEFT JOIN con_art_lang AS e ON d.idart = e.idart
                WHERE
                    (
                        (
                            c.idcat = b.idcat
                            AND b.idcat = a.idcat
                        )
                    )
                    AND a.idcat = 233
                    AND e.online = 1
                    AND e.redirect = 0
                    AND e.external_redirect = 0
                    AND d.is_start = 0
                
[12-Oct-2010 18:21:04] /deutsch/xxx/xxx/ next_record called with no query pending in Module ID 116.

Nachtrag 2:

Durch das Anlegen einer (!) neuen Kategorie über das Backend gibt es folgende (relevante) Änderungen im MySQL-Dump zwischen 4.8.13 heil auf geschrottet:

Die folgenden Zeilen werden durch das Anlegen ersatzlos gelöscht:

Code: Alles auswählen

INSERT INTO `con_cat_tree` VALUES (112337,73,0);
INSERT INTO `con_cat_tree` VALUES (112338,75,1);
INSERT INTO `con_cat_tree` VALUES (112339,303,2);
INSERT INTO `con_cat_tree` VALUES (112340,304,2);
INSERT INTO `con_cat_tree` VALUES (112341,302,2);
INSERT INTO `con_cat_tree` VALUES (112342,74,1);
INSERT INTO `con_cat_tree` VALUES (112343,84,2);
INSERT INTO `con_cat_tree` VALUES (112344,284,3);
INSERT INTO `con_cat_tree` VALUES (112345,77,1);
INSERT INTO `con_cat_tree` VALUES (112346,291,2);
INSERT INTO `con_cat_tree` VALUES (112347,292,2);
INSERT INTO `con_cat_tree` VALUES (112348,293,2);
INSERT INTO `con_cat_tree` VALUES (112349,294,2);
INSERT INTO `con_cat_tree` VALUES (112350,377,2);
INSERT INTO `con_cat_tree` VALUES (112351,295,2);
INSERT INTO `con_cat_tree` VALUES (112352,296,2);
INSERT INTO `con_cat_tree` VALUES (112353,297,2);
INSERT INTO `con_cat_tree` VALUES (112354,305,2);
INSERT INTO `con_cat_tree` VALUES (112355,306,2);
INSERT INTO `con_cat_tree` VALUES (112356,307,2);
INSERT INTO `con_cat_tree` VALUES (112357,308,2);
INSERT INTO `con_cat_tree` VALUES (112358,309,2);
INSERT INTO `con_cat_tree` VALUES (112359,310,2);
INSERT INTO `con_cat_tree` VALUES (112360,311,2);
INSERT INTO `con_cat_tree` VALUES (112361,78,1);
INSERT INTO `con_cat_tree` VALUES (112362,82,2);
INSERT INTO `con_cat_tree` VALUES (112363,298,2);
INSERT INTO `con_cat_tree` VALUES (112364,299,2);
INSERT INTO `con_cat_tree` VALUES (112365,300,2);
INSERT INTO `con_cat_tree` VALUES (112366,312,2);
INSERT INTO `con_cat_tree` VALUES (112367,313,2);
INSERT INTO `con_cat_tree` VALUES (112368,314,2);
INSERT INTO `con_cat_tree` VALUES (112369,348,2);
INSERT INTO `con_cat_tree` VALUES (112370,79,1);
INSERT INTO `con_cat_tree` VALUES (112371,346,1);
INSERT INTO `con_cat_tree` VALUES (112372,301,2);
INSERT INTO `con_cat_tree` VALUES (112373,80,1);
INSERT INTO `con_cat_tree` VALUES (112374,315,2);
INSERT INTO `con_cat_tree` VALUES (112375,316,2);
INSERT INTO `con_cat_tree` VALUES (112376,336,2);
INSERT INTO `con_cat_tree` VALUES (112377,340,2);
INSERT INTO `con_cat_tree` VALUES (112378,350,2);
INSERT INTO `con_cat_tree` VALUES (112379,337,2);
INSERT INTO `con_cat_tree` VALUES (112380,380,2);
INSERT INTO `con_cat_tree` VALUES (112381,381,2);
INSERT INTO `con_cat_tree` VALUES (112382,382,2);
INSERT INTO `con_cat_tree` VALUES (112383,338,2);
INSERT INTO `con_cat_tree` VALUES (112384,341,2);
INSERT INTO `con_cat_tree` VALUES (112385,375,2);
INSERT INTO `con_cat_tree` VALUES (112386,358,2);
INSERT INTO `con_cat_tree` VALUES (112387,339,2);
INSERT INTO `con_cat_tree` VALUES (112388,344,2);
INSERT INTO `con_cat_tree` VALUES (112389,359,2);
INSERT INTO `con_cat_tree` VALUES (112390,345,2);
INSERT INTO `con_cat_tree` VALUES (112391,361,2);
INSERT INTO `con_cat_tree` VALUES (112392,362,2);
INSERT INTO `con_cat_tree` VALUES (112393,360,2);
INSERT INTO `con_cat_tree` VALUES (112394,379,2);
INSERT INTO `con_cat_tree` VALUES (112395,383,2);
INSERT INTO `con_cat_tree` VALUES (112396,384,2);
INSERT INTO `con_cat_tree` VALUES (112397,81,1);
INSERT INTO `con_cat_tree` VALUES (112398,85,2);
INSERT INTO `con_cat_tree` VALUES (112399,317,2);
INSERT INTO `con_cat_tree` VALUES (112400,318,2);
INSERT INTO `con_cat_tree` VALUES (112401,319,2);
INSERT INTO `con_cat_tree` VALUES (112402,376,2);
INSERT INTO `con_cat_tree` VALUES (112403,320,2);
INSERT INTO `con_cat_tree` VALUES (112404,321,2);
INSERT INTO `con_cat_tree` VALUES (112405,322,2);
INSERT INTO `con_cat_tree` VALUES (112406,342,2);

INSERT INTO `con_cat_tree` VALUES (112525,290,0);
INSERT INTO `con_cat_tree` VALUES (112526,323,0);
INSERT INTO `con_cat_tree` VALUES (112527,324,0);
INSERT INTO `con_cat_tree` VALUES (112528,333,1);
INSERT INTO `con_cat_tree` VALUES (112529,363,1);
INSERT INTO `con_cat_tree` VALUES (112530,364,2);
INSERT INTO `con_cat_tree` VALUES (112531,365,2);
INSERT INTO `con_cat_tree` VALUES (112532,366,2);
INSERT INTO `con_cat_tree` VALUES (112533,367,2);
INSERT INTO `con_cat_tree` VALUES (112534,368,2);
INSERT INTO `con_cat_tree` VALUES (112535,369,2);
INSERT INTO `con_cat_tree` VALUES (112536,370,2);
INSERT INTO `con_cat_tree` VALUES (112537,371,1);
INSERT INTO `con_cat_tree` VALUES (112538,372,2);
INSERT INTO `con_cat_tree` VALUES (112539,373,1);
INSERT INTO `con_cat_tree` VALUES (112540,334,1);
INSERT INTO `con_cat_tree` VALUES (112541,325,0);
INSERT INTO `con_cat_tree` VALUES (112542,327,0);
INSERT INTO `con_cat_tree` VALUES (112543,351,1);
INSERT INTO `con_cat_tree` VALUES (112544,356,2);
INSERT INTO `con_cat_tree` VALUES (112545,352,2);
INSERT INTO `con_cat_tree` VALUES (112546,353,2);
INSERT INTO `con_cat_tree` VALUES (112547,354,2);
INSERT INTO `con_cat_tree` VALUES (112548,355,2);
INSERT INTO `con_cat_tree` VALUES (112549,328,1);
INSERT INTO `con_cat_tree` VALUES (112550,329,1);
INSERT INTO `con_cat_tree` VALUES (112551,330,1);

Die folgenden Zeilen kommen hinzu:

Code: Alles auswählen

INSERT INTO `con_cat_tree` VALUES (112578,330,1);
INSERT INTO `con_cat_tree` VALUES (112577,329,1);
INSERT INTO `con_cat_tree` VALUES (112576,328,1);
INSERT INTO `con_cat_tree` VALUES (112575,355,2);
INSERT INTO `con_cat_tree` VALUES (112574,354,2);
INSERT INTO `con_cat_tree` VALUES (112573,353,2);
INSERT INTO `con_cat_tree` VALUES (112572,352,2);
INSERT INTO `con_cat_tree` VALUES (112571,356,2);
INSERT INTO `con_cat_tree` VALUES (112570,351,1);
INSERT INTO `con_cat_tree` VALUES (112569,327,0);
INSERT INTO `con_cat_tree` VALUES (112568,325,0);
INSERT INTO `con_cat_tree` VALUES (112567,334,1);
INSERT INTO `con_cat_tree` VALUES (112566,373,1);
INSERT INTO `con_cat_tree` VALUES (112565,372,2);
INSERT INTO `con_cat_tree` VALUES (112564,371,1);
INSERT INTO `con_cat_tree` VALUES (112563,370,2);
INSERT INTO `con_cat_tree` VALUES (112562,369,2);
INSERT INTO `con_cat_tree` VALUES (112561,368,2);
INSERT INTO `con_cat_tree` VALUES (112560,367,2);
INSERT INTO `con_cat_tree` VALUES (112559,366,2);
INSERT INTO `con_cat_tree` VALUES (112558,365,2);
INSERT INTO `con_cat_tree` VALUES (112557,364,2);
INSERT INTO `con_cat_tree` VALUES (112556,363,1);
INSERT INTO `con_cat_tree` VALUES (112555,333,1);
INSERT INTO `con_cat_tree` VALUES (112554,324,0);
INSERT INTO `con_cat_tree` VALUES (112553,323,0);
INSERT INTO `con_cat_tree` VALUES (112552,290,0);

Für meinen Geschmack deutlich zu viel?!

Grüße
Andreas

Das Verhalten mit und ohne Patch ist aber nicht das gleiche, oder?

Interessanterweise werden - soweit ich das sehe - alle Einträge der con_cat_tree unterhalb der Leerzeile in dem ersten Dump genau wiederholt in dem zweiten. Die sind wohl nur entgegengesetzt sortiert. Für die Reihenfolge sollte das aber keinen Unterschied machen. Aber auch die oberen (z.B. idcat 73) gehören zu dem betroffenen Mandanten?

Vielen Dank für den abendlichen Support!

Dodger77 hat geschrieben:Das Verhalten mit und ohne Patch ist aber nicht das gleiche, oder?

Doch. Das ist das mysteriöse. Ich wollte es selbst nicht glauben, habe eben gerade den Patch nochmal neu eingespielt und mit diff verglichen. Er ist definitiv online.
[Nachtrag]: Ich habe die Dumps ohne/mit Patch nicht verglichen. Augenscheinlich im Backend ist jedoch kein Unterschied zu erkennen.[/Nachtrag]

Dodger77 hat geschrieben: Interessanterweise werden - soweit ich das sehe - alle Einträge der con_cat_tree unterhalb der Leerzeile in dem ersten Dump genau wiederholt in dem zweiten. Die sind wohl nur entgegengesetzt sortiert. Für die Reihenfolge sollte das aber keinen Unterschied machen.

Die Leerzeile habe ich bewusst gesetzt. Der 2. Block war in WinMerge als "verändert" markiert, ich habe jedoch keine parallelen zwischen beiden gefunden und dachte daher, er ist hier von einem Ersetzen ausgegangen. Die beiden Blocke waren auch durch einige zig Zeilen getrennt. Sofern das relevant ist, kann ich Dir die Dumps auch (zensiert) vollständig schicken..

Dodger77 hat geschrieben:Aber auch die oberen (z.B. idcat 73) gehören zu dem betroffenen Mandanten?

Muss eg. Ich habe:
- Backup eingespielt
- SQL-Plain-Dump gezogen
- Login
- Kategorie angelegt
- SQL-Plain-Dump gezogen
- Beide Dumps verglichen

Zu diesem Zeitpunkt kann niemand anders im System gearbeitet haben. Die Zeilen müssen also ursächlich durch einen Klick auf Kategorie anlegen in einem Mandant entstanden sein.

Grüße
Andreas

Ich kann da gerne morgen herein sehen, um das nochmal zu überprüfen. Es wäre super, wenn ich dafür einen - gerne anonymisierten - Dump der con_cat und der con_cat_tree bekommen könnte. Am besten wäre natürlich vor dem Auftauchen des Problems und danach.

Dodger77 hat geschrieben:Ich kann da gerne morgen herein sehen, um das nochmal zu überprüfen. Es wäre super, wenn ich dafür einen - gerne anonymisierten - Dump der con_cat und der con_cat_tree bekommen könnte. Am besten wäre natürlich vor dem Auftauchen des Problems und danach.

Herzlichen Dank - schicke ich Dir.

Ich habe jetzt das teilweise empfohlene Downgrade auf 4.8.12 vorgenommen. (nur /contenido/). Dies scheint problemlos zu funktionieren, hierin tritt der Fehler noch nicht auf.
Ich werde hier noch weitere Tests fahren, betrachte das aber gerade mal als meine Exit-Strategie. (Auch wenn es doch einige Einträge im Changelog gibt, die einem die 4.8.13 schmackhaft machen.)

Grüße
Andreas

Noch was: Ich habe überlegt, was diesen Mandanten von anderen Mandanten unterscheidet. Beim Mandant sind derzeit 8 Sprachen hinterlegt, von denen jedoch nur 7 aktiv genutzt werden. Evtl. hilft das.

Die Abfrage, die oben einen Fehler produziert im Log stammt aus einem Modul und kommt nicht von Contenido. Anscheinend ist das Statement an der Stelle nicht korrekt. Wo hier allerdings der Fehler ist kann ich erst mal nicht feststellen.

dominik.ziegler_4fb hat geschrieben:Die Abfrage, die oben einen Fehler produziert im Log stammt aus einem Modul und kommt nicht von Contenido. Anscheinend ist das Statement an der Stelle nicht korrekt. Wo hier allerdings der Fehler ist kann ich erst mal nicht feststellen.

Danke, aber ich denke dann wird die Zeile auch irrelevant sein. Beim Erstellen einer neuen Kategorie sollte imho kein Plugin greifen, schon gar nicht schreibend.
Nachdem der einzige Unterschied zwischen mein Vorher/Nachher-Dump aus dem Anlegen einer einzigen Kategorie besteht, wird man dann diese Meldung ignorieren können.
Diese wurde vermutlich zuvor bei einem davon unabhängigen FE-Aufruf generiert - evtl. sogar während ich die Dumps hin und hergespielt habe und hierdurch die Datenbankstruktur unvollständig war.

Nachdem das Loggin soweit ich weiß nicht in die Datenbank erfolgt, dürften die Datenstände asynchron sein.

Grüße
Andreas

So, zum Anfang nur erstmal soweit ich das aus dem mir vorliegenden DB-Dumps sehen kann:

In der con_cat ist einiges im Argen. Es gibt Kategorien, deren Vorgänger (preid) gar nicht existiert. Es gibt für einen Mandanten keinen Baum (also parentid 0) ohne Vorgänger (preid 0), d.h. es fehlt dort im Prinzip der oberste Baum.

Für den betroffenen Mandanten existieren 2 oberste Bäume (parentid und preid 0). Einer davon hat einen Nachfolger (postid), der nicht existiert.

Die alte Art der Erzeugung der con_cat_tree war für solche Probleme offensichtlich fehlertoleranter, obwohl ich nicht die Hand dafür ins Feuer legen würde, dass es mit einer 4.8.12 oder vorher nicht auch irgendwann "knallen" würde.

Söö, ich bin inzwischen einen großen Schritt weiter, ganz herzlichen Dank auch an dieser Stelle noch einmal an @Dodger77, der mir in den letzten Tagen auch außerhalb des Forums sehr weitergehofen hat.

Damit Ihr davon auch profitieren könnt, versuche ich mal alles zusammenzuschreiben, was ich in dem Rahmen verstanden habe.

Ausgangssituation:
Wir betreiben mehrere Contenido-Installationen, teilweise aus der 4.4er-Generation und älter, die im Laufe der Zeit zumindest 2 Serverwechsel hinter sich gebracht haben, die wir küzlich auf die 4.8.13 gebracht haben.

Problem:
Nach dem Anlegen einer neuen Kategorie war die komplette Kategorieansicht im Backend zerstört, auch im Frontend traten massive Darstellungsfehler auf.

Datenstruktur verstehen:
Zunächst muss man sich über die Datenstruktur im Klaren sein:

Con_Cat: Dies ist die primäre Tabelle in der alle Kategorien verwaltet werden

Aufbau: Pro Mandant haben alle Kateogoriebäume eine feste Reihenfolge. Bei nur einem Sprachbaum ist das offensichtlich - die Reihenfolge kann durch die Pfeile verändert werden. Besitzt ein Mandant jedoch mehrere unabhängige/unsynchronisierte Sprachbäume, so besteht diese Reihenfolge weiterhin und muss (in der DB) gewarht bleiben - auch wenn Sie im Backend nicht mehr sichtbar/offensichtlich ist.
ParentID: Die ID des hirachisch übergeordneten Ordnerns, bei Root-Bäumen die 0
PreID: Die ID des Vorgänger-Ordners. Beim ersten Baum pro Mandant die 0. Sollte es in einer anderen Sprache einen vorstehenden Kategorie-Baum geben, so ist dessen ID einzutragen.
PastID: Die ID des Nachfolge-Ordners. Beim letzten Baum pro Mandant die 0. Sollte es in einer anderen Sprache einen nachfolgenden Kategorie-Baum geben, so ist dessen ID einzutragen.

Alle 3 IDs können offensichtlich im Fehlerfall händisch angefasst werden. Arbeitet man hierbei einigermaßen vorsichtig/weiß was man tut scheint man dabei kein größeres Chaos anzurichten.

Con_Cat_Tree: Sekundäre Tabelle, die die con_cat abbildet, genau genommen nur cached um schnellere/leichtere SQL-Abfragen zu ermöglichen und zu alten Plugins kompatibel zu bleiben

Aufbau: Der Aufbau ist zu vernächlässigen, Tabelle wird beim Anlegen eines neuen Root-Baumes pro Mandant komplett neu generiert. (=Neue Root-Kategorie anlegen ist damit zugleich der Trick um die Tabelle neu zu schreiben, falls es beim Generierungsprozess Probleme gab, welche durch das händische Eingreifen in die SQL-Struktur behoben wurden)

Lösung:
Beim Anlegen einer neuen Kategorie wird nicht die con_cat zerstört - lediglich die Neugenerierung der con_cat_tree schlägt fehl, da diese sensibler ist als bei <=4.8.12. In diesem Fall beim betroffenen Kategoriebaum prüfen, ob die oben definierte Struktur gewahrt ist. Falls nicht ist diese händisch zu korrigieren. An sich selbstverständlich, dennoch der Hinweis: Bevor man in die Datenbank hinfasst, UNBEDINGT ein Backup machen. Es empfiehlt sich auch bei Problemen das Backend über den "Wartungsmodus" für Kunden/Redakteure zu sperren.

Hoffe ich kann damit dem ein oder anderen weiterhelfen. Soweit die Theorie die meine ersten Tests bestätigen, ich melde mich hier, wenn ich das Problem so lösen konnte.

Viele Grüße
Andreas

CONTENIDO Forum

[CON-348] Fehler in der Baumstruktur nach Update auf 4.8.13

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8

Re: [CON-348] Fehler in der Baumstruktur nach Update auf 4.8