[Meinungsaustausch] D7 vs. D8 springt Deutschland erst ab Drupal 9 auf den Zug

Das ist eine gute Fragestellung. Ich habe mich seit der ersten echten Release mit Drupal 8 befaßt. Fazit man konnte einfache Seiten damit erstellen. Es fehlten aber zu Anfang wesentliche Module und auch jetzt, 2 Jahre später, gibt es etwa zu Rules noch kein User Interface, das für einen "einfachen" Webentwickler geeignet wäre. Wer bereits komplexe Seiten mit Drupal 7 aufgebaut hat und dort eine Fülle von Modulen findet, die seine Bedürfnisse abdecken, sucht bei Drupal 8 oft vergeblich.

Dazu kommt die gestiegene Komplexität. Wer nicht gewohnt ist mit der Kommandozeile zu arbeiten, und das sind nach meiner Erfahrung eine Menge der Webentwickler, bekommt doch manche Module oder Distributionen, die zwingend den Composer voraussetzen, nicht mehr instralliert. Das ist bei Drupal 7 noch deutlich anders. Dort reicht FTP für das Aufsetzen von Seiten und es bedarf nicht eines SSH Zugangs zur Webseite (auch wenn das Arbeiten mit drush bei Drupal 7 deutliche Vorteile bringt).

Ich arbeite seit ca. 10 Jahren mit Drupal (seit dem Beginn von Drupal 6). Bei Drupal 6 und Drupal 7 hat es 5-12 Monate gedauert, bis alle wichtigen Module wieder verfügbar waren und man weiter mit reiner Konfiguration, und das ist ein wesentlicher Punkt beim Aufbau von Drupal Seiten, seine Webseiten aufbauen konnte.

Mit Drupal 8 kommt der Bruch. Kenntnisse in PHP reichen nicht mehr. Man muß sich in Symphonie als PHP-Framework einarbeiten. Das kostet Zeit und Energie. Ein Freiberufler tut sich damit definitiv schwer, denn dieser Aufwand wird nicht honoriert. Dazu kommt noch die höhern Systemanforderungen. Wie kann ich den Kunden erklären, daß, nur damit eine Seite in etwa wie vorher läuft, er höhere Hosting-Kosten akzeptieren muß. Dazu kommt, daß ich auch meinen Aufwand (s.o.) auf die neuen Seiten umlegen muß. Also muß ich höhere Preise nehmen.

Agenturen dagegen sind froh, daß Symphonie Programmierer einfacher zu finden sind. Anstatt auf die Konfigurationsfähigkeit von Drupal zu setzen, fangen sie an, benötigte Features zu programmieren. Gleichzeitig wird das Ergebnis aber als "intelectual property" der Firma gesehen und nicht mehr wie früher an die Kommunity zurückgegeben. Auch das hat dazu geführt, daß die Modulentwicklung heute nur noch schleppend voran kommt.

Diejenigen, die bisher mit Drupal auch für kleine Projekte arbeiten konnten, fragen sich, ob nicht ein Umstieg auf ein anderes CMS mit wenigen Änforderungen der bessere Weg für die Zukunft ist. Soweit bin ich noch nicht, aber ich merke auch, daß sich deutlich weniger Leute als früher für Drupal interessieren. Bei der VHS-Düsseldorf ist gerade zum zweiten Mal nacheinander ein Einführungskurs für Drupal nicht zustande gekommen.

Dries und Acquia setzen heute auf Big Business. Man will mit Drupal große Projekte angehen, die auch viel Budget haben. Kleine Agenturen und Freiberufler bleiben dabei auf der Strecke, da sie die dafür notwendige Programmierung nicht mehr leisten können. Große Projekte erforden eben viele Mitarbeiter. In meinen Augen entfernt sich Drupal damit von seinen Wurzeln in der Kommunity. Früher hieß es: "Come for the software, stay for the community!" Davon ist heute nicht mehr viel zu spüren.

Ich habe mir Drupal 8 angesehen, nachdem die stabile Version herauskam, aber erst vor ein paar Monaten versucht, ernsthaft eine größere Seite damit zu erstellen. Hat nicht funktioniert. Ein großes Problem war die nötige .csv-Migration, die sich mangels Feeds nicht vollständig bewältigen ließ. Dazu kam, dass Media ziemliche Macken hatte (kann sein, dass das inzwischen gefixt ist, da war wohl was unterwegs). Irgendwann bin ich ausgestiegen und habe das Projekt - problemlos - mit Drupal 7 realisiert. Angesichts der nachträglichen Kundenwünsche und nötigen kleinen Individualisierungen sicher eine gute Entscheidung - in Drupal 8 hätte es zu viele mögliche Fallstricke gegeben.

Überhaupt, die Dateiverwaltung. Media hat in Contrib gut funktioniert. Jetzt im Core ist es deutlich komplizierter geworden. Ist ja schön, dass man viel konfigurieren kann ... aber doch bitte nicht auf Kosten von Klarheit und Nutzerfreundlichkeit. Und dann wundert man sich, wenn die Leute zu Wordpress laufen?

Ich sehe es wie wla. Für kleine Seiten war der Aufwand mit Drupal schon bisher unverhältnismäßig groß, selbst mit einer Distribution und einer eigenen Theme-Basis. Für komplexere Seiten, wo man die Flexibilität nutzen kann, sieht man auch den höheren Aufwand ein. Allerdings nicht unbegrenzt - wenn das zugrunde liegende System zu komplex wird, als dass man sich (auch als Einzelkämpfer) mit vertretbarem Aufwand einarbeiten kann, kommt man nicht mehr klar. Denn der Konfigurations- und Theming-Aufwand wird ja auch da nicht weniger.

Ich komme vom Theming, bin aber im letzten Jahr in Symphony eingetaucht, in der Hoffnung, mich damit für Drupal 8 Modulentwicklung zu rüsten. Wenn es denn so einfach wäre ... Symphony ist eines, die Drupal API kommt aber immer noch mal obendrauf. Andererseits, wenn man sich umschaut in der Entwicklerszene, stellt man fest, dass Symphony und vor allem Laravel als Frameworks weit verbreitet sind, ganz ohne ein CMS wie Drupal obendrauf. Da beschleicht mich schon der Gedanke, ob sich Drupal womöglich selbst überflüssig macht, wenn es sich zu sehr in Richtung Enterprise entwickelt. Denn das, was Drupal gegenüber Symphony zu bieten hat, ist ja vor allem die Konfigurierbarkeit per Backend in modularer Vielfalt, und das kann man für ein Enterprise-Projekt mit weniger Ballast und zielgenauer direkt programmieren.

Ich jedenfalls schaue mich seit einiger Zeit nach neuen Wegen um. Contao mag ich immer noch gerne, obwohl es schon fast zu "groß" ist, um noch eine Alternative für kleine Projekte zu sein. Interessant finde ich Herbie für Visitenkartenseiten. Vielleicht sollte ich mich auch bei Wordpress umsehen. Oder eben ganz auf PHP- und JS-Frameworks umstellen: Symphony, Laravel, React ...

Da mit Drupal 8 die Basis verändert wurde, was generell gut ist, weil es Drupal noch vielseitiger macht, ist eine neue Lernphase notwendig.
Bisherige Module lassen sich nicht mehr mit ein paar kleinen Anpassungen upgraden, sondern erfordern oft eine komplette Neuentwiclung.
Deshalb dauert die Migration der Module sehr lange.
Einige Teilfunktionen sind anders gelöst, weshalb einige Module in der bestehenden Form nicht mehr nötig sind.
Auch das verwirrt.
Dadurch, dass Drupal nun auf Symphony basiert, können sich neue Entwickler, die Symphony kennen, schneller einarbeiten als alte Drupaler.

also ich steige mit allen projekten von d7 direkt auf joomla oder wp um. ich rate allen meinen kunden nicht mehr drupal zu nutzen.
ich werden d8 und wohl d9 nicht mehr nutzen

Leute dass hier ist das Drupal-Center irgendwie Ist die Frage da oben zwar berechtigt, aber sollten wir nicht eigentlich etwas tun, damit genau dass nicht passiert, Dass sich Menschen, die Drupal Jahre lang beim Wachsen geholfen haben von Drupal abwenden ist doch mehr als bedenklich.

Von meiner Seite aus gern, ich habe den Sprung zu Wordpress (nur mit einer Kundenseite) hinter mir und das ist für mich nicht ansatzweise eine Alternative.
Mein größeres Portalprojekt läuft auf D7 und wird das vermutlich auch noch 3 weitere Jahre tun, denn bis D9 verfügbar ist und D7 nicht mehr supported wird, vergeht wohl noch einige Zeit.

Ich kann mit meinem Projekt nicht zu D8 wechseln, da etliche Module fehlen und ich keine passenden Alternativen finden konnte.
Auf den entsprechenden Modulseiten gibt es auch keine Ansagen zu wann eine D8 Version verfügbar ist oder ob überhaupt eine kommt.

Was macht man in diesem Fall? Warten? es kann ja nicht sein, das man ein Projekt mit einem Jahr Entwicklung nicht mit Drupal 8 weiter betreiben kann, nach so langer Zeit in der D8 schon verfügbar ist.
Meine größte Sorge ist das plötzlich mit D9 begonnen wird und die Module einfach in der Luft hängen bleiben.

Mein Vorschlag wäre einen Thread zu eröffnen der sich nur mit Alternativ Modulen beschäftigt, denn die Sucherei kostet enorm viel Zeit (und testen auch). Parallel könnten sich vielleicht mehrere überreden lassen unter den entsprechenden Issues nach einer D8 zu fragen, wenn eine hohe Nachfrage da ist passiert ja meistens auch etwas.

Grüße Jenna

wir, die wir aktiv mit Drupal arbeiten, sollten über unsere Erfahrungen berichten.
Ich habe leider gerade zu wenig Zeit, aber vielleicht findet sich der Eine oder Andere und macht ein paar Videotutorials, in denen er die Unterschiede und die Vorteile zeigt.

So etwas bringt die Technik voran.

Mich freut, dass Drupal 8 nun noch deutlicher seine Datenbankaffinität ausspielt.
Jeder Inhalt ist eine entity - das ist doch ein super Ansatz.

Ganz ehrlich ich hab damit angefangen. Aber wenn ich mir die Fragen hier im Center so durchlese befürchte ich, dass man hier immer noch einigen erklären muss, warum wir plötzlich Composer verwenden, welche Vorraussetzungen Drupal neuerdings an PHP stellt, usw. Und wenn man dass dann gut gemacht hat, dann müsste man den Leuten auch gleich noch das Themen beibringen. Ein Mensch alleine kann den notwendigen content gar nicht produzieren.

genau das ist ja völlig unhandlich... kommandozeilen.. in wlechem digitaler zeit leben wir denn, daß man sowas nutzen muss?

Christian ich muss dir da leider widersprechen. Ich liebe meine Tastatur und ich habe verdammt schnelle Finger. Da kommt keine Maus der Welt hinterher. Wer Drupal immer noch über die UI bedient und seit Drupal 6 nicht mindestens einmal Drush ausprobiert hat, der wird ernsthaft nicht mehr viel mit Drupal anfangen können. Wenn wir in Drupal 8 keinen Composer hätten und die Abhängigkeiten jedes einzelnen Moduls oder gar des Drupal Core manuelle herunterladen müssten, dann würde ein Init eines Drupal Vaniella wahrscheinlich 2 Tage dauern.

So dauert ein Init aber abhängig von deiner Internet-Geschwindigkeit gerade mal 1 - 2 Minuten. Auch die Installation via Drush geht schneller von der Hand als über die UI. Das sind nur zwei Beispiele. Das Problem dass ich sehe ist eher, dass viele dass nicht wissen oder sich der Kommandozeile strikt verweigern. Weil Duglas C. Engelbart irgendwann die Maus erfunden hat und Steve Jobs dazu gesagt hat „Jungs Ihr sitzt hier auf einer Goldmine“ Das kommt dann dabei raus.

https://vimeo.com/5207683

kann man nur nicht installieren! und moderne cms sollten sowas eben per mausklick machen...
und wie kann man einem kunden sowas zumuten sein cms per noch zu erlendem skript aktuell zu halten. ein bischen der zeit hinterher

Ein gutes Thema. Und ich finde wir sollten das so stark pushen, wie es geht. Ich bin seit D6 dabei und muss nun mit D8 Drupal komplett neu erlernen. Hinzu kommen all die neuen Technologien, die verwendet werden. Es kann doch nicht sein, dass ich als Sitebuilder Drupal nicht mehr einfach installieren kann. Wie sollen denn neue Sitebuilder für das CMS begeistert werden, wenn sie sich erstmal mit durch einen Dschungel von Fremdwörtern kämpfen müssen.

Ich bin da voll bei Christian und kann ihn sehr gut verstehen. Ich hab nun auch meine ersten Wordpress-Seiten aufgesetzt, da der Aufwand unter D8 mir kein Kunde zahlt. Als Einzelkämpfer habe ich hauptsächlich kleinere bis mittlere Seiten. Alleine dafür, dass ich D8 auf einem Server installieren konnte, brauchte ich mehrere Tage, um zu verstehen, was die eigentlich alles von mir wollen. Vorbei die Zeiten einfach per FTP die Seite auf den Server zu schieben und gut ist. Hinzu kommt, dass ich auf Windows arbeite, das macht die Sache nicht einfacher.

Auf dem Drupalcamp in Essen hat der Olaf Backdrop CMS vorgestellt, das ist ein Fork vom Beginn der Drupal 8 Entwicklung. Das werde ich mir mal genauer ansehen, da es eine Weiterentwicklung von D7 ist und gerade für Sitebuilder interessant ist. Denn Wordpress ist nicht wirklich eine Alternative.

Mal eine kleine Übersicht meiner Hürden im Vergleich D7 zu D8:

Drupal 7:

• Download zip
• Entpacken
• Upload
• Installieren
• Fertig

Drupal 8:

• Download
• Entpacken
• Per FTP auf den Server laden
• Kaffee trinken gehen
• Mittagessen
• Upload bei 20% -> Abbruch
• Recherche zur Installation
• Was ist Composer?
• Wie installiere ich Composer?
• Welches Betriebssystem brauche ich dafür?
• Wie mache ich das unter Windows?
• Wie aktiviere ich das Subsystem für Linux unter Windows?
• Subsystem funktioniert nicht richtig?
• Wie setze ich eine Virtuelle Maschine auf?
• Was ist Linux und wie funktioniert es?
• Kommandozeile? Was ist das?
• Welches Linux benötige ich? Debian oder Ubuntu oder was sonst noch?
• Was ist DrupalVM?
• Warum kriege ich das unter Windows alles nicht ans laufen?

Tage später...

• Irgendwie läuft nun das Linux Subsystem unter Windows
• Keine Ahnung wie ich das gemacht hab und welche PATH-Variablen ich wo eingetragen hab und was die so machen. Aber hey: Composer läuft! Yeah!
• Recherche: Wie installiere ich D8 mit Composer richtig.
• Was ist Composer überhaupt?
• Und endlich: D8 ist installiert und läuft! Yeah!
• Aber nur Lokal. Mist, wie krieg ich das jetzt auf den Server?
• Recherche ergibt. Am Besten mit Git.
• Was ist Git? und wie funktioniert es?

to be continued.

Ihr kriegt die Idee... Da kann mir doch keiner ernsthaft erzählen wollen, dass man mit dem ganzen Prozedere Nachwuchs für Drupal begeistert.

Oh mein Gott. Danke für diese super ehrlich Antwort. Allerdings könnte man das ja auch einfach So machen.

• Virtual-Box installieren
• Linux installieren
• AMP drauf
• Drush und Composer druaf
• Drupal runterladen
• Spaß haben

.

Wenn man sich das ganze dann auch noch in ein Bash-Skript packt, dass man bei jedem Kunden wieder hervorziehen kann, dann startet man sein Skript, geht Kaffee trinken und Drupal ist fertig. Und zwar jedes mal bei jedem Kunden.

Das ist, was die Leute in der Community tun, die sich für Symphony und Composer entschieden haben. Und ich hab das oben ja schon mal gesagt. Auf der Konsole bist du einfach schneller als mit der Maus.

Da unten ganz untern in der Fußzeile hab ich übrigens meine Seite verlinkt. Mag sein, dass ich noch richtig viel zu tun habe. Mag sein, dass mit Drupal 8.5.0 und PHP7.2 alles noch schlimmer wird. Aber an Beiträgen wir deinem sehe ich einfach, dass es Zeit wird. Drupal neu aufzurollen. Wenn zusehen mehr hilft als lesen, dann sollten wir einfach wieder mehr Videos machen. Wie in den guten alten Tagen von Drupal 6 Und damit meine ich tatsächlich uns, das Drupalcenter. Offensichtlich ist ja Bedarf da.

