mehrfachzuordnung in 4.6.x

[emergence]

da die mehrfachzuordnung ja ein wirklich feines feature war, hab ich mir ein paar gedanken dazu gemacht ob und wie es sich wieder in die aktuelle version integrieren läßt.

es momentan komplett zu deaktivieren, war nach durchsicht des codes eine absolut richtige entscheidung...

es spielen da ein paar intressante aspekte mit rein...
ein paar dinge die ich jetzt einfach nur mal so aufliste ohne näher darauf einzugehen...(sonst vergesse ich die punkte...)

beim verschieben von artikeln in eine andere kategorie wird eine neue idcatart vergeben...

bei der zeitgesteuerten verschiebung wird nur der idcat wert angepasst... der idcatart wert bleibt gleich... (ist nicht konsistent)

so wie das query in der conMoveArticles geschrieben wurde, wurden alle artikel auch wenn sie mehrfach vorhanden waren und dem zu änderten idart wert entsprachen ohne rücksicht auf verluste auf die time_target_cat gesetzt... da kam es dann zu dem fall das ein und der selbe artikel mehrfach in einer kategorie angezeigt wurde...

die zeitsteuerung ist in der con_art_lang definiert... in meinen augen die falsche position... in die con_cat_art könnte man sie verlegen... (dann wäre die verschiebung in allen sprachen ident)
oder man schafft eine eigene tabelle die sich nur um die zeitsteuerung kümmert...

das liebe problem mit den idcatart werten...
meiner meinung nach müsste ein idcatart wenn er einmal vergeben wurde immer mit dem artikel in dieser einen kategorie verknüpft bleiben...
wenn man den artikel nur verschiebt sehe ich an sich kein problem den idcatart wert beizubehalten...
kommt eine mehrfachzuordnung hinzu muss eine neue idcatart vergeben werden...

es gibt da ja das nette feld status in der db tabelle con_cat_art -> das könnte man vielleicht dazu nutzen zu definieren ob die idcatart gültig ist...
ein löschen der idcatart werte sollte somit nie stattfinden... ausser der idart wert wäre wirklich nicht mehr vorhanden...

das schlimme an der ganzen sache: es ist ein wahnsinnsaufwand...
sollte das ganze wieder ein thema werden, sprich man möchte das wieder implementieren, kommt man um eine bereinigung der obrigen punkte fast nicht herum...

falls ich etwas vergessen haben sollte, bitte ich um eine ergänzung...

[trixta]

zwar keine ergänzung zu den gedanken von emergence. wollte nur betonen, dass mir dieses feine feature auch recht wichtig ist. ich glaube zwar dass die priritäten bei euch andere sind, aber würde euch (timo) bitten mal drüber nachzudenken, ob das vielleicht in ne spätere version wieder aufgenommen wird. es gibt halt seiten bei denen braucht man das feature...

[timo]

in irgendeiner Version sicherlich, aber in absehbarer Zeit nicht...denn ohne einen Komplettumbau geht es leider nicht.

[malsdgtac]

Wäre nicht eine Möglichkeit für dieses Problem eine Kopierfunktion einzubauen? Das könnte man ohnehin öfters brauchen.

Ich könnte mir das so vorstellen:
Artikel kopieren, der Artikel wird in der gleichen Kategorie nochmals neu erstellt (mit vollen Inhalt), dann kann man diesen ja in die entsprechende Kategorie verschieben.

Nicht die ideale Variante - aber eine zumindest öfters gute Alternative

[emergence]

ähm du hast dir die 4.6 noch nicht angesehen oder ?
das kopieren von artikeln funktioniert ja...

[trixta]

hi,

