Drupal 7 oder 8 für neue Projekte?

Würde momentan Drupal 7 nehmen wenn es etwas mehr ist als eine normale Firmenpräsentation.

Viele Module aus D7 sind in D8 noch nicht verfügbar, am besten du guckst die benötigten Module vorher durch die du bei D7 einsetzen würdest ob Ersatz dafür in D8 verfübar ist.

Grüße Jenna

Na ja dass kommt darauf an :-D Natürlich spricht vieles für Drupal 7

Das ganze Drupal-Center schwört auf 7 und zum schnellen Umsetzen eines Projektes ist es mit Sicherheit auch die richtige Wahl. Man darf nur nicht vergessen, dass auf Grund der Unterschiede der Architekturen von Drupal 7 oder Drupal 8 auf keinen Fall all zu schnell migriert bzw benutzerdefinierte Module auf D8 umgestellt werden können. Also Entweder du nimmst D7, bleibst dabei und hoffst, dass dein Kunde nie auf die Idee kommt, nach D8+ zu fragen und der LTS für D7 noch lange lange Zeit weitergeht, oder du beißt in den saueren D8-Apfel und machst Abstriche beim Funktionsumfang zugunsten von Zukunftssicherheit. Das kommt auf den Kunden und das jeweilige Projekt an. Jenna hat im Grunde aber natürlich Recht. Wenn du dich mit Drupal 7 auskennst und nicht neu damit beginnst, dann kannst du D7 durchaus noch 20 Jahre verwenden.

Gut, dann bleibe ich auch bis 2038 bei Drupal 7 (wenn du das sagst), kicher...

Grüße Jenna

Windows XP oder Windows 10?

Drupal 8 erfordert etwas Umdenken, und ein paar Module, die für bestimmte Aufgaben nötig sind, gibt es noch nicht.
Mir fehlt zum Beispiel das Full_Calender_Module, mit dem übe einfach Views direkt Eventkalender befüllt werden können.

Dennoch, wenn es keine solche Abhängigkeit mit einem alten Modul gibt, sollte man das modernste System einsetzen, weil es in modernen Umgebungen am besten läuft.

Hmm...wie soll das funktionieren, wenn es keine Sicherheitsupdates mehr gibt?
Und selbst alles patchen ist vermutlich so aufwändig, wie sich in Drupal 8 einarbeiten und fehlende Funktionalitäten mit einem Modul ergänzen.

Ich selbst habe gar kein gutes Gefühl dabei, sehr umfangreiche D7 jetzt noch anzubieten.
Finde es schon fast fahrlässig.

Eigentlich absurd, dass ausgerechnet die einfacheren Projekte sich problemlos unter D8 umsetzen lassen und für komplexe Dinge soll man noch D7 verwenden.

Diese Aussage hat natürlich nichts damit zu tun, dass ich mir nicht wünschen würde, dass es D7 noch 20 Jahre gibt. ;-)
Weil wir sehen hier natürlich auch im Regen wegen fehlender Module.

kurzer Blick auf die Uhrzeit, o.k. Kaffee Mangel im montviso büro...ich habe das als Schreibfehler aufgefasst (nicht 20 sondern 2 Jahre waren sicherlich gemeint.)

Grüße Jenna

Hmmm....Kaffee Mangel kann schon mal dazu führen, dass man einen Spaß nicht versteht.
Und bei Drupal ist meine Fähigkeit zum Humor auch MIT Kaffee eher gering. ;-)
Ich habe das durchaus als ernst gemeint gelesen, weil zwei Jahre wären ja völlig im Rahmen.
Solange gibt es ja sicherlich noch offizielle Sicherheitsupdates.
Nur kann ich dem Kunden kein komplexes System aufs Auge drücken, dass nach zwei Jahren schon wieder ein derart aufwändiges Update benötigt.
Oder, was meinst Du?

Gerade Drupal ( aber auch die meinsten anderen Framework-Systeme) tauscht doch bei großen Versionssprüngen gern komplett mal eben den Core aus - salopp gesagt. Jedenfalls sind Updates von "alten" Seiten auf neue Systeme unter Beibehaltung der Themes/Templates für meine Kunden oft zu teuer.
Kleinere Seiten erstelle ich mittlerweile am liebsten nur noch mit JS-Frameworks, wie Backbone o.ä.

Na so ganz ernst gemeint war's nicht und Schreibfehler war's auch keiner. Allerdings muss man schon genau abklappern was der Kunde will und dann seine Module zusammensuchen. Auch wenn ich nach der Driesmode in Nashville durchaus dass Gefühl habe, dass unser Feedback zu D8 im Bezug auf Composer usw. angekommen ist. Ob das Hilft, was die Anzahl der fehlenden Module angeht wage ich zwar zu bezweifeln. Erlicher Weise mussan aber auch sagen, dass es für vieles bereits Lösungen in Kernsystem gibt, für das ich früher ein Zusatzmodul gebraucht hätte. Drupal Commerce ist hier ein Paradebeispiel.