Ach und der Nachwuchs fühlt sich wohl eher wie Neo in der Matrix, wenn er unter Anleitung mit Linux herumspielen darf. Wobei die Betonung natürlich auf Anleitung liegt. Hart ist das wirklich nur für Alle, die Drupal 7 bis jetzt gewöhnt waren. Neueinsteiger kennen das Vorher nicht und benutzen hoffentlich auch keine Maus :-) Aber selbst Dries sieht das Problem ja

Wie du kannst kein Drush installieren. Drupal auf einem Shared Server zu betreiben ohne SSH-Zugriff und eigene Ressourcenkontrolle grenzte ja schon zu Drupal 6 Zeiten an glatten Selbstmord Also zumindest, bei entsprechender Anzahl aktivierter Module.

Da kann ich so also nicht nachvollziehen.

Sobald ich hier im Center auch nur irgendwas von Shared-Hosting in Verbindung mit Drupal lese, sitze ich weinend vor dem Bildschirm und dass ist jetzt kein Problem, dass mit Drupal 8 erst neu hinzugekommen wäre. Außerdem ist der Installer ja durchaus noch da. Wenn man Ihn unbedingt braucht.

Aber auch für die Web-UI muss der Server gewisse Abhängigkeiten erfüllen. Warum also nicht gleich alle erfüllen und für dich als Entwickler ein angenehmes Arbeitsumfeld schaffen, in dem du Drupal einfach mal mit drush up aktualisieren, einen Kaffee trinken und wieder zurückmummen kannst, wenn die Aktualisierung abgeschlossen ist. Das ist doch super! Meine Kunden würde ich übrigens auch nicht auf die Kommandozeile lassen, da bin ich ganz bei dir!

Dazu braucht es einen eigenen Server, den muss man pflegen

Na ja zum Autofahren brauchen die meisten auch ein eigenes Auto. Ich verstehe dich durchaus. Aber ganz ehrlich um Drupal zu lernen reicht virtualbox und wenn du das mal gelernt hast, dann willst auch nicht mehr ohne eigene Server Ach ja ich hatte ja noch den Link von Dries https://dri.es/three-ways-we-can-improve-drupal-evaluator-experience

Gerne. Und da hab ich noch ein Menge weggelassen... ;-)

Und ja, das kann man so machen. Hab ich auch schon öfters gelesen. Theoretisch funktioniert das ganz wunderbar. Aber wenn man als Windows-User bis dato noch keine Berührungspunkte mit der Linux-Welt hatte, dann ist das eine enorm große Hürde. Hab ich alles schon versucht. Nur leider kommt immer irgendwann der Punkt, an dem irgendwas nicht funktioniert. Drush habe ich auch in einer VM nicht vollumfänglich zum laufen bekommen. Und nach stundenlanger Lösungssuche, geb ich dann leider auf. Zusätzlich zu allen neuen Begriffen und Fremdwörtern, die man dann bei seiner Lösungssuche nachschlagen und verstehen muss, kommt dass es alles auf Englisch ist. Kaum eine hilfreiche Anleitung ist auf deutsch. Das macht es nicht einfacher.

Und was leider auch die/meine Realität ist, ist dass man von der Community leider mittlerweile auch ein tendentiell eher genervtes Schulterzucken bekommt, wenn man nur erwähnt, dass man Windows-User ist. Das war zu D7 Zeiten auch anders, weil es in 90% der Fragen unerheblich war, auf was man arbeitet, da man auch ganz gut auf Drush verzichten konnte, so wie ich. (ob das sinnvoll ist, ist auch eine andere Diskussion)

Ich denke eine (deutsche) Anlaufstelle für Neulinge in dem Bereich wäre schon extrem hilfreich. Wie du sagst, mehr Videos, aber eben auch der unvoreingenommene Austausch. Bin da gerne bereit mitzuwirken.

PS: Bin übrigens der_wilko ausm Drupalchat.

Siehst du, so klein ist die Welt.

Ich sehe das Problem ja durchaus. Und ich muss auch ganz ehrlich zugeben, dass ich mich seit Windows 10 mit keinem Subsystem mehr auseinandergesetzt habe oder gar drüber nachgedacht habe, dass es echt noch Menschen gibt, die zum Entwicklen im Web Windows verwenden. Ich war windows Insider und für mich ist windows in Verbindung mit einem Webserver so anstrengend geworden, dass es einfach wesentlich schneller geht Linux zu installieren und einen kompletten Server mittels SSH-Verbindung zu deplpyen, als zu versuchen Windows beizubringen Drush und Composer global auszuführen oder gar das Linux Subsystem zu nutzen. Aber ich glaube es ist an der Zeit mal wieder etwas Spaß zu haben und nachzusehen, ob man Drupal nicht vielleicht doch auf Windows zum Laufen bekommt mit XAMPP und so. Das würde zumindest Inhalte für mein kleines Projekt schaffen.

Auch wenn alleine Drush aufzusetzen unter Windows schon eine echte Hausnummer ist :-D Hast du ja hoffentlich inzwischen gesehn

Ich habe den obigen Thread hier nur überflogen. Aber da es z.B. auch um Drush, Composer, Symfony, Git usw. ging sowie Joomla und Wordpress als Alternativen zunächst mal ein paar Stichpunkte dazu:
Auf der Symfony-Seite wird darauf hingewiesen, daß auch Joomla inzwischen Symfony-Komponenten nutzt. Ich weiß zwar nicht wo die Wordpress-Reise hingeht, kenne aber Leute, die sich bemühen auch Wordpress immer mehr auf moderne Beine zu stellen. Die haben sich z.B. von Drush inspirieren lassen und WP-CLI entwickelt, wodurch für mich Wordpress überhaupt erst ernsthaft supporten lässt.

Ja, einen eigenen Server muss man pflegen. Aber Nein, den braucht man nicht unbedingt. Ich habe hier im DC z.B. auch mal eine Anleitung gepostet, wie man Composer bei Hosteurope zum laufen bringt. Aber ohne SSH Zugriff und z.B. Zugang zu MySQL per Commandline würde ich den Betrieb jedes CMS, egal ob Wordpress, Backdrop usw. problematisch finden, da Server-Verwaltungstools schnell mal an Ihre Grenzen stoßen können. Wer Drupal oder irgendein anderes CMS selbst pflegen möchte, sollte sich meiner Meinung nach aneignen, wie man dieses nach dem aktuellen Stand der Technik ordentlich organisiert mit Drush, Composer, Git und Co. Ansonsten gibt es dafür auch entsprechende Dienstleister, die das können ...

Oh, versteh mich nicht falsch, das sollte keine Arbeitsaufforderung sein... ;-)

Dann hab ich mich falsch ausgedrückt. Mir geht es nicht darum, Drush auf Windows zum laufen zu kriegen, sondern darum Anfängern den Einstieg in eine Drupal-Entwicklungsumgebung zu erleichtern. Denn, und das ist eigentlich was ich sagen wollte, als Windows-User habe ich bislang keine Berührungspunkte mit der Linux-Welt. Und ich empfinde sie auch nicht so selbsterklärend und einfach, wie es immer dargestellt wird.

Deine Videos sind, ohne sie schon angeschaut zu haben, wahrscheinlich genau die richtige Richtung. Sobald ich Zeit habe, führe ich sie mir zu Gemüte. Und wer weiß, vielleicht klappt's ja dann endlich mit Drush und mir... ;-)

Die Frage ging zwar nicht an mich denke ich. Aber ich verstehe das Problem. Als Windows-User hat man ähnlich wie der durchschnittliche Mac-User zunächst mal kaum Kontakt zur Commandline. Da geht reinen Linux-Gui Usern dann auch so. Aber in der Windows-Welt hat man zusätzlich das Problem, daß es keinen Unix-Unterbau gibt, abgesehen zu diesen neuen Sub-System zu dem ich nicht viel sagen kann. Es gibt aber ein paar grundsätzliche Problem, die fast alle betrifft: Und das sind Unterschiede zwischen Entwicklungs-Umgebungen und Ziel-Systemen, selbst wenn mal mit Linux entwickelt. Oft reicht es aber, wenn eine ausreichend große Ähnlichkeit vorhanden ist und das bekommt am ehesten mit virtuellen Systemen hin, die man allerdings heutzutage nicht unbedingt komplett selbst konfigurieren muss. Einen guten Einstieg in das Thema ist z.B. das DrupalVM Projekt von Jeff Geerling: https://www.drupalvm.com/

Ja und dann hast du wieder das Problem, dass die Drupal-VM komplett englisch ist und dass gerade Einsteigern die Hürde, zusätzlich auch noch englische Dokumentationen zu wälzen, genommen werden sollte.

Versteh mich bitte nicht falsch, ich kann englisch und ich Übersetze den Core wie ein Verrückter.

Aber genau da ist doch der Punkt Es macht sich einfach keiner mehr Gedanken um all die Hobbyisten und Freiberufler, die halt blöderweise keine 1 in Englisch hatten und Drupal trotzdem toll finden.

Darum entscheidet sich meiner Meinung nach auch keiner mehr für Drupal. Es fehlt an kostenloser Eduction, die einfach nachzuvollziehen ist, was die Grundlagen angeht, seit es Drupal 8 gibt und zwar ganz gewaltig.

Von Themen für Experten wie Themeing oder gar Modul-Programmierung will ich gar nicht reden.

Überm Teich machen Firmen wie Drupalize.me und Ostraining.com sowie Frelancer wie Buildamodule.com Geld damit Drupal einfach und verständlich zu erklären. Und für die Menge an Inhalten sind die Damen und Herren echt nicht teuer.

Hier in Deutschland gibt's das Drupal Center in dem aktuell mehr Menschen offen zugeben, dass Sie zu Wordpress laufen, statt konstruktiv zu überlegen, was man gegen diesen Trend tun kann und wie man die Community dabei integrieren kann. Ich wage einfach mal zu behaupten, dass dir das so mit Wordpress in Richtung Drupal nicht passieren würde. Einfach, weil wir die Probleme nicht lösen, die Drupal-Interessenten haben. Und dass größte Problem dabei ist nicht, dass Drupal plötzlich so kompliziert geworden wäre, sondern, dass es einfach niemanden mehr gibt, der Drupal wieder einfach machen will, weil wir uns im Grunde damit abgefunden haben, dass es ist wie es ist.

Hi, eigentlich bin ich relativ passiv hier im Forum. Ich schlage aber mal eine Lanze für Drupal 8. Versteht mich nicht falsch, aber manche Begründungen gegen Drupal 8 kann ich hier nicht nachvollziehen:

Die Installation
Also ich weiß nicht, was ihr so macht. Aber bei mir dauert eine einfache Installation von D8 genauso lange wie die bei D7. Composer muss man ja auch in der Regel nur 1x installieren und dann läuft es. Falls mal was nicht läuft, gibt Google innerhalb kurzer Zeit eine Antwort. Und versteht mich nicht falsch, ich bin kein Entwickler, sondern einfacher Sitebuilder. Tipp: Versucht die aktuellste Version von D8.x zu installieren, hier ist im Vergleich zu den anfänglichen D8-Versionen, nochmal vieles verbessert worden.

Kurz: Man muss sich halt ab und zu mal zwingen, seine eigene Komfortzone zu verlassen und sich neuen Herausforderungen und neuen Techniken zu stellen.

Die Module
Eine Begründung teile ich aber mit allen: Rules & und viele andere Module fehlen noch und lassen es nicht wirklich zu, ein komplettes funktionierendes D7 Projekt auf D8 fahren zu lassen. Ich bin aber guter Dinge, dass sich das hier bald ändert.

Drupal 8 hat viele Vorteile
Und BigPipe ist eines davon. Auch die verbesserten SEO-Settings bei der Artikel und Seitenerstellung finde ich gut. Die aufgeräumtere Menüstruktur im Backend und das Theming finde ich einfacher. Und beim Theming müssen wir alle mal ehrlich sein. Soooo groß sind die Umstellungen nicht, im Gegenteil -es ist meiner Meinung nach mit Twig einfacher geworden. Die Portierung von D8 auf D9 soll wesentlich einfacher sein.

Versteht mich nicht falsch. Ich mag nach wie vor D7. Aber eine neue Website würde ich nicht mehr mit D7 anbieten. Und Wordpress ist für mich keine echte Alternative für Firmenwebsites.

also ich habe mal bei backdrop geschaut. das wird wohl mein drupalersatz werden...
ein protierung von d7 zu d8 ist auch ziemlich umständluich und aufwendig. und ich habe mal getestet eine etwas aufwendigere siete direkt mit dem d8 tool zu migrieren. da siwrd mri schon gesagt, daß module fehlen, die aber in d8 aktiv sind. also voller fehlermeldungen, die es gar nicht geben dürfte. und nach migration waren kein views mehr da, und felder nicht. also echt mies!

...vielleicht sollte ich noch sagen, dass ich Windows 10 User bin. Und ich komme mit XAMPP und der Shell eigentlich ganz gut klar. Und für die Portierung auf einen anderen Server ist GIT nicht erforderlich. Wäre schön, aber es geht natürlich auch ganz klassisch ohne via FTP und MySQL-Import.

