CMS-Vergleich
Comments
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
%
123
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Still loading...
ABCDEFGHIJKLMNOPQRSTUVWXYZAAAB
1
Contao (4.x)KirbyCraftDrupalTYPO3WordPressProcessWireDein LieblingsCMS?
2
#1: Genereller Aufbau
3
Vielleicht kein wirkliches Szenario, aber einfach mal um ein paar Begriffe zu klären. Bei Contao ist das zentrale Element erstmal der *Seitenbaum*, den man definiert. Hier können Seiten beliebig tief verschachtelt angelegt werden. Die Seiten haben dann jeweils ein *Layout*, in dem mehrere *Bereiche* angelegt werden können (Header, Content, Footer, Seitenleisten, alles was man möchte).

In der Artikelebene kann man dann den Seiten *Artikel* zuordnen, die in den Layoutbereichen ausgegeben werden. Artikel können wiederum unendlich viele *Content-Elemente* haben.

*Also*: Seite -> Layout -> Artikel -> Content-Element

Artikel hängen also immer fest an der Seite, zu der sie gehören und können nicht geshared werden.

Zusätzlich gibt es noch *Module*, die direkt in Layoutbereiche gehängt oder als Content-Elemente benutzt werden können, für so Kram wie Navigationen und die Suchfunktion.

(Hier ist die Frage hauptsächlich: Wie ist diese Struktur bei anderen Systemen?)
Kirby unterscheidet sich von den hier bisher vorhandenen CMS durch seinen Verzicht auf eine Datenbank. Für die Umsetzung sind vor allem Templates, Snippets und Markdown-Dateien interessant. Dabei wird durch den Namen eine Content-Markdown-Datei festgelegt, welches gleich benannte Template verwendet werden soll. Im Template ist die Grundlogik einer Seite definiert. Hier werden z.B. Header- und Footer-Snippets (oder beliebige andere PHP-Logik) eingebunden, die so auch in allen anderen Templates verwendet werden können.

Zur besseren Organisation der Logik gibt es dann noch Controller, Page Models und Plugins. Routen (URL-Struktur) entstehen durch die Verschachtelung der Inhalte in den Content-Ordnern und lassen sich durch freie Routing-Patterns zusätzlich sehr flexibel gestalten.

Die URL-Struktur kann einfach durch Unterordner der Content-Ordner festgelegt werden (enthalten die Markdown-Dateien). Jeder Ordner steht für eine Seite. Wenn die Seite im Menü sichtbar sein soll bekommt sie einen Nummer prefix. D.h. 1-Home, 2-Contact etc.
Seiten(bäume) gibt es hier nicht. Es gibt drei Arten von Content (Section-Types):

- Einzelseiten (Singles)
- Kanäle (Channels)
- Strukturen (Structures)


Die Idee dahinter ist recht simpel: Singles für Dinge die nur ein mal vorkommen (Landingpages, Impressum, Kontakt); Kanäle für alles Chronologische (Contao: News, Events); und Strukturen für alles was Taxonomische Zusammenhänge hat (Seitenbaum / MetaModels)

Und jetzt wird es spannend: An alle Section-Types (und nicht nur an die) kannst Du eine beliebiege Kombination aus Feldern dranhängen (Build-In Rocksolid / MetaModels)

Um dann aber Unterscheidungen in Kanälen z.b. zwischen unterschiedlichen Blog-Einträgen zu machen helfen dir Entry-Types.

Zusammengefasst:
* Section-Types
* Singles
* Channels (mit Entry Types)
* Structures (mit Entry Types)
* Custom-Fields (kannst Du an alles dranhängen, auch User, Assets, ...)
Ähnlich wie in Contao, Strukturierung in Seitenbäumen.

Den Seiten sind Backendlayouts zugewiesen, in die definierten Layoutbereiche lassen sich Content-Elemente einbinden.

Es gibt verschiedene Möglichkeiten Content-Elemente redaktionell oder im Template zu referenzieren und so global oder mehrfach einzusetzen.

Funktionalitäten wie News, Blog, Ansprechpartnersuchen werden über (eigene) Extensions realisiert, die bpsw. als Content-Element auf einer Seite eingebunden werden

