Was ist eigentlich der Sinn hinter der Bezeichnung "Artikel"?
Seit jeher verstehe ich nicht, wieso man diese (in der Praxis tatsächlich oft sehr sinnvolle und daher letzten Endes wohl auch unerlässliche) zusätzliche Container-Ebene eigentlich "Artikel" nennt.
Es möge mir doch bitte mal jemand eine Webseite zeigen, auf der mehr als ein einzelner Artikel (sinngemäß als solcher, in voller Länge) gleichzeitig zu sehen ist..!? So was habe ich zumindest in 10 Jahren des Dauer-Web-Surfens noch nie gesehen!
Egal ob die Dinger nun "Artikel", "Nachricht", "Event", "Blog-Beitrag", "Katalog-Eintrag", usw. heissen, es ist doch eigentlich immer das selbe Prinzip hinter einer modernen Website:
- Aufteilung nach Seiten / Menü-Navigation
- statische (eher kleine) Inhaltseinheiten, Module, Werbebanner, etc.
- eventuell auch ein (großer) statisch eingebundener "Artikel"
- Teaser-Listen (mit oder ohne Seitenumbruch..)
- verschiedenartigste Filter-Möglichkeiten
- Leser-Module (wo dann –auch– das gesamte Ding angezeigt wird..)
Gut, vielleicht gibt es manchmal Seiten auf denen mehrere "Katalog-Einträge" in vollem Umfang angezeigt werden (wobei diese dann meist auch nicht ganze DIN-A4-Seiten an Text umfassen, wie es bei einem längeren "Artikel" ja schon mal der Fall sein kann/darf)..
Mein Lösungsansatz –der mir jetzt auch gerade kommt, wo ich die "Dinger" aufgelistet habe– wäre folgender:
1. Artikel als zusätzliche, system-strukturelle Container-Eben auf jeden Fall behalten, dann aber nicht mehr "Artikel" nennen, sondern vielleicht einfach "Inhaltsbereiche"...
2. Dafür aber vielleicht standardmäßig ein weiteres Core-Modul "Artikel" welches vom Prinzip her z.B. dem des Nachrichten-Moduls gleicht. Also ein Ort (Menüpunkt) an dem man (der Redakteur) tatsächliche Artikel zunächst einmal (ggf. auch nach Archiven getrennt) erfassen, verfassen und verwalten kann...
3. Oder aber, was ich fast noch besser fände, dass man die "Contalog"-Idee weiter verfolgt, wonach sich Contao im Ganzen in so etwas wie die Catalog-Erweiterung verwandelt:
Das könnte dann so aussehen, dass man in den allgemeinen Einstellungen zunächst einmal global festlegen kann, wie viele verschiedene "Inhaltsarten" ("Dinger") man im System haben möchte, und wie diese genau heissen sollen (z.B. "Artikel", "Nachrichten" und "Häufige Fragen", etc.). Jede dieser Inhaltsarten erzeugt dann einen eigenen, individuellen Menüpunkt (ein eigenes Backend-Modul) unter "Inhalte", z.B.:
- SEITENINHALTE* (spezielles, fixes Modul, wie bisher "Artikel"; auch meiner Meinung nach idealer Weise fusioniert zusammen mit der "Seitenstruktur", sowie zusätzlich unterteilt nach den "Layout-Bereichen" aus dem der jeweiligen Seite zugewiesenen Layout; und der dann im Gesamtkonzept vielleicht passenderen Bezeichnung "Seiteninhalte")
- Artikel (oder "Essays", oder what ever..)
- Nachrichten (oder "News", oder what ever..)
- Häufige Fragen (oder "FAQs", oder what ever..)
- ... ...
- Events (spezielles, fixes Modul, wie bisher)
- Newsletter (spezielles, fixes Modul, wie bisher)
- Formulare (spezielles, fixes Modul, wie bisher)
- Kommentare (spezielles, fixes Modul, wie bisher)
4. Die letzte Container-Ebene der "Inhaltselemente" zwar nach wie vor auf "Inhaltsbereich"-Ebene verfügbar lassen, aber auch genauso für jeden einzelnen Datensatz ("Nachricht", "Artikel", oder wie auch immer die Inhaltsarten bezeichnet werden) zur detaillierteren Strukturierung des Datensatz-Inhalts anbieten.
Die allgemeine Container-Struktur (und entsprechend auch die Baumstruktur der *SEITENINHALTE-Ansicht) würde dann folgendermaßen aufgebaut sein:
- Seite XYZ
- Layout-Bereich
- Inhaltsbereich (ursprünglich "Artikel")
- Frontend-Modul (im Speziellen hier z.B. ein Datensatz-Leser-Modul)
- Datensatz-Inhaltselement
- Datensatz-Inhaltselement
- ... ...
- direktes Inhaltselement
- ... ...
- Inhaltsbereich (ursprünglich "Artikel")
- Layout-Bereich
Wobei in der SEITENINHALTE-Ansicht dann natürlich nicht die Datensatz-Inhaltselemente einzeln aufgeführt werden.
Die Layout-Bereiche wären in diesem Modell also von den Inhaltsbereichen (vorher: "Artikeln") los-gekoppelt und würden in der SEITENINHALTE-Ansicht als weitere Strukturebene zusätzlich angezeigt werden. Sie wären hier jedoch nicht direkt editierbar, sondern werden automatisch –entsprechend der Einstellungen im der Seite zugewiesenen Layout– generiert/angezeigt. Bis auf diese Layout-Bereiche wären dann die Seiten, die Inhaltsbereiche, die Frontend-Module und die direkten Inhaltselemente bequem per Drag'n'Drop beliebig innerhalb der SEITENINHALTE verschiebbar...
5. Um die quasi-Auslagerung der "Artikel" in ein extra Backend-Modul zu kompensieren müsste es dann natürlich einen zusätzlichen Datensatz-Leser-Modul-Typ geben, welcher es ermöglicht, einen konkreten Datensatz auszugeben/anzuzeigen (anstelle der Ansteuerung/Auswahl über ein Datensatz-Lister-Modul).
...
Mögliche Probleme beim Wegfall der Artikel in Contao
Hallo zusammen,
ich bin durch Zufall heute auf diesen Thread gestoßen, als ich nach etwas ganz anderem gesucht habe.
Beim Lesen dieser Threads und auch der Google Group dazu bekomme ich etwas Bauchschmerzen wenn die Artikel komplett wegfallen würden. Zumal das teilweise weitreichende Konsequenzen für Dutzende Webseiten hätte, die auf mehrere Artikel pro Seite basieren.
Dazu vielleicht nachfolgend mal ein Anwendungsbeispiel aus der Praxis, wo es mich schon nerven würde, wenn die Artikel an sich wegfallen würde:
1. Includen von Artikeln
Es tritt öfters der Fall ein, dass man bestimmte Elemente eine Seite gern auch auf den unter Seiten 1zu1 verwenden möchte. Daher bietet sich ein Include an. Dies kann nicht nur die Hauptspalte (main) betreffen sondern auch die Linken und Rechten Spalten. Würde es jetzt keine Artikel mehr geben, müsste man jedes Element, welches man auch auf den Unterseiten haben möchte erneut als Element anlegen oder aber als Single-Element includen. Bei einem Element mag das ja noch händlebar sein, aber was ist, wenn ich einen Artikel referenziere der 5 Elemente enthält und das auf 5 Seiten include und ich auf einmal ein Element hinzufügen möchte oder wegnehmen möchte? Das sind schon 5 x 5 = 25 Änderungen notwendig!
Gerade bei größeren Webseiten kann da schon mal eine ganz schöne Summe zusammen kommen und das Risiko etwas zu vergessen ist sehr groß.
(Hinweis: Ich bezog mich jetzt wirklich nur auf Content-Elemente eines Artikels wie eine Überschrift, Bild, Text - Module bindet man sowieso in 85% der Fälle via Layout ein)
Ein (kleines Beispiel) aus der Praxis:
Kontakt-Bereich mit einem Kontaktformular in der Hauptspalte mit einer Übeschrift und vielleicht einem kurzen Text und einem allgemeinen Kontakt-Block auf in der Link/Rechten Spalte. Man benötigt in der Regel die Überschrift "Kontaktformular" sowie die Kontakt-Daten ebenfalls auf der "Nachricht gesendet"-Seite. Ich realisiere das oft so, dass ich einfach die Artikel include. Würden die Artikel jetzt wegfallen, dann müsste ich jedes einzelne Element der Seite includen lassen.
Bei diesem kleinen Beispiel wäre das noch händelbar, jedoch nicht, wenn man wie oben beschrieben das auf x Seiten einsetzt.
2. CSS-Klassen und ID's für Artikel
Es ist möglich Artikeln CSS-Klassen und ID's zuzuordnen. Dies kann manchmal sehr hilfreich sein, wenn man darin befindliche Elemente bzw. deren Eigenschaften verändern möchte, wie zum Beispiel Angaben zu Margins, Paddings, Font-Sizes, etc. Wenn man einer Seite mehrere Artikel hinzufügt, kann man einem Artikel so eine Klasse zuweisen, wenn dies erforderlich ist.
Ein Beispiel aus der Praxis:
Ich habe ein oder mehrere spezielle Seiten mit folgendem Aufbau: Ich habe oben einen Slider, der Randlos gesetzt wird und sichtachsentechnisch bündig links und rechts mit der Seite abschließt. Die darunter folgenden Elemente (Überschrift, Text, etc). sollen aber einen Innen-Abstand wieder haben, damit sie nicht an den Rand geklatscht aussehen. Also weiße ich dem Artikel in dem Fall zum Beispiel eine Klasse zu, dass ein innenabstand gesetzt wird. Möchte ich zum Beispiel jetzt aber als Redakteur darunter noch einen Bild haben, welches bündig wieder abschließt, dann bräuchte ich nichts zu machen, als einen neuen Artikel anlegen mit diesem Bild und ihm keine Klasse zu weisen.
3. Zeitsteuerung für Artikel
Es kommt durchaus vor, dass man Artikel zeitsteuern möchte und alle darin sich befinden Element. Würde man keine Artikel mehr haben, müsste man jedem Element eine Zeitsteuerung hinzufügen oder den Besucher auf eine andere Seite umleiten.
4. Veröffentlichung und Entwurf
Ich habe Kunden, die teilweise bei größeren Änderungen von Seiten, den Artikel dublizieren und die Änderungen durchführen. Gerade wenn in einem Aritkel mehrere Text- und Bildelemente im Wechsel sind. So können die Änderungen durchgefürt werden, korrigiert werden und erst mit dem Online schalten auch auf der Webseite sichtbar werden.
Würde man die Artikel wegfallen lassen, müssten alle Element erst einmal händisch dubliziert und angepasst werden. Auch müsste für jedes Element wieder das sichtbar und unsichtbar eingeschaltet werden.
5. Übersichtlichkeit bei komplexen Webseiten
Bei komplexen Webseiten, kann es manchmal sehr hilfreich sein, wenn man einzelne CE-Elemente in eine Gruppe - sprich Artikel - zusammen fasst. Voraussetzung ist natürlich eine sinnvolle Bezeichnung des Artikels. Gerade wenn man eine Seite mit sehr vielen Elementen hat, wo aber sich nur immer ein kleiner Teil ändert, kann das Readakteuren helfen.
Meine Meinung
Grundsätzlich bin ich für einen Erhalt der Artikel in Contao - Verbesserungwürdig wäre in der Tat eine Bezeichnung für "Artikel". Das verwirrt am Anfang immer Kunden, sodass ich teilweise "Artikel" in Inhaltsbereich übersetzte, da es für Kunden einfacher ist.
Ich habe die Erfahrung gemacht, dass Kunden damit sehr gut zu recht kommen, vor allem in Hinblick auf Typo3 - dort ist es teilweise sehr umständlich.
Es ist oben angeregt worden, die Artikel als CE-Element zu machen. Insoweit die oben skizzierten Problem-Beispiele damit gelöst sind, wäre ich mit einverstanden. Für kleinere Seiten die nur 1 Artikel-Element haben, macht es Sinn dieses eventuell wegfallen zu lassen. Für größere Seiten (30 Seiten + x ) - würde ich ziemliche Bauchschmerzen teilweise bekommen, wenn ich auf einmal hergehen müsste und das Konzept und die Aufteilung anpassen müsste.
Was ich an Contao teilweise sehr schätze ist die Freiheit die man bei der Anlege von Elementen hat. Man kann bzw. der Redakteur kann sich entscheiden ob er erst einen Text, dann ein Bild, dann ein Download oder doch eine andere Reihenfolge haben will. Ich empfinde die Artikel als ein Stück dieser Freiheit, weil Sie quasi als Sammelblock für diese einzelnen Elemente dienen.
Zuätzlich helfen Sie gerade bei komplexeren Webseiten - vorrausgesetzt man hat sich intelligent benannt - einem leichter in der Übersicht zu verstehen, wo befindet sich welches Element.
Ich hoffe mein Beitrag hat ein Paar Anregungen in dieser Diskussion geschaffen.