Lust und Frust mit Contao => Eine rein subjektive Kritik

[Jogibär]

Hallo zusammen, und erstmal ein gesundes 2016!


ich nutze Contao/TypoLight seit ca. 2009 (ca. 2-4 Seiten im Jahr) und empfand es damals als das beste System was Ausstattung und Möglichkeiten betrifft.

Mit der Zeit habe ich Contao immer weiter selbst für meine Bedürfnisse angepasst, bin aber auch immer wieder auf die gleichen Probleme gestoßen. Inzwischen macht sich bei mir immer mehr Frust breit, habe mir deshalb schon viele andere Systeme angeschaut und ausprobiert, z.B. ProcessWire, Drupal, OctoberCMS, WordPress mit Plugins, Craft, Concrete5, darunter auch "FlatFile-System" wie Grav, Cockpit, SiteCake, Herby, etc.

Contao bietet viele tolle Ideen und ist mir ans Herz gewachsen, deswegen will ich auch nicht einfach wechseln, aber ich möchte euch einfach von meinen Gedanken berichten und fragen, wie ihr das empfindet.


1.) Recht starre Standard-Datenstruktur mit wenig Erweiterungsmöglichkeit bei wenigen PHP-Kenntnissen

Z.B. keine Erweiterung des Systems (für Nicht-Programmierer) für weitere Felder oder ganze Datenstrukturen, noch nicht einmal Taxonomie wie z.B. in WordPress oder Drupal selbstverständlich. Taxonomie bietet doch so tolle Möglichkeiten bei der Filterung einer Ausgabe.

Einfach mal den Teaser um die Möglichkeit eines Vorschaubildes erweitern? Leider nicht ohne tiefere Kenntnisse möglich. Nutze doch ein Plugin, heißt es dann.
Habe ich gemacht, lief nur nicht mehr in der neuesten Contao-Version. Dann halt einen Entwickler engagieren!
In Concrete5 beispielsweise kann man einfach beliebige Felder zur Datenhaltung hinzufügen, z.B. wenn man auf jeder Seite ein Teaserbild ausgeben will, ohne jedes Mal ein separates Bild-Element hinzuzufügen, und es mit einer Klasse zu definieren, einfach als Basis für eine Seite festlegen.

Wäre es nicht toll, dem User das Anlegen von beliebigen Datenstrukturen zu erlauben? In ProcessWire wird dieser Gedanke in Extremform betrieben. Alles ist eine Seite in einem Baum, die Datenhaltung, also der gesamte Aufbau, liegt somit ganz beim Admin. Die Datenbank-Ausgabe in ProcessWire geschieht über eine jQuery artige Sprache – eine geniale Idee, damit auch Amateure damit klarkommen.

Wie oft habe ich in Contao das Anlegen von globalen Daten vermisst, einfach links aufgeführt als Menüpunkt, z.B. für Kontaktdaten, die dann gezielt auf der Seite ausgegeben werden können. In ProcessWire beispielsweise lege ich mir einfach eine "Daten"-Seite an, der Ausgabebaum der Seiten liegt dann auf einer anderen Ebene. Entsprechend benannt sieht auch der Endkunde, wo er welche Daten vorfindet.
Solche frischen Ideen vermisse ich in Contao.


2.) Keine richtige Trennung von System und Inhalten.

Zudem finde ich es schade, dass Config-Dateien, Inhaltsdateien, genutzte Plugins und Templates in verschiedenen Ordnern liegen.
Hier machen andere System es ebenfalls leichter, mit einer bewährten Basiskonfiguration umzuziehen, weil einfach alles Daten (auch die benötigten Plugins) in einem Content-Ordner strukturiert sind. Bei Updates einfach den Systemordner austauschen – fertig! Falls etwas nach einem Update nicht läuft, einfach erstmal wieder alten System-Ordner einfügen. Gerade bei Life-Systemen sehr hilfreich.


3.) Teilweise umständliche Bedienung mit zu vielen Infos

Da das Vorhalten und Ändern von Inhalten nun einmal der Hauptgrund eines CMS ist, könnte man nach 10 Jahren doch mal das System hinterfragen und über den Tellerrand schauen, wie es andere CMS machen. Es wird von barrierefrei gesprochen, aber meiner Erfahrung nach haben auch ganz normale, "gesunde" Laien bereits Probleme mit der Bedienung.
Einerseits finde ich die Möglichkeiten über Artikel/Seitenelemente genial, weil sehr mächtig, gerade solche Elemente vermisse ich in anderen CMS, aber die Herangehensweise der Bedienung finde ich suboptimal.

Es sind relativ viele Klicks nötig, um an ein Element zu kommen bzw. eines anzulegen. Ja, ich kenne die Tastenkürzel, aber von einen Kunden, der alle paar Wochen mal was editiert, kann ich das nicht verlangen. Aber auch mit Tastenkürzeln bleibt das Grundproblem bestehen: Eine Überfrachtung mit (winzigen) Icons, die auch selten gebrauchte Funktionen zeigen, zusammen mit für Laien eher unwichtigen Infos, z.B. die der Artikeldaten.
Und warum muss Contao ungefragt die Seitenstruktur ständig verkürzen, die man dann erst wieder über die gelbe Breadcrump-Leiste entfalten muss. Bei kleinen Seiten doch eher unnötig, oder?

In der Seitenstruktur wird gerne mal auf den Bleistift geklickt, weil der Kunde ja Inhalte auf der Seite bearbeiten wollen, also ganz naheliegend. Ich muss dann auf das stiftartige Icons rechts außen verweisen, mit dem er erstmal in den Artikel kommt, der leider standardmäßig wie die Seite heißt.
Auch hier halte ich im Normalfall den Gang in den Artikel und die ganzen Infos für einen Laien für nicht relevant. Er will doch nur ein Element auf der Seite aufrufen und bearbeiten und sich im Normalbetrieb nicht mit unzähligen strukturellen Möglichkeiten herumschlagen.

Für den Profi ist es schön, die ganzen Möglichkeiten der Untergliederung zu haben, aber warum könnte für Laien nicht eine vereinfachte Bedienoberfläche existieren, die für 90% der Fälle ausreicht?
Z.B. sieht er die Seitenstruktur, klickt auf "bearbeiten" und kann seine Elemente der Hauptspalte hinzufügen.
Und muss man dem normalen Benutzer 4 Speichern-Buttons unter einem Element zumuten, das verwirrt doch mehr als es nutzt.

Genauso das Neu-Anordnen der Seiten: Wer einmal Drag & Drop in anderen CMS erfahren hat, fühlt sich in Contao in der Zeit zurückversetzt. Auch wieder mehr Klicks als nötig und teilweise nicht intuitiv, z.B. Seiten als erste Unterseite einfügen (Pfeil rechts), oder Verschiebevorgang über "Ablage leeren" abbrechen.

Bei der Medienverwaltung finde ich WordPress vorbildhaft: Große Bilder (auch bei Hochformat!), simple Sortierung nach Datum des Uploads, wenn gewünscht. Dazu eine Raster-Ansicht, um viele Bilder auf einmal zu sehen.



Ich finde in Contao einfach die Sichtweise des Programmierers bzw. Profis zu dominant, der das System vielleicht jeden Tag bedient und alle Kniffe kennt.
Eine Frontend-Bearbeitung als Feature wird ja immer mal wieder im Forum geäußert – und abgeschmettert.
Hier muss ich RockSolid(Themes) mal positiv erwähnen, dessen Komponenten bei mir inzwischen zu jeder Installation dazugehören, dort gibt es auch Front-Editing.

Trotzdem ist es ein Unterschied, ob ein CMS grundlegend dafür ausgelegt wurde oder nicht, z.B. im Hinblick auf "Grids", die eine Eingabe im Backend noch weniger intuitiv werden lassen, z.B. durch die manuelle Eingabe von verschiedenen Klassennamen.

Es ist nicht so einfach einem potentiellen Kunden die Vorteile der hohen Strukturierbarkeit der Inhalte in Contao zu verdeutlichen, wenn er auf der anderen Seite Drag & Drop Frontend-Bearbeitung erlebt hat, wo live Spaltenbreiten geändert und Inhalte einfach reingezogen werden können. Concrete5 hat das z.B. sehr schön direkt ins System integriert, SiteCake machte es in absolut genial minimalistischer Weise mit reinen HTML-Dateien (ist aber noch im Aufbau). In WordPress habe ich wohl 1 Duzend solcher Plugins gesehen – und nicht alle haben katastrophalen Code produziert.
Für den (potentiellen) Kunden ist es auch (leider) nicht so relevant, wie es "darunter" aussieht, die Seite läuft und es macht ihm Spaß sie zu pflegen.

Bei einer Firmenseite wiederum kommt man ohne gute System- und Programmierkenntnisse eigentlich nicht weiter, z.B. bei der Eingabe von wiederkehrenden, strukturellen Daten, z.B. Produkte mit bequemer Ausgabe.
In Contao 2 war der Catalog dafür ein geniales Werkzeug für den Nicht-Programmierer. Heute gibt es MetaModells, die für kleinere Dinge aber überdimensioniert erscheinen. Installation / Konfiguration erfordert einiges an Wissen, ging in manchen Version schief, und dann das Bangen, ob alles auch in der nächsten Version noch läuft.
Selbst das oft belächelte WordPress stellt seit Version 3 benutzerdefinierbare Felder zur Verfügung (Custom Post Types), die recht einfach eingefügt oder auch über Plugins sehr komfortabel zu verwalten sind.
Contao installiert mir stattdessen FAQ, Events, Nachrichten, Listings, anstatt mehr auf Flexibilität zu setzen.