Ich bin auch ein Einzelkämpfer, der sich ehrenamtlich durch den Drupal-Dschungel quält. Ehrlich gesagt, finde ich den Ansatz soooo schlecht nun nicht, der gewählt wurde. Es stört mich zwar einiges immens (darunter die schon angesprochenen fehlenden Anleitungen auf Deutsch, wobei ich da nicht so ein Videogucker bin, denn das ständige Videoanhalten und spulen nervt mich mehr als das Lesen), aber mit Durchwurschteln komme ich ja weiter.
Viel schlimmer finde ich, dass es an Erklärungen mangelt. Warum stelle ich bei den Kontextfiltern etwas so ein, warum, wenn der Wert nicht in der Liste ist, usw. Was genau passiert da in der Datenbank im Hintergrund. Da fehlt mir das Verständnis und das ist auch genau mein Problem. Wenn ich etwas grundsätzlich nicht verstanden habe, habe ich Schwierigkeiten, obeflächlichlichem "Klicken Sie hier, jetzt hier, tragen Sie hier den Wert XY ein..." zu folgen. Wenn ich das mache, bekomme ich genau das Ergebnis, das der Video- oder Blogbeitrag zeigen möchte, aber eben genau nur das.
Da ich jetzt keine Hotel habe oder Marathon-Anmeldungen verarbeiten möchte, sondern auf einer Schulhomepage lediglich einen View für alle Unterseiten machen möchte, habe ich schon verloren, weil ich das Grundgerüst schon nicht verstanden habe.
Ich glaube, dass es hier am meisten fehlt.
Übrigens geht mir das bei CSS genauso. Ich weiß nicht, wie oft ich schon Selektoren gegoogelt habe... und nach einigem Hin- und Herprobieren erst mein Firefox Developer die richtigen Einstellungen gemacht hat. (Lag es nun am DIV-Padding oder a-Margin, usw... Das haut eigentlich in die gleich Kerbe, auch wenn ich dafür gleich Schelte kriege, dass ich das NICHT kann...
Nachdem ich aber verstanden habe, wo man beim Theming den Hebel ansetzt, klappt das schon deutlich besser. Das gefällt mir erheblich besser als bei Drupal 7, oder ich verstehe jetzt mehr davon. Wer weiß.
Übrigens läuft die aktuelle Schulhomepage auf der Webspace eines Shared Hosters ohne Drush und ohne Performance Probleme (bisher)... Mal sehen, wie das aussieht, wenn erstmal die Inhalte reinkommen...
Mein Plädoyer: Leute, gebt nicht auf. Ich werde hier weiter Fragen stellen und hoffen Antworten zu erhalten, die ich verstehen kann. Und werde auch versuchen, laienhaft Antworten zu geben, wenn jemand noch weniger Plan hat als ich.
LG,
Highman72

Dass die Schulhomepage gehackt worden war, habe gottseidank nicht ich zu verantworten... War eine Typo3-Site... steinalt und unflexibel. Sollte ja schon länger zu Drupal und jetzt halt im Hauruck-Verfahren....

Drupal ist ein riesiges Ökosystem, es gibt Module für alles und jedes, zumindest fast, und da kann man nicht erwarten, dass es für alles eine perfekte Anleitung gibt, nicht mal auf drupal.org, schon gar nicht außerhalb des englischen Sprachraums. Auf drupal.org gibt es eigentlich sehr viel - aber wenn man eine Verständnisfrage im Detail hat, fehlt es doch oft.

Views ist ein gutes Beispiel. Ich habe mir lange alles angeschaut, was es zum Thema gab (ich bin ja auch schon seit 2009 mit Drupal unterwegs), und habe trotzdem lange einige Details nicht verstanden, z.B. wofür die Select-Einstellung in den Relationships "muss die relationship xy haben" gut ist. Irgendwann fiel der Groschen, dass man damit verkettete Abhängigkeiten bauen kann. Aber sowas erzählt einem ja keiner ...

Zu D6-Zeiten gab es Mustardseedmedia, von seinen Videos habe ich viel gelernt. Später kam Johan Falk mit den grandiosen Serien zu Views ("Taming the beast"), Rules, Panels u.a. Diese Serien waren so strukturiert aufgebaut, dass sie sicher für viele Drupaler eine Erleuchtung waren. Irgendwann verließ Johan Falk Node One (ging er nicht zurück in den Schuldienst?) und einige Zeit später ging Node One in Wunder (damals Wunderkraut) auf. Spätestens da war ein Großteil der Videos nicht mehr auffindbar. Nur noch ein kleiner Teil war über die Wunder-Seiten zu erreichen. Vimeo hat leider eine grottige Suchfunktion, aber ich hatte den Eindruck, dass die Videos ganz weg waren. Warum konnten die der Community nicht erhalten bleiben? Selbst für D8, vielleicht sogar noch D9, könnten die Tutorials Einsteigern helfen, die Grundstruktur besser zu verstehen. Die ändert sich gerade in Views, Rules und Panels sicher nicht so drastisch.

Ganz schwierig wird es, wenn man lernen will, wie Drupal unter der Haube tickt. Antworten zu Einzelfragen findet man in Issue queues, Stackoverflow, Drupal Answers usw. via Google. Aber der große Zusammenhang fehlt leider oft. Da wüsste ich gerne mehr Strukturelles.
Auch wieder ein Beispiel: Ich musste im Workflow-Formular eine Reihenfolge umstellen. Ich habe mir per kpr() den Aufbau angesehen, meinte, mit hook_form_alter alles richtig erfasst zu haben ... aber es tat sich nichts. Nach langem Weiterforschen die Lösung: Workflow kommt erst vorbei, wenn hook_form_alter längst durch ist. Man musste es anders angehen, dann hat es auch geklappt.

Warum ist es so schwer, an fundierte und gut aufbereitete Informationen darüber zu kommen, was wie funktioniert und programmiert werden muss? Warum muss man sich alles aus kleinsten Puzzleteilen zusammensetzen? Was muss ein Modul haben jenseits der "Anmeldung", wie findet man die passenden Hooks, wie sucht man danach (ja, ich kenne die Suchfunktion in der Referenz, das meine ich nicht)? Ein ähnliches Modul umarbeiten ... ja, hab ich gerade bei einem kleinen Plugin gemacht. Abendfüllend ist das leider auch nicht. Ob Bücher oder Videos, meistens ist nach create/edit/view/delete und ein paar Menu- bzw. Routing-Basics Schluss bzw. die Beispiele sind so simpel, dass man davon nicht mehr viel ableiten kann.

Mit Blick auf D8 habe ich mir ein paar Monate drupalize.me gegeben. Die erklären schon gut, aber auch da hatte ich das Gefühl, dass im fortgeschrittenen Bereich, wo es ans Programmieren geht, viel zu früh Schluss ist. Also habe ich es wieder gelassen. Später habe ich einen weiteren Versuch mit OSTraining gemacht. Katastrophe. Ein kleiner Kurs zu D8, und der bestand hauptsächlich aus dem (überspitzt gesagt) monotonen Vorlesen einer Powerpoint-Präsentation. Viel zu abstrakt, viel zu weit weg von der Praxis.
Schließlich habe ich den Symfony3-Kurs bei KNP-University durchgearbeitet. KNP sind wirklich zu empfehlen. Die Erklärungen sind verständlich, die Beispiele mit Humor und gleichzeitig praktisch zusammengestellt, und man bekommt für 30 $/Monat alle Unterlagen: Video-Download, wörtliche pdf-Transkripte mit Screenshots und den Code. Da mir das ganz normale Leben dazwischen kam, habe ich noch nicht alle Einheiten ganz nachgearbeitet, aber dort habe ich das Gefühl, wirklich was gelernt zu haben.
Aber beim D8-Kurs hatte ich selbst bei KNP den Eindruck, wieder etwas im Vagen gelassen zu werden. Keine Ahnung, warum das so ist.

Genau so etwas ist es, was ich zu finden suche in einem Forum wie diesem. Eben schon mit klick hier und klick da, aber eben auch mit warum. Genau das hätte ich im Übrigen bei meiner letzten Site gebraucht, vielleicht auch bei dieser, allerdings halte ich den Groschen irgendwie immer noch verdammt fest...

LG,
Highman72

Die Videos liegen bei Wunderkraut Schweden, dort sehr gut aufgelistet und über Vimeo anzusehen.

https://digitalist.se/blogg/learn-drupal-7-wunderkraut

Grüße Jenna

"Selbst jetzt, wo Drupal 8.5.0 nur noch ein paar Wochen entfernt ist gehen hier im DC mehr Fragen zu Drupal 7 als zu Drupal 8 ein"
Warum wundert das?
Wie viele Drupal 7 Seiten sind da draußen im produktiven Einsatz unterwegs und wie viele Drupal 8-Seiten?
Von den vielen D7 mittelgroßen Seiten, die ich selbst betreibe oder für Kunden betreue, können die wenigstens eben mal so auf D8 portiert werden.
Wenn ich eine relativ einfache Seite neu aufsetze, dann gerne mit D8.
Da wähle ich von vorne herein andere Strategien und fühle mich damit sicher.

Aber bin ich jeck und schlage einem meiner Kunden vor, sein laufenden Projekt auf D8 umstellen zu lassen?
Da sind teilweise viele Module im Einsatz um individuelle Unternehmens-Prozesse abzubilden und vor allem zu vereinfachen.
Wenn man das nun neu aufsetzen wollte, müsste man einen Großteil der Funktionen selbst programmieren.
Das sind Firmen, die ganz sicher das Geld nicht haben, alles neu programmieren zu lassen.

Drupal war gedacht, Geld zu sparen bzw. zu verdienen und das funktioniert auch seit vielen Jahren,
Womit soll ich also zum heutigen Zeitpunkt eine derart aufwändige Umstellung rechtfertigen?
Ich will hier nicht in die Reihen derer einstimmen, die nur herziehen über D8. Das will ich sicher nicht. Dazu ist es stellenweise viel zu smart.
Aber es ist unterm Strich ein komplett anderes System.

Ich kaufe ja auch keinen E-Sportwagen, dessen Funktionen noch nicht ausgereift sind, solange mein Skoda noch fährt - mit der Begründung, in zwei Jahren wird dieser Skoda nicht mehr weiter entwickelt.
Sondern ich werde mich zu gegebener Zeit - also bevor mein Skoda nicht mehr fährt oder es keine Ersatzteile mehr gibt - nach einem adäquaten Ersatz umtun.

Genau das haben manche Kunden gemacht, als es Zeit war, sich von D6 zu verabschieden, aber D8 noch keine Alternative war. Sie haben sich nach adäquaten Ersatz umgetan, z.B. TYPO3.
Und zwar nicht mit mir, weil ich aus gutem Grunde vor fast ca, 8 Jahren (oder vielleicht auch schon 10) von TYPO3 auf Drupal umgestiegen bin und das nicht mehr anbiete.

Also bitte nicht darüber wundern, warum es so ist, sondern versuchen, die Zielgruppe zu verstehen, die bei D7 eine ganz andere ist, als bei D8.

Kissmedve schreibt

Stimmt, kommt mir auch so vor. Es gibt Grundlagen zu D8, die hat man sich ja auch schnell angeeignet. Danach wird es schwierig mit Tutorials und Büchern.
Das war früher besser.
Das liegt z.T. am Zeitgeist und daran, dass es sich nicht rentiert, Bücher für so eine mikroskopisch kleine Zielgruppe zu schreiben.
Aber führt natürlich auch dazu, dass manche Leute sich schwer tun, in D8 tiefer einzusteigen.

Da schau an. Als ich zuletzt gesucht hatte, hießen Wunderkraut Schweden noch nicht Digitalist. Na, immerhin. In der Liste scheinen zwar Views, Rules und Panels nicht dabei zu sein, aber sie werden einem auf Vimeo in der Seitenleiste angeboten. Freut mich, dass Wunderkraut Schweden offenbar etwas nachgelegt hat. Da wird die Übersichtsseite mit den großen Serien vielleicht auch noch irgendwo sein ...
Danke für den Tipp!

Vielen Dank ihr lieben, für all diese tollen Antworten an einem Montag. Am schönsten bringt es doch missingdot auf den Punkt. Dass sollte man bis zur Drupalcon in Nashville fast übersetzen oder daraus ein Video machen. Ja ich habe eine Idee davon, was du meinst und ich sitze hier mit einem lachenden und einem weinenden Auge. Wenn demnächst alle Fragen hier mit so viel Engagement, Humor und gleichzeitiger Ernsthaftigkeit beantwortet werden, dann bekommen wir noch den Splash Award für die Beste Community aller Zeiten.

Unser Feedback hat nicht nur hier Anklang gefunden, sondern auch auf Drupalchat.eu Genauer bei https://www.drupal.org/u/baddysonja

Sie würde unser Feedback gerne in Form einer Zusammenfassung mit nach Nashville zur Drupalcon nehmen. Das bedeutet auch, dass noch mehr Feedback durchaus willkommen ist, bevor wir das Ganze zusammenfassen)

Ihr abschließender Kommentar für heute

Baddý Sonja Breidert @baddysonja 22:22
@Jo it would be very appreciated if you could somehow take the feedback and create a summary of:
* Identify the problems (too complicated for D7 sitebuilders because ..., ..., .... )
* Collect suggestions (....)
And then just share it with me via google docs
then we can potentially send the same document (without our answers) to other local communities (FR, ES, BE, NL, DK, ..) and ask them to fill it in too. Then we can see if we all have something in common
Most important try to bring some solutions on the table, what can we do to fix it. How was it done back in the days and what worked
Browsing through the chat and I really like the one from "Eingetragen von missingdot (136)
am 26.03.2018 - 11:16 Uhr" - can many here relate to this?

Baddý Sonja Breidert @baddysonja 22:32
Ich gebe Euch den Splash Award für die Beste Community aller Zeiten

Ich weiß ich werfe jetzt mal ein idee in den Raum, ohne mich selbst darauf committen zu können, aber wäre es nicht ein gute Idee, die Doku von DrupalVM und ähnlichen Projekten zu übersetzt z.B. als Teil des Drupalcenter-Handbuchs?
Evtl. kann man auch alternative Konfig-Dateien auf Deutsch schaffen und schauen, ob man evtl. irgendwie noch ein deutsches User-Interface schaffen kann. Ich kenne mich zwar noch nicht so gut mit Vagrant aus, aber der Ansible teil zur Organisation innerhalb der VM beherrsche ich ganz gut und kann evtl. da etwas behilflich sein.

An sich ist die Idee super, Allerdings schaffen wir es ja nicht mal den Core freizugeben, geschweige denn das Drupal 8 Benutzerhandbuch zu übersetzen. Deswegen befürchte ich, dass wir diese Idee etwas hinten anstellen müssen.

Die Videos zu Views, Rules sind unter dem Link Taxonomy, vocabularies and terms versteckt, aber alle vorhanden Part 1 - 14 usw.,

Auf Vimeo dann: rechte Spalte, ganz unten, auf mehr anzeigen...kommen noch etliche weitere Videos zu den Hauptmodulen.

https://digitalist.se/blogg/learn-drupal-7-wunderkraut
Taxonomy, vocabularies and terms

Grüße Jenna (ist ja heute hier fast wieder wie früher...)

Das seh ich etwas anders. Ich erwarte sehr wohl von jedem Modulentwickler, dass er eine ausreichende/umfassende Anleitung zu seinem Modul bereitstellt. Genauso erwarte ich, dass die Modul-Projektseite uptodate und ist eine klare, verständliche Beschreibung enthält, was das Modul tut. Es kann doch nicht sein, dass die Entwickler Wochen und Monate mit der Entwicklung eines Moduls verbringen und dann keinen darüber aufklären, wie man es richtig einsetzt und was es alles kann.

Ein aktuelles Beispiel "Media in core": Naiv wie ich bin, dachte ich kann einfach das vorhandene Imagefield mit dem neuen Media-Entity austauschen. Wohlgemerkt bei gleicher Funktionalität. Pustekuchen. Das Media-Modul benötigt soviel Konfiguration, dass mir schlicht die Lust vergeht es zu verwenden. Die Dokumentation ist mehr als lückenhaft.

Und ganz ähnlich seh ich das bei Drupal Core selber. Mit D8 hat man das - natürlich aus Gründen - so verkopft zusammengeschraubt, dass man dabei scheinbar ganz vergessen hat, was eigentlich die verschiedenen Zielgruppen sein können und wer das am Ende denn bedienen können muss/soll. Ich verstehe einfach nicht, warum man Drupal nicht konzeptionell so aufstellen kann, dass es selbsterklärend ist und nicht jedes Modul noch zwölf Zusatzmodule und eine hohe Einarbeitungszeit benötigt, um - gefühlt - die einfachsten Anwendungsfälle abzubilden.

Gerne. Nur wenn wir darüber diskutieren, kann es besser werden! Wenn du in irgendeiner Form Hilfe brauchen kannst, lass es mich wissen! :D

Auch ich schaue mich nach Alternativen um. Aber um mich soll es in dem Kommentar garnicht gehen.

Ich glaube tatsächlich nicht, dass es nur um "deutsche Anleitungen" geht. Ich glaube, das Problem liegt in der Nachwuchs/Neulingförderung. Meine These dazu lautet wie folgt.

Mit D6/D7 konnte ich einem Drupalneuling relativ einfach sagen: Nimm deinen Webspace, lade das hoch, hier ist die Anleitung zur Installation. Er hatte auf seinem bereits vorhandenen Shared Webspace ein schnelles Erfolgserlebnis. Dann konnte er schnell anfangen, was damit zu machen. Und von da aus konnte er lernen. Dann wurde er irgendwann interessierter und so weiter - er entwickelte sich zu einem Drupaler. Irgendwann kamen dann Tools wie Drush dazu.

Dieser leichte Einstieg fehlt - denn D8 ist nicht mehr für diese Nutzung gebaut. Dadurch haben wir keinen Nachwuchs.

Wo früher (mir unverständlicherweise) über die krasse Lernkurve nach der Drupalinstallation geredet wurde, haben wir diese Kurve nun noch weiter vorgezogen. Wie lange braucht ein Neuling (ohne Hosting oder mit bereits vorhandenem SharedHosting) bis zu seinem ersten Erfolgserlebnis: Einer minimal angepassten Drupalinstallation abrufbar im Netz?

Jeder Fußballverein baut seine Jugendmannschaft um genug Nachwuchs zu haben. D8 legt die Einstiegshürde für Neulinge mindestens in die zweite Liga - um da aus dem Stand drüber zu springen, brauche ich eine Menge Vorwissen und eine hohe Motivation*. Es hilft nicht mal, wenn ich das per Tutorials und Videos genau erklärt bekommen würde - andere Systeme installiere ich in 2-5 Minuten ohne jedes Vorwissen. Zack, Erfolgserlebnis.

Und ohne Nachwuchs stirbt jedes Ökosystem, jede Community, jede Gemeinschaft.

* Die Sache mit der Motivation ist auch interessant: In einem System mit leichtem Zugang habe ich im Verhältnis mehr intrinsische, also aus sich selbst heraus motivierte Menschen. Diese geben auch gerne zurück. Bei einem komplizierten Zugang verschiebt sich das Verhältnis zu extrensisch motivierten Personen - der Chef oder die Agentur bestimmt, dass mit D8 gearbeitet wird. Die emotionale Verknüpfung zum Thema ist viel weniger stark, wenn überhaupt vorhanden. Dadurch wird auch weniger zurück gegeben - es entstehen Agenturlösungen, die nicht geteilt werden. (Wurde in einem Kommentar weiter oben schon genannt).

Ich unterschreibe deinen Kommentar 1 zu 1! Sehr gut beobachtet. Eine ähnliche Diskussion hatte ich auf dem Drupalcamp in Ruhr. Seit D8 kommen Neulinge nur noch dann ernsthaft mit Drupal in Verbindung, wenn sie einen Job in einer Drupal-Agentur beginnen. Denn die Einstiegshürden sind zu hoch, sich da einfach mal kurz selbst mit zu befassen. Da ist aber, genau wie du sagst, keine emotionale bzw. gewachsene Verbindung mehr da. Drupal ist bzw. wird dann zu einer Insellösung für große Agenturen, die Community stirbt nach und nach. Und das ist aktuell schon zu beobachten.

Hohe Einstiegshürden