Bei WordPress ist das zentrale Objekt ein Post Type, der default und custom Ausprägungen haben kann. Im standard bspw. Seiten und Artikel, die über Bäume beliebig geschachtelt werden können. Seiten sind eher statisch und Artikel eher Datumsbasiert.
Der Post Type kann durch eigene ergänzt werden, die gleiche Eigenschaften, Meta Daten wie der Standard haben können, oder auch custom Meta Daten. Ebenso wird ein UI automatisch erzeigt, optional oder auch dies ist erweiterbar per API.

jedem Post Type sind optional Taxonomien zugeordnet, was die Möglichkeit von Klassifizierung in allen Ausprägungen ermöglicht.

Über diese Objekte und Zusatzdaten gibt es Standard Queries, die man beliebig zusammen bauen kann. Diese sind auch ein Manko von WP, denn die API ist hier nicht so flexibel und vor allem schnell, wie sich das manche Anforderung so wünscht. Aber das mus gesondert nach Größe und Ziel beleuchtet werden; bspw. Shop vs. Kleinunternehmerseite.
4
5
#2: Mehrsprachigkeit
6
Will man eine Seite für mehrere Sprachen fit machen, kopiert man einfach den Seitenbaum und übersetzt dann alle Artikel. Mit einem extra Plugin kann man dann die Seiten in Sprache A und Sprache B miteinander verknüpfen, sodass man im Frontend über ein Sprachwechsler-Modul dann auch zwischen “Über uns” und “About us” springen kann.

Ich finde die Lösung mit dem kopierten Seitenbaum mittelmäßig, denn wenn man die Hauptsprache noch nicht ganz fertig gestellt hat, führt das am Ende irgendwie immer dazu, dass man die Sprachversionen da immer manuell synchronisieren muss, sonst fehlt in der anderen Sprache dann eine neu angelegte Seite.

Andererseits hat dieser Ansatz den Vorteil, dass die beiden Sprachversionen auch gegebenenfalls einen anderen Aufbau haben können, oder Seiten, die in manchen Sprachversionen nicht vorhanden sein sollen.

Bei Bildern und anderen Dateien, die man z.B. zum Download anbietet hat man die auch die Möglichkeit die Meta-Daten in diversen Sprachversionen einzugeben. Für eigene Module kann man die interne Label-Funktion verwenden, die auch mehrere Sprachen unterstützt. Leider gibt es dafür dann keine Editier-Möglichkeit für den Kunden (außer man baut sie sich selber)

(Frage: Ist Mehrsprachigkeit direkt supported, und wie funktioniert sie? Werden Content-Elemente direkt übersetzt, oder kopiert man wie bei Contao den “Seitenbaum”?)
Mehrsprachigkeit lässt sich durch einfaches Duplizieren der Content-Dateien und einer Anpassung der Config-Datei herstellen.

Die Content-Dateien erhalten im Namen einen Sprachzusatz. Es gibt dann z.B. im Content-Ordner contact für zwei Sprachen zwei Dateien, z.B. contact.de.txt und contact.en.txt. Je nachdem welche Sprache autom. erkannt wurde (wenn so konfiguriert) oder welche Sprache ein Sprachwechsler eingestellt hat, bezieht Kirby die Inhalte aus der passenden Markdown-Datei.

Weiterhin lassen sich URLs übersetzen und es gibt Custom Language Variables, die unabhängig von den Content-Dateien funktionieren.
Mehrsprachigkeit ist von Haus aus eingebaut.
Du kopierst nicht den ganzen Seitenbaum sondern übersetzt direkt am Eintrag.

Einen Sprachwechsler musst Du dir aber zu einem gewissen Grad selber bauen.
Mehrsprachigkeit out-of-the-box, entweder durch Anlegen eines parallelen Seitenbaums, falls anderer Aufbau notwendig, oder durch Kopieren der Inhalte im bestehenden Seitenbaum:


- Neue Sprache wird systemweit definiert
- Übersetzung einer Seite wird angelegt
- Übersetzung der Content-Elemente
-- Kopie von Elementen mit Beibehalt der Beziehung Quellsprache -> Zielsprache. Dabei ist redaktionell nicht ohne weiteres möglich in der Zielsprache Content-Elemente anzulegen die in der Quellsprache nicht vorhanden sind. Änderungen an der Position der Content-Elemnten in der Quellsprache werden auf die Zielsprache synchronisiert
-- Kopie von Elementen ohne Beibehalt der Beziehung. Quellsprache wird als Basis genommen, Datensätze sind danach aber unabhängig voneinander. Position und Art der Content-Elemente kann von Quellsprache abweichen

