Phantomkategorien unter Content -> Artikel

[lunsen_de]

Hallo, bei mir tritt ebenfalls das Problem mit dem Verschwinden der Kategorien auf, allerdings unter völlig anderen Vorraussetzungen, und zwar beim Update.

Wir haben sehr viele Contenido Installationen laufen, und zwar auf einigen verschiedenen Servern. Wir haben die Probleme noch nie bei einem System gehabt, bei dem 4.8 die Basis ist (d.h. Erstinstallation mit 4.8 und dann nur Updates auf 4.8.12 usw.). Bei diesen Systemen ist bei uns Alles in Ordnung.

Das Problem tritt auf bei einem System welches von z.B. 4.6.24 auf 4.8.12 geupdated wurde, allerdings noch mit einer kleinen Änderung.

Nach dem Update und dem Einloggen ins Backend waren unter Content -> Artikel komische Kategorien zu sehen. Sie hatten keine Namen und hatten das Icon einer zu synchronisierenden Kategorie. Klickte man dann einmal auf Content -> Kategorie und dann wieder auf Artikel waren diese verschwunden, tauchten also nur beim Login und dem Ersten ansehen von Content -> Artikel auf.
Weil mir das nicht gefiel habe ich die Datenbank durchstöbert und alle Einträge für die idcats 11, 24 und 25 gelöscht (waren übrigens bei allen Updates von 4.6 auf 4.8 da und immer mit diesen idcats 11,24,25).

Da ich vor einem Update immer eine Testinstall mache, hatte ich immer 2 Systeme zum vergleichen und konnte nunden Unterschied finden, der meine Kategorien beim Anlegen einer Neuen Kategorie zum Teil verschwinden läßt.

Lasse ich die Datenbank unberührt und die Einträge mit den 11, 24, 25 drinne kann ich Kategorien anlegen und verschieben ohne das etwas verloren geht. Schmeiße ich die Sachen aus der Datenbank raus, wird beim ersten arbeiten in Content -> Kategorie (also z.B. neune Baum anlegen) die Tabelle con_cat_tree zerstört und im Backend fehlen die meisten.

Da ich schon alles was im Forum zu diesem Problem zu finden war probiert habe (tab löschen, neu anlegen, neu generieren, nochmaliges Update usw.) und nichts half, komme ich hier nicht weiter. Ich habe irgendwo gelesen, dass idcat, preid und parentid zusammenhängen. kann es sein dass da das Problem entsteht wenn man Einträge löscht und damit irgendwelche Verknüpfungen nicht mehr passen?

Was kann man tun, um die 3 Kategorieeinträge wegzubekommen und trotzdem nicht das Problem mit den verschwindenden Kategorien zu haben.

Gruß lunsen_de

PS: anbei ein Screenshot zum Verständnis und zur Glaubwürdigkeit (hört sich ja schon etwas seltsam an). Habe das Ganze jetzt schon bei Systemupdates getestet und festgestellt.

problem.jpg (25.01 KiB) 6878 mal betrachtet

Einen Nachtag kann ich noch machen: wenn ich in die Datenbank (aus der ich die 3 Einträge gelöscht habe) die 3 Einträge in die con_cat wieder einfüge, danach die con_cat_tree lösche und im Backend unter Kategorie (wo dann nichts mehr zu sehen ist) einen neuen Baum erstelle, sind die Kategorien wieder da. Allerdings sind die 3 Kategorien unter Content -> Artikel mit den blauen Icon (wie im Screenshot) wieder da, also auch keine Endlösung.

[Oldperl]

Hallo lunsen_de,

das händische Löschen in der DB kann nicht funktionieren, da es Querverweise gibt, die dabei nicht "korrigiert" werden.
Deine Kategorien werden zur Synchronisation angezeigt, da sie anscheinend in einer anderen Sprache erstellt wurden. Evtl. mal in die con_cat_lang schauen, ob dort den besagten Kategorien eine aktive Sprache (idlang) zugeordnet ist. Hier sollte auch ein Vergleich mit korrekt angezeigten Kategorien hilfreich sein.

Ich denke das da Überbleibsel aus der alten 4.6er Installation vorhanden sind, die diese Probleme bedingen. Das es sich hier um ein ähnliches Problem wie in diesem Thread beschrieben handelt denke ich dagegen weniger.