Hier stellt sich für mich immer wieder die Frage, für welche Zielgruppe Contao eigentlich gedacht ist, auch im Hinblick auf die Konkurrenzsysteme.
Nur für wirklich ambitionierte Programmierer und Fulltime-Redakteure die technisch versiert sind?
Ein Designer, der sich nur wenig mit PHP-Programmierung auskennt, ist dann meist auf Entwickler (bzw. Plugins) angewiesen, die ihm helfen.
Nicht jede Website bietet aber so viel Budget an, bei bestimmten Wünschen gleich einen Entwickler mit ins Boot zu holen.



Contao 4:

Leider bleiben mit Contao 4 meine geäußerten Kritikpunkte bestehen, es gibt einfach keine frischen Ideen. Soweit ich weiß, wurde auch im Netz niemals mal bei den Nutzer gefragt, was die so denken oder sich wünschen.
Ich weiß, dass "unter der Haube" viele Veränderungen stattfanden und ich weiß um die Arbeit von Leo und anderen Entwicklern, bitte also nicht falsch verstehen!
Aber wenn ich in den ChangeLogs schaue finde ich seit einem gefühlten Jahr nur Bugfixes und ansonsten ein ziemlich gleich gebliebenes System, also kein wirklicher Grund umzusteigen. Zudem immer die Sorge, dass Plugins nach dem Wechsel einer Major-Version nicht mehr laufen. Das ist auch einer der Gründe, warum ich eben nicht voll auf Plugins setzen möchte, sondern mir eine flexiblere Basis wünsche.



Sorry, dass es so lang wurde, aber ich musste mir das mal von der Seele schreiben ;-)
Bitte nicht vergessen: Ich mag Contao ebenfalls und ich wollte nur einfach meine subjektive Sichtweise schildern. Es bietet eben auch einiges Gutes, was ich in anderen CMS vermisse und was mich hindert, einfach zu wechseln. ProcessWire finde ich hier am vielversprechendsten. Der Entwickler baut selbst aktiv Websites, kennt also die Praxis, und lässt sich regelmäßig im Forum blicken; ist dort an Diskussionen beteiligt, wo auch gemeinsam Pro und Contra für manche Ideen aufgeführt werden. So wird das System sehr rasch weiterentwickelt.


Mich würde einfach eure Sichtweise interessieren und vielleicht auch, ob und wie ihr einzelne der angesprochenen Punkte gelöst habt.


VG
Jürgen

[Samuell]

Hallo Jürgen,
danke für Deine ehrliche Meinung.
Ich werde mich einmal an Deinem Text lang hangeln und zu den Punkten schreiben, wie ich es als Frontend Entwickler sehe und erlebe, denn in dieser Position bin ich ebenfalls kein PHP-Kenner sondern eher im Bereich Themes, HTML und CSS zuhause.

Ich nutze Contao ebenfalls seit ca 2009, baue damit aber deutlich mehr Seiten als Du und hab mir entsprechend eine Basisinstallation (Angepasste Version) erstellt.
Bei meinem Blick über den Tellerrand habe ich in anderen Systemen immer wieder schöne Lösungen, wie auch andere Stellen entdeckt, die aus meiner Sicht deutlich schlechter gelöst waren.

1.) Recht starre Standard-Datenstruktur mit wenig Erweiterungsmöglichkeit bei wenigen PHP-Kenntnissen

Auch als Nicht-Programmierer finde ich es mittlerweile nicht mehr schwer eine Erweiterung um gewisse Felder im dca zu erweitern.
Zu diesem Thema gibt es zB auf der Contao Konferenz 2015 einen Beitrag von Kirsten, der auch via youtube zu finden ist.
Mit dieser Version hat man sich schnell mal ein Feld eingebaut.
Eine interne Taxonomie würde ich in diesem Zusammenhang ebenfalls schön finden.

Andererseits wiederum kenne ich auch Einsteigern, die gern ein noch schlankeres Basissystem hätten und sogar gern die News,Events und FAQ rauswerfen würden.

Man kann es also leider nicht allen recht machen.

Mein persönlicher Favourite wäre eine Datenbasis mit der man sich zumindest einfachere Datenkonstrukte wie News, Events oder Inhaltselemente selbst konigurieren kann.
Eine Basis dieser Strukturen wird dann bereits im System angeboten, sind sozusagen vorkonfiguriert.
Aus meiner sicht muss dies allerdings nicht mit einer "Klickibunti-Oberfläche" möglich sein, sondern darf gern über eine konfigurierbare Datei möglich sein.

Derzeit löse ich das über Custom Elements oder den dca und bin damit recht zufrieden.

Auch hier wird der Mittelweg schwer. Denn eine eigene Sprache, die es in ProcessWire gibt, geht in Richtung eines TypoScripts, dass es für TYPO3 gibt und das oft als Nachteil empfunden wird.

globalen Daten
Solltest Du in ähnlicher Form leicht mit Contao lösen können.
Ich lege immer am Ende des Seitenbaums eine separate Seite an, deren Namen "Seitenübergreifende Inhalte" heißt.
Hier kann ich entweder als Artikel oder Inhaltselement Bereiche für Öffnungszeiten, bestimmte Bilder oder Kontaktdaten hinterlegen und diese als Referenz oder via InsertTag an beliebiger Stelle auf der Seite einbinden.
Der Kunde versteht es :-)

2.) Keine richtige Trennung von System und Inhalten.
Das ist ein Stück weit eine Glaubensfrage.
Gehört die config.php nun zum System, dass es konfiguriert oder sollte es ausgelagert werden.
Weiterhin möchtei ch ganrnicht Templates, Module/Plugins und Configfiles alle wild in einem Ordner herumfliegen haben.

Sicher muss ich mir die in Contao an verschiedenen Stellen zusammensuchen, aber spätestens mit einem Spickzettel sind diese Infos schnell gefunden und innerhalb von 5min zusammengestellt.

3.) Teilweise umständliche Bedienung mit zu vielen Infos

Das für uns wieder von Artikeln wurde oft diskutiert und ich für meinen Teil brauche Sie oft, gerade wo derzeit Blöcke inn sind, die über die volle Breite gehen, einen eigenen Hintergrund enthalten und dann Inhalte anzeigen.
ich möchte die Artikel nicht missen.

Über den Punkt, dass unsere BE aktualisiert werden muss, sind wir uns alle einig.
Entsprechend werden derzeit schon die Icons in Farbe und Größe optimiert.
Weiterhin wird in einer Arbeitsgruppe daran gearbeitet, ein zukünftiges Contao 4.x BE übersichtlicher zu gestalten und Benutzerfreundlicher zu machen.
Hier ist man also aktiv, allerdings wird das Konzeptionieren und das Umsetzen noch einige Zeit in Anspruch nehmen.

Medienverwaltung
Die Lösung von WP geht für mich GARNICHT.
Ich will nicht alle Bilder wild in einem Ordner liegen haben.
Das soll sauber nach Ordnern getrennt werden und dies sag ich auch meinem Kunden.
Auf dem PC wirft man ja auch nicht alle Bilder wild in einen Ordner.

Drag and Drop im BE
Fänd ich auch schön, leider anscheinend derzeit nicht so gut umzusetzen.

Zielgruppe
Einerseits brauchen wir den einfachen Benutzer Marke "ich will mir nur mal kurz ne eigene Seite zusammenklicken".
Andererseits bringt uns dieser nicht weiter, da er in 90% der Fälle eher nur nimmt, seine Seite baut und wieder weg ist.

Andererseits müssen wir auch den Profil eine Basis bieten, die hohe Flexibilität schätzt, denn diese sind eher Bereit sich im Forum einzubringen, haben das Wissen bei der Programmierung und Erweiterung zu helfen oder die Mittel auch mal Geld in die Hand zu nehmen.

Contao 4:
Die Sorge dass eine Eiweiterung vielleicht in der kommenden Version eines CMS nicht mehr funktioniert hast du in jedem System, egal wie es heißt.
Technik entwicklet sich einfach weiter und entweder ist man am Ball und Kompatibel oder man ist raus.

[Jogibär]

Hallo Samuell,

ja, mit dem Ordnen in der Mediathek gebe ich dir recht, ich selbst mache es auch so,
ich meinte hier mehr die Darstellung in der Matrix und größeren Vorschaubildern.
Aber da Contao eine DB nutzt, wären "Tags" für Bilder doch auch sehr schön für eine Gliederung und schnelle Suche (wo wie im Finder von OS X).

Dass am Backend gearbeitet wird, habe ich nicht mitbekommen, das ist ja positiv. Bin gespannt.

Die Daten lege ich bisher auch im Seitenbaum an, aber gerade bei mehrsprachigen Projekten, wo dann überall ein Container liegt, oder auch nur ein einzelner Datencontainer, der mehrere Sprachen enthält (über die Language Tags), wird es unübersichtlich bzw. unlogisch.