Interessant, muss ich mich näher mit beschäftigen.
Ich dachte, das sei mangels Rules noch total hinten dran...
Danke für die Info.

Das haben aber dann wohl einige Hoster noch nicht begriffen ... was modernste heißt

viele Hoster bieten heute schon PHP7 und fordern ihre Kunden mehr oder weniger intensiv dazu auf, ihre Anwendungen darauf umzustellen.

Hoster brauchen immer eine Zeit lang, auch weil sie eine große Bandbreite an Kunden zu bedienen haben.

Unbedingt mal ansehen. Rules war nicht soweit, also haben sie das selbst gelöst. Überhaupt ist commerce eine gute Quelle, wenn man Lösungen / Codedesign Ideen sucht - finde ich jedenfalls.

Danke, Olafkarsten, schaue ich mir gerne an.

bin zwar spät mit der Antwort dran - aber trotzdem

Ich habe gerade 2 Projekte mit D8 aufgesetzt. Bbeim ersten kamen die Nutzer und wollten Bilder nur skalieren, wie gewohnt mit Editor. Da hängt es schon. Das Media Modul ist irgendwie mit dem viel zu frühen Tod von Aaron in D8 nicht viel weitergekommen.

Bei einem andern sollten dann PopUp Videos eingebunden werden.

