Auffinden von Inhaltselementen, die Einträge in mehreren Elementtypen enthalten

[gbecker]

Hallo,

um beim Erstellen von Inhalten schneller voranzukommen, habe ich immer wieder bereits bestehende Inhaltselemente kopiert und mit anderen Inhalten befüllt.

Teilweise habe ich dabei auch den Elementtyp z.B. von Text auf HTML, von Hyperlink auf Text, von Bild auf Überschrift, etc. umgestellt.

Bei einer Revision der Datenbank habe ich zufällig festgestellt, dass Inhalte, die vor einem Wechsel des Elementtyps bereits in die Datenbank geschrieben wurden, bei einem Wechsel nicht gelöscht werden.
So entstehen Inhaltselemente, mit zwei befüllten Elementtypen, von denen nur einer genutzt wird.
Kommen solche Kopiervorgänge mit Elementtypwechsel häufiger vor, bläht dies die Datenbank erheblich auf.

Mit einer manuellen Bereinigung der nicht genutzten Inhalte in der Datenbank konnte ich deren Größe bisher um ca. 50% verringern.

Da ich mir nicht sicher bin, ob ich alle ungenutzten Inhalte aus der Datenbank entfernt habe, wollte ich fragen, ob es eine Möglichkeit gibt, Inhaltselemente mit Mehrfachinhalten gezielt herauszufiltern?

[Ainschy]

Ich würde sagen das Problem ist selbst erschaffen. Beim kopieren eines Inhaltes-Elements werden alle Einträge aus dem Datensatz übertragen, auch solche die nicht zum Element "gehören".

[Black Pirate]

Eine Möglichkeit wäre im Datenbank Admin verschiedene sql Abfragen zu machen.

zb. Abfrage in der tl_content
- alle Feld type html mit Feld text nicht leer

Theoretisch wäre das Feld text ja leer bei einem html Element
und das Ergebnis würde dir dann Einträge anzeigen die "altlasten" enthalten

[cliffparnitzky]

Ich frage mich, warum du ein Element kopierst, um dann daraus ein anderes zu machen?

[gbecker]

@Black Pirate
Besten Dank für Deinen konstruktiven Lösungsvorschlag!

@Ainschy, cliffparnitzky, mlweb, zonky, zoglo
Ich habe Seitenstrukturen, die sich in großen Teilen wiederholen, zahlreiche wrapper-Elemente (HTML), die bestimmte Sektionen auf einer Seite umschließen. Um Arbeit zu sparen, und Strukturfehler auszuschließen, habe ich diese kopiert. Bei Abweichungen in der Struktur habe ich bestehende Inhaltselemente umfunktioniert. Dabei war mir nicht klar, dass bereits bestehende Inhalte erhalten bleiben.

Wie gehen denn erfahrene Redakteure mit der Mehrfach-Kopieren-Funktion um?

Gibt es irgendwo eine Hinweis, dass bei einem Elementtyp-Wechsel bereits bestehende Inhalte in der Datenbank erhalten bleiben?

Es könnte ja auch durchaus vorkommen, dass man aus Versehen einen falschen oder unpassenden Elementtyp ausgewählt hat, diesen nachträglich korrigiert und dann in das gleiche Problem läuft.

[zonky]

Gibt es irgendwo eine Hinweis, dass bei einem Elementtyp-Wechsel bereits bestehende Inhalte in der Datenbank erhalten bleiben?

ist mir nicht bekannt ... "das war aber schon immer so"!

Wenn Du den Typ wieder änderst, siehst Du ja, dass die ursprünglichen Eingaben wieder da sind. Für manche User ist das auch ein Vorteil, wenn aus versehen der Typ geändert wurde.

Du könntest ein Script bauen, was das DCA ausliest und guckt, welche Spalten bei welchem Typ aktiv sind und dann alle anderen Spalten (bis auf die Standardsachen) leerst.

Ich würde mal behaupten, die "überflüssigen" Spalteninhalte stören nicht weiter und dürften in der Performance keinen Unterschied machen - Deine DB wird dadurch sicher nicht von 50 MB auf 50GB angewachsen sein. Ein guter Index macht da mehr aus!

Für die Zukunft könntest Du einen save_callback schreiben, der beim Speichern aufräumt.

[Ainschy]

...
Ich habe Seitenstrukturen, die sich in großen Teilen wiederholen, zahlreiche wrapper-Elemente (HTML), die bestimmte Sektionen auf einer Seite umschließen. Um Arbeit zu sparen, und Strukturfehler auszuschließen, habe ich diese kopiert. Bei Abweichungen in der Struktur habe ich bestehende Inhaltselemente umfunktioniert. Dabei war mir nicht klar, dass bereits bestehende Inhalte erhalten bleiben.

Wie gehen denn erfahrene Redakteure mit der Mehrfach-Kopieren-Funktion um?

Gibt es irgendwo eine Hinweis, dass bei einem Elementtyp-Wechsel bereits bestehende Inhalte in der Datenbank erhalten bleiben? ...

Vllt. braucht es einen anderen Ansatz. Wenn sich nur 5% der kopierten Inhalte ändern, wäre es sinnvoll die restlichen 95% in wieder verwendbares Template zu bauen. Mit Rocksolid Custom Elements ließen sich die Eingaben strukturiert zusammenfassen und im Template ausgeben.

Möglicherweise wäre MetaModels für deinen Projekt ein Ansatz um Inhalte schnell und einfach zu erstellen und zu pflegen?

[gbecker]

Herzlichen Dank für die Vorschläge.