Ich glaube, dass wir hier langfristig vor einem riesigen Nachwuchsproblem stehen. Nicht jeder Drupalentwickler wird für immer und ewig mit diesem System arbeiten (z.B. neuer Job) und den Nachwuchs zu rekrutieren wird zunehmend schwerer werden. Die Wahrscheinlichkeit, dass Hobbyisten oder universitäre Projekte auf Drupal setzen wird immer geringer. Komplexität ist hierbei ein Faktor. Ein weiterer und ich glaube auch wichtigere Grund ist die offen kommunizierte Meinung: Drupal's Zielgruppe sind nicht mehr die kleinen Projekte. Auch meine Agentur strebt nach den dicken Fischen und ja, die bekommt man mit einem "Drupal for Corporate" besser als mit einem Hobbyisten-Image. Doch ist das Nachwuchsproblem dann damit hausgemacht. Man sollte nicht unterschätzen wie hoch der Prozentsatz der Entwickler in Agenturen ist, die eben aus dem privaten oder schulischem Umfeld zu Drupal gekommen und aus irgendeinem Grund dabei geblieben sind (trotz der immer schon verhältnismäßig hohen Einstiegshürden). Zum anderen hat sich Drupal auch anderen Disziplinen geöffnet: Twig, Symfony, Decoupled Drupal, OOP: All das sorgt wenigstens für eine Öffnung für andere Professionals, wenigstens etwas…

Entwicklungsumgebungen, Composer und Hosting

Die "Webentwicklung unter Windows" Thematik wurde hier ja schon angeschnitten. Dies ist jedoch in der Webentwicklung seit Jahren ein Trend. Immer mehr Tools benötigen Kommandozeilen-Tools. Seien es die Frontendentwickler mit Node.js, Bower, Taskrunner und Co. oder CSS Prä- oder Postprozessoren. Oder PHPUnit und Behat für das automatisierte Testen. Alle die zugrunde liegenden Tools sind stark kommandozeilenbasiert und werden inbesondere im Frontendbereich relativ knapp oberhalb der Anfängerliga eingesetzt. Neben dem fundamentalen Nachteil von Windows keinen Unix Unterbau zu besitzen (ist halt so, kann man nix machen), habe ich jedoch den Eindruck, dass Microsoft die Kommandozeilennutzung lange Zeit dämonisiert hat und bevor der PowerShell eigentlich nichts brauchbares von Haus aus mitlieferte. Dieser Umstand hat zur Fokussierung auf die Unix-basierten Betriebssysteme in der Webentwicklerwelt geführt. Das entwickeln und supporten dieser Tools für Mac OSX und Linux ist deshalb sehr viel einfacher und deckt eben auch einen großen Teil der Entwicklerwelt ab. Hätte Windows in dieser Hinsicht eine lange Tradition - wer weiß, vielleicht gäbe es trotz des zusätzlichen Aufwandes der Unterstützung von Windows, ein breiteres Angebot solcher Tools.
Zusammenfassend habe ich Respekt vor jedem, der sinnvoll unter Windows Webseiten entwickeln kann.

Composer ist ein teil der kommandozeilenbasierten Werkzeuge und scheidet spätestens seit Drupal 8 ja die Geister. Hinzu kommen vielleicht auch durch Unwissen viele falsche Fakten wie z.B. "mein Shared Hosting hat kein Composer, damit kann ich Drupal nicht nutzen". Auf dem Produktivsystem muss auch zwangsläufig kein Composer installiert sein. Die Abhängigkeiten können auch lokal aufgelöst und dann über FTP, SSH und Co. übertragen werden. Composer hat neben der ersten Schwierigkeiten auch einige Tücken, die vielleicht einige von euch schon festgestellt haben. Auf der anderen Seite sollte bedacht werden, wie PHP-Libraries in Drupal 7 genutzt wurden. Ich lese in der Readme des Moduls und suche nach der entsprechenden Library. Suche sie im Netz, entpacke sie in den /sites/all/libraries Ordner. Trotzdem funktioniert etwas nicht: Ah, der Ordnername muss leicht anders lauten. Nun wird die Bibliothek erkannt, cool. Oh nein, die Library nutzt einen PSR-Standard. Also brauche ich noch das xautoload Modul. Läufts jetzt? Nein, ich habe leider eine neuere Version des Library installiert, die mit dem Modul nicht mehr kompatibel ist.
Composer ist in der Lage genau diese Probleme automatisiert zu lösen (zumindest im "perfekte Welt" Blick, in der Module die Versionen richtig spezifizieren und die Libraries selbst semantisch Versionen und die damit verbundenen Herausforderungen zur Abwärtskompatibilität) einhalten.
Ja Composer ist eine hohe Einstiegshürde - aber er beschleunigt und sicher euren Entwicklungsablauf nachhaltig. Und ja, es ist auch möglich Drupal komplett ohne Composer aufzusetzen und zu warten (auch Module wie Address). Aber genau dann müsstet ihr euch eben um Versionen selbst zusammen suchen, euch um das Autoloading kümmern oder manuell "includen" :P. Genau deswegen wird Composer gepredigt.

Es gibt derzeit auch einige Iniativen, Composer zugänglicher zu machen, aber das ist sowohl komplex als auch von Volontären abhängig.

Open Source und dessen Monetarisierung

Das bringt mich zum nächsten Punkt "Open Source". Ich erwische mich auch ab und zu, dass ich denke "Boah dieser Maintainer, warum fixt der das Problem nicht, erzeugt nicht ein neues Release", "Boah, warum dauert es simples Problem im Core zu fixen 5 Jahre". Zum anderen sollte beachtet werden: Mit dem Core oder Modulen über das ihr meckert, wurden abertausende von Stunden freiwillig investiert. Dafür wäre zunächst erst einmal ein Dank vor der Kritik angebracht. Ich liebe gute Dokumentationen oder gut betreute Module. Wenn ich jedoch nur Konsument bin, kann ich zwar Forderungen stellen aber kein Maintainer ist euch irgendetwas schuldig.
Ihr benutzt das Ergebnis aus etlichen Arbeitsstunden völlig frei. Damit meine ich nicht nur, dass es kostenlos ist, ihr könnt damit machen "was ihr wollt" (im Rahmen der Art der Softwarelizenz). Das Kapital als Freelancer, Agentur oder Hobbyist ist sein Wissen. Für ein vergleichbares kommerzielles CMS würdet ihr Unmengen an Lizenzkosten abdrücken und wärt in noch stärkerer Abhängigkeit zu dem jeweiligen Anbieter. Ein Handwerksunternehmen braucht einen Fuhrpark, Maschinen, Verbrauchsmaterial usw. Für uns reicht ein Rechner, eine ordentliche Internetleitung und das "Wissen". Veränderungen und neue Techniken zu erlernen benötigt eigene Motivation und Zeit. Und ja, mich schockiert es auch zu Beginn mühsam Erlerntes Wissen (Drupal 6) nicht mehr regelmäßig anzuwenden und "einfach wegzuwerfen". Aber das Erlernen der Neuerungen in Drupal 8 ist meine Investition, die ich langfristig als Freelancer oder Angestellter anwende. Als Hobbyist, sieht das natürlich etwas anders aus.

Zum anderen sehe ich jedoch auch, dass es viele große Agenturen gibt, die wenig zum Drupal Ökosystem zurückgeben. Sicher, wie oben beschrieben müssen sie es nicht. So funktioniert Open Source (auch). Dennoch gibt es große Drupal Agenturen mit sehr vielen Entwicklern, die die größten sind sich auf Drupalkonferenzen zu vermarkten, jedoch wenig contributen. Das stimmt mich auch nachdenklich und ärgert mich auch ab und an. Denn bei den großen Projekten, die dort teilweise bearbeitet werden, werden sie auf ähnliche Probleme stoßen wie du und ich -> und ich bin mir sicher, dass sie einige davon intern lösen und nicht "zurückgeben".
Zum anderen gibt es vergleichsweise kleine Agenturen, die massiv contributen. Diese, zusammen mit den Volontären, sind Helden innerhalb des Drupal-Ökosystems. Trotz des wirtschaftlichen Druckes Zeit abzuzwacken eine generische Lösung für ein Problem zu finden und diese frei zur Verfügung zu stellen, obwohl letztendlich der Kunde dafür bezahlt. Hier sehe ich die Aufgabe der Verkäufer in den Agenturen die Kunden auf "Open Source" einzuschwören. Ich sehe es in meiner Agentur, dass manche Kunden sogar teilweise stolz darauf sind Module zu sponsoren oder ein Problem identifiziert zu haben, dass wir für sie innerhalb einer Modul Issue Queue gelöst haben. Die Arbeit für ein eigenes generische Module auf Drupal.org kann einen Vorteil für Kunden haben: Umso mehr Nutzer das Modul nutzen, desto eher erweitern ander dieses oder finden Fehler, bevor es der Kunde getan hat.

Das Gute an Open Source ist eben auch die Möglichkeit zum Wechseln, ohne auf irgendwelche Vertragslaufzeiten zu achten. Wenn sich Wordpress als die bessere Lösung für ein Projekt herausstellt, finde ich es absolut valide es zu nutzen. Eine Massenabwanderung wäre sehr traurig, aber dennoch aber eben die Freiheit des jeden Einzelnen. Deshalb sollten wir uns an solchen Themen wie diesen nicht herunterziehen lassen, sondern darauf aufbauen. Es ist wichtig Diskussionen zu führen, auch um im schlechtesten Fall sich die validen Beweggründe für eine Abkehr bewusst zu machen.

Drupal.org

Wer schon einmal mit einem anderen CMS gearbeitet hat, wird schon einmal ein CMS erlebt haben, das keine zentrale Plattform für den Austausch bietet. Einer der Gründe, warum ich seinerzeit bei Drupal hängen geblieben bin, ist dass ich den Core, Dokumentation, Issue Queues und Foren auf Drupal.org finde. Ich habe damals auch mit TYPO3 gearbeitet. Hier gab es mehrere externe Foren für den Meinungsaustausch, ein katastrophales Extension-Repository, ein super technisiertes Ticket System zum Bugmelden (aber damals nur für den TYPO3 Kern). Wenn man damit gearbeitet hat, kann man wertschätzen wie wichtig Drupal.org für Drupal ist. Ich kann diejenigen, die sich vor der englischen Sprache nicht scheuen, sich aktiv auf Drupal.org zu beteiligen. Jeder Maintainer, der Open Source lebt, wird freut sich erstens darüber zu hören, wie ihr ein Modul verwendet und er ist genauso froh aussagekräftige Fehlerbeschreibungen zu bekommen. Manchmal weiß dieser nämlich gar nicht um das Problem, da er den Anwendungsfall so noch nicht gesehen hat. Wer weiß, vielleicht gibt es frustrierte Nutzer eines von mir erstellten Moduls, die entnervt aufgegeben haben, ohne dass ich überhaupt davon wusste? Das wäre jammerschade. Natürlich sind nicht englischsprachige Anwender dabei benachteiligt und deshalb hat das Drupalcenter auch seine Daseinsberechtigung.

Zusammenfassend bleibt zu sagen: Ich kann eine gewisse Unzufriedenheit über die Entwicklung von Drupal nachvollziehen. Mir geht es auch ab und zu so. Dennoch sollten wir nicht vergessen, was Open Source bedeutet mit all seinen Vorteilen und Nachteilen. Und darüber nachdenken, welche Rolle ich innerhalb des Projektes einnehme: Anwender, Fehler Reporter, Übersetzer, Modul-Maintainer, Sponsor usw. Auch wenn es nicht immer so rüberkommt und bestimmte Agenturen und Entwickler großen Einfluss haben, Drupal funktioniert nur als Ganzes. Mit all seinen verschiedenen Nutzern. Selbst mein Marketing-Kollege konnte sich aktiv einbringen bei der letzten DrupalCon in Wien. Statt nur zu Konsumieren und zu Verkaufen nahm er am Marketing-Sprint teil. Das ist aus meiner Sicht eine super Entwicklung und zeigt, dass es wert ist den Fokus nicht immer nur auf die die-hard Backendentwickler zu legen.

" Mit dem Core oder Modulen über das ihr meckert, wurden abertausende von Stunden freiwillig investiert. Dafür wäre zunächst erst einmal ein Dank vor der Kritik angebracht"
Vollkommen richtig. Das ist auch der Grund, warum ich mich meistens sehr stark zurück halte.

Aber evt. wäre auch genau das ein Grund gewesen, darüber nachzudenken, ob man das Rad so sehr neu erfinden muss.
Es ist ja auch die Arbeit von abertausenden freiwilligen Modulentwicklern, die nun teilweise in die Tonne gekippt werden kann.

Es wäre wirklich mal eine Überlegung wert, wie man die Arbeit der Freiwilligen besser honorieren könnte.
Neulich habe ich mich schlau gemacht, wie ich Weiterentwicklung des Modules "Rules" unterstützen könnte.
Da kann man Sponsor werden, muss aber einen höheren dreistelligen Dollar-Betrag aufwenden.
Puh...ich dachte, da kann ich einfach einen Betrag meiner Wahl per PayPal spenden...100Dollar gerne, mehr geht nicht.
Dafür verzichte ich auch sehr gerne darauf, als Sponsor genannt zu werden.

Sowas sollte man flexibler gestalten.
Wenn die zu spendenden Beträge niederiger wären, würden sich sicher mehr freiwillige Spender finden und es käme evt. genauso viel zusammen, wie durch ein paar Sponsoren.

Zman, da bringst du einen guten Aspekt mit in die Diskussion. Nämlich den Punkt Open Source mit all seinen Vor- und Nachteilen. Ich gebe zu, dass mir im Eifer des Gefechts vielleicht auch ein bisschen die Demut abhanden gekommen ist. ;-)

Und auch einen anderen Teil sprichst du an, die Partizipation in der Community. Ich war jahrelang stiller Drupalnutzer, habe mich über viel gefreut, über viel geärgert, viel Zeit mit Fehler- und Lösungssuche verbracht und habe tolle Projekte umgesetzt. Und ganz nebenbei ein paar Euro damit verdient. Mit einem Framework, das mich keinen Cent kostet. Hurra! :D Tatsächlich ist das nun einfach auch meine Art der Partizipation, um der Community zurückzuspiegeln, dass ich finde, dass der eingeschlagene Weg auch viele Schattenseiten und Gefahren birgt. Aber ich kann auch genauso lange über die tollen Momente zwischen Drupal und mir berichten, wenn gemeinsam abends kuschelnd auf dem Sofa liegen. Das ist aber nicht Teil dieser Diskussion... ;-)

Bei allem Respekt vor der Leistung derer, die viele, viele Arbeitsstunden ins Projekt einbringen, sollte man nicht vergessen, dass jeder auch persönliche intrinsische Motive dabei hat. Sei es der Spaß am Entwickeln und die Freude, dass Andere mit dem Geschaffenen auch was anfangen können, sei es die Suche nach Anerkennung per se oder die Hoffnung, sich über die Community für gute Jobs profilieren zu können. Die Diskussion, ob sich die aktive Beteiligung an Open Source für Entwickler lohnt oder wie Entwickler davon finanziell besser profitieren können, gibt es schon sehr lange. Wenn das System grundsätzlich - im beschriebenen globalen Sinne - nicht funktionieren würde, gäbe es längst keine Open Source Projekte mehr. Das Gegenteil ist der Fall.

Mir geht es übrigens ganz und gar nicht darum, Maintainer zu kritisieren, dass sie nicht schnell genug Module voran bringen. Meinetwegen darf das dauern. Aber ich würde es sehr begrüßen, wenn das Orchester, das zusammen spielen soll, auch in etwa gemeinsam auf der Bühne eintrifft. Wenn es einerseits heißt, dass in Zukunft der Abstand von einem Major Release zum nächsten kürzer werden soll - und damit eben auch der Support für die nächst alte Version - und andererseits selbst mehr als zwei Jahre nach dem Release von D8 wichtige Contrib-Module noch nicht wirklich einsetzbar sind, dann sehe ich da einen massiven Widerspruch. Und der beunruhigt mich. Den Kunden interessiert es kein bisschen, warum Drupal keine verlässliche Zeitschiene auf die Kette kriegt, der Kunde möchte wissen, dass seine Website möglichst lange "hält". Egal, ob auf D7 oder D8.

Ich denke, dass D8 mit der Zeit auch wieder "Einsteigerfreundlicher" werden wird. Es kostet tatsächlich sehr viel Zeit, sich in D8 einzuarbeiten. Ich habs aber gemacht, weil ich mit Drupal in eine nachhaltige Plattform investiere, die für unsere Projekte auf dem aktuellen Stand der Technik ist.

An wen richtet ihr eigentlich Eure Apelle? Es gibt keine Instanz, die bestimmt, wie es mit Drupal weitergeht, außer den Entwicklern, die die Ärmel hochkrempeln und den Agenturen, die Geld und Zeit investieren.

Ihr könntet Euch z.B. mal zusammensetzen und eine Anleitung für Anfänger erarbeiten, wie man D8 auf Windows zum Laufen bekommt und etwa auf all-inkl.de ausrollt.

Die Idee von Drupal ist, das die Anwender gemeinsam ihre Probleme lösen, z.b. in Drupal User Groups. An freundlicher Unterstützung wird es sicher nicht mangeln.