Bei beiden bin ich dann lieber wieder zu D7 zurück. Die Arbeitszeit kann ich mir von der Freizeit abziehen :-(

Nun der große Nachteil: alles stürzt sich bei der Enwicklung von Themes auf D8 und etliche D7 (Kauf) Themes werden nicht mehr angeboten.

Auch kostenfrei Themes werden nicht mehr gepflegt: https://www.drupal.org/project/nucleus

Hier kommt nun immer eine Sicherheitswarnung weil ein Subtheme das im Kundenauftrag entwickelt worden ist auf Nucleus aufbaut. Nun sag mal dem Kunden, dass seine Investition umsonst war, bzw nach 17 Monaten abgeschrieben werden muss.

Nun nehmen die Entwickler D9 in Angriff und D8 ist außer bei Standartanwendungen mehr als eine Baustelle.

Insgesamt bin ich mit der Situation mehr als unzufrieden

Ich kann dich gut verstehen, wenn du auf sicher setzen willst, kann ich dir wirklich nur bootstrap als theme empfehlen, weil es für D7 und D8 gepflegt wird und sicher auch später für D9.
https://www.drupal.org/project/bootstrap
Auch wenn es gute andere Themes gibt, sind die eben nicht so weltweit verbreitet, das sie alle Versionen abdecken.

Soweit ich sehen kann, passiert aber noch nichts in Richtung D9, siehe hier: https://www.drupal.org/project/drupal/releases?api_version%5B%5D=39794

Wäre ja auch noch schöner, wenn jetzt D9 in Arbeit wäre, ich kann nach 1,5 Jahren Drupal 8 immer noch nicht updaten, weil etliche Module aus D7 fehlen, und auch kein brauchbarer Ersatz aufzutreiben ist.
Ich bleibe weiterhin bei D7 und gucke nebenbei wie sich die Module für D8 weiter entwickeln, der Zustand momentan ist für meine Anforderung eine echte Katastrophe und ein Ende ist auch nicht absehbar.

Und hilfreiche Kommentare wie "schreib am besten ein eigenes Modul" sind dann auch wahnsinnig hilfreich. Mich nervt dieser Zustand auch gewaltig, da ich bei einem Update gezwungen wäre externe Agenturen einzuschalten, einfach weil es zu komplex wird oder modulseitig einfach nicht verfügbar ist.

Insofern kann ich dir nur empfehlen auf eine Basis wie Bootstrap zu setzen, denn das was dir gerade mit deinem Theme passiert, kann dir mit jedem anderen Theme (welches nicht die Verbreitung wie z.B. bootstrap hat) immer wieder passieren.

Grüße Jenna

Also ehrlich gesagt finde ich es etwas erschreckend, dass man Leuten im Drupalcenter für neue Projekte Drupal 7 empfiehlt.
Man könnte es andersum auch als ein Beleg für das Scheitern von Drupal 8 sehen.

Ich persönlich finde ziemlich wenig, was für Drupal 7 spricht.
Klar: so Sachen wie Video Popups muss man evtl. selber bauen, was nicht trivial ist (gerade selber gemacht).

Habe in letzter Zeit mit einigen Leuten gesprochen, die Drupal 8 nicht verwenden und konnte deren Argumente auch nachvollziehbar.
Drupal 8 hat einen klaren Schritt Richtung Enterprise gemacht. Man kann es, wenn man nur FTP verwendet, kaum noch auf den Server wuppen. Einmal alles löschen und wieder neu hochladen - für Sicherheitsupdates - dauert schon mal eine halbe Stunde.

Dann dieses ganze Composer-Gedöns: es wird nicht klar kommuniziert seitens des Core-Teams, dass man das überhaupt nicht verwenden muss und es auch so geht, aber es sorgt für große Verunsicherung. Und die Doku sorgt noch mehr dafür, wie dieses bekannte Selbsexperiment zeigt: http://matthewgrasmick.com/compare-php-frameworks

Der Schritt Richtung Enterprise s.o. bedeutet finde ich konkret:
- Drupal 8 eignet sich deutlich weniger für Leute, die auch noch andere CMS-Systeme anbieten und Drupal nur nebenbei machen
- Leute, die sich nur hobbymäßig mit Drupal beschäftigen, werden bei vielen Dingen, die über reines Sitebuilding hinausgehen, schnell frustiert sein.
- Die ganze Lingo der Dokumentation und das Bild, das gezeichnet wird, spricht die Sprache: "Hobbyentwickler, lerne es richtig oder bleib weg". Diese ganzen Begriffe wie Dependency Injection, Controller, Service, Plugin usw. sind scheinbar vor allem dazu da, um Leute einzuschüchtern :D

Insofern kann man es den Leuten nicht vorwerfen, wenn sie die Zeichen der Zeit genau so verstehen, wie sie gemeint sind.

Andererseits...

Nichtsdestotrotz: Wer schon extensiv mit D7 gearbeitet hat und als Entwickler etwas lernfähig, oder womöglich sogar ein Team von Entwicklern hat, für den sieht es komplett andersrum aus.

Soo schwer ist das wieder auch nicht zu verstehen alles. Die Oberfläche ist im Prinzip gleich geblieben. Den Wysiwyg muss man gar nicht mehr mühsam einrichten, der funktioniert endlich out-of-the-box.
Solange man das Bilder-einfügen-Ding nimmt, das der CKEditor mitbringt, ist auch das Bilder einfügen und dabei skalieren _viel_ einfacher geworden.
Ja, Wiederverwendbarkeit von Bildern und Media gehen noch nicht wirklich im Wysiwyg.
Für mich ist allein das Config-Deployment im Core ein ausreichender Grund. Endlich funktioniert das, was mit Features immer Flickschusterei blieb. Und das funktioniert gerade auch für kleinere Projekte gut, wo man alleine an der Seite arbeitet. Da deploymt man einfach einmal alles und muss gar nicht nachdenken. Größere Projekte haben Methoden, wie sie nicht alles global deployen müssen.

Man muss halt bereit sein, kleinere Module, die noch fehlen, selber zu schreiben. Und so schwierig ist das mit dem OOP wirklich nicht. Wozu gibt es schliesslich das Examples-Modul? Man kann immer noch mit Copy+Paste sein Modul bauen, nach der Vorlage, wenn man möglichst wenig lernen will. Vor allem sollte man das Lernen von OOP-Prinzipien als jemand, der PHP nicht nur total widerwillig anfasst, als willkommen betrachten. Denn die PHP-Welt funktioniert mittlerweile per OOP und aus guten Gründen.

Zudem geht die komplette Entwicklungspower in D8. Also der ganze neue, heiße Scheiss wird für D8 gebaut. Da gibt es schon coole Sachen. Und die wirklich wichtigen, großen Sachen sind m.E. schon alle portiert, oder es gibt ein Nachfolgemodul, das die Rolle übernimmt. Rules güldet finde ich sowieso nicht, da ich die Sinnhaftigkeit dieses Modules nur für wirklich kleine Aufgaben bis jetzt eingesehen habe. Rules ist Coding über die UI. Sobald das etwas komplexer wird, ist es einfacher und übersichtlicher, ein kleines Modul zu bauen.
Bezüglich des geplanten Upgrade-Paths mit D9 wird man vermutlich ein solch radikales Core-Upgrade wie z.B. von D7 auf D8 nie mehr erleben. Man kann den Ankündigen mißtrauen, wenn man es will. Wenn man regelmäßig liest, was dort geplant ist und wie es jetzt schon umgesetzt wird mit den Point-Releases (8.4, 8.5 etc) sieht man, das es funktioniert. Es wird keinen großen Schritt von D8 auf D9 geben. Es werden nur alte APIs deprecated. Aber deprecatete Sachen sind schon jetzt als solche in der API gekennzeichnet, und wer sein Contrib-Modul up to date hält, der hält sich an sowas und muss es voraussichtlich für D9 dann einfach _gar_nicht_ anpassen.

Es wird in Zukunft viel weniger kleine Drupal-Seiten geben, weil das System für Hobbyentwickler aus o.g. Gründen eigentlich keine Option mehr darstellt. Das war eine bewußte Entscheidung seitens des Core-Teams, man war sich aber evtl. nicht bewußt, dass es so deutlich durchschlagen würde.

Drupal 8 scheitert wirklich an den Nutzern (und ich würde sie nicht alle als Hobby-Entwickler bezeichnen) die ihren Lebensunterhalt mit D7 verdienen indem sie schicke Firmenwebsites mit allen denkbaren Funktionen entwickeln können, ohne eben eigene Module schreiben zu müssen.

Rules hilft mir in so vielen Fällen und funktioniert hervorragend in D7, da möchte ich nicht wissen wieviel Zeit ich wieder investieren sollte um alle meine Rules Funktionen in eigene Module auszulagern.

Zudem mir z.B. noch einige weitere Module fehlen und das rechnet sich vom Zeitfaktor überhaupt nicht, das alles selbst zu entwickeln.

Ich behalte D8 natürlich auch im Auge und habe es parallel mitlaufen und erkenne logischerweise die Vorzüge die es später für mein etwas größeres Projekt bietet, aber darum geht es ja nicht! Es geht ja um die kleineren Projekte und um die jenigen die nicht mal eben ein Modul schreiben können oder sich damit noch Sicherheitslücken reinreißen.

Aber wie du schon sagst, wenn etwas fehlt schreibst du das Modul "kurz" selber, das kann man aber nicht von jedem verlangen, ist eben bei D7 auch nicht nötig.
Und das wird viele kleine Agenturen oder Freelancer entweder viele Aufträge kosten oder die Kunden müssen mühselig auf andere CMS umgeleitet werden.

Ärgerlich wird es wenn wir jetzt (also die D7 Nutzer) in eine jahrelange Übergangsphase geraten, in dem Themes oder Module für D7 plötzlich nicht mehr gepflegt werden, aber für D8 noch kein passender Ersatz zur Verfügung steht. Und damit sind wir wieder beim Enterprise D8.

Und das bedeutet das man dem hier Fragenden eigentlich nicht weiter helfen kann und er nicht weiß wie er die Problematik seinem Kunden klarmacht, da diese ja meist davon ausgehen man drückt auf den Knopf für Update und fertig...

-
Grüße Jenna

Ich denke, dass diese Übergangsphase jedoch nicht kleiner werden wird, wenn hier (und sicherlich auch woanders) Drupal 7 weiter für Neuinstallationen empfohlen wird. Die Blocker für kleinere Seiten in Drupal 8 sind doch gar nicht mehr so groß. Viele Module wurden portiert oder es gibt bessere Drupal 8 Alternativen für diese. Es bleibt eher die Frage, ob Drupal als solches noch optimal für kleinere Seiten ist, aber es war schon immer etwas technischer und komplizierter als andere Lösungen. Dafür jedoch mit einer riesigen Flexibilität, die für Kunden, die noch nicht wissen "wohin es sie treibt", sehr gut war.

Hier muss man natürlich auch sehen, aus welcher Position heraus man argumentiert. Mit Drupal als einem Open Source CMS und seinem ganzen Ecosystem, bekommt man ohne eine finanzielle Investition ein ziemlich ausgereiftes Produkt auf dem Silbertablett geliefert. Wir müssen keine teuren Baumaschinen kaufen, keine Fabrikhalle bauen, um unsere Kunden bedienen zu können. Letztendlich sind Investitionen eher in Zeit und Wissensaufbau. Aus dieser Situation heraus muss man immer betrachten, was andere Leute dazu treibt Module zu entwickeln und auch langfristig zu supporten. Ich tue das selbst und arbeite glücklicherweise in einer Firma, die mir Zeit gibt, diese Module weiterzuentwickeln, Patches anzubieten und so weiter. Aus dem einfachen Grund, weil wir diese für unsere Kunden einsetzen.

Was passiert jedoch, wenn wir den Kunden verlieren, der Kunde das Budget kürzt, ich aus dem Unternehmen ausscheide. Werde ich weiterhin meine private Zeit für das Modul (oder mehrere) aufbringen, damit andere davon ihren Lebensunterhalt bestreiten können? Das hat viel mit der Open Source Philosophie zu tun, aber letztendlich schuldet in einem Open Source Projekt niemand einem anderen etwas. Und bei unsupporteten Modulen kann man am Ende nur hoffen, dass es noch eine Agentur gibt, die wirtschaftliche Interessen in der weiteren Pflege des Moduls hat, oder einen Freiwilligen, der Zeit hat es aus Spaß an der Freude oder einem Hobbyprojekt zu pflegen.

Und dies ist auch ein Grund, warum die meiste Entwicklung momentan bei Drupal 8 Modulen abgeht. Eben weil die führenden Agenturen hier wirtschaftliche Interessen haben. Die Bugs, Feature Requests, Support für Drupal 7 Module, die unsere Firma macht, liegt daran, dass wir noch unzählige Drupal 7 Projekte für unsere Kunden betreuen. Je weniger dies in den kommenden Monaten werden, desto weniger werden wir an Drupal 7 "zurückgeben" können. Dies im großen Stil gedacht sorgt am Ende für das Gefühl, dass sich viele Modulentwickler nicht mehr um Drupal 7 scheren.

Es gab ja auch schon Versuche über Spenden oder Crowdfunding die Entwickler zu unterstützen. Wenn es hierfür ein verlässliches Verfahren gäbe, wäre es denkbar, dass auch viele kleine Firmen oder Einzelunternehmer mit einem schmalen Beitrag dafür sorgen können, dass ein Entwickler sich um neue Features oder Support kümmert.

Am Ende, sollte sich jeder der Open Source Software einsetzt, sich über die Risiken bewusst sein, jedoch auch selbst überlegen: Habe ich selbst das Mögliche getan, bevor ich meckere oder auf ein anderes System umstelle? Hätte ich selbst nicht mal einen Bug auf drupal.org melden sollen, hätte ich selbst nicht einen Vortrag bei einem Drupal Meetup halten können, hätte ich nicht selbst mehr Leuten in Foren unterstützen können, hätte ich nicht selbst versuchen können einen Kunden zu überzeugen, dass sich eine Investition in ein generisches Drupal Modul auf drupal.org gelohnt hätte.
Ich kann diese Fragen für mich auch nicht zufriedenstellend beantworten :)