Ich weiß natürlich, dass man es nicht allen recht machen kann, aber ein System so flexibel wie möglich zu bauen, kann doch nie der falsche Weg sein.
Z.B. News kann man sehr einfach über Taxonomie nachbauen, aber eben auch andere Dinge, das finde ich das faszinierende. Und sollte Jemand FAQs brauchen, könnte er es sich über flexible Datenfelder ganz schnell selbst anlegen und erweitern, z.B. auch mit Bildern.

Den Beitrag von Kirsten werde ich mal anschauen, ich hatte bisher nur veraltete Entwickler-Tutorials gefunden und es hagelte Fehlermeldungen.
Ich kann durchaus ein wenig programmieren, aber "ein wenig" genügt halt meistens nicht, um eigene Vorstellungen ganz umzusetzen...

[Samuell]

Hier findest Du die Folien:
https://kirsten-roschanski.de/contao...ml#/startseite

Hier das Video:
https://www.youtube.com/watch?v=pd_kCMpVdGM

Das dca kann einem das Leben schon erleichtern und das auch als Nicht-Programmierer.

[BugBuster]

und warum muss Contao ungefragt die Seitenstruktur ständig verkürzen, die man dann erst wieder über die gelbe Breadcrump-Leiste entfalten muss. Bei kleinen Seiten doch eher unnötig, oder?

Das macht Contao nicht eben mal so, dass hast du in dem Fall so gewollt. Wenn du in der Seitenstruktur eine Seite anklickst (nicht eines der Icons), dann wird nur noch in der Struktur diese Seite und tiefer angezeigt. Das ist ein Feature und auch gut so.
Das nutze ich ständig, besonders wenn man zwischen Artikel und Seitenstruktur hin und her wechselt ist das sehr hilfreich, wenn ich zum Beispiel alle Unterseiten einer Seite bearbeiten will und nicht immer durch die gesamte Seitenstruktur durch scrollen will.


Du findest eine jquery artige Sprache für Amateure verständlicher als PHP? Finde ich nicht, ganz im Gegenteil.


Zielgruppe war und wird immer bleiben, Profis mit Kenntnissen in HTML5, CSS und Grundkenntnisse in PHP. (Javascript von Vorteil)


Contao 4 ist ein ganz eigenes Thema. Ein Major Release muss gar nicht abwärtskompatibel sein. Contao versucht es so gut es irgendwie geht. Mehr "Angst" habe ich da schon vor Contao 5, aber das ist ja noch sehr lange Jahre hin.

[Jogibär]

Das macht Contao nicht eben mal so, dass hast du in dem Fall so gewollt. Wenn du in der Seitenstruktur eine Seite anklickst (nicht eines der Icons), dann wird nur noch in der Struktur diese Seite und tiefer angezeigt. Das ist ein Feature und auch gut so.

Ich klicke das Icon ganz rechts an, um schnell zu den vorhandenen Artikeln zu gelangen.
Geht das auch anders, ohne dass mir die Seitenstruktur verkürzt wird? Oder kann ich das abstellen?
Bei einem kleinen Seitenbaum ist das doch wirklich nicht nötig und es braucht jeweils einen Klick mehr, um wieder alles zu sehen.


Anhand deiner Beiträge sehe ich, dass du ein Profi bist und dir sicherlich auch alles selbst programmieren kannst,
aber die Meinung zu den von mir angesprochenen Punkten hätte ich spannend gefunden. Bist du denn mit allem zufrieden?

Dass die Zielgruppe die ist, wie von dir angesprochen, glaube ich nicht.
Ein System, dass einen CSS-Editor zum zusammenklicken bereitstellt, will doch scheinbar auch Laien mit ins Boot holen.
Und gerade darauf will ich doch hinaus: Warum nicht auch dem Laien oder Amateur-Programmierer mehr Möglichkeiten zur einfachen Erweiterung bieten?

PS: Ich habe inzwischen das Video bzw. Materialien von Kirsten angeschaut und konnte vieles daraus lernen.

[Samuell]

Doch das ist derzeit die interessantere Zielgruppe.

Der interne Editor wird wahrscheinlich mittelfristig rausfallen.
Bei der COD haben wir ihn in Rücksprache mit Leo schon jetzt nicht mehr unterstützt und rein auf sass/scss gesetzt.

[BugBuster]

Wenn es nach den Frontend Profis geht inkl. Leo, dann wäre der interne CSS Editor schon längst Geschichte. Zu Contao (TYPOlight) 2.7 Zeiten oder älter war der sicherlich sinnvoll, da man besonders über die Demo gut sehen konnte, wie mit den von Contao selbst generierten Klassen und IDs umzugehen ist.
Heutzutage nutzen viele bereits externe CSS Framework wie bootstrap, Foundation, etc.
Ich nutze den internen liebend gern, da er mit die Generation der browserkompatiblen Anweisungen an einigen Stellen abnimmt.

Das die Seitenstruktur gekürzt wird wenn man direkt den Artikelbutton anklickt ist mir noch gar nicht aufgefallen. Muss ich mir bei Gelegenheit anschauen, ich nutze den Button selten.

Allgemein ist es nicht einfach neue Features ins System zu bekommen, besonders nicht wenn es dazu bereits eine Erweiterung gibt. Ursprünglich sollte das System ja so schlank wie möglich bleiben.
Es wurde meist bei den Konferenzen und Camps schon öfters nachgedacht das eine oder andere zu ändern, zb. die Seiten-Artikel Struktur aufzulösen.
Das Problem ist dann bei sowas wieder die Abwärtskompatibilität und das die Mehrheit der Nutzer das auch haben möchte.

Ich habe mich mit den Gegebenheiten arrangiert und nutze es so wie vorgegeben.

[Spooky]

Ich klicke das Icon ganz rechts an, um schnell zu den vorhandenen Artikeln zu gelangen.
Geht das auch anders, ohne dass mir die Seitenstruktur verkürzt wird? Oder kann ich das abstellen?

Welches Icon meinst du? Das Icon ganz rechts in der Artikelübersicht ist , das zeigt dir nur die Infos über den Datenbankeintrag an.

// achso, du meinst in der Seitenstruktur, also . Den Button benutze ich auch selten, macht aber Sinn, dass dieser Button dieses Verhalten hat. Wenn er das nicht machen würde, würde der Button keinen Sinn machen - der Button heißt ja "Edit the articles of page ID …", daher soll er Button ja auch nur die Artikel eben dieser Seite anzeigen.

[Jogibär]

Ja, beim Artikelbaum macht das schon Sinn, aber warum kürzt Contao mir auch den Seitenbaum?

[Spooky]

Ja, beim Artikelbaum macht das schon Sinn, aber warum kürzt Contao mir auch den Seitenbaum?

Habe ich schon beschrieben, wenn Contao das nicht machen würde, würde der Button ja keinen Sinn ergeben.

[Jogibär]

Naja, wie du sieht kann man da durchaus konträrer Meinung sein ;-)

Ich möchte den Button ja einfach nutzen, um schnell zu den Artikel der Seite zu springen.
Welche Veranlassung gibt es deshalb, mir zwangsweise auch den Seitenbaum zu kürzen?
Wenn ich nämlich direkt anschließend zu anderen Seiten gehen will, ist ein geöffneter Seitenbaum bei einer kleinen Website doch ok.

[MacKP]

Äh.. dann klick doch einfach auf 'Artikel' in der Navigation? Dann hast du den kompletten Seitenbaum. Der Link den du nutzt ist eben genau für den Anwendungsfall da, das man eine große Seite hat mit vielen Seiten und Artikeln. Da macht das mehr als Sinn. Alle Redakteure, denen ich das Verhalten gezeigt habe waren sehr froh über genau diese Einschränkungen. Erst recht wenn es ein Hosting ist, das nicht ganz so schnell ist und deswegen die Einschränkung unheimlich viel Zeit beim laden der Artikel erspart. Dann ist natürlich auch noch die Frage, ob bei kleinen Seiten die Redakteure überhaupt Zugriff auf die Seitenstruktur brauche.. das ist dann aber immer unterschiedlich.

Contao ist inzwischen eben ein System, was auch gehobeneren Ansprüchen genügen muß (und das auch tut). Eben nicht nur kleinen Seiten. Wenn du wirklich nur mit kleinen Seiten (oder so viele kleine Seiten) arbeitest, dann wäre eventuell ein anderes CMS besser geeignet. Eventuell sogar eins ohne Datenbank.

Wie in anderen Threads schon genügend besprochen (dazu könntest du ja mal die Suche benutzen), macht die Unterteilung mit Artikeln immer noch Sinn und ist eigentlich für viele Unumgänglich. Für kleine Seiten mag das teilweise eventuell etwas viel sein. Aber auch da finde ich es sinnvoll für Redaktuere, Artikel kopieren zu können um dann in der Kopie zu arbeiten. Das wäre ohne Artikel eben so nicht möglich und nur sehr umständlich zu Handhaben. Ich bin auch immer dafür, das man möglichst viele Content-Elemente anlegt und nicht alles in einen TinyMCE rein haut. Das mag am Anfang auch erst mal umständlich wirken, ist aber bei der Pflege einer Seite um längen besser zu Handhaben.

