Kategorie verschieben führt zu bösen Fehler

[mattmarr]

Hallo!

Ich hab hier gerade ein sehr übles Problem bei einem Kunden und finde einfach nicht die Lösung.

Wenn ich Contenido(4.9.12 oder 4.8.20) eine Kategorie oder Baum verschiebe ist danach die Seite Kategorie komplett leer.
Schau ich dann in das Log, steht folgendes drin:

Code: Alles auswählen

[02-Jan-2017 10:40:34 Europe/Berlin] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 72 bytes) in /var/www/html/.../contenido/includes/functions.str.php on line 511

Ich hab auch schon das memory_limit deutlich erhöht (z.b. 2000M). Hat alles nichts gebracht.
Im Quelltext konnte ich zumindest die Stelle ausmachen wo der abbruch stattfindet.
Die Datei functions.str.php in der Function recCats().

Ich konnte zwar den Kategoriebaum wiederbeleben aber nach einem erneuten verschieben ist wieder alles schrott.

Code: Alles auswählen

Server Betriebssystem	Apache/2.4.7 (Ubuntu)
PHP Datenbankerweiterung	mysqli
Datenbankserver-Version	5.5.44-0ubuntu0.14.04.1
Installierte PHP-Version	5.5.9-1ubuntu4.11

oder

Code: Alles auswählen

Server Betriebssystem	Apache
PHP Datenbankerweiterung	mysqli
Datenbankserver-Version	5.0.51a
Installierte PHP-Version	5.6.21

Ich bin für jeden noch so kleinen Tip dankbar, damit das auf der Kundenseite nicht mehr passiert.



Gruß
Matthias

[mattmarr]

Ups...sorry, es betrift doch nur 4.8.20.
Bin wohl mit den Contenido durcheinander gekommen.

Wäre trotzdem net für Hilfe auch wenn es hier nur Version 4.9 Themen gibt.

[homtata]

Ich würde darauf tippen, dass die in der Datenbanktabelle con_cat minutiös gespeicherte Abfolge der Kategorien zerschossen ist und beim Verschieben und dem Versuch der Neuordnung das dann endgültig in die Hose geht. Du könntest händisch mal in der Tabelle abgleichen, ob die ganze Anordnung der preid, postid, parentid so überhaupt stimmt. Druck dir mal die Navibäume aus, notiere dir die IDs dazu und dann geh mal die Tabelle durch, ob das alles so stimmen kann. (Backup vor den Änderungen nicht vergessen. Ist der Baum komplett zerschossen, wirds eh schwierig).

[mattmarr]

Hallo!

Ich würde darauf tippen, dass die in der Datenbanktabelle con_cat minutiös gespeicherte Abfolge der Kategorien zerschossen ist und beim Verschieben und dem Versuch der Neuordnung das dann endgültig in die Hose geht. Du könntest händisch mal in der Tabelle abgleichen, ob die ganze Anordnung der preid, postid, parentid so überhaupt stimmt. Druck dir mal die Navibäume aus, notiere dir die IDs dazu und dann geh mal die Tabelle durch, ob das alles so stimmen kann. (Backup vor den Änderungen nicht vergessen. Ist der Baum komplett zerschossen, wirds eh schwierig).

Stimmt, habe schon mehrere gefunden bei z.b. preid eine "0" stehen sollte es aber nicht tut.
Jetzt heist es viel durchschauen. Über 360 Kategorien.


Danke & Gruß

[rethus]

Bin mir nicht sicher ob dir das hilft... und ob es in 4.8.20 schon drin war, aber schau mal unter "Content ⇒ Artikel", dort das Menü zu Artikel-Suche öffnen und auf "Lost and Found" klicken.
Ich hatte den Bereich noch nie verwenden müssen, bin aber mal darüber gestolpert und hab mich gewundert, warum der so extrem versteckt ist. Vielleicht hilft es dir...

Good Luck.

BTW &4fb: Bitte diesen Thread ins 4.8er Forum verschieben

[frederic.schneider_4fb]

@rethus:
Das 4.8er Forum ist zum 31.12.2016 geschlossen worden. Da der Nutzer ursprünglich davon ausging, es ginge auch um 4.9, habe ich den Beitrag offen gelassen. Es wäre jetzt aber unfair, im laufenden Support den Beitrag in einen Bereich zu schieben, wo Ihr das Problem nicht abschließend klären könnt, selbst wenn es jetzt eher um Version 4.8 geht. Grundsätzlich werden 4.8er-Supportanfrage zukünftig aber geschlossen/gelöscht.