Wir richten hier keine Apelle an irgendjemand, sondern sammeln Meinungen für die Drupalcon Nashville.

Es scheint so zu sein, dass wir nicht die einzeigen sind, die den Aufsprung auf Drupal 8 verpasst haben. Es ist ja schön und gut, dass die Drupal Community entschieden hat D8 auf neue Füße zu stellen. Aber der Exportwelmeister Deutschland scheint gewaltig hinterherzuhinken, wenn es darum geht Drupal 8 zu lernen.

Die Frage ist also was wir dagegen tun können. Ich kann dir ein Beispiel geben, dass dich vielleicht Überraschen wird. Die Deutsche Übersetzung von Drupal 8 liegt zu 100 % fertig auf localize.drupal.org.

Leider haben wir einfach nicht genug Leute im Team um diese Zeitnah freizuschalten. An der Umfrage hierzu haben bis heute 12 Leute teilgenommen 12. Nicht etwa 200 oder 1200. Das Zeigt, dass Drupal 8 zwar wahrgenommen wird, aber vielen offensichtlich der Aufwand zu groß geworden ist, den es braucht um Drupal ans Laufen zu bekommen, geschweige denn zu verstehen. Eine Diskussion wie die oben stehende musst du hier mit der Lupe suchen und ich bin für die rege Beteiligung wirklich dankbar.

Was ich hier raus lese, ist, dass alleine die Angst vor der Kommandozeile oder vor Linux oder der schlicht Standpunkt „Ich bin Windowsnutzer, verdammt“ und „Warum um Himmelswillen kann ich denn nicht einfach FTP verwenden wie früher“ Wenn Drupal von Anfang an so kompliziert ist, dass Neulinge den Spaß daran verlieren und Angebote wie Drupalize.me oder OS-Training in Deutschland fehlen und wir auch keine Videos mehr zu Drupal machen, aus denen man einfach lernen kann, dann wird die Community so lange schrumpfen, bis sie in Deutschland komplett verschwunden ist. Und hiergegen sollten wir doch etwas tun. Noch dazu ist das nicht nur ein Problem hier in Dt. offenbar auch in Frankreich und in anderen Ländern. Auf lange Sicht bedeutet dass, das wir das Drupalcenter zu machen können, weil einfach keiner mehr mit Drupal 8 arbeiten will. Da ist doch was faul im Drupalversum, meinst du nicht

Ich werde mit derzeit ca. 50 Drupalseiten in den nächsten Monaten, bis spätestens End Of Life von Drupal 7 auf andere CMS Lösungen (Craftcms, Jekyll, Processwire) umsteigen. Backdrop stellt für mich keine Alternative dar. Drupal ist ein rundum tolles CMS, aber der Arbeitsaufwand für die Drupal 8 Migrationen steht in keinem Verhältnis. Wo immer möglich habe ich Drupal für diverse Kundenseiten eingesetzt. Drupal 8 kam mehrmals nicht zum Einsatz, weil wesentliche Module wie rules, ds, commerce nicht einsetzbar waren oder sich im endlosen Dauer-Wartezustand befanden. Mir gefällt überhaupt nicht wie sich Drupal's UX und einige Module entwickelt haben. Auch ist Drupal's Fokus stärker auf Entwickler ausgerichtet. Drush und composer sind super Tools, die ich lieben gelernt habe. Für Anfänger halte ich Drupal wenig/nicht geeignet. Gerade für kleinere Projekte ist Drupal wegen hohem DB Performance-/Speicherverbrauch unattraktiv geworden.

Dies soll kein Drupal Bashing sein. Selbstverständlich habe ich großen Respekt vor der Leistungen der vielen Drupal Entwickler.

Deutschland hinkt ja bei so einigen Dingen hinterher...

Dries hat es doch so schön formuliert: "Drupal is for ambiituos projects". Für das untere Marktsegment der "Broschürenseiten" ist Drupal (Core zumindest) im Moment sicher nicht das gefälligste Tool.

Als Entwickler bin ich nach wie vor Drupal-Fan, gerade weil die Community zuerst an saubere Konzepte, APIs und Architektur denkt, und danach erst an "klicki bunti". Wobei es sicherlich jede Menge "Room for improvement" bei der UX gibt.

Für meine Kundenprojekte baue ich sowieso spezialisierte Backends und möchte gar nicht, dass die einen "Page builder" in den Fingern haben.

Was ihr eigentlich möchtet, ist eine Drupal-Distribution. Guckt Euch z.b. mal Varbase an.

so sehe und erlebe ich das auch.

Ich werde, so lange wie möglich, bei D7 bleiben, da ich 250 unterschiedliche Module einsetze, viele von denen (besonders kleinere) es (noch) nicht für D8 gibt und ich 120 Custom-Templates habe, die alle bei D8 neu angelegt werden müssen. Der Zeitaufwand dafür ist jenseits von gut und böse.

Die Migration von großen Projekten ist eine Katastrophe und mir rollen sich schon jetzt die Fingernägel hoch, wenn ich nur daran denke. Aus diesem Grunde bleibe ich solange bei D7, wie es möglich ist. Mit D8 beschäftige ich mich auch solange nicht, da der Tag leider nur 24 Stunden hat.

Nachtrag: Die Migration meines Projektes von D6 auf D7 hat WOCHEN gedauert und ich bekomme gerade wieder graue Haare, nur wenn ich daran denken muss.

So etwas tue ich mir nie wieder freiwillig an, damit beschäftige ich mich erst wenn es nicht mehr anders geht.

Das Problem ist doch, dass da nun eine große Lücke klafft, die es unter D7 so nicht gab.
Ich betrachte jemanden wie Ionit oder mich durchaus als ambitionierten User und ich habe viele Webseiten unter D7, die sicher weit über "Broschürenseiten" hinaus gehen.
Es ist ja auch nicht so, dass ich mit D8 gar nicht klar käme. Ich habe mir Composer erschlossen, habe keine Angst vor der Konsole und mache kleine Erweiterungen mit Modulen oder auf Ebene Template.

Aber viele eigene und Kunden-Projekte können definitiv nicht auf D8 umgestellt werden, weil die Module fehlen bzw. das Budget für eine Eigenprogrammierung als Ersatz für diese Module.
So geht es unendlich vielen Drupal Anwendern und kleinen Agenturen.
Damit ist doch logisch, dass noch massenweise Fragen zu D7 auftauchen.

"Die Migration meines Projektes von D6 auf D7 hat WOCHEN gedauert und ich bekomme gerade wieder graue Haare, nur wenn ich daran denken muss
Ach eben fällt mir wieder ein, woher ich die vielen grauen Haare habe. ;-)

Also zu der Composer-Geschichte wollte ich nur noch mal anmerken. Ich habe heute mittels Composer auf 2 Projekten den Sicherheitspatch bzw die Aktualisierung auf Drupal 8.5.1 eingespielt wie nix einfach nur mit composer update. Da war nicht viel mit

• Archiv runterladen
• Archiv entpacken
• Vorhandenen Core überschreiben

Es mag ja alles seine Vor und Nachteile haben , aber in solchen Momenten ist das definitiv ein Vorteil. Eine Zeile Code in zwei Kommandozeilenfenstern mit zwei unterschiedlichen Remote-Verbindungen und alles ist gut geworden. Wenn dass kein echtes Argument für Composer ist, dann weiß ich auch nicht mehr weiter.

nur bei einem normalen hoster kriegst du keinen compopser installiert!!!

Dieses Problem dürfte aussterben. Außer man bezeichnet Strato als "normalen" Hoster. ;-)
Ich habe Composer inzwischen bei HostEurope, 1und1 und All-inkl. installiert.
Gerade bei letzterem ging es wirklich einfach inklusive Drush. Es gibt auch eine gute Anleitung dazu, mit der das jeder kann, der die SSH Konsole findet.

Auch Contao nutzt inzwischen Composer und (fast) kein Hoster kann das mehr verschlafen.

wo ist die gute anleitung?

Für Composer:
https://all-inkl.com/wichtig/anleitungen/skripte/sonstiges/composer/inst...

Für Drush:
https://all-inkl.com/wichtig/anleitungen/skripte/cms/drush-fuer-drupal/i...

Eine andere Variante wäre, composer nur lokal zu verwenden und das fertig gebaute Projekt dann auf normalem Wege auf einen Server zu schaufeln, etwa via git oder ftp.

Alles gute Ideen. Die Definition von Normal bezüglich eines Webhosters würde mich aber wirklich interessieren. Ich schaffe es auch nicht mehr Drupal unterhalb von 9 euro I'm Monat zu hören, aber hey, dafür funktioniert auch jeder Schnickschnack.

klingt einfach. trotzdem werde ich drupal 8 nicht nutzen: wei oben schon gesagt, die portierung von d7 zu d8 ist einfach zu aufwendig bei den meisten seiten, die ich mit d7 umgesetzt habe. das ist eine protierung zu wp oder joomla einfacherer und sicherer. und bei den einachen seiten ist die portierung zum neuen cms einfacher und für die kunden und mich einfacher mit wp oder joomla mit aktualsierungen.

Die Portierung ist wirklich in den meisten Fällen noch nicht möglich.
Für neue Projekte ist D8 dennoch eine Option für mich.
Es gibt einfach Dinge unter Drupal, die sind anderswo nicht zu haben.
Inhaltstypen, Views ect.
WP ist da definitiv keine Alternative und Joomla...gibts das echt noch? ;-)
Dann schon lieber Contao.

inahltstypen, eigene felder gibts in joomla und wp auch, ansichten bedingt.

und updates sind ein kinderspiel ;) im vergleich zu drupal

Also ich war und bin auch überrascht und enttäuscht, wie unausgereift Drupal 8 bereits früh Sitebuildern (Nicht-Programmierern) als die bevorzugte Version empfohlen wurde. Wie schon einige von euch bemerkt haben, gibt es noch einige Probleme bei Modul-Updates und vieles fehlt noch. Man könnte berechtigt sagen, d8 steckt noch in den Kinderschuhen oder tat es bis vor kurzem noch. Ich habe vor ca. 2 Jahren vermutet, dass Drupal 8 für einfache Websites schon gut zu gebrauchen ist und habe angefangen, welche damit zu bauen. Das Resultat war, dass ich mit diesen Systemen einige Probleme mitgeschleppt habe, die ich jetzt erst mit update auf 8.5 gelöst habe, und die Update-Prozedur lief alles andere als problemlos.

Jetzt habe ich einen guten Eindruck und glaube, das schlimmste ist überstanden, baue komplexere Systeme aber immer noch mit D7, weil mir da ansonsten zu viele Module fehlen (Rules, …). Ich weiss, dass man vieles mit custom-modulen lösen und von daher auch in Erwägung ziehen kann, vieles von dem mit der neuen Version zu bauen. Das ist allerdings nicht so meine Stärke und die vielen ausgereiften Module und die damit verbundenen, schier unendlichen Möglichkeiten bei D7, ohne coden zu müssen, machen das ganze Drupal-System für mich so einzigartig.

Und ich glaube nie und nimmer daran, dass Drupal 7 bereits im Jahr 2020 nicht mehr unterstützt wird. Das war vielleicht irgendwann mal der Plan, verzögert sich aber mit Sicherheit, gerade weil so viele Drupal 7 Websites noch nicht auf D8 migriert wurden und werden, weil so vieles an Modulen fehlt. Und wenn, dann gibt es mit großer Wahrscheinlichkeit noch genug Leute, die ein LTS-Projekt wie jetzt für D6 daraus machen. In sofern nutze ich teileise auch weiterhin Drupal 7 für neue komplexere Systeme, achte allerdings bei der Modulauswahl darauf, dass es einen späteren Upgrade-Pfad gibt und bevorzuge diese dann.

Andere CMS als Alternative:
Natürlich habe ich da auch schon über einen Fokus-Wechseln nachgedacht, doch als ich vor Drupal von Joomla weg bin, wusste ich warum – auch wenn das System mittlerweile sicherlich besser wurde. Und von Wordpress habe ich immer wieder den Eindruck, dass das auf einem viel niedrigeren Level von Systematik, Sicherheit, Kontrolle, … lebt. Da investiere ich lieber weiter in Drupal8-Lernen …

Halte ich genauso, ich hab' mit Drupal 7.5 begonnen. Vorher hatte ich nichts je davon gehört. Und diejenigen, die schon länger dabei waren, mögen sich erinnern: war es nicht vielleicht doch ähnlich, als Drupal 7 neu war? Bevor der Stand von Drupal 7.5 erreicht war? Und 8.5 ist das, was wir jetzt, seit paar Tagen im Prinzip, haben. Und im Vergleich zu 8.1, 8.2, 8.3... Vergegenwärtigt euch mal, was wir hier haben. "Core-Media", "Layout Builder", "Paragraphs". Nur so Beispiele... Und das ist ja quasi erst der Anfang. Was da draus werden wird. Das reicht für echt fette Sachen, ich denke auch noch jahrelang. Und die Dokumentation auf drupal.org ist wirklich ambitioniert, sei es auch nur auf Englisch. Das alles hat das Zeug dazu, dass in Zukunft respektvoll gesagt wird "Ououou, Drupal, das hat schon was. Aber ist natürlich auch nicht einfach". Und was bedeutet das? Tja, für Mini-Sites? Da muss man das eigentlich nicht nehmen. Aber ehrlich gesagt war das bei Drupal 7 schon genauso. Man konnte, und kann es lassen. Ich denke, es gibt mittlerweile ganz coole Sachen für Mini-Sites. Früher hieß das WordPress oder Handmade. Ich hab Mini-Sites trotzdem oft mit Drupal gemacht. Einfach um das Potential zum Wachsen mit einzubauen.

Aber jetzt das Problem, wurde ja auch schon oben passend beschrieben. Aber nochmal aus meiner Sicht des kleinen Drupal-Freaks: Der Switch zu den Kommandozeilen-, Twig-, .yml-Gurus. Der hat nicht richtig gezogen. Im Prinzip eine Fehleinschätzung. Das begann schon bei Drupal 7 mit dem Omega 4-Theme: Yeah, jetzt alles supercool mit Sass, Composer, Drush, Susy-Framework, Guard... Hey, wir erklären es euch: Ihr packt das auf eure Development-Umgebung, zack, zack. Und los geht's... Wie, ihr versteht das nicht? Wo ist das Problem? Drauf und benutzen! Das sind die Tools der Zukunft! Tja, da konnten bereits viele nicht mehr folgen. Ich hatte mich damals da durchgequält. Und ich hatte das Gefühl, als einziger der nicht-Super-Pros. Die Foren waren noch voll von Leuten die sagten: "Ey, ich raffe überhaupt nichts mehr". Und ich glaube, diese Leute sind jetzt weg. Da dürfte die Basis weggebrochen sein und ich glaub' nicht, dass die wieder kommt.

Plötzlich, mit Drupal 8: Omega 5! "Hier, wieder so wie Omega 3. Mit dem Kommandozeilen-Hype, das haben wir wieder zurückgenommen". Oder Drupal-Commerce: dasselbe. Composer, Composer, Composer! Du liest von massig Leute, die haben es niemals geschafft, das Ding überhaupt zu installieren! Klar, wenn du Ahnung hast, fragst du dich natürlich "Hä, wie kann man das nicht hinbekommen? getcomposer.org - fertig!" Drupal commerce: nüchterne Feststellung - "Die User sind kommandozeilenresistenter als wir je gedacht hatten." Zurückgerudere. Aber vielleicht zu spät. Ich glaube, da ist eine Kluft entstanden, die ist zu groß. Ich vermute, da sind tausende weggebrochen. Aber die Masse machts! Ist Windows besser als alles andere? No! War VHS besser als Betamax? No! Aber was hilfts? Ist WordPress besser als Drupal 8? Never! Aber was, wie gesagt, hilfts? Ich habe schon jetzt den Eindruck, Drupal verbleibt bei ein paar Super-Profi-Agenturen in den USA, die bauen ihre Super-Distributionen, fette Boeing und Non-Gov-Sites... Und hier? In meinem Umfeld heisst das Ecosystem "WordPress" - fertig. "WordPress" ist synonym für den Begriff "Webseite". Joomla, Typo... Gibt's nicht mehr. "Wir wollen gerne eine WordPress-Seite haben. Die sehen so modern aus und das ist total einfach", "Können wir die Seite durch eine WordPress-Seite ersetzen?". Nicht das die eine Ahnung hätten, wovon Sie eigentlich reden. Aber was hilft' s?