Viele Grüße

[Spooky]

Welche Veranlassung gibt es deshalb, mir zwangsweise auch den Seitenbaum zu kürzen?

Wenn das nicht passieren würde, würdest du nicht nur die Artikel der Seite sehen, von denen du die Artikel sehen willst - sondern alle.

[tab]

Also ich sehe dieses Verhalten auch nicht zwingend als vorteilhaft an. Dass ich das seither nicht gemerkt habe, liegt wohl daran, dass ich den Button vorher vermutlich noch NIE genutzt habe. Ich lege normalerweise beim Erstellen einer Website alle - oder zumindest die allermeisten - Seiten gleich zu Anfang an. Danach benutze ich dann fast nur noch direkt die Artikelverwaltung. Bevor die Website dann freigeschaltet wird, nutze ich dann nochmal die Seitenstruktur, um das Caching etc für die Seiten auf die gewünschten Werte für den produktiven Betrieb einzustellen. Da brauche ich dann aber keine Artikel mehr zu bearbeiten.

Den internen CSS-Editor habe ich lange Zeit fast ausschliesslich genutzt, stelle aber jetzt für neue Projekte um auf externes SCSS. Die Vorteile es internen Editors gegenüber externem CSS sehe ich wie Bugbuster in der automatischen Generierung der Anweisungen für die Browserkompatibilität und auch in den Variablen. Allerdings waren mir da immer die erlaubte Namenslänge zu kurz und ich musste immer krampfhaft nach sinnvoll abgekürzten Bezeichnungen suchen. Jetzt ist das in SCSS problemlos und die Browserkompatibilität werde ich mit Mixins auch noch automatisieren. Für media queries sind die ja sowieso genial und viel flexibler als der interne Editor, wo ja pro Stylesheet nur global ein media query eingegeben werden kann. Ich könnte mir aber vorstellen, dass der interne Editor sinnvoll weiter genutzt werden könnte, wenn man die dort definierten Stylesheets mit SASS/SCSS/LESS-Dateien verknüpfen könnte. Mit ein paar weiteren Einstellungen pro Stylesheet könnte ich mir das dann ganz nett vorstellen. Das bräuchte dann allerdings wohl einiges an Neuentwicklung und ich weiss nicht, ob es schon z.B. fertige, nutzbare Werkzeuge gibt, um die Anweisungen und Variablen innerhalb eines Stylesheets mit einer externen SASS/SCSS/LESS-Datei abzugleichen / zu synchronisieren. Da ist es dann die Frage, ob der dafür benötigte Zeitaufwand nicht an anderer Stelle sinnvoller eingesetzt ist.

[Jogibär]

Ich nutze eben gerade oft die Seitenansicht, um schnell einen Überblick zu bekommen, klicke dann auf das Icon für den Schnellzugriff auf die Artikel.
Aber lassen wir das, ist halt Ansichtssache.

Nicht falsch verstehen, ich mag ebenfalls die Einteilung in Artikel und Elemente! Gerade das bieten ja die meisten anderen CMS nicht.
Ich habe auch bereits mehrere größere Seiten umgesetzt und da ist das extrem hilfreich.

Mir ging es ja auch – neben der rascheren Erweiterbarkeit – um die Usability für eher unbedarfte User.

Wundert mich, dass alle eure Kunden noch nie Probleme hatten, die Icons auseinanderzuhalten oder zu verstehen, oder ob sie immer klar wissen, was der Unterschied zwischen "Speicher und schließen" und "Speichern und zurück" ist. Ihr müsst bedenken, dass es nicht wenige Leute gibt, die vielleicht 1-2x im Monat auf ihrer Seite etwas ändern und dann immer wieder Fragen auftauchen.
Und ja, ich gebe natürlich eine Schulung und gebe auch eine visuelle Kurzanleitung mit – trotzdem tun sich doch viele schwer damit.

Ich meinte mehr in dieser Hinsicht eine Vereinfachung des Backends, also eine Reduzierung an Informationen für den "einfachen" Redakteur.

Aber ich verstehe, dass das nicht so einfach umzusetzen ist und Contao intern über die Jahre gewachsen ist. War ja auch nur ein Vorschlag zur Überlegung für zukünftige Versionen.

EDIT: Weil es im Post oben angesprochen wurde: Den internen CSS-Editor nutze ich auch nicht, sondern nutze externe SASS-Dateien.

[tab]

Das kommt auch auf den Kunden an. Die meiseten brauchen nur einen "Redakteursaccount", da reduziere ich mitteles Rechteverwaltung das Backend sowieso schon weitestgehend. Neue Artikel oder gar Seiten können da manche gar nicht anlegen, sondern nur z.B. neue Nachrichten in einem bestehenden Nachrichtenarchiv. Da wird das BE dann schnell seeeehr übersichtlich. Will der Kunde allerdings selbst Seiten und Artikel neu anlegen und womöglich noch selbst am CSS rumfrickeln, dann erwarte ich auch, dass er sich mit der Materie zumindest etwas beschäftigt (wobei ich ihn gern mit Schulungen unterstütze). Schliesslich kann das einen ganzen Rattenschwanz an notwendigen Änderungen nach sich ziehen, je nachdem wie das Layout und die Navigation ausgelegt sind.

Edit: Sagen wir mal so: Das Findes des richtigen Buttons wird da mitunter noch das kleinste Problem sein...

[speedweb]

Hallo,
für ganz unbedarft die mit dem Backend nicht zurecht kommen, kannst du folgende Erweiterung verwenden:
Rocksolid Frontend Editing für Contao
Installiere ich eigentlich immer da diese Erweiterung für Standardbenutzer sehr Hilfreich ist, und diese im Backend nicht lange suchen müssen.

CONTAO ist genau richtig so wie es ist - wenn mann sich vernünftig eingearbeitet hat gibt es keine Probleme damit.
Kenne kein vergleichbares System das so flexibel und einfach wie CONTAO ist.
Vernünftig Einarbeiten muss man sich in jedes System, um damit erfolgreich zu Arbeiten.

Gruß Thomas

[Jogibär]

Hallo,
für ganz unbedarft die mit dem Backend nicht zurecht kommen, kannst du folgende Erweiterung verwenden:
Rocksolid Frontend Editing für Contao
Installiere ich eigentlich immer da diese Erweiterung für Standardbenutzer sehr Hilfreich ist, und diese im Backend nicht lange suchen müssen.

CONTAO ist genau richtig so wie es ist - wenn mann sich vernünftig eingearbeitet hat gibt es keine Probleme damit.
Kenne kein vergleichbares System das so flexibel und einfach wie CONTAO ist.
Vernünftig Einarbeiten muss man sich in jedes System, um damit erfolgreich zu Arbeiten.

Gruß Thomas

Ganz ehrlich, ich war auch immer Feuer und Flamme für Contao und habe es bei Projekten immer verteidigt.
Heute muss ich zugeben, dass ich betriebsblind war. Ich sage ja nicht, das in Contao alles altbacken und umständlich und in anderen CMS durchweg perfekt ist.
Man will es nicht glauben, aber alles lässt sich i.d.R. noch optimieren und verbessern, wenn man einfach die besten Ideen zusammenträgt, damit noch mehr Menschen damit klarkommen.


Zum Beispiel finde ich in OctoberCMS diesen Medienmanager vor,
3 flexible Ansichten für Detail- / Bild-Kombinationen, blitzschnelle Ordner-Erstellung und Filterung der Daten, Detailansicht (wenn gewünscht) auf gleichem Level, sofortiger Drag & Drop Upload, klare UI:
OctoberCMS-Media.jpg


PS: Die Rocksolid Plugins, zusammen mit deren Front-Editing hatte ich ja selbst erwähnt – war ja auch nur ein kleiner Teil meiner Kritik.

[tab]

Hmm, im Prinzip läuft es darauf hinaus, dass dann irgendwann mal alle CMS identisch sein müssten. Das würde natürlich die Auswahl des CMS vereinfachen . Und wenn das nicht passiert, dann nur aus lizenzrechtlichen Gründen . Wenn jedes CMS sich immer weiter "optimiert", muss das eigentlich die letztendliche Konsequenz sein. Ist halt nur die Frage, ob es auch Sinn macht und wer es bezahlt. Ideen gibt es viele, hätte ich auch reichlich davon. Aber dann überlege ich mir, wie dringend ich das wirklich brauche, ob ich das selbst realisieren kann oder wieviel ich bereit wäre, dafür zu bezahlen. Dann ist es auch meist schnell vom Tisch. Und es ist schon auch die Frage, inwiefern ein immer weiter aufgeblähter Core bei einem CMS wirklich Sinn macht. Ich habe ja jetzt schon bei den meisten Installationen einen Teil der zum Core gehörenden Erweiterungen deaktiviert, eben alle, die ich nicht brauche bei dem jeweiligen Projekt. Und man merkt das tatsächlich, wenn auch nur im Bereich von unter 10% bei den Antwortzeiten. Jedenfalls bilde ich mir das ein .

[servpoint]

Ein erfolgreiches CMS muss aber dem Fisch schmecken und nicht dem Angler. Wer vergisst für wen das CMS gemacht ist, der wird von seinen Kunden auf lange Sicht verlassen werden.

MfG Stefan

[Samuell]