habe die kopierfunktion auch nicht gesehen wußte aber, dass es sie gibt. ich dachte allerdings, dass die bereits in der 4.5 freigeschaltet war und bereits in der 4.4.5 ins werk gesetzt wurde. letztendlich ist die möglichkeit einen artikel kopieren zu können, ein sehr gutes feature, aber nicht im ansatz eine lösung für das problem, für das man die mehrfachzuordnung braucht. ich habe im semptember eine seite gemacht, bei der pressemitteliungen einmal in der kategorie presse und weitere male in einer themen rubrik mehreren themen zugeordnet werden sollten. das artikellisting für die kategorie themen, sollte die letzten 20 artikel aller themen mit nennung der themen zum artikel anzeigen. das geht aber beim kopieren nicht.
1. würde der artikel mehrfach gelistet werden (jeder ist ja nun eigenständig)
2. würde immer nur die nennung von einem thema möglich sein
im übrigen wäre der workflow total verhunzt. anstatt ein und denselben artikel mehreren kategorien durch einen einzigen klick zuzuordnen, müsste man mehrere klicks duchführen, findet man dann einen rechtschreibfehler, darf man gleich alle gleichen artikel einzeln verbessern.

ich gehe auch mal davon aus, dass es mehrere gibt die so eine artikel-struktur aufbauen wollen und daher ist das thema mehrfachzuordnung wichtig. bei reinen präsentationsseiten kommt so eine artikelstruktur natürlich seltener vor.

[malsdgtac]

Hallo trixta,

stimmt natürlich, es ist schade um die Funktion. Für eine Webseite von uns ist diese absolut notwendig. Unter www.steiermark-aktiv.at haben wir einzelne Artikel einer Vielzahl von Kategorien zugeordnet, um einzelne Ausflugszielen Themen hinzuzuordnen.

Aber in vielen Fällen hilft mir das Kopieren auch - schön dass es das gibt, muss ich mal suchen.

[kashban]

Hi!

Ich verwende die Mehrfachkategorisierung ebenfalls auf zwei Websites und halte das für ein unverzichtbares Feature für ein modernes Content Mangement System. Solange das nicht wieder implementiert ist, kann ich die neuen Contenido-Versionen nicht guten Gewissens einsetzen.

Ohne sehr tief im Contenido-Code zu stecken, scheint mir das Problem nach Durchsicht von emergence's Punkte folgendes zu sein:

Im Contenido-DB-Design bilden Kategorien und Artikel atomare Einheiten (IDCAT und IDART). Damit der gleiche Artikel in unterschiedlichen Kategorien jeweils andere Eigenschaften haben kann, wird das Kreuzprodukt gebildet (IDCATART).

Vereinfacht ausgedrückt: Es gibt für jede Kategorie, in die ein Artikel (IDART) eingestellt wird, eine Kopie des Artikels (IDCATART), die dessen Eigenschaften in dieser Kategorie definiert. Der Inhalt des Artikels ist jedoch immer gleich, egal, in welcher Kategorie er steht. Er variiert nur in unterschiedlichen Sprachversionen.

beim verschieben von artikeln in eine andere kategorie wird eine neue idcatart vergeben...

bei der zeitgesteuerten verschiebung wird nur der idcat wert angepasst... der idcatart wert bleibt gleich... (ist nicht konsistent)
so wie das query in der conMoveArticles geschrieben wurde, wurden alle artikel auch wenn sie mehrfach vorhanden waren und dem zu änderten idart wert entsprachen ohne rücksicht auf verluste auf die time_target_cat gesetzt... da kam es dann zu dem fall das ein und der selbe artikel mehrfach in einer kategorie angezeigt wurde...

die zeitsteuerung ist in der con_art_lang definiert... in meinen augen die falsche position... in die con_cat_art könnte man sie verlegen... (dann wäre die verschiebung in allen sprachen ident)
oder man schafft eine eigene tabelle die sich nur um die zeitsteuerung kümmert...

Das sollte schnell behoben werden.

Das korrekte Vorgehen beim zeitgesteuerten Verschieben von Artikeln (IDCATART) sollte sein: IDCAT in IDCATART auf Zielkategorie ändern, *solange* die Paarung IDART und neue IDCAT noch nicht existiert. Esistiert sie, kann man entweder den zu verschiebenen Artikel einfach verwerfen oder dessen Eigenschaften über die bestehenden in der Zielkategorie kopieren und die alte IDCARART dann löschen.

das liebe problem mit den idcatart werten...
meiner meinung nach müsste ein idcatart wenn er einmal vergeben wurde immer mit dem artikel in dieser einen kategorie verknüpft bleiben...
wenn man den artikel nur verschiebt sehe ich an sich kein problem den idcatart wert beizubehalten...
kommt eine mehrfachzuordnung hinzu muss eine neue idcatart vergeben werden...