Die Schlussfolgerung, für mich und meine speziellen Anforderungen, die nicht auf jeden von euch übertragbar sind: Ich setze voll auf Drupal 8! Ich glaube mit dem Zeug hast du die nächsten Jahre ALLE Möglichkeiten. Alleine Core-Media. Die ganzen siebener-Jahre haben wir uns so etwas gewünscht - und nie bekommen. Jetzt ist es da. Und Rules und Feeds, das kommt auch noch. Und wenn nicht kommt was besseres. Und gut, ich werde jetzt mal meine nächste Dev-Site von Beginn an mit Composer hochziehen, NICHT mit Drush 9 updaten, geht ja nicht mehr. Das ist ja nur noch dazu da, mir mitzuteilen, dass ich Composer zu benutzen habe, wofür ich früher so schön "drush up" benutzen konnte. Und wenn's nicht funktioniert, muss ich halt wieder so lange Gas geben, bis es funktioniert. Wenn ich mal nicht-verklärt zurückdenke, war' s mit Drupal 7 auch so. Immer neu einarbeiten, immer neu frickeln, immer rumärgern. Aber ich habe ein echt gutes Gefühl, dass es sich lohnt. Ich war in den 90er mit meinem Macintosh ein Exot in der Windows-Welt. Heute ist es andersrum. Ich bin mit meinem Kubuntu-Lenovo ein Exot in der MacBook-Welt. Und ich bin mir sicher, dass ich mit meinem Drupal in Zukunft ein Exot in der WordPress-Welt sein werde, zumindest was den ganzen Mini-Sites und Mittel-Sites-Markt betreffen wird. Aber egal, ich habe, wie gesagt, eben ein gutes Gefühl.

Holla Hans-Peter,

Ich gebe dir vollkommen Recht. Drupal 8 ist wohl etwas für Exoten. Das bestätigt auch diese sehr aktive Diskussion hier. Das müsste aber gar nicht so sein. Ich erzähl euch schnell eine kleine Geschichte:

Bei der Gründung des Drupalcenter hat man sich dafür entschieden eine Plattform online zu stellen, die Menschen, die über Drupal stolpern erklärt, was Drupal ist, wie Drupal funktioniert und was Drupal vor Vorteile bei der Verwaltung von Werbeprojekten bietet. Ich weiß nicht ob das Forum zuerst da war und das Handbuch später kam. Tatsächlich hatten wir irgendwann beides. Hinzu kanmen 2 Arten von Nutzern:

1. Diejenigen, die sich mit Drupal beschäftigt und anderen näher gebracht haben
2. Diejenigen, die dankbar waren, dass Ihnen jemand Drupal erklärt und schnell erkannten wie toll Drupal ist.

Im besten Fall erklärte Gruppe 1 so gut, dass bald mehr Nutzer aus Gruppe 2 in Gruppe 1 Wechseln konnten. Irgendwie scheint das ganze sinn gehabt zu haben, denn aktuell hat das Drupalcenter 1804 registrierte Mitglieder. Von denen mag der ein oder andere zu Wordpress gewechselt sein, oder ist inzwischen gestorben. Ich hab Unter Drupal 6 Angfangen, meine erste Webseite zu machen und Drupal aus dem Drupalcenter heraus entdeckt und gelernt.

Ich habe mich gerade mal im Handbuch umgesehen. Dort gibt es einen einzigen Eintrag zu Drupal 8 in Form eines Backlinks (mehr oder weniger). Dort findest du dann die Spielweise einer Studentin, die sich in Eigenarbeit versucht Drupal 8 beizubringen und Ihr Wissen weiterzugeben (find ich klasse)

Der Rest des Handbuchs bezieht sich auf Drupal 7 und früher. Der einzige Eintrag in einem Handbuch, über Drupal, dass von Drupal-Fans für Drupal-Neulinge geschrieben wurde. Auf der einzigen Seite in dieser ausgereiften Form, die ich in unserem Sprachraum (DE, AT, CH) für Drupal kenne, der sich auf Drupal 8 bezieht ist einer, in dem sich jemand einen Backlink auf seine Seite holt!

Bei der Gelegenheit muss ich euch noch sagen, dass ich neulich aus versehen die Systemanforderungen von Drupal 8 auf Drupal.org ins Deutsche übersetzt habe, weil ich davon ausging, dass dort inzwischen Content translation ausgerollt ist. Natürlich ist dem nicht so und wir haben die Revison auf den Englischen Originaltext zurückgesetzt. Das ist jetzt vielleicht 48 Stunden her.

Die Reaktion des Websmasters, dem aufgefallen ist, was ich angestellt hatte, war sinngemäß folgende:

Das bedeutet, dass selbst jemand, der sich um Drupal.org als Webmaster kümmert, nach einer Google-Anfrage oder vielleicht auch auf Grund persönliche Verbindungen annimmt, der Drupal-Center sei der richtige Ort, für die deutsche Community um Drupal 8 zu lernen. Wären wir noch bei Drupal 7 oder Drupal 6 würde ich diese Annahme auch sofort aus meiner eigenen Erfahrung heraus unterschreiben,

Wenn dem so wäre, dann hätten wir im Handbuch nicht exakt einen Eintrag zu Drupal 8 in Form eines Backlinks!

Ich für meinen Teil bin darüber sehr traurig und vermisse die Zeit, als hier Menschen noch aktiv daran gearbeitet haben Drupal für Einsteigern, unabhängig von Vorbildung und Alter, Drupal näher zu bringen.

Ich kann nur hoffen, dass Drupal.org irgendwann in der Zukunft damit beginnt Content Translation auszurollen und sich dann genügend Nutzer finden, entsprechende Inhalte zu übersetzen.

Im Drupalcenter selbst scheint der Geist von einst verschwunden zu sein und einer Stimmung platz gemacht zu haben, die mehr aus nörgeln besteht, denn aus aktiv handeln oder gar darin anderen Drupal erfolgreich näher zu bringen.

• Ja auch ich war mal Nachwuchs.
• Ja auch ich habe Drupal im Drupalcenter gelernt
• und ich bin bei Drupal geblieben und auf Drupal 8 umgestiegen
• Aber was soll der Nachwuchs machen, der nach mir kommt. Auf Drupalcenter.de jedenfalls kann er sich nicht mehr über Drupal informieren

Nach der ganzen Diskussion in den letzten Tagen und den vielen verschiedenen Meinungen hierzu bin ich abschließend der Meinung, dass das END Of LIFE von DRUPAL 7 in der Tat auch dass Ende des Drupalcenter sein könnte.

"Wenn ich mal nicht-verklärt zurückdenke, war' s mit Drupal 7 auch so. "
Da erinnere ich mich anders. Ich habe noch unter D6 angefangen als Umsteiger von TYPO3.
Da habe ich mir sehr schwer getan, weil die Denke beim seitenorientierten T3 eine ganz andere war.
Dann kam D7 und ich hatte keinerlei Probleme. Sehr schnell gab es viel mehr und tollere Module.
Ich war im D7.-Himmel. ;-)
Klar, ich baue auch drauf, dass D8 noch ausreift und dass die Luft etwas dünner ist, als bei Wordpress.
Aber es ist sehr schwer zu kommunizieren, aus den Gründen, die Du gut beschrieben hast.
Drupal kann 10x besser sein, die Leute wollen trotzdem Wordpress.
Überredet man die dann zu D8, dann gibts doch einen Shitstorm bei den ersten Problemen und fehlenden Modulen.

Doch, ich hatte immer Probleme. Und wenn ich keine hatte, hab' ich mir welche "besorgt", in dem ich so weit erweitert hatte, bis ich welche hatte. Das war kein Problem mit Views-Kontextfiltern die genau das, was ich filtern wollte, nicht kriegten. Oder irgendwelche fields-/entity-reference-Verbauten, oder einfach den Commerce-Shop gefüllt mit massig Daten per Bulk-Import, Taxonomie-Groß-Vokabularsammlungen, die automatisch ausgefüllt werden, User-Import-Tools, usw. Diese Dinge, die einen mit angehaltenem Atem den "Import" oder "Sichern"-Knopf drücken lassen, die gab's immer. Vor allem wenn man, so wie ich, selber keine Module baut, sondern die vorhandenen notfalls derart langzieht, dass sie doch noch das machen, was man braucht.

Jeder benutzt das System, das er am besten kennt.
An den Universitäten wird viel mit WP gemacht.

Um bei Drupal zu landen, muss man vieles hinterfragen.

Wordpress und auch Joomla sind Systeme, die hauptsächlich von Blogdiensten abgeleitet sind, mit denen man mit etwas Mühe auch Daten verwalten kann.

Damit kann man zwar schon einiges machen, und hübsch aussehen können alle, weil sie am Ende HTML erzeugen.

Der große Unterschied steckt im Untergrund.

Drupal ist vorrangig ein datenbankorientiertes Verwaltungssystem, mit dem man auch Blogs darstellen kann.

Das ist ein anderer Denkansatz, der auch eine andere Entwicklungsphilosophie erfordert.

Während man bei T3 in Seitenstrukturen denken muss und bei Joomla und WP in Dokumenten, muss man bei Drupal in Datenstrukturen denken.

Das macht Drupal extrem flexibel, aber für viele auch wesentlich anstrengender.

Hinzu kommt, dass die Benennung von Elementen anders ist.

Ein Modul ist nicht eine Komplettlösung für eine spezifische Aufgabe, sondern eine vielseitige Lösung für eine Teilaufgabe.

Diese Flexibilität führt schnell dazu, dass der Eine oder Andere den Überblick verliert.

Alleine der Umstand, dass es bei Drupal keinen expliziten Backendzugang gibt, verwirrt viele.
Wenn man sich damit aber ein wenig befasst hat, weiß man die Vorteile schon zu würdigen.

Das Denken in Entities und Relationen ist zunächst anstrengend.

Wer eine reine Auflistung von Dokumenten braucht, ist mit WP und Joomla sicher gut bedient.
Wer eine strenge Seitenstruktur will, ist bei T3 ganz gut aufgehoben.

Ronald hat es perfekt getroffen, genau das macht Drupal, egal welche Version, so einzigartig und ein WP, Contao oder Joomla wird das in dieser Form niemals können.

Gerade musste ich Multifield durch Paragraphs ersetzen, und nach der üblichen Grummelei, wieder ein Modul tauschen zu müssen, tun sich mit Paragraphs wieder tausend neue Wege für mein Vorhaben auf und es ist auch für D8 als Stable verfügbar.
Und dabei war mein Start vor etlichen Jahren mit Drupal 6 alles andere als problemlos. Ich habe es mindestens 6 x wieder deinstalliert und mich furchtbar aufgeregt das es nicht mal ein Imagefield gibt. Nach 2 Wochen und etlichen Tests mit anderen CMS hat mich irgendwas, unter anderem auch dieses Forum, bewogen damit weiter zu machen.

Und mit D7, wie Montviso so schön schreibt, war bzw. ist man im Modulhimmel. Ich denke das Drupal 7 mind. noch 3 Jahre weiter läuft und parallel läuft bei mir nun D8 mit, damit der Umstieg irgendwann nicht zur Katastrophe führt.
Das ich mir nun rein für Drupal 8 noch Git, Composer, Drush und etliches mehr dazu aneignen muß, ist schon viel verlangt, aber ich bin sicher das es sich im Endergebnis (für etwas größere Projekte) lohnen wird. Die D8 Installation selbst (ich arbeite mit Win 10) lässt sich mit Putty in 5 Minuten abhandeln, für alles andere werde ich mir wohl eine 2. Festplatte mit Linux installieren, was tut man nicht alles für Drupal.

Trotz allem fehlen etliche Module für D8 und ich bin dafür einen Zwergenaufstand zu starten, das erstmal Drupal 8 mit allen wichtigen Abhängigkeiten bereit gestellt wird bevor plötzlich die erste D9 Dev zum Download bereit steht.

Frohe Ostern, Jenna

Wegen dieser Kleinteiligkeit der Bausteine bin ich bei Drupal, das ist eben der Unterschied zwischen einem CMS/Blog-System und einem CMF (F für Framework) wie Drupal.

Noch eine Anmerkung zum Vergleich mit anderen Systemem.

Ich denke schon, das alles, was Ronald schreibt, richtig ist. Und gleichzeitig ist es gut, wenn wir gut darauf achten, dass wir keine Vermutungen über andere Systeme schreiben, denn z.B. habe ich mal aus Langeweile in einem deutschen Typo3-Forum rumgelesen und da schrieb doch tatsächlich jemand über Drupal, dass das ein reines Blogsystem sei – schmunzel, schmunzel …

Bei diesem Zwergenaufstand wäre ich auch dabei – und ich kann mir nicht vorstellen, dass es soweit kommt.

Euch allen frohe Ostern

wo kann ich den die befhler eingeben? per putty? oder wie mache ich das?

@caw, ja genau - ich verwende Putty und WinScp als SSH Client.

danke für die info!

Ich gehe inzwischen auch davon aus, dass mit dem Ende von D7 einige Dinge ebenfalls am Ende sein werden, aktuell sollte ich z.B. die Quiz-Funktionalität und die Reservationsfunktionalität in Kundenprojekten umsetzen. Da muss ich gar nicht lange überlegen, das werden D7-Projekte sein, ich mag das System nach wie vor. Ich glaube nicht mehr, dass es diese Funktionen überhaupt je in D8 geben wird. Die "Adoption Rate" von D8 ist kleiner als diejenige von D6 damals.

Ebenfalls klar am Ende ist Drupal als System für Einzelentwickler. D8 ist für Entwicklungsteams und für grössere Enterprise-Anwendungen. Da hat D8, soweit ich sehe, echte Stärken gegenüber D7. Ich werde es wohl für eine Art Saas-Plattform für Kundenprojekte nutzen, die ich über längere Zeit aufbauen werde (aber mit einiger Sicherheit extern entwickeln lassen werde). Richtig gut ist scheint auch der Bereich Commerce auf D8, den ich ebenfalls weiterhin anbieten möchte.

Aber daneben habe ich halt viel mehr Kleinprojekte als Grossprojekte, die z.B. auch auf Shared-Hosting laufen müssen. Das sind keine Projekte für Drupal 8, da muss man sich als Kleinagentur nichts vormachen wollen (und auch keine Projekte für Drupal 9). Für Kleinagenturen ist eine KMU-Website inzwischen eine "Commodity", sie muss innerhalb Stunden zu 80% aufgesetzt sein. Jedes einst innovative Produkt wird irgendwann zur "Commodity", die einfach funktionieren muss.

Für Kleinagenturen ist es wohl vermutlich Pflicht, nach Alternativen zu suchen. Im Bereich der kleinen Sites ziemlich überzeugt hat mich bisher übrigens Backdrop CMS, auch wenn ich selber noch kein "richtiges" Projekt umgesetzt habe. Es ist rasend schnell (man merkt erst bei Backdrop, wie träge D8 ist), der Umstieg von Drupal 7 ist sehr einfach und es macht Spass, mit dem System zu arbeiten. Aber man soll anderseits nicht probieren, grössere Projekte damit umzusetzen. In einigen Bereichen ist Backdrop hinter D7 zurück, es gibt weder Rules noch Search API noch Entity Translation, Medienverwaltung ist mehr oder weniger D7 ohne Media-Modul.

Oder aber man verwendet weiterhin D7 für gewisse Projekte. Die "Adaption Rate" von Drupal 8 ist dermassen niedrig, dass es noch Jahre dauern wird, bis die Zahl der D8-Installationen (leicht steigend) die Zahl der D7-Installationen (leicht sinkend) erreichen wird. Drupal wird es sich gar nicht leisten können, irgendwann die nächsten Jahre mehrere hunderttausend D7-Installationen nicht mehr mit SIcherheits-Updates zu unterstützen.

Mehr zur Adaption Rate übrigens hier https://www.metaltoad.com/blog/sluggish-drupal-8-adoption-lags-even-d6

Wie Humor? So oder wie?

https://vimeo.com/263765910

Gut im Gegensatz zum Rest meiner Videos ist die Audiospur, na ja, aber der Humoransatz gefällt mir, wenn man den Humor denn nur immer treffen würde.

@mazze schreibt

Da ist dann die Frage, wer oder was stopft das Loch, wenn D7 dennoch weg ist?

Wir als Kleinagentur haben viele solche Projekte, wo Drupal-Funktionalitäten verwendet werden, die kein anderes CMS ersetzen kann. Also auf Basis von Views, Rules ect.

Ich sehe das nicht so, dass D8 nur für Enterprise sein wird.

Ich habe vor einiger Zeit angefangen, mir eine D8-Installation zurecht zu legen, die nur stabile Module enthält, die eigentlich jedes Kundenprojekt brauchen kann.
Und dazu habe ich mir eine SASS Entwicklungsumgebung eingerichtet und mich in Bootstrap eingearbeitet mit dem Ziel, möglichst schnell individuelle Designs technisch umsetzen zu können, so wie sie uns von Grafiker-Geschäftspartnern geliefert werden.
Und den Workflow bei Composer-Updates versuche ich auch noch zu optimieren.
Momentan komme ich nicht weiter, weil wir privat in einer Renovierung stecken und die Arbeitszeit voll in Kundenprojekte fließen muss.

