 in <b>/www/htdocs/w00cef8c/wp-content/themes/Working-Draft/header.php</b> on line <b>45</b><br />
https://workingdraft.de/wp-content/themes/Working-Draft/icon.png){kind=icon}
Obwohl es nicht die Kernkompetenz von Anselm, Stefan und Peter ist, waren diese Revision mal wieder Content Management Systeme dran. Dazu kommen die üblichen drei Links.
Schaunotizen
- [00:00:10] CMS, CMS, CMS!
- Cory Etzkorn hat mit Choosing the Best CMS einen langen, detaillierten Artikel über Content Management Systeme geschrieben, an dem wir uns entlang hangeln. Stefan ist ein Fan des flexiblen Craft CMS – außer richtig guten Lösungen für Mehrsprachigkeit und Content Staging fehlt es an nichts. Einigkeit herrscht darüber, dass unter den Homepage-Zusammenklick-Baukästen Squarespace der beste Baukasten ist. An WordPress finden wir besonders die Vielfalt und Flexibilität beeindruckend, speziell dass man mit sehr wenig Fachwissen sehr weit kommen kann. Während keiner von uns Siteleaf kennt, können wir umso mehr positives über Kirby (kleines textbasiertes CMS) sagen. Der nerdige statische Seitengenerator Jekyll wird gerade von Peter evaluiert, doch vor Langsamkeit und Ruby-Gefrickel wird gewarnt. Für Software-Nerds ist die Kombination von Jekyll mit Github Pages sehr zu empfehlen, jedoch ist es prinzipbedingt nicht unbedingt kundentauglich. Das gilt auch für das ähnliche Middleman, das einem noch mehr Ruby-Skills als Jekyll abverlangt. Zum Ende geben wir noch unsere gänzlich unfundierten Meinungen und Vorurteile zu Drupal, Typo3, Joomla, MODx und Perch zum Besten. Als kostenlose Geschäftsidee offerieren wir das Konzept Static Site Generator als App mit gegenüber klassischen CMS klaren Vorteilen bei Sicherheit und Performance.
[00:56:31] Keine Schaunotizen
- Investigating the overhead cost of compiled es2015
- Konkrete Zahlen zum Aufbläh-Effekt von JS-Transpilern.
- CSS Variables: Why Should You Care?
- Kurzer Überblick. Anlass: demnächst auch in Chrome!
- Let’s Encrypt Smart Renew.sh
- Damit das Zertifikat auch in Zukunft schön knackig und frisch bleibt.
Kommentare
Markus Günther #
Geschrieben am 29.02.2016 um 16:13
Oh so jungfräulich. Dabei hat der Peter viele TYPO3 Kommentare erwartet.
Ich danke euch für diesen Überblick. Als TYPO3 Entwickler schaut man zu selten über den Tellerrand. Hatte zwar auch schon MarkDown basierende CMS angeschaut, aber die Generatoren find ich persönlich da viel Interessanter.
Danke auch das Ihr TYPO3 nicht ganz so schlecht hab wegkommen lassen und das Ihr den Georg so positiv erwähnt habt, denn denke das was ihr von der Drupal Community beschrieben habt trifft ebenso auf die TYPO3ler zu. Es sind einfach ein Haufen sehr nette und engagierte Leute (wie in vermutlich vielen Open-Source Communities).
Macht weiter so!
Markus Schober #
Geschrieben am 1.03.2016 um 09:57
Wieder mal eine super Revision – macht weiter so!!
Ich muss hier aber mal ne kleine Korrektur anbringen :) Craft basiert auf dem Yii-Framework, nicht Laravel – aber das ist eher zweitrangig. Zum Thema Mehrsprachigkeit hat Craft eigentlich alles an Board. Es ist nicht so wie bei WordPress, dass man einfach ein Plugin reinschmeißt und fertig (Gott sei Dank), sondern es ist etwas Arbeit, aber überschaubar. Hier gibts einen guten Guide dafür: https://craftcms.com/docs/localization-guide
Beste Grüße aus Österreich!
Schepp #
Geschrieben am 10.03.2016 um 22:09
Dank Dir für die Ergänzung. Und beste Grüße zurück! :)
Yannick Albert #
Geschrieben am 1.03.2016 um 19:11
ProcessWire?! jQuery-ähnliche-API und so… Ansonsten: Cockpit, für Nerds mit Kleinkrambedarf (Made in Germany).
Schepp #
Geschrieben am 10.03.2016 um 22:09
Stimmt, Processwire haben wir leider vergessen. Aber wir hatten es zum Glück früher schon ein paar Mal in der Sendung beackert.
Sebastian Preisner #
Geschrieben am 10.03.2016 um 16:33
Ich würde euch auch mal ProcessWire nahe legen. Zwar habe ich nie mit ModX gearbeitet jedoch scheinen einige Parallelen zu sein da viele von dort zu ProcessWire migriert sind. (https://processwire.com/talk/topic/3691-tutorial-a-quick-guide-to-processwire-for-those-transitioning-from-modx/). Ich Arbeite nun seit einem Jahr aktiv damit und kann es nur wärmstens empfehlen da es alles nötige liefert das ein CMS benötigt und vor allem für den Frontendentwickler ein traum darstellt da es einem keinerlei vorgaben macht. Vieles das bei anderen CMS erst durch externe Plugins möglich ist lässt sich in Processwire durch Plugins vom Entwicklerteam (Coreplugins) einfügen. Caching ist direkt integriert und es unterstützt auch mehrsprachigkeit. Die Community ist nicht so riesig wie bei anderen CMS dafür aber sehr sehr hilfsbereit und freundlich.
Schepp #
Geschrieben am 10.03.2016 um 22:05
Danke für die Ergänzung! Processwire ist in der Tat ein heißes Eisen. Auch wenn die Kollegen es diesmal vergessen haben, so hatten wir es früher schon zweimal thematisiert, einmal sogar als ein Hauptthema einer Revision:
Revision 99: ProcessWire, Sueddeutsche.de und mehr und
Revision 138: Auf der roten CMS Couch
Sebastian #
Geschrieben am 11.03.2016 um 12:06
Cool, die kommen beide auf meine Playlist ;)
Sebastian #
Geschrieben am 11.03.2016 um 12:24
Übrigens, seit 2012/2013 hat sich bei Processwire einiges getan. Die Version 3.0 ist derzeit aktiv im Development und schon von Version 2.5 zu 2.7 gab es einige tolle neue features… Evtl. nochmal eine Erwähnung im Cast wert ;).
Schepp #
Geschrieben am 12.03.2016 um 10:41
Wir müssen mal wieder eine Schwerpunkt-Sendung ProcessWire machen, glaube ich :)
Tilman #
Geschrieben am 10.03.2016 um 23:02
Um an der Stelle die Brücke zum Frontend zu schlagen: Mich würde ja sehr interessieren, wie ihr, sofern das überhaupt passiert, Frontend entwickelt. Für Websites, die mit einem Redaktionssystem im Rücken betrieben werden. Wie gestaltet ihr den Umsetzungsprozess? Vor allem in Bezug auf Projekte mit mehreren beteiligten Entwicklern. Wer macht wann was, wer definiert die Struktur des Markups, etc.
BEM, Atomic Design, Pattern lab, Styleguides und all diese wunderbaren Tools versuchen doch vor allem die Organisation der Frontend-Entwicklung zu verbessern. Aber wo ein Frontend ist, da ist häufig auch ein CMS. Mit Plugins, Modulen und Erweiterungen, die häufig einen eigenen Organismus darstellen, gerne noch separate Stylesheets und Javascript mitbringen.
Wie geht ihr vor, wenn es starke Abhängigkeiten zwischen Frontend und Backend gibt? Z.B. beim bidirektionalen Austausch von Daten und nachzuladenden Inhalten. Arbeiten alle Entwickler in einem Entwicklungssystem, jeder mit einer lokalen Instanz, in einer virtuellen Maschine oder findet die Entwicklung weitestgehend losgelöst statt: Die Frontend-Umsetzung findet in einer statischen Variante (Prototyp/Clickdummy/Interface Inventory,…) statt, der Backend-Entwickler wird regelmäßig mit den Früchten dieser Arbeit beliefert und kann sie integrieren.
Was sind eure Erfahrungen, Best practices und Empfehlungen?
Christoph Rumpel #
Geschrieben am 20.03.2016 um 14:23
Hier auch mein Senf zum CMS Thema :-)
Hatte jetzt auch schon einige CMS hinter mir. Mir kommt es aber vor je mehr man sich als Entwickler weiterentwickelt desto weniger will man mit CMS zu tun haben. Die eigenen Ansprüche werden einfach immer höher und CMS können das kaum mitmachen. Bei WordPress finde ich es besonders schlimm. Deshalb bin ich seh froh dass ich immer weniger damit zu tun habe. Heißt natürlich nicht dass es für genug Leute sicher eine gut Lösung ist. Aber den Core darf man sich nicht ansehen!
Was mir noch etwas gefehlt hat ist bei Drupal die Neuerungen. Gerade Version 8 bringt extrem viel Neues mit. Der komplette Kern wurde neu programmiert ist ist jetzt auch endlich objekt-orientiert. Dazu kommt die Verwendung von modernen Tools wie Symfony und anderen bekannten PHP Packages. Gerade aus Entwicklersicht ist das extrem spannend und deshalb denk ich dass Drupal weiter wachsen wird und für große Projekte sehr interessant ist.
Danke für wieder eine interessant Episode
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.