Wer hier von Enterprise D8 spricht, ist meiner Meinung nach einfach nicht mehr fit genug oder schlicht nicht mehr Willens eine Seite so mit D8 zu planen, wie er es zu D7-Zeiten noch getan hat.

Ein Beispiel

Habe ich früher eine Seite mit D7 geplant, habe ich die Funktionen des Core betrachtet, mir angesehen was möglich ist und dann entsprechend versucht dem Wunsch meines Kunden zu erfüllen. Was nicht ging, das ging nicht.

Seit D8 draußen ist höre ich immer nur Beschwerden über Funktionen, die es für D8 noch nicht oder nicht mehr gibt. Das ist schlicht nur zur Hälfte war. Der Großteil der wichtigen Funktionen, die Drupal 7 hat vermissen lassen befindet sich bereits im Core oder noch in experimentellen Modulen, die in naher Zukunft stabil werden.

Das einzige was sich geändert hat, ist teilweise der Weg zum Ergebnis.

Fehlte früher tatsächlich mal eine Funktion in Drupal 7, dann wurde diese schlicht gebaut. Allerdings, und das muss man ganz klar sagen, bauen Entwickler aus Zeit- und Kostengründen immer nur die Module, die Sie für Ihre eigenen Projekte benötigen.

Wer jetzt eine Funktion in Drupal 8 vermisst, der muss entweder in der Community fragen, wie er diese nachbauen kann oder selbst nach einer Lösung suchen.