Wer vergisst für wen das CMS gemacht ist, der wird von seinen Kunden auf lange Sicht verlassen werden.

Das, bzw. ein CMS muss immer dem Kunden UND dem Entwickler oder den Entwicklern (FE, BE, ... ) gefallen, sonst sind auch die mittelfristig einfach weg.

[Jogibär]

Das, bzw. ein CMS muss immer dem Kunden UND dem Entwickler oder den Entwicklern (FE, BE, ... ) gefallen, sonst sind auch die mittelfristig einfach weg.

Sehe ich auch so, wobei es am Ende wohl doch darauf ankommt, wie viel Geld ein Entwickler einnehmen kann. WordPress ist da vielleicht so ein Fall: Vielleicht intern nicht elegant, aber die Entwickler können gut davon leben.

Contao bietet ja bereits eine tolle granulare Anpassung. Meine Vorschläge der Bedienung sollten auch mehr in die Richtung gehen, dass man noch mehr Komplexität vor dem Redakteur verstecken kann und ihm eine noch bessere Hilfe für die Anpassung der Inhalte gibt. Und so etwas wie größere Schriften, Icons und Vorschaubilder ist doch nun keine dramatische Veränderung für den Entwickler, oder?

Dass z.B. das Einpflegen von Inhalten in einem Grid über die manuelle Eingabe von Klassen wenig intuitiv ist, sollte doch eingesehen werden. Rocksolid hat zwar mit ihrer Extension das für meine Begriffe bestmögliche rausgeholt, aber ich hatte für Contao 4 auf eine native Unterstützung gehofft, die die Anordnung dem Redakteur auch visuell zeigt. Platz genug wäre am Desktop ja – die Bildschirme werden immer größer, nur Contao bleibt auf 960px.


Wenn man sich hier im Forum umschaut, gibt es doch viele (wie mich) die zwischen den beiden Gruppen stehen, d.h. die zwar gut HTML/CSS können, PHP aber nur in Templates oder einfachen Funktionen verwenden können und nicht den ganzen Zusammenhang intern verstehen. Darauf zielte mein Vorschlag mit der Vereinfachung zur Erweiterung von Contao ab (z.B. dem Hinzufügen von Feldern für einzelne Elemente).
Das Beispiel aus der Praxis mit dem Wunsch nach einem Bild für den Teaser eines Artikel hatte ich ja schon erwähnt.

[speedweb]

was soll da CONTAO nicht schon lange können ???

Das Beispiel aus der Praxis mit dem Wunsch nach einem Bild für den Teaser eines Artikel hatte ich ja schon erwähnt.

das geht doch ohne Probleme...
20160103_0002.jpg

[Jogibär]

Ja, in den Editor kann ich natürlich so ziemlich alles reinhauen...
Ich rede hier von einem Eingabefeld, d.h. mit bequemer Größenwahl, Ausrichtung wie beim Text-Element beigefügt.

Durch den Vortrag von Kirsten habe ich nun dazugelernt, ich werde das mal ausprobieren. Wobei es bei einem Bildfeld wohl wieder etwas komplexer wird.

[speedweb]

denke dass sich das sicher von den News übernehmen lässt...

Nur wenn ein Redakteur mit dem Editor nicht klar kommt, heißt es aber noch lange nicht dass für alle das gesamte System umgestellt gehört.
Entweder den Redakteur schulen, oder eigene Formulare zur Eingabe erstellen. (z.B.: rocksolid custom Elements)
Lösungen gibt es für alles - wenn ein Redakteur solche Sonderwünsche hat ist der Entwickler eben gefordert - aber sicher nicht das System dafür verantwortlich.
Warum sollten sich 100e User nach Sonderwünsche eines einzelnen richten. Wenn es demnach ginge würde es ein solch flexibles System wie CONTAO erst gar nicht geben.

[Jogibär]

Die du Weil du die RockSolid Custom Elements erwähnst:
Diese Agentur zeigt doch eigentlich, welche tollen Ideen man in Contao (von Haus aus) schon hätte integrieren können, ohne dass es nachteilig oder überladen wäre (die nun integrierte Bilderweiterung für srcset's ist ja u.a. auch von denen).
Wenn ein CMS ein FAQ-, Listing-, Events- und Newsmodul von Haus aus mitbringt, kann man mir nicht erzählen, man wolle aus Schlankheitsgründen keine weiteren Ideen integrieren.
Gegen "Blogging"-Funktion wurde sich ja auch immer gewehrt, soll man halt WordPress nutzen! Während WordPress sich immer mehr zum CMS entwickelt und immer beliebter wird.

Es fehlt Contao m.M nach an Ideen oder der Fähigkeit, mal was wirklich Neues seit TypoLight einzubringen, und das finde ich halt schade!
(Ich rede nicht von Optimierungen unter der Haube und dem Update von Drittanbieter-Plugins, sondern echten Innovationen).

[Samuell]

Generell bin ich bei Dir, nicht dass Du denkst Du mußt Deine Meinung hier verteidigen.

Welche "echte Innovation" schebt Dir denn vor?

[Jogibär]

Eine meiner Hauptwünsche, wo es bei den meisten CMS eigentlich hapert (und was ich deshalb als Chance für Contao sehe, am Markt für Aufsehen zu sorgen), wäre:

eine visuelle (intuitive) Integration von komplexen HTML-Elementen und -Strukturen, z.B. dem Grid und den Elementen von Bootstrap, Foundation, etc.
Ich weiß, dass ein Bootstrap-Plugin begonnen wurde, aber das Konzept sollte m.M. nach lockerer sein, d.h. der Entwickler müsste sich das für verschiedene Frameworks oder Plugins bei Bedarf selbst schneidern können.
D.h. er definiert in ähnlicher Weise wie jetzt ein Template, jedoch mit dem Unterschied, dass er zuvor (ähnlich wie bei RS Custom Elements), Felder für dieses Element anlegen kann (am besten visuell wie beim Formular-Editor). Dieses Element könnte er für einen Redakteur freigeben und vielleicht auch bestimmte Felder darin.

Wirklich hilfreich wäre es dann, wenn der spätere Endnutzer / Redakteur einzelne Zeilen und Spalten hinzufügen könnte, die ihm visuell als Raster dargestellt werden (also einem Grid).
In diese Raster könnte er nun einzelne Elemente hineinziehen (oder durch Klick auswählen) und dort die Konfiguration vornehmen, sowie Inhalte einfügen.

Die komplexen Einstellungen eines Elementes (z.B. bei einem Slider), könnten an separater Stelle global definiert werden, so dass der Redakteur keine weiteren Kenntnisse braucht.

In WordPress gibt es solche Editoren, die wie draufgepfropft wirken und dem User auch teilweise das Design der kompletten Seite übernehmen.
Und gerade hier wäre weiterhin die Lücke für ein CMS wie Contao: Der Webdesigner kann den Rahmen vorgeben, der Kunde kann, bei Bedarf, recht einfach selbst Inhalte einpflegen.


Zudem fände ich so etwas wie "Favoriten" sehr nützlich, wie man es schon von Windows oder OS X kennt,
d.h. der Kunde möchte regelmäßig nur die Inhalte von ein paar Elementen ändern.

Als Entwickler würde ich ihm nun bestimmte Artikel oder Elemente in die Favoriten legen, das z.B. links im Menü oder auf der Contao-Startseite als Link vorliegen könnte.
Damit müsste er nicht erst lange im Artikel- oder Seitenbaum suchen und kann nach dem Login sofort mit der Inhaltsanpassung beginnen.


Taxonomie hatte ich ja anfangs schon erwähnt. Damit könnte man sich einen eigenen Stichwortbaum bauen, dann auf einfache Weise bestimmte Artikel herausfiltern und auf einer Seite ausgeben.
Die Artikel könnten dann auf der gesamten Website verstreut sein und ich könnte mit einem Klick einen Artikel wieder herausnehmen.
Gerade auf kleinen Seiten, wo es selten echte News gibt, sind auf diese Weise verlinkte Artikel rascher und differenzierter umzusetzen.

[the_scrat]

Kritiken an Contao gab es ja schon öfters hier im Forum, aber selten habe ich eine so gute und passende Kritik gelesen wie von Jogibär.

Als absoluter Contao-Fan (zwar nicht der erster Stunde, aber nun auch schon seit einigen Jahren) stimme ich dir (und das fällt mir echt nicht leicht) in so gut wie allen Punkten zu.

Contao hat vieles verpasst. Damals 2009/2010 war es -für mich- die beste Wahl. Es hatte die Innovation des Extension Repository (was in nahezu jedem anderen CMS fehlte), dazu eine saubere Oberfläche und moderne Programmierung und war Open Source. Heute, 5-6 Jahre später ist dieses Bedienkonzept allerdings veraltet, in jeglicher Hinsicht. Das Backend hat sich nicht wirklich verändert und lässt sich ähnlich "träge" bedienen wie noch 2010.

Und natürlich kann man vieles nachrüsten mit zig Erweiterungen die das Backend modifizieren, aber bis auf wenige Ausnahmen hat man dadurch auch keinen wirklichen Vorteil.

Für mich ist das Backend absolut logisch und ich kenne nach den Jahren auch nun alle Kniffe und weiß exakt was ich machen muss (was der langjährigen Erfahrung zu verdanken ist). Immer wieder stelle ich jedoch fest, dass Kunden aber weiterhin ein Problem damit haben das Prinzip Seitenbaum, Artikel, Contentelement, Dateiverwaltung auseinanderzuhalten. Und das endet dann meist in Frust, bzw. dass ich weiterhin alle Änderungen per Word zugeschickt bekomme mit dem Hinweis "Bitte einbauen auf Seite XY"..... nicht zu vergessen, das, obwohl die Kunden teilweise mehrere Stunden Einweisung erhalten (nicht am Stück, sondern immer wieder... 20 min. hier, 20 min. da). Die meisten sind halt Webseiten wie Facebook gewöhnt, Bilder hochladen, Texte einfügen etc.

Ich für meinen Teil merke auch einen massiven Rückgang der Community. Sei es durch Erweiterungen oder generell dem Support (verglichen mit 2010).

Seit viel zu langer Zeit hängen wir zwischen ER2 und Composer fest. Für Neulinge eine Katastrophe. DAS große +, die Erweiterungsverwaltung schleift sinnbildlich seit vielen Monaten so nebenher.
Ich verstehe auch viele Entwickler, die sich zurückziehen oder nichts mehr supporten. Wenn ich drank denke was ich teilweise für Forderungen (per E-Mail) erhalte. Und dabei mach ich das wirklich nur zum Spaß und muss nicht davon leben.

Ob Contao sich mehr zum AgenturCMS entwickelt, kann sein. Was das Framework von Contao3 angeht missbrauche ich es auch gerne mal für andere Dienste (ohne wirkliche Webseite), da das Framework und der Aufbau einfach genial sind und zudem "schlank".

Mir persönlich fehlt "unter der Haube" eigentlich nichts. Programmiertechnisch bin ich mit dem IST-Zustand schon sehr zufrieden. Die Oberfläche von Contao könnte sich aber mal dem Jahre 2015/16 anpassen. Bedeutet mehr Workflow auf einer Seite, ohne ständige Reloads. Automatisches Speichern wäre mal ein Anfang. Und definitv mehr AJAX. Ein perfekt zu bedienendes Backend würde evtl. sogar ein Frontend-Editing überflüssig machen. Auch wenn ich das FE-Editing von RockSolid selbst nutze weil ich damit teilweise schneller bin als mit dem schwerfälligen Standard-Backend zeigt es doch, was möglich wäre.

Ich hab keine Ahnung was sich mit Contao 4 ändert, ich habe es mir ehrlich gesagt noch nicht angesehen (nur die YT-Videos)..... aber der bisherige Tenor ist immer der gleiche, Contao 4 ist eine Baustelle. Und das, obwohl viele JETZT erstmal auf Contao3 updaten.

[neophron]

http://alistapart.com/article/managi...agement-system

[Samson1964]

ich nutze Contao/TypoLight seit ca. 2009 (ca. 2-4 Seiten im Jahr) und empfand es damals als das beste System was Ausstattung und Möglichkeiten betrifft.

Mit der Zeit habe ich Contao immer weiter selbst für meine Bedürfnisse angepasst, bin aber auch immer wieder auf die gleichen Probleme gestoßen. Inzwischen macht sich bei mir immer mehr Frust breit, habe mir deshalb schon viele andere Systeme angeschaut und ausprobiert, z.B. ProcessWire, Drupal, OctoberCMS, WordPress mit Plugins, Craft, Concrete5, darunter auch "FlatFile-System" wie Grav, Cockpit, SiteCake, Herby, etc.

Ich bin erst Anfang 2013 auf den Zug aufgesprungen, nachdem ich Jahre vorher schon Typolight entdeckt hatte. Damals sagte ich mir: Warum Typolight, wenn ich TYPO haben kann?! Okay, TYPO3 habe ich nie installiert. Außerdem war ich ein Fan von Flat-File-Systemen, insbesondere phpCMS. Irgendwann war aber auch für mich der Punkt erreicht, okay ich versuche es mit MySQL, auch wenn Backup und Restore dort aufwendiger ist. WordPress und Joomla fielen nach jahrelangen Erfahrungen wegen des schlechten Backends und der Unhandlichkeit/Unübersichtlichkeit unter den Tisch. Drupal testete ich viele Monate und war begeistert von den Inhaltselementen, allerdings auch erschüttert von der Grundinstallation: völlig nackt und alles mußte man nachrüsten. Dabei kann man auch viel falsch machen. Nach einem halben Jahr stellte ich Drupal wieder in die Ecke und überlegte: eigenes CMS programmieren oder phpCMS selbst weiterentwickeln. Doch dann entdeckte ich Contao...

1.) Recht starre Standard-Datenstruktur mit wenig Erweiterungsmöglichkeit bei wenigen PHP-Kenntnissen