Bei meinem Ansatz wollte ich auf Erweiterungen bewusst verzichten, weil ich in der Vergangenheit wiederholt Probleme bei Updates hatte. Eine gewisse Zeit funktionierten die Updates, bis sich dann die Versionen der einzelnen Erweiterungen nach und nach nicht mehr durchgängig aktualisieren ließen. Auch wusste ich nie genau, ob der Update-Status für das System und alle Erweiterungen valide war, oder nicht. Ab diesem Zeitpunkt wurde jedes Update eine Zitterpartie, ob die Website danach noch funktionierte.

Die einfachste und schlankeste Lösung scheint mir daher, Section-Wrapper als HTML-Inhaltselemente zu verwenden. So kann ich Grid- und Flex-Layouts am leichtesten kombinieren, ohne dabei auf Erweiterungen wie Grid-Bundles oder ähnliches zurückgreifen zu müssen. Der Nachteil dieser Lösung ist natürlich das Handling. Für die Kennzeichnung der Wrapper kommen HTML-Kommentare zum Einsatz.

Der vorgeschlagene Lösungsansatz, auf wiederverwendbare Templates zu setzen, behagt mir persönlich deswegen nicht, weil damit eine andere Update-Problematik auftritt, die zwischen Core-Templates und Custom-Templates. Dieser Ansatz würde vermutlich darauf hinauslaufen, dass ein Theme ähnlich wie eine Erweiterung installiert werden müsste und nicht einfach importiert werden könnte. Ich denke da an den Ansatz von pdir.

Zur Performace: Nach meinen Messungen mit Lighthouse war die Website nach der manuellen Datenbankbereinigung um ein paar Prozent schneller.

[zonky]

Zur Performace: Nach meinen Messungen mit Lighthouse war die Website nach der manuellen Datenbankbereinigung um ein paar Prozent schneller.

Das deutet m. E. eher darauf hin, dass das Caching nicht oder nicht optimal eingestellt war.

[gbecker]

Für Leute, denen es ähnlich ergeht oder ergangen ist, hier mein Lösungsansatz, der einfach und recht schnell umsetzbar ist:

Mit
SELECT DISTINCT type FROM tl_content;
nachsehen, welche Inhaltstypen in Verwendung sind.

Dann die einzelnen Inhaltstypen mit z.B.
SELECT * FROM tl_content WHERE type = 'headline';
SELECT * FROM tl_content WHERE type = 'html';
SELECT * FROM tl_content WHERE type = 'hyperlink';
SELECT * FROM tl_content WHERE type = 'image';
SELECT * FROM tl_content WHERE type = 'list';
SELECT * FROM tl_content WHERE type = 'text';
etc.
durchgehen und nach ungenutzten Einträgen suchen.

Falls ungenutzte Einträge vorhanden sind, mit der von Ainschy vorgeschlagenen Methode (siehe Suchen nach Klassennamen in einem Artikel) überprüfen, ob dies tatsächlich der Fall ist. Wenn ja, die Einträge im entsprechenden Datenbankfeld löschen.

VORSICHT: Bei serialisiert gespeicherten Einträgen in der Datenbank wie z.B. bei der cssID, führen direkte Korrekturen im Datenbankfeld zu Fehlern (siehe ebenfalls Suchen nach Klassennamen in einem Artikel).

Bei der Datenbankbereinigung bin ich auf Einträge gestoßen, die im redaktionellen Alltag sicherlich häufiger entstehen, z.B. wenn Icons zunächst als Bilder in einem Textblock eingefügt werden. Später könnte sich herausstellen, dass es besser wäre, die Icons als separate Bild-Elemente einzubinden. Wenn dann der Element-Typ von "Text" auf "Bild" umgestellt wird, entsteht der doppelte Eintrag. Um dies zu vermeiden, müsste das Text-Element zunächst gelöscht und dann ein neues Bild-Element erstellt werden. Möglicherweise wird das ja im redaktionellen Alltag tatsächlich immer so gemacht.

[Spooky]

Grundsätzlich ist es gewollt, dass bspw. der Text eines Text-Inhaltselementes bestehen bleibt, wenn du das Inhaltselement auf "Bild" änderst. Somit geht der Text nicht verloren und kannst ihn wiederherstellen, wenn gewünscht.

[zonky]

Im Prinzip sollten die Daten von "Text" nach Änderung zu "Bild" in der Versionierung noch vorhanden sein - bis zum Löschen der Version...

Bisher habe ich auch noch von niemanden gehört/gelesen, der sich an dem bisherigen Vorgehen gestört hätte - und wie gesagt, ich sehe da auch wenig Prerformanceprobleme.

[gbecker]

Kann ich denn bestimmte Versionen eines Inhaltselements auch löschen, oder nur vergleichen und ggf. wiederherstellen?
Über "Daten bereinigen", was ich sehr regelmäßig für alle Daten durchführe, um Änderungen zu testen, werden die von mir angesprochenen, doppelten Einträge nicht gelöscht.

[zonky]

A: Kann ich denn bestimmte Versionen eines Inhaltselements auch löschen, oder nur vergleichen und ggf. wiederherstellen?
B: Über "Daten bereinigen", was ich sehr regelmäßig für alle Daten durchführe, um Änderungen zu testen, werden die von mir angesprochenen, doppelten Einträge nicht gelöscht.

zu A: m.E. nicht - nur direkt in der DB

zu B: das sind zwei paar Schuhe - die Versionen sind in einer eigenen Tabelle abgelegt, die Du mit "Daten bereinigen" löschen kannst (oder ältere Einträge werden nach X Tagen gelöscht) - Deine Angaben stehen ja in "einer Zeile" in tl_content und die wird nicht angefasst