Wenn aber niemand in der Community auf d.o. nachfragt, wie er diese oder jene Funktion aktuell implementieren kann, dann wird auch niemandem auffallen, dass diese Funktion noch fehlt.

Es wäre interessant, sich mit einem spezifischen Projekt mal direkt an die Community zu wenden und zu fragen, ob jemand ein vorhandenes D7 Projekt auf D8 nachbauen möchte, um herauszufinden, wie viel Prozent an Funktion der Webseite in Drupal 8 tatsächlich noch fehlt.

Sollten da am Ende wirklich noch 10 % Funktionalität fehlen muss man immer noch sehen ob die Masse diese 10 % Funktionen tatsächlich braucht. Nur dann ist es nämlich wahrscheinlich, dass jemand seine Zeit und damit sein Geld in die Entwicklung von Funktionen steckt, die er selbst nicht, aber andere Menschen aus der Community benötigt. In Drupal 7 heißt sowas Custom-Module und muss auch heute schon gekauft werden.

So entstehen übrigens auch die experimentellen Module im Core. Der Punkt ist leider, dass es oft einfacher ist, bei dem zu bleiben, was man kennt, als aktiv an der Community zu partizipieren, bis man an der richtigen Stelle gehört wird und die Masse der Community ganz von sich auch damit beginnt, das Problem das im eigenen Projekt vorhanden ist zu beseitigen. Opensource bleibt Open Source und das hat auch im Fall von Drupal mit ganz viel Kommunikation rund um den Globus zu tun.

Wenn meine Drupal-8 Probleme nicht hier im DC gelöst werden können, dann frage ich halt auf d.o oder auf Stackexchange. Irgendwo gibt es immer eine Antwort auf meine Fragen, vorausgesetzt ich formuliere diese gut genug. Und wenn ich nicht weiterkomme na dnn poste ich eben eine idee auf Drupal.org