Kann ich mich nicht anschließen. Ich habe zwar recht schnell angefangen, mich mit der Programmierung eigener Module zu beschäftigen, aber allein die Möglichkeiten mit dem DCA ist für Nichtprogrammierer überwältigend. Wäre ich Nichtprogrammierer würde ich das exzessiv benutzen und parallel auch MetaModels.
Da ich mich aber mit PHP ganz gut auskenne, nutze ich die Möglichkeiten eigener Erweiterungen. So habe ich gestern innerhalb von zwei Stunden schnell mal einen Webgrabber für einzelne Internetseiten aus vorhandenem Code "zusammengeklickt". Dazu noch eine eigene Klasse um den DOM zu parsen, fertig.

Z.B. keine Erweiterung des Systems (für Nicht-Programmierer) für weitere Felder oder ganze Datenstrukturen, noch nicht einmal Taxonomie wie z.B. in WordPress oder Drupal selbstverständlich. Taxonomie bietet doch so tolle Möglichkeiten bei der Filterung einer Ausgabe.

Taxonomie fehlt leider, muß ich Dir recht geben.

Einfach mal den Teaser um die Möglichkeit eines Vorschaubildes erweitern? Leider nicht ohne tiefere Kenntnisse möglich. Nutze doch ein Plugin, heißt es dann.
Habe ich gemacht, lief nur nicht mehr in der neuesten Contao-Version. Dann halt einen Entwickler engagieren!
In Concrete5 beispielsweise kann man einfach beliebige Felder zur Datenhaltung hinzufügen, z.B. wenn man auf jeder Seite ein Teaserbild ausgeben will, ohne jedes Mal ein separates Bild-Element hinzuzufügen, und es mit einer Klasse zu definieren, einfach als Basis für eine Seite festlegen.

Wie die Vorschreiber schon erwähnten, ist das über den DCA möglich. Zusätzliche PHP-Kenntnisse sind von Vorteil, wobei Du solche Codeschnipsel im Internet bereits findest oder hier im Forum gepostet werden.

Wäre es nicht toll, dem User das Anlegen von beliebigen Datenstrukturen zu erlauben? In ProcessWire wird dieser Gedanke in Extremform betrieben. Alles ist eine Seite in einem Baum, die Datenhaltung, also der gesamte Aufbau, liegt somit ganz beim Admin. Die Datenbank-Ausgabe in ProcessWire geschieht über eine jQuery artige Sprache – eine geniale Idee, damit auch Amateure damit klarkommen.

MetaModels? EFG? Hatte ich längere Zeit benutzt, bis ich relativ fit mit der Programmierung von eigenen Erweiterungen war. Danach flogen beide Erweiterungen wieder aus dem System.

2.) Keine richtige Trennung von System und Inhalten.

Zudem finde ich es schade, dass Config-Dateien, Inhaltsdateien, genutzte Plugins und Templates in verschiedenen Ordnern liegen.
Hier machen andere System es ebenfalls leichter, mit einer bewährten Basiskonfiguration umzuziehen, weil einfach alles Daten (auch die benötigten Plugins) in einem Content-Ordner strukturiert sind. Bei Updates einfach den Systemordner austauschen – fertig! Falls etwas nach einem Update nicht läuft, einfach erstmal wieder alten System-Ordner einfügen. Gerade bei Life-Systemen sehr hilfreich.

Kann ich nicht nachvollziehen. Ich finde die Struktur gut so. Alles schön getrennt, aber trotzdem in einem Ordner (DOCROOT).

3.) Teilweise umständliche Bedienung mit zu vielen Infos

Da das Vorhalten und Ändern von Inhalten nun einmal der Hauptgrund eines CMS ist, könnte man nach 10 Jahren doch mal das System hinterfragen und über den Tellerrand schauen, wie es andere CMS machen. Es wird von barrierefrei gesprochen, aber meiner Erfahrung nach haben auch ganz normale, "gesunde" Laien bereits Probleme mit der Bedienung.
Einerseits finde ich die Möglichkeiten über Artikel/Seitenelemente genial, weil sehr mächtig, gerade solche Elemente vermisse ich in anderen CMS, aber die Herangehensweise der Bedienung finde ich suboptimal.

Es sind relativ viele Klicks nötig, um an ein Element zu kommen bzw. eines anzulegen. Ja, ich kenne die Tastenkürzel, aber von einen Kunden, der alle paar Wochen mal was editiert, kann ich das nicht verlangen. Aber auch mit Tastenkürzeln bleibt das Grundproblem bestehen: Eine Überfrachtung mit (winzigen) Icons, die auch selten gebrauchte Funktionen zeigen, zusammen mit für Laien eher unwichtigen Infos, z.B. die der Artikeldaten.