es gibt da ja das nette feld status in der db tabelle con_cat_art -> das könnte man vielleicht dazu nutzen zu definieren ob die idcatart gültig ist...
ein löschen der idcatart werte sollte somit nie stattfinden... ausser der idart wert wäre wirklich nicht mehr vorhanden...

Meiner Ansicht nach sollte jede IDCATART eine eindeutige Identifizierung eines IDART/IDCAT-Paares sein. Eine Abfrage auf IDART liefert der Tabelle con_cat_art liefert mir alle Kategorien, in denen der Artikel vorkommt. Entsprechendes für CATART. Es darf kein Fall vorkommen, wo es zwei IDCATART-Datensätze gibt mit der gleichen IDART/IDCAT-Paarung. D.h., derselbe Artikel kann nicht zweimal in derselben Kategorie stehen. Ist das schon sichergestellt? Ich halte diese Restriktion für unverzichtbar, um mit dem derzeitigen Design eine konsistente Kategorisierung zu erreichen.

Was passiert denn genau, wenn ein Artikel verschoben wird? Da gibt es vier Fälle:

1. 1 Quellkategorie -> 1 Zielkategorie
2. n Quellkategorien -> 1 Zielkategorie
3. 1 Quellkategorie -> n Zielkategorien
4. n Quellkategorien -> n Zielkategorien

Fall 1 ist simpel: Ersetze in der bestehenden IDCATART IDCAT durch neue Kategorie. Es darf per Definition keine gleiche Paarung IDART/IDCAT in der Zielkategorie geben, so dass hier nichts geprüft werden muss.

Fall 2 sollte folgendermaßen funktionieren:
Verfahre wie Fall 1, zusätzlich lösche alle IDCATART bis auf die mit der neuen Kategorie. Problem: Es können nur die Eigenschaften einer IDCATART übernommen werden. Bei manuellem Verschieben sollte der User auswählen können, welche alte IDCATART-Eigenschaften übernommen werden. Bei zeitgesteuertem Verschieben gewinnt die IDCATART, die zuletzt verschoben wurde.

Fall 3: Ersetze in der alten IDCATART IDCAT durch die neue Kategorie und erzeuge IDCATART-Kopien für jede weitere Kategorie. Ist die Quellkategorie in den Zielkategorien enthalten, entfällt das Ersetzen der Kategorie in der Quellkategorie und es werden nur die Kopien erzeugt.

Fall 4: Der komplexeste Fall mit mehreren Lösungsmöglichkeiten:

a) Lösche alle IDCATART zu diesem Artikel außer einer (möglichst eine, die auch als Zielkategorie vorkommt). Verfahre dann genauso wie in Fall drei.

b) Ersetze in jeder IDCATART, deren IDCAT in den Zielkategorien nicht vorkommt, durch eine Ziel-IDCAT. Lösche überflüssige Quell-IDCATARTs bzw. erzeuge neue für zusätzliche Zielkategorien.

Grundsätzlich halte ich es für sinnvoller, bei Fall 4 Variante a) zu implementieren, da man sonst nicht vorhersehen kann, welche Alteigenschaften ein Artikel in einer neuen Kategorie hat. Er sollte die bekommen, die im Zeitpunkt des manuellen Verschiebens eingestellt sind. Bei zeitgesteuerter Mehrfachverschiebung gewinnt der zuletzt verschobene Artikel.

Das oben beschriebene Verfahren funktioniert, solange sichergestellt ist, dass ein IDART nur einmal in Zusammenhang mit einer IDCAT vorkommt, es also keine Doubletten gibt.

Die Umsetzung halte ich für machbar, wenn ich mir das DB-Design so ansehe. Es braucht nicht einmal zusätzliche Tabellen, lediglich die Bedingung eindeutige Paare IDART/IDCAT muss eingehalten werden.

Wie tief das im Code verwurstelt ist, kann ich ohne eingehenderen Review nicht einschätzen, aber das Problem ist allemal lösbar.

das schlimme an der ganzen sache: es ist ein wahnsinnsaufwand...
sollte das ganze wieder ein thema werden, sprich man möchte das wieder implementieren, kommt man um eine bereinigung der obrigen punkte fast nicht herum...