Was hier aber zu prüfen wäre, wie verhält sich Contenido beim Löschen einer Sprache, bzw. wie geht Contenido dabei mit vorhandenen Kategorien um. Löschen der Sprachen ist denke ich immer möglich, nur was bleibt dabei an "Restmüll" oder wird dabei Alles die Sprache Betreffende mit gelöscht.

Gruß aus Franken

Ortwin

[lunsen_de]

Hallo, das hilft nicht wirklich weiter. in der con_cat_lang sind keine Einträge für die zweite Sprache mit den besagten idcats. Auch werden die Icons in der zweiten Sprache nicht alle angezeigt, sondern nur eine.
Also wie könnte man die Einträge beseitigen oder bestimmte Einträge/Querverweise in der Datenbank anpassen, damit die Icons verschwinden?

Gruß lunsen_de

[Oldperl]

Hallo lunsen_de,

wieso hilft das nicht weiter?
Schau halt nach für welche Sprachen die Einträge vorhanden sind und ob die Sprachen auch im System vorhanden sind. Wenn nicht könnte man einfach eine vorhanden Sprache zuweisen.

Und sorry das ich dein Problem nicht gleich auf Anhieb lösen kann. Sowas bedingt eine eigene Fehlersuche am defekten System.

Gruß aus Franken

Ortwin

[Dodger77]

Ich habe das mal abgetrennt und als gesondertes Thema neu angelegt, denn:

• Das Problem sind die (ich nenne diese mal in Ermangelung eines besseren Begriffs) Phantomkategorien.
• Das Verschwinden von Kategorien bzw. nicht Erscheinen von neu angelegten liegt mit hoher Wahrscheinlichkeit am manuellen Löschen von Kategorien in der Datenbank.

[lunsen_de]

Beitrag wiedergefunden!

Hallo, ich habe nicht verlangt, dass das Problem sogleich gelöst ist, nach einem Beitrag. Ich durchsuche die Datenbank jetzt schon den ganzen Tag und versuche alles genauestens zu beschreiben und hoffe auf Hilfe oder Ansätze, wo kann man suchen, was kann man tun. Ich habe auch nur vermutet, dass es zu diesem Bug passen könnte, die Überschrift passt ja halbwegs. Ich habe natürlich weitergesucht, auch unter den letzten Anmerkungen von Dir.

Ich habe, wie eben geschrieben. In den Sprachen gesucht, besser gesagt das System hat 2 Sprachen und ich suche in 4 Tabellen: con_cat, con_cat_art, con_cat_lang und con_cat_tree
- in der con_cat gibt es die Idcat der 3 Kategorien (aber keine Spalte lang oä.)
- in der con_cat_art gibt es auch die 3 Einträge (also ich denke 3 Artikel, die mal gelöscht oä wurden und im Backend nicht mehr sichtbar sind, aber auch hier keine spalte mit lang etc.)
- in der con_cat_lang gibt es die Einträge nicht (aber hier eine spalte lang, aber für keine lang sind die 3 idcat dabei)
- in con_cat_tree sind die Einträge wieder da, aber nur mit den Spalten idtree und level.

Vielleicht kannst du mir nocheinmal erklären, wei ich dann eine Sprache zuweisen kann. Kann man in der con_cat_lang einfach 3 Einträge machen und die Kategorien oder Artikel sind im Backend normal sichtbar um Sie dann zu löschen? Und wenn ja, was schreibe ich in die anderen Spalten wie idtplcfg usw. Vielleicht einfach einen anderen Eintrag kopieren, aber dann fehlt mir sicher wieder idcatlang (oder findet man die in einer anderen tabelle)?

Viele Frage und ich hoffe weiter auf Hilfe.

Gruß lunsen_de

[Dodger77]

Ich würde empfehlen, erst mal gar nichts in der Datenbank zu löschen.

- in der con_cat_lang gibt es die Einträge nicht (aber hier eine spalte lang, aber für keine lang sind die 3 idcat dabei)

Das sieht doch interessant aus.

Man könnte für die 3 Kategorien neue Einträge in der con_cat_lang machen für eine Sprache. Die Primärschlüssel idcatlang müssen dann jeweils 1 größer sein als der aktuell größte Wert. Danach sollte man in der con_sequence für den seq_name "con_cat_lang" den Wert entsprechend erhöhen (aktuell größter Wert der idcatlang + 1).

Wenn das passiert ist, sollte es es möglich sein, die Kategorien über das Backend zu löschen.

[lunsen_de]