Am Anfang beeindruckte mich bei Contao die übersichtliche Bedienung und die schlichte Eleganz. Das ist auch heute noch so.
Gewöhnungsbedürftig ist die Trennung von Seiten- und Artikelstruktur. Für eine WordPress- oder Joomla-Nutzer sind zudem die Inhaltselemente etwas völlig Neues. Bei einem Projekt mit -zig Redakteuren erlebt man da schon so manches:

• Artikel dienen als Nachrichtenträger, um sich dann zu wundern, das bei den Nachrichten nichts erscheint.
• Bei Artikeln wird alles in den Teaser gepackt und sich dann gewundert, daß nichts erscheint oder ungewohnt erscheint.
• Bei Nachrichten wird alles in den Teaser gepackt, Bilder per Paste&Copy dort in den TinyMCE eingefügt. Sind die Benutzer halt so gewohnt von WordPress und Co.
• Neuer Artikel dient als neue Seite, und Bearbeiter wundert sich dann, das seine Seite nirgends auftaucht.

Für den Profi ist es schön, die ganzen Möglichkeiten der Untergliederung zu haben, aber warum könnte für Laien nicht eine vereinfachte Bedienoberfläche existieren, die für 90% der Fälle ausreicht?
Z.B. sieht er die Seitenstruktur, klickt auf "bearbeiten" und kann seine Elemente der Hauptspalte hinzufügen.
Und muss man dem normalen Benutzer 4 Speichern-Buttons unter einem Element zumuten, das verwirrt doch mehr als es nutzt.

Den Unterschied zwischen "Speichern und schließen" und "Speichern und zurück" habe ich noch nicht begriffen. Nutze ich auch eher nie das "zurück".

Genauso das Neu-Anordnen der Seiten: Wer einmal Drag & Drop in anderen CMS erfahren hat, fühlt sich in Contao in der Zeit zurückversetzt. Auch wieder mehr Klicks als nötig und teilweise nicht intuitiv, z.B. Seiten als erste Unterseite einfügen (Pfeil rechts), oder Verschiebevorgang über "Ablage leeren" abbrechen.

Über Drag & Drop wurde bereits im Forum diskutiert. Soll wohl programmiertechnisch schwer umzusetzen sein. Das mit den Einfügeoptionen ist ein Fallstrick für Anfänger, aber auch mir passiert das manchmal noch. Da landen dann Seiten und Artikel an den unterschiedlichsten Stellen.

Bei der Medienverwaltung finde ich WordPress vorbildhaft: Große Bilder (auch bei Hochformat!), simple Sortierung nach Datum des Uploads, wenn gewünscht. Dazu eine Raster-Ansicht, um viele Bilder auf einmal zu sehen.

Kann ich nicht nachvollziehen. Ich finde die von WordPress grauenhaft. Ein paar zusätzliche Funktionen täten aber auch der Contao-Dateiverwaltung ganz gut, z.B. eine Suche oder Mehrfachbearbeitung.

Ich finde in Contao einfach die Sichtweise des Programmierers bzw. Profis zu dominant, der das System vielleicht jeden Tag bedient und alle Kniffe kennt.
Eine Frontend-Bearbeitung als Feature wird ja immer mal wieder im Forum geäußert – und abgeschmettert.
Hier muss ich RockSolid(Themes) mal positiv erwähnen, dessen Komponenten bei mir inzwischen zu jeder Installation dazugehören, dort gibt es auch Front-Editing.

Trotzdem ist es ein Unterschied, ob ein CMS grundlegend dafür ausgelegt wurde oder nicht, z.B. im Hinblick auf "Grids", die eine Eingabe im Backend noch weniger intuitiv werden lassen, z.B. durch die manuelle Eingabe von verschiedenen Klassennamen.

Die CMS mit Frontend-Bearbeitung haben mir alle nicht gefallen, von daher brauche ich sowas nicht. Von den -zig Redakteuren, von denen die meisten im Backend ohnehin nur wenig zu sehen kriegen, hat sich deswegen auch noch keiner beschwert.
Für Spalten nutze ich die Erweiterung simple_columns. Geht einfach und intuitiv. Mit Contao und Grids habe ich mich noch nicht beschäftigt.

[Traumkunst]

Aber wenn ich in den ChangeLogs schaue finde ich seit einem gefühlten Jahr nur Bugfixes und ansonsten ein ziemlich gleich gebliebenes System, also kein wirklicher Grund umzusteigen.

=> Muss auch nicht schlecht sein... in anderen Systemen (Shopware. Ahem.) erlebe ich z.B., dass die sich nicht wirklich zu angestrengt ums Bugfixing kümmern, dafür aber gefühlt ständig "neue Features" raushauen. Macht sich ja auch viel besser im Changelog: Wir haben wieder jede Menge mega-coole Features integriert. Hat dann auch die Presse was von. Aber der Philosophie, die "coolen Features" einfach mal coole Features sein zu lassen und sich statt dessen fokusmäßig um die Stabilität und Performance des Systems zu kümmern, kann ich für meinen Teil extrem viel abgewinnen.

für welche Zielgruppe Contao eigentlich gedacht ist [...] Nur für wirklich ambitionierte Programmierer und Fulltime-Redakteure die technisch versiert sind?

=> Witzigerweise stelle ich mir in letzter Zeit die selbe Frage. Am Anfang fand ich Contao (da noch Typolight) super, weil
• ich das Backend total aufgeräumt fand
• die Bedienung gerade auch für nicht-technikaffines Volk recht intuitiv war, dabei aber trotzdem komplexe Inhaltsseiten gebaut werden konnten (die meisten anderen CMS hatten einfach 1 WYSIWYG-Feld pro Seite => fertig. Spätestens wenn der Redakteur mal eine Tabelle bauen wollte, war mit TinyMCE Schluss. Selbst ich kann da in der WYSIWYG-Ansicht keine Änderungen an der Tabellenstruktur vornehmen und muss in die Code-Ansicht wechseln. Usw.) Alles kein Problem in Contao. In diesem Punkt bin ich also ganz entgegengesetzter Meinung.
• Als jemand, dessen Schwerpunkt nicht auf PHP/SQL-Programmierung liegt, konnte ich mit Contao auch ohne externe sehr gute Ergebnisse erzielen und komme recht weit (auch wenn ich mit Hard-Hard-Hardcodern regelm. und gerne zusammenarbeite :-)) Auch hier komme ich also eigentlich zu einer anderen Meinung und finde, dass man gerade als nicht-Hardcore-Techniker sehr einfach wirklich ansprechende Ergebnisse erzielen kann.
• Dann kam noch das Extension Repository dazu => ein Traum!

Aber es werden tatsächlich auch ein paar Entwicklungsentscheidungen getroffen, die ich ganz komisch finde. Da gehe ich jetzt im einzelnen nicht drauf ein, weiß auch nicht ob ich eine solche Stimme "verdiene"... aber ich schaue mit ein bisschen Bangen auf künftige Contao-Versionen, weil ich fürchte, dass die Ausrichtung doch zunehmend technischer, "codiger", wird. Naja, vielleicht täuscht das auch. *fingerkreuz*

Grundsätzlich würde ich mir wünschen, mit Contao "out of the box" auch komplexere Inhaltselemente anlegen und verwalten zu können. Quasi sowas wie "Meta Models", nur in einfach, stabil & vor allem intuitiv ;-) Vielleicht so ähnlich wie "Catalog" damals, aber eben im Core, um Versionsdifferenzen etc von vornherein zu vermeiden, und auch einfach so, als "Statement". Die News, FAQs, Events, etc. ... sind ja praktisch nur Spezialfälle -- es wäre schön, wenn man einfach grundsätzlich selbst Datensätze dieser Art definieren und dann über die üblichen "Liste & Reader"-Module ausgeben könnte. Das würde Contao aus dem Stand zum ultimativen Schweizer-Messer des Webdesigners machen. Aber ich weiß... träum weiter ;-)

Ach, eine ganz wichtige Sache noch, die ich zu den Contao-Pros oben zugesellen möchte:
• Die Menschen. Contao zieht eine bestimmte Wellenlänge von Usern an, die ich als sehr angenehm empfinde. Kommunikation ist möglich (keine Selbstverständlichkeit), und i.d.R. angenehm und zielführend. Keine "hingerotzten" Kommentare, keine allwissenden Gurus, die sich herablassen, anderen ihre "Tropfen der Weisheit" in Maßen zukommen zu lassen... Auf Anfänger wird nicht herabgeschaut, sondern denen wird konstruktiv geholfen. Man kann sicher Vermutungen darüber anstellen, warum das gerade hier so ist (bei einigen anderen CMS mag das auch so sein, aber ich bin ganz am Anfang durch die "Foren-Wüsten" anderer CMSse oder auch Frameworks *schüttel* *buah* da ist es teilweise echt unterirdisch). Contao verbindet Menschen, die m.E. auf einer sehr angenehmen und menschlichen Wellenlänge unterwegs sind. Vielen vielen Dank.

[Jogibär]