falls ich etwas vergessen haben sollte, bitte ich um eine ergänzung...

Ich empfehle sehr, für die nächste Contenido-Version obige Ausführungen zu berücksichtigen. Wie emergence selbst sagt, verhält sich Contenido zurzeit inkonsistent, was Artikelkategorisierung angeht und so etwas hat die unangenehme Angewohnheit, immer größere Probleme zu verursachen, deren Lösungsaufwand in keinem Verhältnis zur frühzeitigen Bereinigung stehen. Insbesondere stellt die Mehrfachkategorisierung ein wichtiges Merkmal eines CMS dar, so dass der Aufwand allemal gerechtfertigt ist.

Viele Grüße,
Kashban

[timo]

Ich empfehle sehr, für die nächste Contenido-Version obige Ausführungen zu berücksichtigen. Wie emergence selbst sagt, verhält sich Contenido zurzeit inkonsistent, was Artikelkategorisierung angeht und so etwas hat die unangenehme Angewohnheit, immer größere Probleme zu verursachen, deren Lösungsaufwand in keinem Verhältnis zur frühzeitigen Bereinigung stehen. Insbesondere stellt die Mehrfachkategorisierung ein wichtiges Merkmal eines CMS dar, so dass der Aufwand allemal gerechtfertigt ist.

Viele Grüße,
Kashban

Wenn du uns die Arbeitszeit finanzierst, dann gerne. Aber wir haben für das CMS eine höhere Priorisierung für unsere Kunden im Bezug auf fehlerfreie Mehrsprachigkeit als auf eine (IMHO auch anders umsetzbare) Mehrfachzuordnung...

Und so ganz sind deine Ausführungen nicht nachvollziehbar, du vergisst die sprachabhängigen Teile...es muß zumindest eine Art con_cat_art_lang eingeführt werden, in der die entsprechenden sprachabhängigen Artikel zu den jeweiligen sprachabhängigen Kategorien zugewiesen werden müssen...das umzusetzen UND einigermaßen kompatibel zu bleiben wird sich (wenn überhaupt umsetzbar) mindestens über 2-3 Major Releases ziehen.

[kashban]

Da hast Du recht, die sprachabhängigen Teile habe ich mir noch nicht genau angesehen und die sind nicht ohne. Ich werde noch mal drüber nachdenken.

Viele Grüße,
Kashban

[i-fekt]

wir haben für das CMS eine höhere Priorisierung für [...] als auf eine (IMHO auch anders umsetzbare) Mehrfachzuordnung...

Und wie?

[timo]

wir haben für das CMS eine höhere Priorisierung für [...] als auf eine (IMHO auch anders umsetzbare) Mehrfachzuordnung...

Und wie?

Mit Artikelweiterleitungen und entsprechend angepassten Modulen. Es wäre übrigens für die Kommunikation nicht hinderlich, wenn du nur die Teile zitierst, die wirklich relevant sind und dann auch entsprechend lange Sätze schreibst, was du wissen willst - ich hab keine Lust 2 Minuten davor zu sitzen und zu denken "was ist hier eigentlich Sache"?

[i-fekt]

Bei einer Artikelweiterleitung würde dann aber doch die Navi falsch aufklappen?

Wie wäre es denn, wenn man Mehrfachzuordnung so löst, dass jeder Artikel der eine Mherfachzuordnung hat doppelt oder x-Mal angelegt wird in der Datenbank. Ändert sich dann in einem Artikel etwas, kopiert Contenido selbständig die Änderungen in den anderen Artikeln (Kopien).

[timo]

Dann brauchst du ein Artikel-Include-Modul

Ich selbst habe aber noch nie den Anwendungsfall gehabt, daß !derselbe! Artikel in 2 Kategorien sein musste...ich kann mir auch keinen Vorstellen

[i-fekt]

Ich habe das hier beschrieben. Das Problem ist nur die Art wie Contenido Artikel speichert und verwaltet. In dem Artikel ist beschrieben, wie zweimal der selbe Artikel vorhanden sein müsste. Das dynamisch abzufragen erscheint mir so als wäre es sehr viel umständlicher mit Contenido.