Ich bekomme ja schon Wutanfälle, wenn sich jemand wundert, warum man Drupal nicht mehr beim Shared-Hoster betreiben soll oder sich mokiert, wenn es um die Anwendung von Kommandozeilenanwendungen wie Composer und Drush geht. Shared hosteing für Drupal war schon zu D7-Zeiten eine schlechte Idee. Wer's nicht glaubt, der möge sein Drupal auf einen VPS packen und diesen Drupal-spezifisch konfigurieren. Man wird auf jeden Fall ein Geschwindigkeitswunder erleben.

Und Wer Kommandozeilentools ablehnt, der hat keine Ahnung wie viel schneller diese die meisten Aufgaben im Gegensatz zu UI von Drupal erledigen. Wer schon mal den Developer Mode mit der Drupal Console in D8 eingeschaltet hat um zu themen und das gleiche dann versucht hat manuell zu machen, der weiß, wovon ich rede.

Wer nicht mit den Tools und Modulen arbeiten möchte, die in Drupal zur Verfügug stehen, der muss fehlendes schaffen oder schaffen lassen, aber bitte nicht meckern, weil man keine Ahnung hat, wie man die Community erreicht um seine Probleme zu lösen oder von einer Idee zu überzeugen.

Der Unterschied zu USA und Deutschland ist, dass hier von Seiten de Firmen viel mehr wert auf Longtimesupport gelegt wird.
Beim Übergang von V6 auf V7 lief das noch ganz gut. Deshalb läuft bei Unis Typo3 nur wegen dem Longtimesupport von Typo3 hat man mit Drupal keine Chance.

2016 ist Durpal 8 herausgekommen da war an ein großes Commerce Projekt noch gar nicht zu denken
Ende 2017 kam Commerce 2 heraus - möchte da jemand sofort ein großes Projekt aufsetzen? ich nicht.

Scenario:
Ende 2015 Vorabplanung Firma braucht Shopsystem
Mitte 2016 Pflichtenheft
Drupal 8 Commerce nicht verfügbar Drupal 7 Commerce nehmen oder Auftrag ablehnen
Ende 2016 Auftrag erteilt
Anfang 2017 Auftrag mit mehreren 5 stelligem Euro Betrag fertig (Da sind interne Kosten der Firma wie Planungskosten, Pflichtenhefterstellung und Grafiker usw mit drin) Der Firma ist es egal ob externe oder interne Kosten. Die externen Kosten für Grafiker und Web auf Stundenbasis ohne Festpreis, das muss man erst einmal finden.

Und nun soll man dem Kunden sagen: Schieß mal noch ein paar tausend nach damit Du nicht in Sicherheitslöcher fällts. Wird halt nicht mehr Supportet, aber ob es wirklich klappt kann man noch nicht sagen

Und noch nicht einmal die Commerce Guys die nichts anderes machen sind soweit:
CommerceKickstart.com for Drupal 8:
Instead of waiting to port the complete distribution to Drupal 8, we opted for a browser based tool you can use to build a Composer file to build your next Drupal Commerce 2.x project. Developed in partnership with Acro Media, it includes a variety of Technology Partners and contributed modules you can use to build and populate your store. Give it a try!

und das Demo der Commerce Guys: https://commercedemo.acromedia.com/ - Fehler: The website encountered an unexpected error. Please try again later.

Sorry da lasse ich aber die Finger vom Upgrade wenn in einem System mehr als 250 Module am Arbeiten sind - da ist man bei Commerce in Verbindung mit Kundenwünschen schnell dabei.

Und nochmal zurück zum D8 Grundsystem und zu kleineren Aufträgen. Der große Vorteil von D6 und D7 war dass jeder Laie sich mit den kleinen Änderungen an Webseiten selber helfen konnte. Bei flachen Webseiten hat man am Service im Hintergrund (Update und einrichten) verdient und mit dem ganzen Kleinkram war man entlastet. Das hört nun schon mit dem rudimentären D8 Mediamodul auf und der Kunde sagt entweder funktioniert es wie beim alten oder ich probier es bei der Konkurrenz. Dann landen sie bei Wix oder 1&1 Baukästen so lange bis sie merken, das reicht ja doch nicht. Aber dann sind sie weg.
Also nimmt man D7 und hofft dass es noch etwas länger läuft. Wäre alles kein Problem wenn in D7 und den Modulen oder Themes die Sicherheitslücken gefixt werden. Die Kosten dafür den Kunden zu übertragen läuft nicht und selber pro bono? ja
Ich weiss open source muss man damit rechnen dass man alles selber macht. Aber seit D5 gab es kein so ein großes Kuddelmuddel mehr

All das zusammen gesehen ist das Urteil derzeit für D8 eher mäßig. Nicht das ich es nicht aufsetzen oder nutzen kann und mit der Konsole arbeite ich auch. Daran liegt also auch nicht.