Aber ich denke, wir sollten jetzt aufhören zu jammern und uns lieber darüber austauschen, mit welchen Strategien man sich D8 so einrichten kann, dass man auch kleineren Projekten die Vorteile von Drupal weiterhin zukommen lassen kann.
Ich bin sicher, das geht, vor allem, weil es ja immer runder läuft.

D7 wird uns noch eine ganze Weile erhalten bleiben. In der Issue Queue wurde von den Maintainern diskutiert, D7 noch bis zu einem Jahr nach einem D9-Release zu unterstützen (mit dem ich allerfrühestens 2020 rechne). Der Wechsel von D8 auf D9 wird relativ schmerzfrei gestaltet, es wird keinen kompletten API-Bruch wie bei 7/8 geben, der Wechsel soll dann eher mit Drupal 8.4 -> 8.5 vergleichbar sein.

Meine ersten D7-Projekte habe ich Ende 2011 umgesetzt, die laufen jetzt seit 7 Jahren und sind immernoch technisch auf dem aktuellen Stand. >10 Jahre Supportfenster für ein Open-Source-Produkt ist jetzt nicht so schlecht, finde ich :).

Ich denke auch, dass man dabei den Lebenszyklus einer Webseite mit im Kopf behalten sollte. Auch wenn wir für neue Projekte weitestgehend auf Drupal 8 setzen, haben wir bisher nur ganz wenige existierende D7 Seiten nach D8 migriert. Insbesondere, wenn die Webseite nicht das Hauptprodukt eines Unternehmens darstellt, sondern nur unterstützend agiert, kann man die nächsten Jahre wohl noch gut mit D7 leben. Es muss schon einen wichtigen Grund geben muss, für ein solches Upgrade zu zahlen oder er hat das Geld zum Investieren.

Zudem erleben viele Seiten (auch größere Portale) innerhalb von mehreren Jahren einen Relaunch. Bei solchen Relaunches wird nicht selten das Datenmodell so stark verändert, dass es ohnehin auf ein Neuaufsetzen mit Datenmigration hinausläuft (egal ob man jetzt upgraded oder nicht), statt die existerende Seite zu verhunzen. Und genau solche Relaunchs wären für uns dann der Punkt dem Kunden zu Drupal 8 zu raten.

Die Unterscheidung von Website als «unterstützend» respektive als Hauptprodukt scheint mir ein sehr gutes Kriterium, danke für den Hinweis:-)

Ach früher, ja, da war alles besser. Das Wetter war schöner und das Brot war billiger. Immer diese Scheiß Veränderungen ;)

Aber mal im Ernst: Die Umstellung von Drupal auf eine moderne objektorientierte Codebasis mit Symfony Komponenten war dringend nötig. Was war denn bis D7? Sitebuilder konnten relativ beschwerdefrei auch komplexere Sites zusammen klicken. Das ist ja schön, aber der Einsatz von unzähligen Contrib- Modulen führte doch letztlich häufig zu Inkonsistenzen und Site- Effekten. Dazu kam, dass Drupal Projekte mit jedem zusätzlich installiertem Contrib Modul langsamer wurden. D8 braucht zwar generell etwas mehr Rechenleistung, skaliert dafür aber nach oben ohne spürbare Performance Verluste. Das sind wesentliche Aspekte, wenn ein System im Enterprise- Sektor bestehen will.

Die Entwicklungen im Web verlangen nach immer leistungsfähigeren Websites. Auch hier hat Drupal 8 erfolgreich mit Services nachgelegt und verfügt über soviel mehr Power im Vergleich zu D7.

Composer und CLI's: Composer wird für die professionelle Webentwicklung zunehmend unverzichtbar. Wir arbeiten mittlerweile mit so vielen PHP Libraries, das es einfach eine Qual ist, diese manuell einzubinden. Für einfachere Projekte kann man aber auch vollständig auf Composer verzichten und D8 wie gewohnt installieren und updaten. Die paar Module, die den Composer wirklich voraussetzen, kann man an zwei Händen abzählen.

Kommandozeilen- Tools waren und sind immer noch die effektivsten Werkzeuge in der Webentwicklung. Eigentlich geht es gar nicht ohne. Was macht ihr denn, wenn ihr vor einem Server ohne ispCP oder Plesk steht? Sagt ihr eurem Kunden dann, "sorry das geht nicht, ich kenn mich mit Linux und der Konsole nicht aus"?

D8 ist nach wie vor auch für Freelancer und kleinere Agenturen ein leistungsstarkes und flexibles System. Aber die Bereitschaft, auch neue Techniken und Methoden zu erlernen, ist letztlich unabdingbar. Nichts ändert sich so schnell wie das Internet. Ich hatte jetzt zweimal Anfragen, um Content für Amazons Alexa zur Verfügung zu stellen. Drupal liefert mir schon mal die Schnittstelle, da brauch ich ja nur noch Scala lernen ;)

Klar kann man zu Wordpress rennen, weil man es gerne einfach hat. Natürlich hat man dann auch nur recht einfache Möglichkeiten.
Aber auch bei Wordpress macht man sich Gedanken, wie man sich für die Zukunft aufstellen soll. Ein konzeptioneller Umbruch und die Erneuerung der Codebasis wird wohl auch bei WP unausweichlich sein. Die Zielgruppe der "kleinen" Website- Betreiber entdeckt zunehmend neue Services wie Wix für kleine Firmensites oder leadpages für Online Marketer. Wordpress verliert langsam den Status der "Allzweckwaffe" bei diesen Anwendergruppen. Und reine Blogger schwinden schon seit Jahren...

@glycid Punkt für Punkt einverstanden... vielleicht war D8.0 für Sitebuilder(!) ganz einfach zu unausgereift, ich jedenfalls habe Tage mit völlig simplen Dingen verbraten und begann irgendwann an mir selber zu zweifeln, und die Codezeile ist mir übrigens durchaus vertraut;-) Es waren mehr die WSOD nach dem simplen Verschieben eines Feldes im GUI, oder was ähnliches, weniger Composer & Co.

Das Argument verstehe ich nicht. Wenn die Performance für größere Projekte optimiert werden kann, dann muss sie doch für kleine Seiten auch ausreichen.
Ich finde gerade die Performance einen großen Fortschritt von D8, auch wenn man nur den internen Cache verwendet.

Genau das sollte dringend wieder verdeutlicht werden. Ich habe mich letzte Woche mal in die Lage eines Anfängers / Umsteigers aus der Nicht-Entwicklerecke, und das ist die Zielgruppe über die wir hier auch reden, hineinversetzt. Da passiert folgendes: Du willst nicht zu Beginn direkt Fehler machen und gehst deshalb nach der "offiziellen" Drupal.org-Doku vor.

1. Direkt im ersten Schritt wirst du vor drei Möglichkeiten gestellt, Drupal erstmal herunterzuladen. Eine davon ist die via Composer, sie wird angepriesen als "recommended". Da denkt sich manch einer, gut, "Einarbeitungszeit in Neues gibt's immer wieder mal, dies hier scheint der zukunftssichere Weg zu sein, ich mache das also mal mit".

2. Du landest nach der Doku später wieder bei drei Wahlmöglichkeiten zur Installation mit Composer: Eine, die halbwegs "offiziell" klingt: "drupal/drupal" sowie zwei andere die schon irgendwie kryptisch scheinen. Du versuchst dich für die saubere zu entscheiden, "drupal/drupal".

3. Ab hier verzweigt sich die Doku auf verschiedene Unter-, aber auch Fremdseiten, die dir verschiedene Fixes erläutern, die du anwenden musst um fortfahren zu können, die dir aber alle wie temporäre Bugfixes erscheinen. Das willst du aber vermeiden, schliesslich bist du Anfänger oder Umsteiger. Ausserdem funktioniert keiner von denen, da sie vermutlich veraltet sind.

4. Bei der favorisierten Installation via drupal/drupal wird dir mitgeteilt, dass du bei dieser Art der composer-Installation deine Site niemals mit Composer aktualisieren kannst (kein Core-Update, nur Module). Du beginnst dich zu fragen "Moment mal, wieso mache ich diese Composer-Installation eigentlich? Und du weisst, du hast es gemacht, um später den Composer-Weg weiterzugehen, zu dem du auch gedrängt wirst. Quatsch!

5. Die Installation nach Anleitung ("drupal/drupal") schlägt fehl. Du bekommst eine Site ohne "vendor"-Verzeichnis. Jetzt darf ein Anfänger / Umsteiger die Doku nach Hilfe durchforsten, was man falsch gemacht hat, oder was noch nicht richtig funktioniert.

6. Das Durchforsten der Doku schlägt auch fehl, denn die Doku ist an dieser Stelle schlicht noch nicht fertig - falsch, inkonsistent, inkonsequent. Du wirst von Seite A nach Seite B und zurück gelenkt - ohne funktionierende Lösung. Auch die Erkenntnis, dass du zu Beginn eine andere Installationsart hättest wählen sollen, ist dabei.
Ein Profi ist ein solches Theater gewohnt und findet irgendwann den Weg, am besten .json-Datei selber editieren, oder was weiss ich, ein Anfänger nicht.

Am Ende hast du aber viel gelesen und weisst nun, das der ganze Composer-Workflow irgendwie nur für Entwickler Sinn macht, die spezielle Module bauen, aber nicht für dich. Also die Empfehlung von glycid, gehört in Punkt 1. der Doku:

Gehe NICHT am Anfang den "recommended"- Weg der "offiziellen" Doku, sondern lade und entpacke das Zip wie immer und mache Updates später über GUI oder Drush 8 (die du nicht mehr bekommst).

Composer ist für später, jetzt bestenfalls für Profis, Entwickler. Und mir liegt übrigens jegliches Composer-Bashing fern. Das ist nur mein Ergebnis eines paartägigen Versuchs.

Ich glaube hier wird das strategische Ziel verfolgt, die User irgendwann in den Composer Workflow zu bringen, bei dem man davon ausgeht, dass er mit der Zukunft immer und immer wichtiger wird. Könnte sinnvoll sein. Aber die breite (angepeilte) Nutzerbasis ist bei dem Tempo überfordert.

Ob ein Modul Composer benötigt oder nicht, sollte noch zuverlässiger in der Beschreibung der Module unterschieden werden.
Wäre toll, wenn es als Filter zum Auswählen bei Modulen angeboten werden würde.
Dann könnte man für Projekte, bei denen der Aufwands-Ball flach gehalten werden muss (Shared Hosting), auf solche Module bewusst verzichten.
Mein erstes Kunden-Projekt, dass ich forsch auf D8 umsetzen wollte, lief nicht rund, weil bei einem der PDF Module nicht erwähnt war, dass es Composer benötigt.
Irgendwo in den Issues fand ich dann die Entschuldigung vom Entwickler, dass er das leider in der Doku vergessen hatte zu erwähnen.
Inzwischen weiß ich, wie ich raus finde, ob ein Modul Composer benötigt, aber als D8-Newbe sieht man oft der Wald vor Bäumen nicht.

wenn ich das hier alles lese.
Ich habe Linux, arbeite aber nicht mit Kommandozeile. Das kann ich nicht und will ich auch nicht. Ich möchte nur Button klicken und dann ist alles gut.
Es muss alles einfach, einfach und verständlich sein. Kommandozeilen sind was für Programmierer aber nicht für User. Ich möchte als User eine Seite erstellen und nicht Programmieren. Für D7 gibt es ja noch eine vernünftige Beschreibung für Installation und Update die mir für D8 völlig fehlt. Hier wird meine Hand von den Erklärungen sehr schlecht geführt.
Ich bin von Drupal begeistert und hoffe D8 bzw. D9 wird für Erstanwender in der Installation und beim Update wieder leicht zu handhaben.Einfach = Update durchführen: ja klicken und fertig.
Donacki

Leider ist das eine sehr landläufige Meinung. Meine Kommandozeile macht so vieles so viel schneller als mit 3 Mausklicks, Einfach, weil ich Tippen kann. Natürlich könnte man jetzt sagen, 3 Mausklicks,. dass ist ja nix, aber wenn du das mit beispielsweise 100 Multiplizierst, dann ist das schon ein Pappenstiel. Schreibst du also ein Skript, für beispielsweise die Installation von Drupal bist du beim ersten mal vielleicht noch langsam Hast du dein Skript bei 20 Kunden eingesetzt hat sich der Aufwand für das erste mal bereits mehr als gerechnet, wenn du dein Skript anstößt und derweil etwas anderes arbeiten kannst. Die Kommandozeile zu vereufeln, ohne jemals damit gearbeitet zu haben, ist schlicht weg nicht in Ordnung. Alleine der Umstand, dass Microsoft jetzt die bash Shell sogar unter Windows eingeführt hat, beweißt, dass eine Kommandozeile nicht persé schlecht ist. Eher, dass Microsoft in den Letzten Jahrzehnten seinen Nutzen die Verwendung der Kommandozeile konsequent aberzogen hat. Das Ergebnis dieser Maßnahmen sind Aussagen wie deine. Aber das muss jeder selber wissen. In diesem Punkt gibt es nur subjektive Meinungen und ich nehme mich da auf keinen Fall aus.

Ich hole die Diskussion noch einmal nach oben, um euch zu zeigen, dass ihr tatsächlich direkt Einfluss auf die Drupal-Con hattet. Direkt auf die Keynote von Dries. Baddysonja hat eure Antworten, zumindest einige Davon ja direkt mit nach Nashville genommen. und tatsache ist, dass dries auf einiges davon reagiert hat. Beispielsweise darauf, dass die Installation von Drupal aktuell zu hart im gegensatz zu anderen Content Management-Systemen ist. Überzeugt euch selbst.

https://youtu.be/8HkOdpNT8Ec?t=36m6s

Die Kommandozeile ist überhaupt nicht was nur für Programmierer. Als es noch keine grafischen Benutzeroberlfächen gab, war die Kommandozeile der Normalzustand, und jeder Jugendliche, der zocken wollte, hatte überhaupt kein Problem damit umzugehen.

Danke besser hätte ich es auch nicht sagen können.

Wenn ihr wisst welche Codes in die Kommandozeile geschrieben werden müssen ist das gut für euch.
Ich weiß es nicht.
Deshalb ist klicken auf fertige Skripte für mich einfacher und deshalb sollte man auch an solche User denken.

Ich bin alt genug, das Zeitalter der Kommandozeile-Bedienung noch erlebt zu haben. Es ist wohl eine Diskusission zwischen Leuten, die täglich stundenlang mit Drupal arbeiten (und dann sinnvollerweise die Kommandozeile nutzen) und anderen, die mal eben was aufsetzen oder ändern möchten und sich zwischendurch mit vielen anderen Dingen befassen, etwa in Kleinagenturen. Wie Anfang Jahr beschrieben, gehöre ich auch zur zweiten Gruppe und kann eine Blick auf Backdrop CMS nur empfehlen: https://mazze.ch/backdropcms

Ich denke an nichts anderes mehr.

Diese Art von User ist Bestandteil meiner schlaflosen Nächte. Genau wie diejenigen, die nicht müde werden Xampp, Bitnami-LampStack und AquiaDevDesktop als ernsthafte Alternativen zu einem Linux-Server anzupreisen. Diese Sorte Mensch beschert mir echte Migräneanfälle, weil es nicht ganz einfach ist darzulegen, warum Windowsprodukte eine miese Idee sind. Auch, wenn man da nur herunterladen und klicken muss. Die Schweinepriester funktionieren nämlich auch noch... bis... ja bis sie eben nicht mehr funktionieren. Und das tun Sie in der Regel bereits dann nicht mehr, wenn ihre Setup-Assistenten Drush oder Composer Systemweit zum Laufen bringen sollen.

Donacki keiner von uns kannte beispielsweise die Befehle, die es braucht, um Drupal mittels Composer zu installieren. Wir hatten in Drupal 7 keinen Composer. Aber wir haben

1. Gelesen
2. Angewendet
3. und verstanden

und jetzt können wir plötzlich Dinge, von denen wir vorher keine Ahnung hatten.

Jetzt kann ich dir sogar ein Skript schreiben, auf das du Klicken kannst, um Drupal 8 unter Linux vollautomatisch zu installieren. Mit Composer, drush, git, zip und allem, was dazugehört. Und wenn ich möchte, dann hänge ich dieses Skript direkt an eine Linux-Iso, sodass du maximal noch deine Benutzerdaten eingeben musst, um die Installation zu starten.

Würde ich versuchen dasselbe unter Windows zu machen, würde selbst ich kläglich scheitern.

Schade finde ich es nur, wenn jemand von sich behauptet er wisse nicht wie die Kommandozeile funktioniert. Es ist noch gar nicht so lange her, da gab es nichts anderes. Selbst Kinder, die Computerspiele spielen wollten wussten, wie die Kommandozeile funktioniert. Nur, weil wir aufgehört haben Computerspiele zu spielen, und stattdessen lieber mit Drupal spielen, um Geld zu verdienen, müssen wir doch nicht vergessen, was für unsere Großeltern normal war. Lesen, Anwenden, verstehen, Umsetzen. Dann klappt's auch mit der Kommandozeile wieder.