Danke für eure Beiträge, fand ich durchaus interessant, die Meinung von anderen zu hören.

Bei ein paar Dingen liegen wir ja sogar gar nicht soweit auseinander, wie mir scheint.

Manchmal hatte ich zwar den Eindruck, als müsste hier eine Verteidigungsrede für Contao gehalten werden, aber das wäre nicht nötig gewesen.
Vielleicht hätte ich zuvor deutlicher auch die von mir als positiv empfundenen Dinge in Contao hervorheben sollen, um nicht so viel Widerspruch hervorzurufen ;-)

Aber letztendlich ging es mir eben nicht um eine „Beweihräucherung“ von Dingen, die seit fast 10 Jahren existieren, sondern um *mögliche* Verbesserungspunkte, eher als Anstoß einer Diskussion.

Ich habe mich z.B. in den letzten Wochen intensiv mit ProcessWire beschäftigt, was aufgrund seines völlig offenen Konzeptes von vielen Entwicklern positiv aufgenommen wurde. Z.B. hat man die Funktionalität von MetaModels dort schon im Core und ist i.d.R. nur auf äußerst wenige externe Plugins angewiesen.

In deren Forum gibt es z.B. einen Bereich, wo auch intensiv und offen über Verbesserungen nachgedacht werden darf – und auch der Entwickler Ryan Cramer beteiligt sich daran, was zeigt, dass er System und Nutzer gleichermaßen ernst nimmt. Zudem berichtet er in einem regelmäßigen Blog wie es mit dem System weitergeht, warum er dieses oder jenes geändert oder hinzugefügt hat, wie man bestimmte Dinge am effizientesten löst, etc.
– Nein, es gibt hier nicht bloß „nette“ Features um auf das System aufmerksam zu machen, sondern Einfachheit, Geschwindigkeit und Sicherheit haben immer oberste Priorität. Aber es findet eben eine behutsame, kontinuierliche Weiterentwicklung statt, da *jedes* System auch immer noch besser gemacht werden kann – selbst wenn man *persönlich* vielleicht gut damit klarkommt. Ich habe mir das ja nicht ausgedacht, dass die meisten meiner Kunden sich mit der Bedienung (aus den beschriebenen Gründen) schwer tun.

Gerade in diesem Punkt empfinde ich die Entwicklung von Contao und auch die Diskussionskultur als etwas wenig offen oder sagen wir konservativ. Als wolle man als Kritik Übender eine heilige Kuh schlachten...
Dass die Community hier aus vielen netten und hilfsbereiten Menschen besteht, hatte ich übrigens nie in Abrede gestellt – und ich trenne auch eine sachliche Diskussion mit anderen Meinungen davon, also bitte nicht missverstehen.

[Traumkunst]

Ich habe mich z.B. in den letzten Wochen intensiv mit ProcessWire beschäftigt, was aufgrund seines völlig offenen Konzeptes von vielen Entwicklern positiv aufgenommen wurde. Z.B. hat man die Funktionalität von MetaModels dort schon im Core und ist i.d.R. nur auf äußerst wenige externe Plugins angewiesen.

Stimmt, das ist wirklich spitzenklasse. Ich hoffe, ich habe mal Gelegenheit, das bei einem kleinen Projekt auszuprobieren. Bisher hatte ich mir processwire nur mal schnell "trocken" in einer Testumgebung angeschaut, aber gerade dieses "Feature" mit dem Anlegen / Organisieren beliebiger Datenobjekte ist natürlich der Hammer.

[neophron]

Seit anderthalb Jahren schaue ich mir Processwire, Bolt CMS und Craft CMS näher an. Diese drei Systeme bieten eine einfache und direkte Möglichkeit, schell und einfach verschiedene Eingabefelder im Backend aufzusetzen und diese nach einer bestimmten Logik im Frontend auszugeben. In Processwire, mit dem ich gerade meine persönliche Seite aufbaue, hat man ein idiotensicheres Eingabesystem.
Contao ist perfekt für gut geschulte Redakteure, die genau wissen welche Inhaltselemente, welche Bedeutung haben.
Was Processwire angeht, habe ich jetzt einen guten Überblick bekommen wofür es gut ist und was besser mit Contao umsetzbar ist. Gerade für Katalogsysteme mit Filterfunktionen ist Processwire eine coole Sache. Die Seite »Skyscrapers« ist ein Beispiel für die Katalogfähigkeit von Processwire. Man kann sie sich als s.g. Profil runterladen und installieren.
http://demo.processwire.com
https://github.com/ryancramerdesign/SkyscrapersProfile

Eigentlich kann ich jedem empfehlen andere Systeme zu testen. So z.B. muss man in Processwire alles selber zusammenbauen, es sei denn man setzt ein html5/css3 Template um. Da man sich dort austoben kann, gibt es im dortigen Forum viele interessante Berichte zu verschiedenen css-frameworks. So bin ich auf das uikit framework gestoßen: http://getuikit.org/index.html
Man verlässt die gewohnten Pfade und findet neue Ideen.

Seitdem ich mit Processwire arbeite, versuche ich mir immer vorzustellen, wie in Contao ein »Custom Fields Builder« aussehen könnte. Einfach mit drag-n-drop schnell ein eigenes Inhaltselement zusammenbasteln, das wäre eine coole Sache. Ok, momentan gibt es die hier schon erwähnten »Rock-Solid Custom Fields«, ich hoffe, dass sie uns noch lange erhalten bleiben.

Die CMS mit Frontend-Bearbeitung haben mir alle nicht gefallen, von daher brauche ich sowas nicht. Von den -zig Redakteuren, von denen die meisten im Backend ohnehin nur wenig zu sehen kriegen, hat sich deswegen auch noch keiner beschwert.

Hat jemand von diesen Redakteuren schon mal so etwas getestet?

Wenn ich die Frontend Helper von Rock Solid demonstriere, sind die Redakteure begeistert. Auch solche, den das Contao-Backend vertraut ist. Gerade in einer Endkorrekturphase ist das Frontend Editing sehr zeitschonend. Je nach Design können die Inhalte in vielen Artikeln und Inhaltselementen verstreut sein. Von dem Geklicke werden nur die Orthopäden glücklich.

[stojovski]

Sorry, dass es so lang wurde, aber ich musste mir das mal von der Seele schreiben

Ist gar nicht lang, und Du hast alle Probleme ganz klar geschildert.
Respekt, ich liebe Contao, aber wenn ich mir die Entwicklung vom Wordpress anschaue, bin echt enttäuscht.
Habe Bücher und Video Anleitungen für Contao gekauft, das bringt mich aber mit der Version 4 nicht wirklich weiter, plugins nur über contao-manager.phar(php).
Nicht jeder muss ein Programmier sein um eine Website zu erstellen.Es ist einfach nicht intuitiv, das muss mann ganz offen sagen.
Dann können wir alle gleich Typo 3 Programmieren lernen.

Danke

[07alex07]

Ist gar nicht lang, und Du hast alle Probleme ganz klar geschildert.
Respekt, ich liebe Contao, aber wenn ich mir die Entwicklung vom Wordpress anschaue, bin echt enttäuscht.
Habe Bücher und Video Anleitungen für Contao gekauft, das bringt mich aber mit der Version 4 nicht wirklich weiter, plugins nur über contao-manager.phar(php).
Nicht jeder muss ein Programmier sein um eine Website zu erstellen.Es ist einfach nicht intuitiv, das muss mann ganz offen sagen.
Dann können wir alle gleich Typo 3 Programmieren lernen.

also Contao 4 ist nicht viel aufwendiger als Contao 3 zu installieren.
Anbei ein Video wie du es machen kannst.

https://www.youtube.com/watch?v=Ov0JTctrbSE

[Acta]

Was mir noch fehlt bei all den Themen:

Eine interne verlässliche Suchfunktion:

Wenn man einmal eine Website mit ca. 200 Unterseiten und ca. 600 Dateien aufgebaut hat, wünscht man sich nicht anderes mehr.

Beispiel: Ich habe eine Datei abcd.jpg und möchte gerne wissen wo die Datei überall eingebunden ist????
Oder einen Text auf der Website - über das Backend funktioniert das irgendwie nicht... und im Frontend auch nur für Indizierte Seiten...

Bisher habe ich dafür keine Lösungen gefunden.

[Samson1964]

Was mir noch fehlt bei all den Themen:

Eine interne verlässliche Suchfunktion:

Wenn man einmal eine Website mit ca. 200 Unterseiten und ca. 600 Dateien aufgebaut hat, wünscht man sich nicht anderes mehr.

Beispiel: Ich habe eine Datei abcd.jpg und möchte gerne wissen wo die Datei überall eingebunden ist????
Oder einen Text auf der Website - über das Backend funktioniert das irgendwie nicht... und im Frontend auch nur für Indizierte Seiten...

Bisher habe ich dafür keine Lösungen gefunden.

Es gibt für das Backend die Erweiterung [prosearch]. Darüberhinaus hatte mich vor Jahren mal jemand kontaktiert, der ein Wartungstool programmieren wollte, um all solche Probleme zu lösen, z.B. welche Dateien sind in Verwendung und wo. schachbund.de sollte als Testobjekt für die erste Version des Tools herhalten. Ich habe schon ewig nichts mehr von dem Projekt gehört.