@etron, die Seite ist online, viellicht haben die nur kurz an der Seite gearbeitet als du neulich drauf wolltest

Für Drupal 8 ist doch aber https://www.drupal.org/project/commerce als Stable verfügbar?

Grüße Jenna

dass der Versionswechsel von D7 zu D8 einen Technologiewechsel enthält.

Das ist nicht einfach ein Upgrade, wie es von D6 nach D7 war.

Fast alles hat sich verändert. Drupal ist ein ganz neues Produkt geworden.

Dies macht es natürlich auch Entwicklern schwerer bestehende Module auf diesen technologischen Standard zu bringen.

Auch beim Wechsel von D6 nach D7 sind Module weggefallen, die einfach nicht mehr gebraucht wurden.
Allerdings haben die neuen Funktionen oft etwas anders funktioniert als die Module der Vorversion.

Verbesserungen, die keine Veränderungen mit sich bringen, sind kaum möglich.

Drupal ist kein Homepagebaukasten, sondern ein Framework, das teilweise wie ein Homepagebaukasten funktioniert, aber weit darüber hinaus geht.

Klar ist Drupal Commerce als Version 8 verfügbar. Aber die Schwierigkeiten die Distribution Commerce Kickstart auf Drupal 8 zu portieren, und das von den wohl absoluten Spezialisten für Drupal Commerce, zeigt doch dass hier noch einiges fehlt.

Genau das ist ja das Problem. Wenn ich D7 als Homepage Baukasten verwenden würde, hätte ich keine Problem mit D8. Die Seiten die ähnlich funktionslos und flach wie die Baukästen sind funktionieren einwandfrei. Genau das funktioniert ohne Probleme, bis auf das rudimentäre Media Modul. Aber viele der Dinge weshalb man nicht einfachere CMS oder Baukästen verwendet, sind überhaupt noch nicht portiert, werden aber in D7 nicht mehr gepflegt. Hier ist ein großes Loch, vor allem wenn Sicherheitslücken auftreten.

Wenn man alles auf D8 umstellen muss was nun mit Sicherheitsrisiko weil unsopported oder nicht gefixte Sicherheitslücken kommen wird. kommen viele mit der jetzigen verfügbaren Arbeitskapazität nicht zurecht, und wieviele Kunden dann abspringen weil man Ihnen Drupal "aufgeschwätzt" hat und sie nun die Umstellung zahlen sollen wird sich herausstellen. Wer das negiert hat wirklich nur Baukästen angeboten.

Und wenn man so manche Kaufthemes in D8 ansieht, so merkt man auch hier an Funktionalität fehlt

Beispiel:
https://themeforest.net/item/eco-green-drupal-theme-for-environment-ecol...
Schaut ja super aus. Schaut euch die Kommentare an und z.B die Unterseite http://ecogreendp.joomlastars.co.in/Services Sie ist mit Einstellung PHP aktiviert und jegliche HTML Tag Prüfung hingepfriemelt. so sicherheitskritisch dass Envarto das Geld zurückerstattet.
Und das ist nicht das einzige schöne Theme. Auf Anfrage bei anderen Theme Entwicklern ob hier die HTML und PHP Standarteinstellungen verwendet werden oder PHP on und Html Tag Prüfung off kommt entweder gar nichts oder die Bestätigung dass sie das derzeit so machen müssen. Dann ist es aber kein Theme mehr sondern ein Template .

Ein anders Beispiel ist wie viele Distributions nicht portiert werden oder sogar nun unmaintained sind. Die gegen ja auch leicht über Baukastenfunktionalität hinaus.

Nun es wird sich herausstellen wie die Installationszahlen steigen.

Und a kommt dann wirklich die Frage auf ob D8 Typo3 den Rang ablaufen wird? Zumindestens nicht was Longtime Support bedeutet. Klar wenn man meint dass Drupal Richtung Enterprise geht kann man es wieder vergleichen.

Man kann viel gegen D8 sagen, aber nicht bzgl. Longtime-Support, wenn eine Seite jetzt mit D8 gebaut wird. Denn wie bereits gesagt, wird es keinen harten Übergang von D8 nach D9 geben. Der wohl relevanteste Post dazu ist von Nathaniel Catchpole https://www.thirdandgrove.com/long-road-drupal-9

Wenn also 2021 Drupal 9 herauskommen wird, und der Übergang zu D9 so weich sein wird wie versprochen, werden D8 Seiten von Stand heute, wenn man D9 eine Lebenszeit von fünf Jahren voraussagt - das wäre sogar etwas kürzer als D8 - 8,5 Jahre supportet, wenn man in regelmäßigen Abständen Module updatet, in eigenen Modulen deprecated Funktionen durch zukunftsfähige ersetzt etc. Dies wäre ein wesentliches Argument, um eine großes Projekt jetzt mit D8 umzusetzen.