Ich glaube, dass jeder der möchte sich so entsprechendes Wissen aneignen kann. Wer nicht möchte, der darf auch weiter klicken und sich über das Ergebnis am Ende der Skriptausführung freuen.

Und vor allem braucht man im Alltag vielleicht ein halbes Dutzend Befehle, da reicht es schon sich eine einseitige Doku für sich selbst anzulegen.

Dem Rest kann ich leider nicht zustimmen. Ich verwende seit zwei Jahren D8 mit Xampp ohne Probleme, erst unter Win 7 und jetzt 10 und ich wüsste nicht, was dagegen spräche, so weiterzumachen.

Bei der Nutzung der CLI geht es nicht darum, Menschen auszuschließen, die sich nicht die Zeit nehmen können oder wollen, Drupal mit der Kommandozeile zu verwalten. Es gibt aber aus der Perspektive der Sicherheit im Moment keinen anderen sinnvollen Weg als per CLI den Code zu verwalten. Neben anderen Vorteilen sollte vor allem eine Web-Anwendung sich nicht selbst verändern können. Und die offiziellen Drupal Security Empfehlungen sehen genau das vor, obwohl man das bei den meisten Hostern gar nicht umsetzen kann und sich anscheinend auch viel zu viele Drupal-Betreiber auch gar nicht darum kümmern.
Das heißt eine sichere Klick-Lösung für Drupal-Updates könnte nur außerhalb von Drupal liegen/betrieben werden. Vor allem kann so etwas nur in Zusammenspiel eines bestimmen Hosting-Setups funktionieren und das heißt nur Hoster könnten das bereit stellen, wenn es Interesse dazu gäbe.
Somit ist es aktuell keine Frage, wie lange man sich täglich mit Drupal beschäftigt, ab wann es sinnvoll wird die CLI zu benutzen. Meiner Meinung nach es eher eine Frage, ob man sich gut genug mit PHP-Webanwendungen im Allgemeinen und Drupal/Backdrop im Speziellen beschäftigt hat, um diese sicher betreiben zu können.
Ein Community-Lösung zur sicheren Code-Verwaltung, die überall funktioniert wäre wahnsinnig komplex und dafür sehe ich aktuell kaum die Energie, da es schon genügend andere Bereich gibt, bei denen wir viel zu wenig Voluntär-Energie haben. Letztlich sind wir alle immer davon anhängig für welche Themen sich Voluntär-Energie findet und was die Leute für machbar halten. Hier werden sicher nicht explizit Entscheidungen getroffen, um Anfänger usw. auszuschließen. Es ist bezüglich Composer einfach so, daß dessen Einsatz die Arbeit der Programmierer ganz extrem erleichtert. Und als klar wurde, daß es mit Composer für viele sehr schwierig wurde, noch Code von Drupal-Org zu nutzen entstand auch eine Community-Lösung namens Ludwig um Download-Pakete zusammenstellen zu können.

Da Composer übrigens relativ viel Arbeitsspeicher erfordert, neige ich dazu, Composer nicht mehr direkt auf Produktiv-Servern einzusetzen, sondern dort den Code nur noch per Git auszurollen. Das heißt, auch wenn man es schafft Composer grundsätzlich bei irgendwelchen Hosting-Paketen zum Laufen zu bringen ist es nicht unbedingt der beste Weg es dort direkt vor Ort zu nutzen.

Danke für diese tolle sachliche Erklärung.

Als ich vor zwei Jahren meine erste D8-Seite erstellt habe, habe ich für meinen Kunden einen geeigneten Hoster gesucht und einige direkt angeschrieben. 8 der 10 Hoster, die ich kontaktiert habe, haben SSH-Zugang und unterstützen die Ausführung von Composer, Drush und git im Shared Hosting oder haben Teile davon schon vorinstalliert. Selbst bei 1&1 habe ich eine D8-Installation mit git und Composer problemlos zum laufen gebracht. Somit kann man sich bei der Hoster-Suche getrost auf andere Kriterien wie SSD-Webspace und -Datenbanken konzentrieren.

Hier sollte man unterscheiden, ob man composer update oder composer install verwendet. Der hohe Speicherverbrauch kommt bei composer update zustande, weil irgendwie die ganzen Abhängigkeiten durchgerechnet werden müssen. Darum sollte man diesen Befehl nur auf der lokalen Entwicklungsinstallation verwenden. Auf dem Webserver reicht dann die Ausführung von composer install, denn nun steht bereits fest, welche Versionen heruntergeladen werden müssen. Hat man auf dem gleichen Server eine parallele Testinstallation, wo man die Updates zuerst installiert, muss Composer in der Production-Installation die Updates nicht mal mehr herunterladen, sondern zieht sie einfach kurz aus dem Cache. So dauert das Update eines Moduls nicht mal mehr als eine Sekunde.

Johny, was 1&1 angeht, war dann offensichtlch auch Glück dabei.
Bzw. die versch. Composer-Befehler schlucken vielleicht auch unterschiedl. viel Memory.
So wie Du schreibst, update mehr.

Ich hatte da schon Probleme, dass memory nicht reicht, obwohl der PHP-Befehl zum Ausführen von Composer mit hochgesetztem memory durchgeführt wurde.
Ich habe das mit dem Support von 1&1 besprochen und die meinte, das sei bekannt und würde sich nicht ändern in absehbarer Zeit.
Man sollte das Update besser außerhalb durchführen.

Bei All-Inkl. habe ich dagegen schon häufiger composer Update ohne Problem durchgeführt.

Also ich kann mich Mazze nur anschliessen.
Ich werde ausschliesslich Backdrop CMS verwenden und
für die meisten Seiten kein D8 einsetzen.
Dafür gibt es für mich zig Gründe, was mich aber letzten Endes überzeugt hat,
ist hier sehr gut zu sehen.
Ich werde das noch in den Showroom stellen und würde mich über Feedback freuen.
https://backdrop.awri.ch/

VG
Robert

Ich sehe Europa weit keine Alternative zu Drupal 8 im Open Source Bereich.

Ich hatte in meinem Leben eher selten ein Probleme Drupal zu installieren.

Ich bin seit Jahren aber nur noch mit Linux Unterwegs, und bereue es keine Sekunde.

Ich kann euch in dieser Hinsicht nicht verstehen, so wie einige mich hier ja nie verstehen wollten.

Ich lese nur dass einige sich null Millimeter bewegt haben

Am liebsten würde ich mein PC ja nur noch mit der Konsole steueren,

Was ich dann ab Fedora 30 mit einer frischen Installation soweit auch in diese Richtung einrichten werde teils mit Emacs

---

Was sind das für Kunden die Shared Hosting wollen, zu genügend steht geschrieben warum man es vermeiden sollte

das steht ja schon bis zum überlaufen im Netz, und stimmt ja so

fertige Skripte sollte man zu erst einmal durch lesen

für mich ist nichts einfacher wie Drupal zu installieren, wenn mein Env. steht.
Wie kann man eigentlich sowas behaupten,

Ich habe ja schon etliche Anwendungen mit Composer installiert die weit aufwendiger sind diese dann ans laufen zu bekommen

Dagegen ist ist Drupal finde ich persönlich die einfachste Installation die es auf diesem Planeten gibt.

Video ddev drupal composer update https://youtu.be/8lLW38BG_OE

Ich dachte DrupalVM wäre Vergangenheit
Ausserdem war ich nie zufrieden damit,
Nie wieder und seit langen verwende ich keine DrupalVM

lando, ddev

Ich kann nicht verstehen wo Ihr euch bewegt doch nicht in der Drupal Community ( nicht persönl. an u/c_logemann )

Wie man das behaupten kann ist ungefähr so einfach, wie Kuchen backen. Es gibt hier in der deutschen Community so viele Nutzer, die einfach keine Lust auf die Kommandozeile, Composer oder gar Linux haben. Sie arbeiten nach wie vor mit FTP und Shared-Hosting.

Wenn du einem solchen User jetzt erzählst, dass Composer zeitweise 1.5 - 2 GB RAM schluckt und er dahinter kommt, dass das bei seinem Hoster für 1,50 im Monat nicht taugt, dann geht er zu Backdrop-Cms oder Wordpress, weil er dort weiter mit FTP arbeiten kann.

Auch Für ist für viele dieser Anwender ein Buch mit 7 Siegeln

Tatsächlich ist die Installation mit Composer sehr viel einfacher und angenehmer, als von dieser Zielgruppe wahrgenommen, aber das interessiert diese Zielgruppe nicht. Ich find es gut, dass du anhand eines Videos versucht hast zu zeigen, wie Ddev funktioniert, muss aber auch feststellen, dass sich diesen Stummfilm wohl nur die wenigsten ansehen werden. Schnapp dir Lieber ein Mikrofon und mach's nochmal. Ganz langsam. Die Deutsche Drupal-Community braucht ganz viel Aufklärung und Mentoring.

Angefangen dabei, warum ein V-Server für knapp 10 € mehr Sinn macht, als der Shared-Hosting-Webspace für 1,50 im Monat.

Ich finde das ja auch traurig. Aber hier in De sind das leider die Fakten. Du wirst nicht glauben wie viele Kunden es gibt, die ernsthaft glauben, dass Sie die Schnittstelle Ihres Auftritts im Internet auf einen Server für unter 10 euro I'm Monat stellen. Dann arbeiten Sie irgendwie am ersten Besucheransturm und Zack bricht eben dieser Internetauftritt zusammen. Schuld ist dann natürlich nicht etwa der, der den Webspace gekauft hat, sondern Drupal. Das nenne ich verdrehte Welt.

Ich finde auch, dass die Installation per Composer keine Hexerei ist... aber wenn jemand das partout nicht will, dann ist es halt so. Aber das Problem bei D8 liegt doch vielmehr in der generellen Handhabung bei der Entwicklung: ich habe Stunden verbracht rauszufinden, wie ich den TWIG-Cache ausschalte. Oder bei kleinsten Fehlern im Template erscheint ein weisser Bildschirm, und dass ein Fehler im Template diesen verursacht, muss man zuerst einmal rausfinden. Ich rede da ingesamt von Tagen, nicht von Stunden. D8 war über mehrere Releases zudem voller Bugs, deren Umgehung fundiertes Programmierwissen erfordern. Mit 8.6 hat sich die Situation wie bereits erwähnt aber deutlich verbessert, für mich was dies der erste "Sitebilder-Release". Schade um die wirklich gute Software, ich mag Drupal nach wie vor sehr und werde schrittweise eine Commerce-Plattform damit bauen. Aber kleinere Projekten gehen bei mir künftig zu Backdrop.

Ich würde hier gerne kurz meinen Eindruck schildern: Ich persönlich habe das Problem, dass ich seit 4 Jahren immer wieder an Projekte und Arbeitgeber geraten bin, in denen ich Drupal 7 Projekte aufräumen musste, die vorher leider schlecht umgesetzt wurden (einige wurden regelrecht in den Sand gesetzt). Die Kunden/ Arbeitgeber wollten dann nicht gleich wieder alles neu machen, sondern hatten das Bedürfnis, die bisherige Arbeit irgendwie zu retten.

Kurzum: Der Wechsel zu Drupal 8 gestaltet sich bei mir so schwer, weil ich mit alten Drupal 7 Projekten beschäftigt bin. Zwei/ drei Projekte habe ich nun auch schon mit Drupal 8 umgesetzt und bin schon schwer verliebt. Hier bei meinem jetzigen Arbeitgeber Abgeordnetenwatch.de bereiten wir gerade den Drupal 8 Wechsel vor, aber danach werde ich sicher keine Drupal 7 Projekte mehr annehmen.

Es ist halt ein riesen Sprung von Drupal 7 auf 8. Man kann nicht erwarten, dass die alten Drupal 7 Projekte mit einem Satz auf 8 gehen, was Entwickler-seitig ganz andere Skills erfordert und was eben einen kompletten Neubau der meisten Projekte nötig macht. Drupal 7 war sehr erfolgreich, die Betreiber sind aber entweder finanziell/ ressourcentechnisch nicht in der Lage, nach wenigen Jahren einen kompletten Relaunch zu machen - oder sie wollen es einfach nicht. Dass sich der Wechsel zu drupal 8 so hinzieht finde ich vor diesem Hintergrund völlig verständlich.

Was ich allerdings nicht verstehe, sind diejenigen, die sich diesen neuen Paradigmen in Drupal 8 verschließen - entweder mit solchen Forks wie BackDrop (wo das Rückwärtsgewandte ja schon im Namen steckt) oder indem sie einfach weiter Drupal 7 auch für neue Projekte verwenden. Ich verstehe, dass die Lernkurve steil ist, gerade wenn man wie ich autodidaktisch mit Drupal die PHP-Entwicklung gelernt hat und nun verstärkt mit CLI, OOP und Composer arbeitet. Das ganze macht Drupal 8 so geschmeidig in der Entwicklung und so unglaublich flexibel und dabei stabil - ich kann es einfach nur jedem empfehlen, den Drupal 8 Wechsel möglichst schnell in die Wege zu leiten.

Auf die Gefahr hin, mich zu wiederholen: composer update braucht diese Massen an RAM, beim Hoster wird jedoch nur composer install ausgeführt, um die Updates zu ziehen und ist das auf Shared Hosting-Umgebungen meist ohne Probleme möglich. Hohe Zugriffszahlen sind dann natürlich eine andere Sache, aber nur wegen Composer braucht man keinen Server mieten.

Ja Jonny, dass stimmt. Wir benutzen ja in der Community auch eigentlich das Prinzip von Dev. Stage. Und Prod.

Aber erkläre das Mal jemand, der noch nie was von Git gehört hat. Mir ist neulich doch ernsthaft die Frage gestellt worden, ob man dann 3 Server für ein Webprojekt kaufen muss. Ich hab dann kurz tief durchgeatmet und bin zum Heulen auf die Toilette. :-D

Und dann haben wir den Rest des Tages einem technisch sehr Interessierten Entscheider den Development Workflow von Drupal erklärt. Jetzt ist er Happy und offenbar Drupals neuester Fan.

Der Kunde braucht plötzlich auch kein FTP mehr, sondern synchronisiert von Dev über Stage auf Prod und dass mittels SSH und git. Aber bis du an den Punkt kommst, an dem jemand begreift, warum das gut für ihn ist und dass in diesem Fall maximal noch ein Befehl ausgeführt werden muss, um den Prozess anzustoßen, hatte ich gefühlt den 7. Cappuccino. Das muß man halt auch Mal sagen.

Für alle die sich schwer tun mit Linux ist Docker schnell eine Umgebung zum Testen.

Letztes Image von Centos ( oder Ubuntu, Debian ) herunterladen; dauert einige Sekunden

Centos im Interaktiven Modus starten
- Nun kannst du alles ausprobieren ohne zu zögern

Zum Testen habe ich eben selbst so Composer, Drush Wrapper, Git, Docker, Docker Compose und ddev installiert
eigentlicher Aufwand fast nicht messbar.

Eignet sich sehr gut zum Testen bevor man später das gleiche in einer Virtuellen Maschine wiederholt.

Ja, Mustardseedmedia, das waren noch Zeiten...

genau - siehe link weiter unten, bzw oben;

OSTraining - das Buch zu D7 war meiner Meinnung nach das beste D7-Buch; und es gab dazu reichlich. Was man zu D8 leider nicht sagen kann, erst kamen einige Bücher zu früh raus, d.h. mit Freischaltung von D8, dadurch waren sie schon wenige Wochen danach veraltet, man erinnere sich, D8 hat anfangs gleich einschneidende Änderungen, das besonders die Modul-Entwickler verärgerte. Und Bücher wollte wohl auch keiner mehr schreiben.
Die videos zu D8 auf OSTraining kenne ich nicht, denn OSTraining hat ja 60+ videos (für Acquia?) erstellt, die kostenlos bei youtube zu sehen sind. Auch schon alt inzwischen, aber mir gefielen sie damals. Bin allerdings nie bis Teil 60 gekommen, kann also nicht sagen, wie tief sie gingen, wahrscheinlich auch nur für Anfänger.

Noch bin ich nicht in die Tiefen von D8 eingedrungen, das überlasse ich wla, bin mit anderem beschäftigt, aber die Paragraphen machen richtig Spaß.

Nicht zu vergessen Randy Fay's videos auf nodeone.se. Ein Teil davon ist immer noch auf der Website von Drupal Commerce zu sehen...

Sehr empfehlen kann ich allerdings drupalize.me, wenn es um Schulungsvideos für Drupal geht. Sie sind kostenpflichtig, aber das Abo kann jederzeit gekündigt werden (ich löse es alle paar Monate wieder), aber den Preis mehr als wert.