[homtata]

@mattmarr: pass aber mit den Werten auf. Es kann schon sein, dass mehrfach "0" stimmt. "preid" heißt nicht zwingend die DIREKT darüberhängende Kategorie, wenn die zu einem anderen Zweig gehört. Vergleich das vielleicht mit einer funktionierenden Installation, um ein Gefühl für die Befüllung der Tabellenspalten zu kriegen. Man hat da schnell die falsche Logik im Kopf...

[Faar]

Vergleich das vielleicht mit einer funktionierenden Installation, um ein Gefühl für die Befüllung der Tabellenspalten zu kriegen. Man hat da schnell die falsche Logik im Kopf...

Meistens ist der Baum in der Artikelanzeige in Content => Artikel noch in Ordnung, bzw. die Reihenfolge stimmt.
Daran kann man sich leiten.
Wenn aber die schon nicht mehr stimmen soll, wirds schwierig.

Aber zu achten ist auch darauf, ob eine Kategorie von Mandant A einen Nachfolger in Mandant B hat und umgekehrt.
Da gab es in 4.8.12 mal ein großes Problem damit, das sich in die DB einnistet und so lange unerkannt wartet, bis plötzlich mal nichts mehr geht.
Der Fehler kann also schon lange vorher entstanden sein.

[mattmarr]

Hallo Faar!

Aber zu achten ist auch darauf, ob eine Kategorie von Mandant A einen Nachfolger in Mandant B hat und umgekehrt.

Da ich mir alle Kategoriepunkte von Mandant auflisten lasse, sollte das doch kein Problem darstellen oder?
Nicht das ich was falsch verstanden habe.

Bin gerade dabei über 300 Menüpunkte in mehreren Sprachen zu kontrollieren. Ganz schön viel Arbeit.



Grüße
Matthias

[mattmarr]

Hi!

Denkfehler von mir oder ein Problem.

die postid und preid müssen am Anfang oder ende 0 sein.
Soweit ist ja alles klar.
Was mach ich aber wenn es mehrsprachig ist und in den oder der anderen Sprache neu Kategorien gibt?
Wie verhält es sich dann mit der postid und preid?

Reicht es wirklich nur die Tabelle _cat zu editieren?

Ich hab hier gerade ein richtig dickes Kundenproblem das ich noch nicht gelöst bekomme.



Gruß
Matthias

[homtata]

Soweit ich weiß, hat die Anordnung in con_cat nix mit der Sprache zu tun, es gibt ja auch keine Spalte dafür. Gedanklich sind die Kategoriebäumen über alle Sprachen hinweg identisch (wird in Sprache 1 ein Ast verschoben, verschiebt er sich auch in Sprache 2). Die Kategorie-IDs sind ja über die Sprachen hinweg identisch. Wird ein Zweig neu angelegt, ist er gedanklich da, wo er in allen Sprachen (wie in der Ursprache) später WÄRE, ob synchronisiert oder nicht. Es wird dann richtig übel für dich zum Checken, falls haufenweise Kategorien angelegt wurden, die NUR in einer Sprache existieren und nie synchronisiert wurden. Dann wirds irre schwierig, die eigentliche Reihenfolge im System hinzufrickeln.
Ist das soweit verständlich? Bisschen blöde zu beschreiben.

[mattmarr]

Hallo homtata!

Ist das soweit verständlich? Bisschen blöde zu beschreiben.

Gut verständlich.
Ich brauch definitiv eine andere Strategie.


Gruß
Matthias

[homtata]

Am einfachsten ist es wahrscheinlich, die Tabelle zu dumpen und in Excel zu öffnen. Dann sortierst du die Kategorien so, wie sie a) in der ersten Sprache sind und hängst dann die Zweige aus Sprache 2 so zwischendrin, wie sie aktuell nach pre und postid korrekt erscheinen.
Dann hast du einmal den Ablauf korrekt durch, und wenn du den Fehler nicht direkt siehst, dann solltest du ihn beim chronologisch korrekten Durchsehen der Werte aber dann doch finden.
LG
Viktor

[mattmarr]

Hi!

Habe mir vorhin erstmal Fix ein Script das mir den Baum komplett und ausliest. so sieht man die Zuweisung schneller.