Wahnsinn, das wars. Habe die 3 Einträge in der con_cat_lang gemacht, Werte wie angegeben erhöht, den Wert in der con_sequence erhöht und Sie waren mit den Namen, die ich bei den einträger vergebn habe im Backend unter Content -> Artikel sichtbar (als normale ungefüllt Kategorien).

Danach habe ich Sie unter Kategorie löschen koennen (hier waren Sie ja vorher nicht zu sehen) und danach funktionierte auch das Anlegen/verschieben etc. von Kategorien wieder ganz normal, ohne Verluste.

Vielen Dank an Euch. Mit den Tipps und Tests war es doch wirlich schnell gelöst.

Gruß lunsen_De

[Oldperl]

Verschoben nach Misc, kein Bug.

Freut mich das du es Lösen konntest.
Da hat Dodger das wohl etwas besser erklärt wie ich meinen ähnlichen Ansatz.

Ich denke aber es handelt sich hierbei nicht um einen Bug, sondern eher, wie auch Dodger meinte, an Überbleibsel einer händischen DB-Pflege. Daher verschieb ich das nach Misc.

Gruß aus Franken

Ortwin

[Dodger77]

Das freut mich, dass es so funktioniert hat.

Ich habe das Verhalten in der Vergangenheit auch mal bei einem Mehrsprachen-Mehrmandantensystem gehabt. Vielleicht finde ich den entsprechenden Datenbankdump noch. Dann sehe ich mir das mal an.

[kummer]

:Ich denke aber es handelt sich hierbei nicht um einen Bug, sondern eher, wie auch Dodger meinte, an Überbleibsel einer händischen DB-Pflege.

Was auch immer die Ursache ist, dürfte das nicht auftreten können. Insofern mag es vielleicht kein Bug sein, dann wäre es allerdings ein Design-Fehler. Wären Constraints definiert, wäre es nämlich auch von 'Hand' nicht möglich, für die idlang einen Wert zu setzen, den es als Sprache nicht gibt. Und unbemerkt dürfte es sowieso nie bleiben. Solche Phantonkategorien gibt es je und je wieder mal; ich höre davon nicht das erste mal. Und es ist nicht anzunehmen, dass die Leute immer wieder in der DB direkt herumfummeln. Wozu auch? Es sei denn, um einen Fehler zu korrigieren, der sich nur so lösen lässt. Während Contenido insgesamt ziemlich stabil ist in Bezug auf die Datenhaltung (was angesichts des ERDs einigermassen erstaunt), trifft das für den Kategorienbereich insbesondere bei Mehrmandanten- und Mehrsprachensystemen nicht zu. Hier treten immer wieder Probleme auf, das das zugrunde liegende Modell nicht wirklich taugt.

[Oldperl]

Was auch immer die Ursache ist, dürfte das nicht auftreten können.

Ölkatastrophen im Golf von Mexiko oder Waldbrände mit radioaktiven Wolken in Rußland dürften auch nicht auftreten können.

ich höre davon nicht das erste mal.

Nur hören oder auch Sehen. Und wenn Sehen dann vielleicht auch schon mal den Grund herauszubekommen versucht?

...das das zugrunde liegende Modell nicht wirklich taugt.

Hmm ja, das ist dann natürlich einfach. Das System taugt nix, daher funktioniert es nicht.

Sorry, aber das hilft nicht wirklich weiter, eine Fehlerdiagnose/-analyse wäre hier viel hilfreicher. Aber dazu brauch es Zeit, Mühe und Arbeit.
Und sollte es sich dann wirklich um einen Bug handeln, was ich nicht ausgeschlossen habe, verschiebe ich den Post gerne wieder nach Bugs.

Gruß aus Franken

Ortwin

[kummer]

Ölkatastrophen im Golf von Mexiko oder Waldbrände mit radioaktiven Wolken in Rußland dürften auch nicht auftreten können.

Offenbar liest man auch die Zeitung und nicht nur das Forum. Gratulation. Man kann die hier aufgetretenen Problem tatsächlich ganz vermeiden. Allegorien in Eheren, Ortwin, aber man muss auch Unterschiede erkennen können.

Nur hören oder auch Sehen. Und wenn Sehen dann vielleicht auch schon mal den Grund herauszubekommen versucht?

Tja, den Grund habe ich ja angesprochen. Es fehlen Constraints. Sobald die drin sind, wird das nicht mehr geschehen. Ganz einfach. Dafür wird dann immer, wenn sowas passiert wäre, ein Fehler bis zum Browser geworfen. Aber das würde ja dann die Frage nach der Fehlerbehandlung aufwerfen. Aber wie ich schon mehrfach vernommen habe, hat das ja 4fb im Griff... Dann folgt als nächster Schritt die Bündelung zu einer Transaktion, damit im Fehlerfall ein Rollback vorgenommen werden kann.