Wenn man dann noch den außerplanmäßigen Long-Time- Support hinzurechnet, den es aktuell für D6 gibt, ergeben sich ganz andere Lebenszeiten als die gerne kolportierten.

Der Technologiewechsel mit D8 wurde unter anderem auch aus diesem Grund vollzogen, um zukunftssicherer zu sein und inkrementelle Feature-Releases überhaupt zu ermöglichen.

Hiervon profitieren natürlich wieder vor allem Entwicklerteams/Agenturen, da diese die Resourcen haben, immer am Ball zu bleiben und die o.g. Modulupdates durchzuführen. Jedoch sind es vor allem diese Teams, die bei Bewerbung um Projekte in Konkurrenz zu TYPO3 gehen.

Will sagen: Die Situation um LTS hat sich deutlich verbessert. Leider wird das zu wenig kommuniziert

Eigentor du sprichst mir aus der Seele. Ich finde ja, die Leute sollten weniger über D8 meckern und mehr überlegen, wie man die Vorteile von D( an den Kunden bringen kann. Was machen die denn alle, wenn Ihr geliebtes D7 futsch ist. Wechseln Sie dann alle zu Wordpress, weil keiner lust hatte, Drupal 8 also solches losgelöst von Drupal 7 zu begreifen und immer noch durch die D7-Brille auf Drupal 8 schaut :-)

Das ist nicht das Problem dass man nicht auf D8 schaut. Das habe ich schon mehrfach genutzt. Nur dass nun viele Teams von D7 Modulen diese einfach fallen lassen und sich auf D8 konzentrieren ist wirklich ungünstig.
Mir fehlt einfach die Arbeitszeit und die Bereitschaft der Kunden das zahlen alles schnell auf D8 zu portieren, weil die Sicherheitswarnungen z.B unsoported in D7 und die unbearbeiteten Bugs täglich mehr werden

Wer sagt, dass man derzeit alles was man in D7 aufbauen kann auch in D8 aufbauen kann der kennt entweder D7 oder D8 nicht.
Was in aller Welt soll man eurer Ansicht nun machen?

Warten - Die Kunden wollen es jetzt
D7 nehmen - Wäre unverantwortlich so schnell wie D7 austrocknet
Alles was fehlt selber erstellen - das zahlt keiner und dazu ist auch keine Zeit.
Und nochmal mit dem Mediamodul müsste ich anfangen, das sind die Kunden eben inzwischen sehr verwöhnt. Hat denn keiner hier einen Kunden der mit dem Umfang der D8 Media Möglichkeiten nun nicht mehr ganz zufrieden ist? Die Hälfte meiner Kunden nimmt mir das Projekt so nicht ab, bzw sagt beim Vorstellen einer Demoseite schon, dass das nichts ist.

Auf diese Zwickmühle gibt es doch keine Antwort oder?

Ich glaube ich habe die Kunden zu sehr verwöhnt, bzw. ihnen ermöglicht dass sie Content
komplett selber erstellen und pflegen....

Das geh mit Meida Entity Browser Entity Embed und konsorten unter D8 aber viel besser. Deswegen ist Meida ja jetzt im Core. Mal ganz ehrlich Media ist nicht einfacher geworden, aber wesentlich flexibler. Wenn du dir beispielsweise Thunder ansiehst, wirst du feststellen, dass Media einfach traumhaft ist. Leider wissen viel einfach nicht, wie sie dieses Ergebnis vonm Vanilla-Core aus erreichen können und das liegt Meiner meinung nach einfach an der Fehlenden Bereitschaft die entsprechenden Tutorials da draußen nachzuvollziehen und dafür zu sorgen, dass Bugs, wie beispielsweise eine fehlende Lightbox-Integration für Media möglichst schnell gefixt werden einfach durch die Partizipierung an der Diskussion zu den entsprechenden Issues. Ganz ehrlich wenn dir ein Kunde Meida unter D8 nicht so abnimmt, wie es unter Thunder zur Verfügung steht, dann hast du es wahrscheinlich schlicht falsch zusammengebaut oder die Vorteile davon deinem Kunden nicht vernünftig näherbringen können.

Abgeshen von einer fehlenden Lightbox integration fällt mir nämlich beim Besten willen nicht en, was D7-Media besser macht als D8 GAR NiCHTS

Von wievielen "unsupported" Modulen warst du denn bisher betroffen? Das waren größtenteils doch sehr spezifische Module, die wohl in typischen Baukastenseiten gar nicht verwendet wurden.

Ich denke auch, dass es nicht zielführend ist, alles existierende sofort auf Drupal 8 portieren zu wollen.

Viele einfachere Webseiten haben einen Lebenszyklus, der häufig nicht bis an das Ende des Supportzeitraums liegt. Selbst für Drupal 6 gibt es noch Backports von Security Patches.