Für Datensätze aus Erweiterungen analog dazu, Übersetzung des Elternknotens, dann übersetzen in Zielsprache.

Umgang mit Fallbacksprache für nicht übersetzte Content-Elemente/Seiten ist konfigurierbar
Mehrsprachigkeit ist in WP nicht vorgesehen.

Ja, das Backend und Frontend kann übersetzt werden, Standards, API sind vorhanden und unterstützen die Entwickler. Aber Content wird im Standard nicht angeboten und muss via Plugin, Custom Solution ergänzt werden. Im Sinne Contao geht das identische mit dem Plugin MultilingualPress, welches es ermöglicht die Artikel, Seiten (post Types) zu verknüpfen. So kann jede Sprache und deren Inhalte gesondert übersetzt werden.
Dies gibt ebenso die Möglichkeit Inhalte zu haben, die nicht in div. Sprachen vorhanden sind, ebenso unterschiedliche Metadaten zu Post Typen.

Möglich durch "MultiSites". Wordpress bietet MultiSites Standardmäßig an. (Quelle: https://codex.wordpress.org/Migrating_Multiple_Blogs_into_WordPress_3.0_Multisite)
7
8
#3: Einfaches Interface (für den Kunden)
9
Wenn man dem Kunden vernünftige Accounts anlegt, die nur die paar Funktionen haben, die sie auch brauchen (siehe 6.), dann ist die Oberfläche tatsächlich ganz benutzbar. Seit Version 4.4. sieht das Backend tatsächlich auch nochmal etwas besser aus. Es ist immer noch weit davon entfernt hübsch oder perfekt zu sein, aber unsere Kunden sind eigentlich relativ zufrieden damit.

(Vielleicht ist das hier zu schwammig formuliert. Frage: Kommen eure Kunden mit dem Interface klar?)
Das Interface ist sehr simpel, ebenfalls mehrsprachig und von Beginn an flexibel konfigurierbar. Allerdings sollte man bereit sein, sich mit der Markdown-Syntax auseinanderzusetzen.Das Interface ist sauber aufgebaut, auch mobil gut bedienbar und vernünftig schnell.Das Interface kann bei umfangreichen Seiten sehr langsam werden. Ist in der aktuellen Version mit PHP7 aber besser geworden. Optisch seit Version 7 beinahe hübsch.

Um von normalen Nutzern zuverlässig bedient werden zu können müssen die Zugriffsrechte sehr detailiert definiert werden. Für die Nutzer in meinem Kundenumfeld (Marketingabteilung Industrierunternehmen) ist meistens trotzdem eine Schulung notwendig.
Hier kann ich nur pos. Feedback von Kunden geben, letzlich ist es subjektiv. Neg. Einwürfe sind mir nur wenig bekannt. Aber gerade Autoren, wenig Rechte haben ein schlankes UI; responisv und Barrierarm, so dass da wenig Kritik bekannt ist.
Parallel der Hinweis auf diesen Vergleich, der das ähnlich sieht https://www.angermann.at/files/slides/CMS-Vergleich.pdf
10
11
#4: Frontend Editing
12
Am Besten ist es jedoch, wenn der Kunde das Backend gar nicht sehen muss. Das Rocksolid Frontend Helper-Plugin hängt, für eingeloggte User, an jedes Content-Element einen “Editier mich!”-Button an, der dann ein kleines Overlay spawnt, wo man die allermeisten Elemente wunderbar und schnell editieren kann. Ich selber nutze das fast nie, weil der Frontend-Helper so viele data-Attribute in den DOM schiebt, dass die Chrome Devtools immer fast abstürzen, aber die Kunden lieben es!

(Frage: Gibt es sowas?)
Dazu gibt es Forum-Diskussionen, implementiert ist es aber nicht.Craft hat eine eingebaute Live-Edit Funktion. Du hackst nicht direkt "im Frontend" rum sondern dein Editor verzieht sich auf 1/3 der Breite - den Rest nimmt die Seite an. Änderungen im Editor sieht man nahezu direkt.

Neben dem Live-Edit existiert noch die Live-Preview. Hier kannst Du Änderungen vornehmen die Du nicht direkt veröffentlichen willst (ein absoltes Pro gegenüber Contao!). Mit Token-Links können die Änderungen rumgeschickt werden und später einfach veröffentlicht werden.
Wird unterstützt, hatte ich noch nicht im produktiven Einsatz.Frontend Editing gibt es via Plugin, leider nicht nur eine Lösung, so dass man sich entscheiden muss. Es ist aber ein seltener Weg in meinem Kundenumfeld.
Parallel arbeitet WordPress gerade an einem Editor, der dies ermöglicht und zum Standard erhoben werden soll, sobald mehr als 100.000 Installationen des Plugins, so ist es aktuell zu haben, aktiv sind.
Mehr dazu findet man hier: https://wordpress.github.io/gutenberg/
13
14
#5: Eigene Content-Elemente
15
Contao bringt eine Menge Kram mit. Text, Bilder, Video, sogar Akkordeons und Bildergalerien (einiges deaktiviere ich auch direkt wieder, wie die Akkordeons, damit Contao nicht auf die Idee kommt sein eigenes Gammel-Javascript irgendwo zu injecten).

Manchmal braucht man dann ja aber doch etwas aufregenderes. Ein lustiges Diagramm, eine Auflistung der Team-Mitglieder mit abstrus komplexem Markup, was auch immer. Natürlich könnte man jetzt ein “HTML”-Content-Element benutzen und den nötigen Code da reinhauen, aber das ist natürlich nicht sehr kundenfreundlich.

Glücklicherweise gibt es dafür das Custom Elements-Plugin von Rocksolid. Da reicht es dann einfach ein Template und einen PHP-Array mit ein paar Konfigurationsoptionen (“Dieses Element hat vorname, nachname, avatar, adresse”) anzulegen und schon kann man das neue Element benutzen, wie ein normales, denn alles fügt sich ganz normal ins Backend ein.
Direkt vorhanden ist es erst einmal nicht, es gibt aber einige Plugins (https://github.com/jenstornell/kirby-plugins/labels/Plugin). Oft kommt man auch schon mit eigenen Tags (https://getkirby.com/docs/developer-guide/kirbytext/tags), die im Markdown verwendet werden können, schon sehr weit.

Im Gegensatz zu anderen CMS baut man bei Kirby das meiste dann doch selbst.
Anders als in Contao gibt es in Craft keine fertigen Content-Elemente.
Du musst dir jedes Element bauen - was beim aufsetzen des Projektes mühsam sein kann.
Es gibt hier zwar Erweiterungen die einen Export und Import der Felder erlaubt, das klappt aber nur zuverlässig wenn man keine Feldtyp-Erweiterungen wie Neo-Fields verwendet.

Auch der eingebaute Text-Editor ist im Gegensatz zum Tiny eine Wohltat. Sehr vernünftiger Markup-Output und in der Standard-Version nur mit den nötigsten Formatierungen ausgestattet.
Es gibt eine Reihe von Default-Content-Elementen (Text, Bild/Medien,...).
Komplexere Elemente werden bspw. über Flux definiert und über Fluid ausgegeben. https://fluidtypo3.org/documentation/templating-manual/introduction/flux-usage.html

In der aktuellen Version ist die Unterstützung für responsive Bilder weiter ausgebaut worden, Bildausschnitte für unterschiedliche Auflösungen lassen sich definieren und vom Redakteur auswählen.
Siehe #1
WordPress ist hier flexibel, die können via Code oder Plugins, die ein UI ergänzen, angelegt werden. Diese sind beliebig zu befüllen, zu nutzen.
Der Editor ist im Standard der TinyMCE; der aber in seiner Ausprägung, in seinen Buttons gut anpassbar ist.
16
17
#6: Spezifische Rollen
18
Oberste Ziel ist ja immer, alles so zu bauen, dass der Kunde nicht aus Versehen irgendwas kaputt machen kann. Dazu ist es natürlich notwendig, dass man die Zugriffsrechte stark einschränken kann. Manchmal soll es dann auch noch extra Redakteursrollen geben, die dann nur Blogeinträge editieren dürfen, und sonst am besten nichts anfassen.

Das kann Contao alles ziemlich gut. Man kann Benutzern Rechte auf einzelne Seiten, einzelne Module und, wenn man will, sogar einzelne Datenbankspalten geben. Eine Rolle, die nur den Titel der Startseite ändern darf? Kein Problem! Außerdem kann man auch einschränken, wo Dateien abgelegt werden können, usw. Die Admin-Seite um Benutzerrechte zu editieren hat bestimmt tausende Checkboxen!
In Kirby ist erst vor Kurzem ein sehr flexibles Permission-System dazu gekommen, mit dem eigene Rollen definiert werden können (https://getkirby.com/docs/panel/permissions)Rollen und Zugriffsrechte lassen sich extrem fein konfigurieren. Lese-/Schreibzugriff auf einzelne Datenbankspalten, Seitenbäume, Sprachen, Content-Elemente etc.

Es lassen sich Arbeitsumgebungen anlegen, in denen Änderungen in einer Previewansicht sichtbar werden. Sind Nutzer auf eine Arbeitsumgebung beschränkt, lässt sich die redaktionelle Freigabe ins Live-System über mehrstufige Freigabeprozesse abbilden.
WordPress fährt ein sehr schlankes Konzept im Sinne der Berechtigung, oft nicht ausreichend. Man kann bspw. im Standard Seiten nicht auf User einschränken, sondern die Rechte hängen am POst Type. Darf man also Seiten editieren, dann geht das über alle Seiten, nicht nur die eigenen. Dazu muss also der Einsatz eines Plugins her.
Parallel kann man aber eigene Rollen und Berechtigungsobjekte anlegen, so dass man hier Spielraum hat. Letzlich ist es aber nicht so flexibel, wie ich es mir oft wünsche, da fehlt eine schöne API.
19
20
#7: Eigene Entwicklungen / Dokumentation
21
Ein Punkt, bei dem ich mir sicher bin, dass andere Systeme überlegen sind. Es gibt zwar einiges an Dokumentation zu Contao, doch das meiste ist für die alte 3.x-Version. Vieles davon geht zwar noch, aber manche Sachen halt nicht mehr, da sich mit der 4.x-Reihe super viel ändert. Aktuell wird da gerade im Grunde das ganze Fundament rausgenommen und gegen ein neues (Symfony) getauscht — möglichst natürlich ohne das Haus einstürzen zu lassen. Für Dokumentation ist da irgendwie keine Zeit.

Dazu kommt dann auch, dass viele der Plugins für die alte Version sind und manchmal in der neuen nicht funktionieren. Manchmal schon, nachdem man zwei Zeilen anpasst und sie in den richtigen Ordner schiebt. Die Plugins kann man dann, bis auf wenige Ausnahmen, auch nicht nehmen um etwas zu lernen, da sie entweder alte Sachen benutzen, die vor Deprecation-Warnings nur so strotzen, oder einfach so schrottig entwickelt sind, dass man seinen Rechner am Liebsten sofort verbrennen würde (klassisches PHP-Problem)

Vor allem am Anfang fand ich auch immer ganz schlimm, dass sich jedes Plugin, was man selber schreibt wie ein riesiger Hack anfühlt. Wenn man sich dann näher damit beschäftigt, sieht man auch dass das alles ein mega Hack ist. In der Zukunft wird das sicher besser, da mit Symfony jetzt ja auch ein besseres System für Plugins/Bundles Einzug hält, aber ich denke es wird noch lange dauern, bis der letzte $GLOBALS[]-Aufruf aus dem Code verschwunden ist.

(Frage: Wie ist der Source / Wie fühlt es sich an Plugins zu schreiben / Gibt es gute Doku / Community?)
Es macht Spaß mit der Dokumentation von Kirby zu arbeiten, weil sie sinnvolle Beispiele enthält und für die schnelle Unterstützung auch Cheatsheets vorhanden sind. Für alle weiteren Fragen gibt es das Forum, in dem mir bisher immer nett und schnell geholfen wurde:
https://forum.getkirby.com/

https://getkirby.com/docs/cheatsheet
https://getkirby.com/docs/toolkit/api (Kirby basiert auf dem Kirby Toolkit)
Die Dokumentation von Craft war einer der Hauptgründe das nächste Projekt mal mit Craft zu probieren.
Man hatte von Anfang an das Gefühl das man schon weiterkommen wird, auch wenn es was kniffliger wird.

Die Dokumentation der Plugins ist oftmals ebenso hervovrragend. Der Slack-Channel ebenso hilfsbereit.
Viel veraltete oder falsche Doku und Erweiterungen die in aktuellen Versionen nicht mehr funktionieren. In manchen Fällen wird das stückweise durch die Verlagerung auf github und offene Kommunikation besser.

Die Extensionentwicklung auf Basis von extbase ist in Ordnung, das Templating mit Fluid finde ich ganz gut.

Die Community ist größtenteils super, teilweise ist Typo3 für die Entwickler sehr identitätsstiftend, das finde ich etwas befremdlich. Findet gefühlt zu 90% im deutschsprachigen Raum statt.
Entwicklungen, Dokumenttionen gibt es massiv, eher zu viel, auch zu viel unvalidiertes. Slack ist aktiv und hilfreich, wenn man diese Ebene beherscht. Ich höre immer wieder, bis dahin komme ich nicht, ich will lesen. Aber das hängt sicher vom Umfeld ab.

Der stärkste Pluspunkt ist die Community, sehr aktiv, sehr austauschend.

Problematisch sehe ich die Fülle von Lösungen, was ist gut, schlecht ist für den "normalen" Nutzer eher schwer raus zu finden, man muss etwas abtauchen, eine Gemeinsachft nutzen, um valide, gewartete Lösungen zu finden. Github hilft hier, da man die Wartung gut erkennt, für Nicht-Entwickler aber eine zu große Hürde.
22
23
#8: Legacy / Ausrichtung
24
Wie bei #7 schon gesagt gibt es einfach mega viele Sachen, die sich wie 2005 anfühlen und nicht wie ein modernes CMS. Wahrscheinlich gibt es noch Funktionen, die noch aus der TypoLight-Zeit dabei sind und sich kaum verändert haben.

Contao ist halt vor allem auch ein CMS für Leute, die keine Ahnung von sowas haben, sich ein CMS runterladen, für 20€ ein Theme kaufen und dann eine Webseite haben. Also Leute, die auch lieber zu Squarespace oder Jimdo gehen könnten.

Ich bin auf der Suche nach einem CMS mit dem Fokus auf Entwickler, die für Kunden Seiten bauen. Mit Unterstützung für einen modernen Frontend-Entwicklungsprozess (nein, mein CMS braucht keinen eingebauten Sass-Compiler, ich will auch im Seitenlayout keine Google Fonts angeben können und mitgelieferte Content-Elemente sollten nicht 20 Javascript-Libraries inkludieren) und einem Interface, dass darauf optimiert ist, dass der Kunde am Ende alles gut pflegen kann.
Kirby ist eindeutig ein CMS für Entwickler, die sich auf das Wesentliche konzentrieren wollen und nicht um viel Ballast drumrum arbeiten möchten. Darauf legt auch Bastian Allgeier (Gründer) großen Wert. Aktuell wird an der Version 3 gearbeitet und als Unterstützer lässt sich die Entwicklung transparent verfolgen und auf Slack diskutieren.

Der Text zu Craft nebenan könnte auch hier stehen.
Absoluter Entwicklerfokus. Heist aber auch: Du musst jede Zeile Markup und Ausgabe selber bauen. Da liefert dir Craft nichts mit. Einerseits eine Wohltat - andererseits frustrierend wenn man sich wieder und wieder durch die entrie-arrays debugged und klickt um an $element zu kommen.

Fertige Themes findest Du nicht, Frontend Plugins gibt es nahezu nicht und wenn musst Du entsprechende Libraries selber einbinden.
Durch die steile Lernkurve (sowohl für Entwickler als auch für Redakteure) und teilweise hohen Konfigurationsaufwand lohnt sich Typo3 hauptsächlich für sehr umfangreiche Webseiten. Dafür wird es dann auch mit dreistelligen Backendnutzerzahlen nicht sehr viel komplizierter.

Es tut sich ziemlich viel in der offiziellen Weiterentwicklung, dabei werden in meinen Augen ziemlich eklige Auswüchse wie TypoScript für die Websitekonfiguration immer weniger relevant und das System an sich einsteigerfreundlicher. Gefühlt wird unter anderem für die Coreentwicklung vermehrt von Eigenentwicklungen abgesehen und immer mehr auf Industriestandards zurückgegriffen.
Hier streiten sich die Gruppen. Entwickler fordern den Umbau zu modernen Code-Architekturen, andere lieben die Abwärtskompatibilität. Es passiert was, es werden mehr fähige Leute aktiv und bringen Konzepte wie Composer, OOP (solide), UNitTests ins Spiel. Letztlich bleibt aber viel Altlast, die man mitschleppt.
25
26
#9: Patternlab
27
Seitdem mir Martin das gezeigt hat, bin ich ein großer Fan von Patternlabs. Beim letzten großen Projekt habe ich das auch freudestrahlend angefangen und ganz gut gepflegt, aber das große Problem ist natürlich, dass es sehr viel Disziplin erfordert, wenn das Patternlab nicht direkt im CMS integriert ist. Leider ist es das hier nicht. Ich hab zwar mal angefangen, da ein Plugin zu schreiben, aber da schwanke ich die ganze Zeit zwischen “boah, was für ein Hack” und “boah, bringt das wirklich was? Vielleicht wechseln wir ja mal das CMS.”.Bestimmt hat dir Martin in dem Zusammenhang auch von Kirby erzählt. Da gibt es bereits ein Plugin (https://getkirby.com/blog/kirby-patterns), das aber seit drei Jahren nicht weiter gepflegt wurde.

Für Version 3 werden die UI-Komponenten aktuell mit Hilfe von Fractal (http://fractal.build/) entwickelt.
Es kann genutzt werden, da für die Erstellung des Frontend alle Freiheiten gelten, hier muss der Entwickler enscheiden wie er arbeitet. Im Stanard ist ebenso keine Templatesprache vorhanden, klassicher Mix, PHP/MArkup ist gefordert. Es gibt aber schöne Lösungen, die Templatesprachen etc. einbringen.
28
29
#10 Multidomain
30
In einem Contao kann ich soviele Seitenbäume anlegen wie ich will, die auch zu anderen Domains gehören können. kunde.de, tolle-werbeaktion-landingpage-von-kunde.de, usw. kann also alles in einem System abgefeiert werden.Ja, das ist möglich: https://getkirby.com/docs/developer-guide/configuration/folders#multi-site-setup

Mehrere Domains können auf eine Installation umgeleitet und dort mit unterschiedlichen Inhalten bedient werden.
Für Craft2 gibt es Workarounds. In Craft3 wird Multidomain-Support eingebaut sein.Wie in Contao, sehr umfangreich.Multidomain wird im Standard unterstützt, ist bspw. im Mehrsprachigkeitsscenario, siehe #2 ein Thema, da diverse Kunden pro Sprache eigene Domains supporten.
31
32
#11 Sonstiges
33
Die Flexibilität von Kirby ist beeindruckend. Überall lässt sich eingreifen und nichts steht im Weg.

Updates sind unglaublich schnell gemacht, einfach zwei Ordner (Kirby und Toolkit) ersetzen und fertig. Eigene Inhalte sind davon nie betroffen. Noch leichter geht das sogar per CLI: `kirby update` in der Shell ausführen; fertig.

Da es keine Datenbank gibt, ist auch die ganze Versionierung völlig problemlos möglich.
Ein dicker Minuspunkt bei Craft ist das fehlen von duplizieren, kopieren oder verschieben von Inhalten.Aus irgendwelchen Gründen ohne Extension bisher keine Unterstützung von Vanity URLs.

Die Systemvoraussetzungen sind für ein CMS lächerlich hoch.

Fazit: Für mehrsprachige Unternehmenswebsites mit vielen Backendbenutzern eine gute Lösung, bei Projektvolumen < 50k€ meistens wahrscheinlich eher überdimensioniert
Inhalte lassen sich beliebig duplizieren, kopieren, verschiebend -- aber nicht via Standard, dafür müssen Plugins oder Custom Solutions her, die API gibt es aber her.
34
35
#12 Sync
36
Die Möglichkeit einfach Daten / Inhaltselemente zwischen verschiedenen Instanzen (Test - QA - Live) umherzuschiebenContao kann das nicht und das Plugin, das 700€ kostet, funktioniert nur mit der alten Gammel-3.5-Version.Da keine Datenbank vorhanden geht ein Sync prima über ein .git Repository. Änderungen die der Kunde einpflegt können mit einem plugin direkt zu commits verwandelt werden.

Der Inhalt kann auch einzeln synchronisiert werden da alles in einem Ordner ("content") steckt. Z.b. via rsync.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
 
 
 
Tabellenblatt1