Übrigens hören und sehen. Immer, wenn ich die Umstellung auf Nested Sets vornehme, werden solche Kategorien sichtbar. Nicht im Browser, sondern in der DB. Das ist kein Einzelfall, sondern - insbesondere bei Mehrmandanten und Mehrspachensystemen - mehrheitlich so.

Obwohl ich das schon mehr als einmal aufgezeigt habe, hier kurz, was gemacht werden müsste:

1. Die Kombination von idcat und idlang in der con_cat_lang müsste einen Unique-Constraint aufweisen.
2. Die Kombination von idart und idlang in der con_art_lang müsste einen Unique-Constraint aufweisen.
3. Mindestens die Tabellen con_lang, con_art, con_cat, con_cat_lang und con_art_lang müssten auf InnoDB umgestellt werden.
4. Die Keys idlang, idart und idcat müssten die entsprechenden Werte der betroffenen Tabellen referenzieren.

Hmm ja, das ist dann natürlich einfach. Das System taugt nix, daher funktioniert es nicht. Sorry, aber das hilft nicht wirklich weiter, eine Fehlerdiagnose/-analyse wäre hier viel hilfreicher. Aber dazu brauch es Zeit, Mühe und Arbeit. Und sollte es sich dann wirklich um einen Bug handeln, was ich nicht ausgeschlossen habe, verschiebe ich den Post gerne wieder nach Bugs.

Darüber haben wir uns ja schon öfter unterhalten. Das ist eine Fehlerdiagnose. Der Fehler ist, dass Constraints fehlen. Und das die Bündelung zu einer Transaktion eben nicht erfolgt. Wäre das so, dann würde dieser Fall nicht auftreten können. Wenn dann noch die Umstellung auf Nested Sets erfolgen würde, liesse sich nicht nur Verschiebungen einfacher vornehmen, es wäre dann auch mit vier ganz einfachen Prüfung möglich, die Integriät des Datenbestandes schlüssig zu prüfen und bei Bedarf ein Rollback vorzunehmen. Genau das ist im vorliegenden ERD auch bei Anwendung von Constraints nämlich nicht möglich.

Wenn jemand von einem Gerüst stürzt, mag man den Fehler darin suchen, dass die betroffene Person die falschen Schuhe angehabt hat (oder vielleicht sie gleichentags unter einer Leiter durchgegangen ist). Oder darin, dass das Gerüst kein Geländer hat. Ich neige dazu, den zweiten Umstand als Fehler anzusehen. Im vorliegenden Fall sind das vier Dinge: fehlende Constraints, fehlende Referenzierung, fehlende Integritätsregeln und das Fehlen von Transaktionen.

Würde man sich um Beiträge aus der Community (oder was sich denn so nennt) nicht foutieren, dann wäre das Problem seit mehr als zwei Jahren gelöst.

[Oldperl]

Ach Andreas,

ich gebe dir doch nur zu gerne in so manchem Recht. Deswegen mußt du doch nicht immer gleich aus der Hose springen.
Ja man kann vieles anders und sicherlich auch besser machen. Aber ich mache doch nicht gleich aus jedem Auto einen Tourenwagen, nur weil ich andere Reifen aufziehe.
Und um beim Vergleich zu bleiben, Contenido ist nun mal kein aktuelles Automodell, sondern ein schon etwas betagtes, aber in den meisten Bereichen zuverlässiges Modell.
Sonst würde es weder weiterhin genutzt, noch geforkt, noch würden wir hier über seine Macken und Schwächen reden.

Ja es fehlen Transaktionen, sofern man Aktionen nicht in einem DB-Query erledigen kann. Ein altes Problem von MySQL bei MyIsam Tabellen.
Ja der DB-Layer gehört mal Grundüberholt.
Ja es sollten Abhängigkeiten vorhanden sein und geprüft werden.
Nein, das Problem würde sich nicht einfach durch Nested Sets erledigen.

Soweit ich das bisher ergründen konnte kommen diese "Phantomkategorien" evtl. von unsauberen Löschaktionen, z.B. auch im Bereich Sprachen. Das kann an abgebrochenen oder unvollständigen DB-Aktionen liegen, wäre dann mit Transaktionen abzufangen, es kann aber auch an einer unsauberen Umsetzung oder nicht abgefangenen Fehlern oder Ausnahmen liegen.

Klar kann man da gleich Alles neu machen, kostet nur jede Menge Zeit, die offensichtlich keiner wirklich investieren will.

Aber was rede ich eigentlich?
Du bist selbst lang genug dabei und kennst sowohl das System als auch das Drumrum. Warum wir darüber immer wieder reden kann ich einfach nicht verstehen.
Also lass mich einfach mein Bugtracking machen. Alles andere ist, wie du ja richtig sagst, seit langem bekannt und es zu ändern liegt nicht in meiner Hand.
Wende dich damit bitte an die dafür zuständigen Herren, die Kontaktdaten sollten dir ja bekannt sein.

Gruß aus Franken

Ortwin

[kummer]

Das Problem hier ist nicht ganz gleich, wie die übrigen Probleme, die sonst vielleicht bestehen mögen. Bei allen Vor- und Nachteilen, die Contenido aufweist, ist es recht eigentlich solide, was die Datenhaltung angeht. Langsam zwar, wenn das nicht stört eine durchaus gute Wahl. Bloss gilt das eben nicht für die Kategorien. Hier liegt mehr als ein Problemchen. Hier kann ein Schaden entstehen, der massgeblich ist. Während wir ansonsten das ERD bemäkeln, weil es zu Anomalien führen kann oder die Leistung beeinträchtigt, besteht hier schlicht und ergreifend die Gefahr, Daten auf eine Weise zu beschädigen, dass die Wiederherstellung mindestens sehr aufwändig ist. Und damit steht die Kategorieabbildung eben auch für Contenido-Verhältnisse quer in der Landschaft.

Nein, das Problem würde sich nicht einfach durch Nested Sets erledigen.

Hmm, doch. Nested Sets in Kombination mit den ganannten Indizes, InnoDB-Tabellen, referenzieller Integrität und Transaktionen lösen diese Probleme tatsächlich endgültig. Die Indizes verhindern Doppeleinträge, InnoDB plus referenzielle Integrität machen die Löschweitergabe möglich und stellen sicher, dass nicht Sprachen, Kategorien oder Artikel referenziert werden, die es gar nicht gibt. Und die verschachtelten Mengen schliessen das ganze nicht nur dadurch ab, dass die Abfrage enorm viel schneller ist, aber vor allem, weil es vier ganz einfache Regeln gibt, die man am Ende prüfen muss. Sind diese nach einer Aktualisierung gülitg, dann sind die Daten integer. Wenn Min(lft) = 1, max(rgt) = 2 * count(*), unique(lft/rgt) = true und wellformed(lft,rgt) = true, dann ist der Datenbestand integer. Falls nicht, muss bloss ein Rollback vorgenommen werden. Wenn das so gemacht werden würde, dann wäre ein Integritätsverlust der Daten nicht mehr möglich.

Alles andere ist, wie du ja richtig sagst, seit langem bekannt und es zu ändern liegt nicht in meiner Hand. Wende dich damit bitte an die dafür zuständigen Herren, die Kontaktdaten sollten dir ja bekannt sein.

Nun ja, Ortwin, ich sage das hier nicht, weil ich mir eine Integration wünsche. Das war mal und ich habe alles gemacht, was verlangt worden ist. Das ist nun mehr als zwei Jahre her. Inzwischen habe ich ja eine Lösung. Ich äussere mich hier aus zwei Gründen: (a) damit diejenigen, die Sicherheit in Bezug auf die Datenhaltung benötigen, sich der Probleme bewusst sind und ggf. eine andere Wahl treffen können und (b) damit diejenigen, die das nicht wollen oder nicht können, wissen, wo man wie ansetzen muss. Dass es zu einer wie auch immer gearteten Integration kommt, halte ich inzwischen für einigermassen unwahrscheinlich. Immerhin benötigt schon ein Minor-Release mindestens zwei Jahre.

Und falls der Eindruck entstanden sein sollte, ich wollte dich für Nested Sets gewinnen, dann wäre das nicht beabsichtigt. Ich hoffe stets auf eine Leserschaft, die etwas grösser ist. Ich meine jetzt einfach zahlenmässig. Und das sich im einen oder anderen Fall eine interessante Diskussion ergeben könnte. Insbesondere bei professionellen Anwendern dürfte ein Interesse bestehen, hier Abhilfe zu kriegen. Davon gehe ich mindestens aus.