Drupal 8 - Das Entwicklungsrisiko eines CMS für große Seitenbetreiber

Insofern gibt es keine Eile für Drupal 8.
Insbesondere, wenn dort noch Bugs enthalten sind, macht die Einführung keinen Sinn.

Die Strategie, nur eine Freigabe zu erteilen, wenn es keine known Bugs mehr gibt, halte ich für richtig.

Microsoft hätte sich und seinen Kunden einen Gefallen getan weder Vista noch Windows 8 in den Vertrieb zu bringen.

Zunächst eine Richtigstellung zur beta version möchte ich vor allem geben:

Das stimmt so nicht ganz. Zunächst mal steht auf der Release-Seite, die auch oben verlinkt ist:

Wir haben nun einen Stand erreicht, der nicht nur die Entwicklung der Module sondern auch von Themes, Dokumentation usw. sinnvoll macht.
Auch wenn das viele zwar runter beten, aber wirklich verstanden hat nicht jeder, daß Drupal ein Community-Projekt ist. Also jede(r), dem es nicht schnell genug voran geht, kann sollte sich nun am Beta-Test beteiligen (also in Test-Installationen und nicht im Produktiv-Betrieb). Ansonsten gilt die Aussage, die sich meines Wissens offiziell noch nie geändert hat: 'it's ready when it's ready'.

Ein paar Gedanken zur generellen Major-Version Upgrade-Problematik:
Die Strategy der kompletten System-Veränderung ist Teil von Drupal von Anfang an. Das hat Vor- und Nachteile und man mag es gut finden oder nicht. Aber das ist nichts neues.
Was allerdings neu ist: Es gibt eine D6 zu D8 Upgrade-Strategie (auch wenn sie noch nicht so gut funktionieren mag) und der D6-Support wurde verlängert ein wenig in die D8-Zeit hinein. Noch mehr wäre schön gewesen, aber der Hauptgrund, daß es nicht mehr gibt liegt darin, daß es zu wenig Unterstützung für die Kern-Entwickler und das Security-Team gibt. Zu wenig Freiwillige und zu wenig Geld für professionelle Unterstützung. Also ich meine, daß jede(r) die/der hier mehr sehen möchte an D6-Livetime sollte sich spätestens jetzt einbringen, versuchen andere zu motivieren oder Geld zu sammeln.

Zu noch existierende D6-Installationen:
Auch für ein Upgrade auf Drupal 7 ist eine Migrations-Technik sinnvoll wie es z.B. auch das Drush SIte-Upgrade-Modul liefert. Aber je komplexer eine Drupal-Site ist bzw. wie stark elementare Funktionen auf Contrib-Module oder Custom Code basiert, je mehr Arbeit ist beim Upgrade nötig.
Nun ja, leider werden viele Drupal-Sites nicht sehr weitsichtig aufgebaut und einfach irgendwelche Module aus dem großen Regal gegriffen und diese zum Teil sogar gehackt usw. Da scheitern dann oft auch schon die normalen Modul-Updates. Wenn ein Chaos erzeugt wurde, muss dann natürlich irgendwann mal aufgeräumt werden. Aber daß dies anstehen wird, hätte in dem Moment den Verantwortlichen bewusst sein müssen, als sie das Chaos erzeugten. Die Betreiber dieser D6-Installationen können eigentlich froh sein, daß sich Drupal 8 so lange verzögert und sollten darauf hoffen, daß es noch länger dauert. Experten, die ein Chaos ordnen können sind leider erheblich weniger im Markt verfügbar als Leute, die es erzeugen können.
Und wie bekommt man nun Ordnung ins Chaos?: Zunächst mal sollte man so schnell wie möglich loslegen. Je größer das Projekt bzw. die Komplexität, um so unwahrscheinlicher ist auch ein Direkt-Upgrade auf Drupal 8. Da man ja doch noch das ein oder andere Contrib-Modul benötigen wird, die es dann hoffentlich wenigstens schon für Drupal 7 gibt. Aber wenn es Module für D6 gab und diese nicht für D7 gibt, dann stehen die Chancen schlecht, daß sich da von allein etwas tut. Nun, ich selbst habe auch D6 Module geschrieben die ich ohne konkrete Projekte nicht auf D7 oder D8 portieren werde. Ich finde es oft auch unverschämt, wie teilweise hier im Druplacenter sich Leute über Modul-Maintainer beschweren. Wir arbeiten entweder in unserer Freizeit an Modulen oder in Rahmen bezahlter Projekte (ob in Agentur, als freier Dienstleister oder Inhouse Developer bei den Betreibern).
Ich verstehe die Frustration von Drupal-Sitebuilder und -Adminitratoren, die nicht programmieren können und dann evtl. vor einer Aufgabe stehen die sie nicht lösen können, wie ein Upgrade eines Systems, das eben Programmierung erfordert. Ja gut, es ließ sich vllt. ursprünglich ohne Programmierung aufbauen und das ist vllt. tragisch. Aber die Situation war tatsächlich absehbar. Ich war anfänglich auch nur Sitebuilder als ich vor über 6 Jahren häufiger vor dem auch damals schon großen Drupal-Modul Regal stand und mir Sorgen machte, was den dauerhaften Support der Drupal-Sites betraf, die ich aufbaute. So begab mich auf die Suche nach entsprechenden Kooperations-Partnern. Und dafür schrieb ich auch meinen ersten Beitrag hier im Drupalcenter: Entwickler/innen als Kooperations-Partner/innen gesucht. Inzwischen übernehme ich diesen Part für andere und beginne gerade ein Projekt für den Betreiber einer großen D6-Site, um dort unter anderem ein Upgrade durchzuführen.

Zu den neuen Funktionen/Veränderungen in D8:
Ich bin immer dafür, daß wir nur einen sehr schlanken Core haben und habe mich vor 2 Jahren auch an entsprechenden Diskussion beteiligt. Skuril an der Thread-Eröffnung ist für mich, daß gerade die bemängelten Ergänzungen ja den Anfängern entgegen kommen (die ich lieber in Anfänger-Distributionen ausgelagert hätte) und die Upgrade-Problematik vor allem den Anfängern zu schaffen macht. Allerdings begrüße ich Views im Core und würde mich auch über Rules freuen, wenn es den Weg in D9 finden würde.
Ähnlich wie bei Drupal 7 ist auch bei Drupal 8 die Veränderung "unter der Haube" viel extremer. Obwohl das für mich mal wieder sehr viel Lernen bedeuten wird, begrüße ich die API-Changes, da diese soweit ich das nachvollziehen kann immer weiter in Richtung eines äußerst professionellen kommerziellen Systems zielen. Die vielen kleinen Spielereien, die auch in kleinen Websites mit Drupal möglich sind, sind meiner Ansicht nach zu einem überwältigendem Anteil von kommerziellen Projekten voran getrieben worden. Und auch wenn der einzelne "Webmaster" das nicht immer so leicht erkennen kann, profitiert auch dieser zumindest indirekt von der Modernisierung Drupal unter der Haube. Und selbst das vor allem in Deutschland bekannte Typo3, das lange Zeit massiv auf Abwärts-Kompatibilität gesetzt hat, beschreitet nun andere Wege z.B. mit Neos. Und wenn da bald mal ein Sackgasse entstehen sollte (oder schon geplant ist, so gut kenne ich mich da nicht aus), dann sind die Anwender, Kunden usw. noch weniger darauf vorberietet als dies offensichtlich bei Drupal immer noch der Fall ist.

Drupal 7 wird ja nun noch eine ganze Zeit supported werden. Danach werde ich ähnlich verfahren wie bei D6 zu D7, kleine Projekte bei Bedarf neu aufsetzen und bei Großprojekten muß einfach auch das Geld vorhanden sein notfalls einen Prof hinzuzuziehen der unlösbares lösbar macht.

Die Vorteile bei D8 sehe ich unter anderem in der langfristigen Modulpflege, die bei D7 ziemlich zeitraubend sein kann, klar braucht nicht jeder Views und ich könnte gern auf den CK Editor verzichten und würde lieber den Bueditor nutzen, aber jedem kann man es nicht recht machen.

Ich bewundere wirklich die Entwickler die uns so einen Haufen neuer Technik als Open Source vorsetzen und ich teste schon länger Drupal 8 und bin von vielen Feinheiten begeistert. Und wenn es sich verzögert ist das zwar sehr schade, aber D7 erfüllt ja für die nächsten Jahre auch jeden Zweck, auch im Hinblick auf Drupal Commerce.

Was ich tue ist, ich achte jetzt schon bei der Modulauswahl auf Hinweise ob es Ports zu D8 geben wird und habe auch jetzt schon eine Liste mit D8 Modulen um bei komplexeren Anwendungen nicht völlig am Sinn vorbei zu arbeiten.

Mich wundert immer nur, das eine neue Drupal Version soviel Bedenken verursacht und teils fast Misstimmung. Wieviel Geld haben wir mittlerweile in unsere PC's gesteckt oder speichert noch jemand auf Diskette? Zuhause steht vermutlich kein Videorecorder mehr herum, sondern High Tech aus dem M-Markt.

Und wenn ich als Kunde ein grosses Projekt will, dann muß auch zumutbar sein alle 3-4 Jahre einen größeren Betrag in die Hand zu nehmen um die neueste Drupal Technik nutzen zu können. Der Kunde renoviert vermutlich auch alle 5 Jahre sein Ladengeschäft oder kauft neue Büromöbel oder den neuesten Firmenwagen.

Nur Drupal soll möglichst einfach, kostenlos, auf dem neuesten Stand sein und es dürfen natürlich keine Folgekosten anfallen?

Ich setzte mittlerweile einen Zusatz in jeden Auftrag, der auf Modulupdates und Core Updates hinweist, das Folgekosten einzuplanen sind, kleine Projekte erhalten bei mir allerdings eine günstige Pauschale für Updates da ich die Installationen und Module gut kenne und daher sehr selten Probleme auftauchen.

Ein Kunde der null Verständnis für solche Art Folgekosten hat ist meiner Meinung nach bei Drupal falsch, ich meine damit die Kunden die Geld mit Ihrer Seite verdienen und in einem Betrieb muß auch modernisiert werden, wenn dies alle 3-5 Jahre anfällt, finde ich das durchaus zumutbar.

Ich hoffe das weiterhin das Prinzip erhalten bleibt das der Kern so schlank wie möglich bleibt, allerdings begrüße ich Views und später Rules im Kern durchaus, plus einiger weiterer neuer Core Module, da es eigentlich die Module sind, die ich jedesmal bei D7 mühselig nachinstalliere und gesondert updaten muß.

Im besten Fall wird D8 so geliefert das man mit Core Modulen normale Projekte abdecken kann, ohne mühselige Einzelmodulupdates und im allerbesten Fall wird dann das Update auf D9 ganz einfach....

Grüße Jenna

Das die Entwickler was besonders hier leisten, dafür muss ich mich mal sehr bedanken!

Nur leider gibt auch ein paar Punkte was mir sorgen machen wenn man ein komplexe Portal ein Upgrade durchführt:

- die größte Angst was die Kunden haben ist: wird die Seite gleich angenommen bei Google und Co. wie vorher oder verliert man User,
weil sich ein paar Fehler eingeschlichen haben, was nicht voraussehbar sind...

- ich kenne Kunden oder auch große Portale, die auf dem alten System/Version weiter fahren und sich nicht erlauben können ein Upgrade,
da das Risiko sehr groß ist...

- man kann nicht alle 3-4 Jahre eine neue CNC Maschine kaufen bzw. eine neue Heizungsanlage für ein Haus

Ich habe mir noch keine große Gedanken gemacht über ein Upgrade und ich verwende noch immer Drupal 6 und ich werde noch ein paar Jahre hin warten bzw. ich werde in kürze ein komplexes Modul integrieren und auch da werde ich auf Drupal 6 setzten, da ich die Vorteile und schwächen schon kenne bzw. schön langsam muss ich mir auch Gedanken, wie ich es mit Drupal 8 umsetzen kann...

...nur wie gesagt, alle 3-4 Jahre einen neue CNC Maschine kaufen, dass werden viele Kunden sich nicht leisten können bzw. immer die Angst haben, dass Google und Co einen nicht mehr wohlgesinnt ist!

Google und andere Suchmaschinen haben eher mit ungeschickten "Frontend"-Programmierungen Probleme, wie früher Flash und zum Teil noch Javascript. Aber das Frontend lässt sich zähmen. Ich habe vor ein paar Monaten in einem Projekt ein Template gebaut, daß mit D7 sehr alte HTML-Strategien nachbaut. Dort erkennt man von außen gar nicht, daß das HTML von Drupal erzeugt wurde.
Wichtig ist vor allem, daß die alten Pfade erhalten bleiben und sich Content nicht "heimlich" verschiebt. Aber das bekommen wir ja sogar meistens hin, wenn wir andere Systeme in Drupal migrieren.

Es wäre sicher schön, wenn wir demnächst längeren Support für die einzelnen Major-Versionen hätten. Und die neue Strategie wir die Situation in der Zukunft ja auch verbessern. Nur für Drupal 6 tickt nunmal jetzt die Zeit. Evtl. verschaffen da uns noch einige Aktivisten eine Galgenfrist durch Sicherherheits-Ipdates, vor allem auch den Backport von Security-Patches, die für D7/D8 auftauchen, aber das Risiko steigt.
Und warum steigt das Risiko? Weil es Sinn einer Website ist 24/7 aus aller Welt über das Internet erreichbar zu sein. Und dort tummeln sich neben den netten auch böswillige und gierige Menschen, die ungeschützte Computer-Systeme angreifen. Ein Vergleich mit irgendwelchen Investitionen, die nicht am Internet angeschlossen sind hinkt daher ganz gewaltig. Vor allem muß zwischen Soft- und Hardware unterschieden werden.
Wenn also eine CNC-Maschine auch ans Internet angeschlossen wird, evtl. zu Service-Zwecken, dann sollte man auch dort für das Einspielen von sicherheitsrelevanten Software-Updates sorgen, ansonsten könnten da sogar Menschen zu schaden kommen, wenn ein böswilliger Hacker diese Maschine manipuliert. Siehe diverse Berichte zu verwundbaren Industrieanlagen z.B. Verwundbare Industrieanlagen: Fernsteuerbares Gotteshaus.

Edit: Diverse Tippfehler behoben

Mit einer CNC-Maschine meinte ich den Vergleich, dass man sich nicht alle vier Jahre eine CNC-Maschine kaufen kann, da sie in den meisten Fällen 10 bis 30 Jahre verwendet werden!
Mir sind die Probleme bewusst mit dem Sicherheitsupdate ect. immer wieder eine neue Core Entwickeln macht für mich nicht viel Sinn!
Wenn man sich zb. die Autoindustrie ansieht, dann wird hier nicht alle 3-4 Jahre eine neue Steuerung verwendet bzw. da gab es als Beispiel eine Simatic S5 und erst nach ca. 15-20 Jahren kam die S7 heraus!

Ich will damit sagen, wie soll man einen Kunden erklären, dass er alles 3-4 Jahre einen 5 Stelligen Betrag in die Hand nehmen muss um auf dem neuesten Stand zu blieben oder weil es keine Security-Patches mehr gibt bzw. wo der Arbeitsaufwand ca. 4-6 Monate beträgt!
Und das Risiko bei Google und Co hat...

Ich kenne mich damit nicht aus! Kann man vielleicht nur das Core verändern und die Module und das herum belassen, dass man nicht immer ein upgrade durchführen muss?

Ein Problem wird ja auch, daß die Drupal 6 Module nicht mehr unbedingt mit den aktuellen PHP-Versionen korrekt arbeiten (es treten Warnungen und sogar Fehler auf). Ich glaube nicht, daß Du auf Dauer selbst alles an die neuen Anforderungen anpassen möchtest.
Software ist nun mal kein langlebiges Wirtschaftsgut wie eine CNC-Maschine. Bei OpenSource gibt es immer ein Verfallsdatum (wenn der Entwickler keine Zeit oder Lust mehr hat und keiner übernimmt). Aber auch bei kommerziellen Paketen bist Du genötigt, regelmäßig die Lizenz zu erneuern und außerdem einen Wartungsvertrag abzuschließen. Da kommt auch ganz schön was an Kosten zusammen und die beinhalten auch noch nicht die nötigen Anpassungen, die beim Ändern der Release auftreten können.

Da hast du sicher recht, dass Software kein langlebiges Wirtschaftsgut gut ist und du hast genug Argumente geliefert womit man den Kunden überreden kann und wenn man bedenkt, dass man jedes mal ein Upgrad überspringen kann, dann sind wir auf ungefähr ich sage mal 12 Jahre...
...und wir wollen auch davon leben!

Microsoft bringt alle 3 Jahre ein neues Betriebssystem heraus.
Kein Betriebssystem wurde solange unterstützt, wie Windows XP (12 Jahre).

Entwicklung ist nur möglich, wenn man hin und wieder auch die Basis auffrischt. Technologien entwickeln sich, und auch die Hacker entwickeln immer mehr Fähigkeiten.

Auch der LINUX-Kernel von vor 12 Jahren ist nichte mehr der gleiche.

.
.
.
Hallo Ronald und Carsten, Jenna und Artweb und wla
... ...und wer sonst noch hier schreiben wird.
.
.
.
.
.
Zunächst einmal einen herzlichen Dank an alle,
die sich an diesem Diskussionsstoff beteiligen,
für die ausführliche Auseinandersetzung mit dem Thema.
.

.
Klar macht Eile keinen Sinn, Ronald.
.
Ich habe von Eile garnichts gesagt!
Allerdings machte es mich schon stutzig,
dass ich mich zum Jahreswechsel noch immer nicht in der Lage sah,
auf den Servern unseres Providers die Betaversion von Drupal hochladen zu können,
weil dieser angab, die php-Version stimme nicht mit den Anforderungen überein.
Gibt's da jetzt eine Version, die man inzwischen aufspielen kann,
um den Seitenaufbau unserer bestehenden Site mal zur Probe stückchenweise zu übertragen?
.
.
Ich habe nicht behauptet, dass es zu langsam geht!
Vielleicht ist das falsch zu Dir hinübergekommen, Ronald;
jedenfalls sollte das nicht den Kern meiner Aussage darstellen.
.
Im Gegenteil:
.

.
Es gibt für mich insofern keinen Grund zur Eile!
.

.
Dem möchte ich keinsfalls widersprechen, Carsten.
Das hat aber nichts damit zu tun, dass Drupal sich zum Ziel gesetzt hat,
mit einem schnellen, schlanken und in der Einfachheit seiner Handhabung unschlagbaren CMS,
gegenüber den aufwendigen anderen Projekten zu punkten.
.
.
Es geht im Wesentlichen vielmehr um die Direktimplimentation vieler Module,
die jetzt im Programmkernel verankert werden und das Ganze stark aufblähen.
Deshalb noch einmal die Frage:
.

.
Leider ist ja von Euch gerade zu dem Kernpunkt meiner Frage kaum etwas gesagt worden.
Oder habe ich da etwas überlesen?
.

.
Hierin besteht das Kernproblem.
Die Drupalentwickler weichen ja nun anscheinend vom Ursprungskonzept ab.
Und mein Einsatz der Betaversion bestätigt diesen Eindruck.
.

.
Hast Du da nicht was falsch in Erinnerung?
Irgendwie hieß das doch:
Nur auf einer soliden Basis lässt sich etwas aufbauen 8-)
Zieht man aber in einer bereits bestehenden Mauer die untere Steinreihe heraus,
dann stürzt das ganze Haus ein.
Du bist sicher kein Maurer, Ronald, oder irre ich mich?
.
Wenn nämlich auf diese Weise zukünftig weiterentwickelt wird,
dann werden von den implimentierten Modulen bald mehr abgestellt sein,
als dass User sie aktivieren.
Irgendwo hier im Forum habe ich gelesen,
dass ein Großteil der bereits in Drupal 7 enthaltenen Module bei vielen brach liegt.
.
...versinnbildlichter Spagat zur herausgezogenen Steinreihe der Mauer:
Da wird ein wesentlicher Bestandteil der Drupalkonzeption über den Haufen geworfen
und das schlanke System wird drall,
obwohl eine Reihe der Nutzer schon jetzt vieles nicht benötigt.
Nun bekommt er noch mehr davon.
Sachen die er gar nicht braucht.
Die, die er braucht (wie in Fall unseres Einsatzes von Drupal hier vor Ort in Berlin)
muss er nach wie vor gesondert laden.
Und Drupal wird immer komplexer.
Die Steinreihe ist quasi die Aufgabe einer der Grundeigenschaften von Drupal,
die es groß gemacht hat!
.
Und da schleichen sich dann ja doch Zweifel ein,
wozu dieser ganze Umfang an Funktionen mitgeschleppt werden soll.
Viel einfacher war da doch, sich die für den individuellen Einsatz notwendigen Funktionen,
die jeder einzelne User benötigte, hinzuzufügen
und sich auf diese komfortable Art genau d a s zusammenzustellen,
was tatsächlich im Einzelfall benötigt wurde.
.
Besonders brisant empfinde ich die Tatsache,
dass es gerade diese Funktionen sind, um die der Kernel aufgepeppt wird,
die der Grund für die mangelnde Kompatibilität sind,
den Übergang von Drupal 7 zu Drupal 8 nicht reibungslos vollziehen zu können,
da sich dies nicht programmieren ließ.
Zum einen sei die Ausgabe von Webseiteninhalten auf Kleingeräten ein Grund,
aber insbesondere das Einbinden einiger zuvor als Module verfügbarer Funktionen
mache einen Update unmöglich,
wodurch es für Sites, die auf Drupal 5 oder 6 entstanden sind,
und die jetzt mittlerweile auf Drupal 6 oder (wie bei uns) auf Drupal 7 laufen,
hinsichtlich der Administration unter Drupal 8 problematisch wird.
Ich finde es irritierend,
dass die Module einen Grund für den Kompatibilitätsmangel darstellen.
Wie kann das sein, wenn diese Module mit den genau gleichen Funktionen,
die zuvor vom User ausgesucht und manuell in den Kernel geladen wurden,
bei fester Integration derselben im Kernel derartige Probleme nach sich ziehen?
.
Aber ich bin Laie und ich denke in Frage der Programmierung wahrscheinlich falsch.
Das muss ich eingestehen.
.
Ich äußere ja hier nur meine persönliche Meinung.
.
Man beachte bitte:
Um hier nicht als Querschreiber und Bremser dazustehen,
habe ich in diesem Thread seit dessen Start nichts mehr geschrieben.
Eröffnet habe ich ihn im vergangenen Jahr!
.
Ich schrieb:
.

.
Die in Amsterdam aufgetretenen Mängel sind aber größtenteils noch immer nicht beseitigt.
Damit möchte ich n i c h t -wie Carsten das betonte- die Z e i t frage ansprechen,
zu welchem Termin Drupal 8 in einer offiziellen Version erscheint.
Wenn es notwendig ist -und da gebe ich Carsten völlig Recht-
soll es solang dauern, bis alle Bugs beseitigt sind und alles topp läuft.
Was ich vielmehr zum Ausdruck bringen will ist genau das,
was ich oben Ronald mit den Mauersteinen veranschaulicht habe,
denn es bewahrheitet sich anscheinend.
.

.
Dies alles wird nun in den Kernel verlagert.
Eine ROSSKUR sozusagen.
Jeder bekommt es nach dem Motto "Friss oder stirb!"
.
Liebe Community:
Ist es nicht diese Flexibilität,
die wir alle an Drupal so lieben?
Ist sie, diese Flexibilität, nicht bis jetzt das "Non plus Ultra" gewesen,
das Drupal so unschlagbar gemacht hat?
Nämlich, dass jeder User genau d a s bekam, was er brauchte?
Dass er sich die Funktionserweiterungen aussuchen konnte!
Die f r e i e Wahl, so wie seine Website ausgerichtet war!
.
.
Müssen wir uns mit Tools so zuschaufeln,
wie Microsoft Word mit seinen hunderten Funktionen,
von denen jeder, der einen 0/8/15 Text schreiben will kaum eine braucht?
.
Muss jeder, der eine Textverarbeitung für Zehnzeiler einsetzt... ...
... ...Schattenbildung mit Fotobearbeitung und Statistiksoftware im Menü haben?
Muss jeder, der Drupal einsetzen will, gleich die ganze Palette Module mitladen?
.
.
.

.
Ok, Carsten.
Wer nichts verändert, der bleibt stehen.
Und Stillstand ist sicher der Tod einer Software,
die dann von anderen überholt wird.
.
Und:
Drupal wurde bis heute immer besser!
Das spricht alles f ü r Veränderungen.
So soll es ja auch in Zukunft sein.
.
Nur weicht man jetzt von Grundsätzen ab, die Drupal groß gemacht haben.
Veränderungen, die die Funktionsvielfalt erweitern sind eine Sache.
Aber DIE BEIBEHALTUNG ALTER FUNKTIONEN, die in den Kernel hineingezwängt werden,
die ist eine andere.
.
Der Vergleich mit Microsoft XP, den Ronald eingebracht hat:
.

.
Man kann dem statistischen Zahlenwerk zweifelsfrei entnehmen:
Kein System war so erfolgreich wie Windows XP!
Dem wird wohl niemand hier im Forum widersprechen.
.
Oder gibt es hier vielleicht jemanden, der Windows Vista vergöttert?
.
.

.
BRAVO, Ronald :-)
So ist es!
Das ist voll und ganz auch meine Meinung.
.
Dasselbe mit Windows 7.
Ein schnelles und stabiles Betriebssystem.
Von Anfang an übrigens.
.
Wegen der Kleingeräte wurde in Windows 8 dann alles "gekachelt".
Das Startmenü wurde merkwürdigerweise entsorgt.
Weniger als 10 Prozent der User des Web benutzen Windows 8.
Alles andere ist Mache der Macher - - - will heißen:
Man gaukelt den Usern ein erfolgreiches Windows 10 vor.
dass verschenkt werden muss, um es an den Mann zu bringen!
.
Jetzt springt man auf einmal auf Version 10 !?!
Nicht einmal die Industrie will es haben.
Und die neueste Strategie:
MICROSOFT MUSS WINDOWS 8 ANDEREN AUFZWÄNGEN, damit es kein Flopp wird.
Aber Windows 7 wird bereits jetzt nicht mehr weiterentwickelt.
.
Tolle Wurst :-b
.
.
Wer im Webdesign tätig ist,
der wird Windows 7 oder Linuxdistributionen vielleicht zu schätzen wissen.
Mit einem guten Editor und Firefoxtools kann man zufrieden sein!
Und sicherlich gibt es viele, die einen Sch***dreck auf Windows 8 geben.
Mit Windows 10 setzt Microsoft noch eins drauf auf die Abartigkeit!
.
Die von Carsten angesprochene... ...
.

.
... ...läuft aber leider auf das zuvor beschriebene Microsoft Syndrom hinaus!
(Dem immer mehr Programme anheim fallen)
.
Wer Word für eine einfache Texterstellung benötigt,
der muss diese Riesentextverarbeitung für Dissertationen und Buchskripts,
für Präsentationen und illustrierte Dokumentationen,
für Tabellen, Statistiken und sonstwas,
mit all seinen Zeichentools und Korrekturprogrammen
und tausenden Absatz-, Formatierungs-, Cover-, Hintergrundbild- und Trallalla-Funktionen
akzeptieren.
.
Hallo Freunde:
Inzwischen arbeite ich mit WordPad,
dem Zubehörtool von Windows!
Damit bin ich besser bedient.
Und Word setze ich noch dreimal im Jahr ein
(falls ich in einem solchen Fall nicht direkt im Quark Xpress layoute).
WordPad kann ich nur jedem von Euch empfehlen,
wenn er nicht mit dem kompletten Office arbeiten muss.
Wer mehr Funktionen benötigt,
der bedient sich anderer Software.
Oder wählt eine Software mit entsprechenden Addons oder externen Zusatzfunktionen.
Alles in einen Kernel zu packen ist nicht sinnvoll.
.
GENAU DIE GLEICHE ENTWICKLUNG befürchte ich bei meinem geliebten Drupal!
.
Da kannst Du mir erzählen, was Du willst, Carsten.
Ich will es ja nicht beschreien, aber ich befürchte,
mit Drupal nimmt das einen ähnlichen Weg!
.
.
.

.
Eben.
.
Und genau diesem Argument,
das Du in Deinem Posting ja voranstellst,
zolle ich hiermit Rechnung!
.
Mein Beitrag zur Community sind diese meinerachtens berechtigten Bedenken,
dass Drupal auswuchert und ihm ein ähnliches Schicksal bevorsteht,
wie so vielen anderen Programmen.
Am Allumfassenden.
An der alle Funtionen beinhaltenden Aufblähkrankheit.
.
Microsoft, so sagen mittlerweile viele Insider,
kann am Festhalten seiner "fortschrittlichen" Betriebssysteme
auch als Branchenriese zu Grunde gehen (andere haben das bereits vorgemacht!).
Das Ende des Internet Explorers haben viele vorausgesagt.
Und siehe da:
Jetzt wird er nicht mehr weiterentwickelt und verschwindet irgendwann ganz.
Er soll gänzlich eingestellt werden - kernelintegriert in Windows 11.
.
Wenn man also zur Community beitragen soll,
dann sollte derjenige, der das fordert auch akzeptieren,
dass gerade diejenigen, die gegen den Mainstream plädieren,
ÄUSSERST NÜTZLICH FÜR DIE PROJEKTENTWICKLUNG sein können.
Und als begeisterter Drupal-User will ich nur zum Projekt beitragen.
.

.
Hier sprichst Du mir doch im Grund aus der Seele, Carsten.
.
Ich meine:
So unterschiedlich sind unsere Ansichten doch garnicht!
.
A U S L A G E R U N G E N statt alles zu implimentieren.
Drupal schlank halten und die Modulvielfalt noch erhöhen.
D a s ist die bisherige Stärke dieses Systems!
(Würde Microsoft den Nutzern die Funktionen von Word gesondert anbieten,
in Form aufladbarer Tools oder Addons,
dann wäre es nach wie vor ein schlankes, schnelles Textverarbeitungsprogramm)
.
Und für die Anfänger wären eher programmierte Unterweisungen sinnvoll
- mit Fehlerkorrekturen für den Selbstlernprozess.
Die haben aber nichts im Kernel zu suchen.
.
Sorry, wer nicht upgraden kann sollte es lernen.
Deshalb kann man doch nicht jedem von Millionen Usern Module zumuten,
die sie letztlich nicht brauchen!
Thoor hat doch phantastische Lernvideos hier im Forum gefertigt,
anhand derer vieles sehr anschaulich an die Anfänger herangetragen wird.
Es sollte doch vielleicht ein Aufgabenkomplex für das Drupalcenter sein,
dies den Interessierten für den Einstieg näher zu bringen.

.
.
.
Auch in d i e s e m Punkt ist die Community gefragt, Carsten.
Das Lernen kann Software nur unzureichend ersetzen.
Sie ist immer nur ein Ersatz für das, was man n i c h t kann.
Und wer nicht in der Lage ist,
sich ein Modul hochzuladen, wenn er dessen Funktion benötigt,
der kann -sorry- auch schlecht mit Drupal arbeiten
- egal ob Drupal 6, 7 oder 8 !
Man muss deshalb nicht alles mit Gewalt in den Kernel stopfen,
um den so komplex wie möglich für jeden und alle zu machen.
Ich bezweifle, dass das für die Anfänger wirklich gut ist.
Das ist das Gegenteil dessen,
was man sich zu Projektbeginn zum Ziel gesetzt hat.
Da war es doch viel komplizierter und Drupal wurde in kurzer Zeit ein Durchstarter.
.
Mit der Auslagerung von Funktionen bringt es Jenna doch auf den Punkt:
.

Eben.
.
MAN KANN ES NICHT JEDEM RECHT MACHEN.
Oder Drupal hat bald mehr kernelintegrierte Funktionen als Word und Excel zusammen.
Individualität ist gefragt.
Und da jeder User seine eigene Vorstellung davon hat,
wie er sich sein Content Management System ausstatten will,
ist die Modulvielfalt für ein schlankes Programm das A und O der Software.
Für mich jedenfalls.
Und in meinem Bekanntenkreis denken viele so.
.
Und in einem weiteren Punkt bestätigst Du mich ja im Grund auch, Jenna:
.

.
Clever.
.
Hätte ich vor 6 Jahren auch tun sollen.
.
Habe ich aber nicht.
Weil ich mich auf Drupal verlassen habe.
Weil ich dachte, es werde weiterentwickelt.
Aber nicht in Richtung eines neues Kernels,
sondern im Hinblick auf die bestehende MODULVIELFALT.
Und meine Themes sind inzwischen auch versickert.
Ihr Development ist eingeschlafen.
Blöderweise hatte ich mich für die f a l s c h e n entschieden.
Und die endeten alle in einer Sackgasse.
Nun habe ich Drupal 7 (ein Jahr Arbeit, bis alles wieder komplett online war!)
Das mit der Liste werde ich ab Drupal 8 genauso machen wie Du, Jenna :-)
.
Aber meine Frage an alle:
Ist das wirklich notwendig?
Und:
Sind das noch die Drupalideale von vor 5 Jahren?
.

.
Da scheinen aber nicht alle Deiner Meinung zu sein, Jenna.
.

.
.
.
Da sagst Du was, Artweb!
.
Leute, die wie wir mit als erste in Drupal eingestiegen sind,
weil es kostenfrei und gut war,
DIE HABEN ÜBERHAUPT KEINE KUNDEN!
Ich bin im Vorstand einer gemeinnützigen Fördervereinigung in Berlin.
.
Und selbst die Leute im südlichsten Teil von Bayern
oder auf der nördlichsten Hallig vor Ostfriesland,
die werden mitbekommen haben, dass der Berliner Senat kein Geld hat.
.
Da gibt es hier keinen "größeren Betrag",
den wir alle 3-4 Jahre in die Hand nehmen können, Jenna!
.
Aber WIR sind es, durch die Drupal so groß geworden ist.
Denn als Drupal noch keiner kannte, waren WIR es,
die als erste zu einem Zeitpunkt, als alles noch nicht so perfekt war,
mit Drupal anfingen (und mit Drupal groß wurden).
Hierdurch entstand natürlich auch eine gewisse Abhängigkeit davon,
dass die Entwicklung uns gerecht wurde.
.
Wir, die kleinen Drupalfans der ersten Stunde,
die zwar nicht engagiert am Kernel mitgearbeitet haben
(davon habe ich sowieso keine Ahnung ;-),
aber die tausende(!) Stunden Zeit und das Vertrauen in Drupal
in den ehrenamtlichen Aufbau von großen Webseiten stecken haben.
Und die die Entwicklung allein durch die Resonanz, die Drupal dadurch hatte, förderten.
.
In den letzten Jahren ist immer mehr von Auftraggebern die Rede.
Von Kunden, für welche die Webdesigner arbeiten.
Das Grundkonzept war aber einmal ein Studentenprojekt.
Es wird mir kaum jemand hier widersprechen,
dass davon nicht mehr viel übrig geblieben ist.
.
Muss es ja auch nicht.
Alles entwickelt sich weiter.
.

.
Drupal hat seinen Siegeszug angetreten.
Da kann man nicht genug Komplimente machen!
Und auch die Entwickler arbeiten ehrenamtlich.
.
Nur sollte man nicht alles über Bord werfen und seinen Wurzeln treu bleiben.
Da wäre die Betreuung der alten Versionen beruhigend.
.

.
Da wird es Dir bald ergehen wie Microsoft-Usern
mit einer nicht mehr betreuten Windows-Version.
.
Friss oder Stirb, Artweb.
.

.
Naja, wenn das so einfach wäre... ...
.
... ...dann hätte ich diesen Thread nicht begonnen :-)
.
.
.
===> Grüße aus dem "Kernel" von Berlin (am Bahnhof Zoo :-)
...hier in der Stadt wurde der Senat u p g e d a t e t. Genützt hat's auch nichts.
Der Chefentwickler ist gegangen und ein neuer "Alter" steht allem voran.
.
:-)))
.
.
.
Euer Drupi
.
.
.
.
.

Moin.
Kannst Du Deine Kritikpunkte auf ein paar wenige Kernaussagen zusammenfassen? Der Text ist irgendwie zu lang zum lesen und wirkt auch mich auch ein wenig konfus ...

Ich gehe mal auf ein paar Punkte ein, die mir beim Überfliegen aufgefallen sind:

Drupal 8 verlangt "PHP 5.4.5 (or greater)", idealerweise jedoch PHP > 5.5. Details dazu findest Du unter anderem in der INSTALL.txt.

Das ist korrekt. Aus diesem Grund wurde sich dafür entschieden, für Drupal zukünftig Symfony als Basis zu verwenden. Damit schafft man eine grundsolide Basis, die nicht nur eine Insellösung ist (wie bisher), sondern von einem breiten Spektrum an Software verwendet wird.

Welche Mängel meinst Du konkret?

Mag sein, dass ich den Satz nicht vollkommen korrekt verstehe, aber ... welchen Übergang meinst Du hier? Meinst Du ein Upgrade von einer Drupal-7-Seite zu Drupal 8? Der funktioniert mit Migrate wunderbar.

Wie kommst Du darauf?

Ehrlich gesagt, habe ich auch nach mehrmaligem Überfliegen Deines Beitrags noch nicht wirklich verstanden, worum es Dir eigentlich geht :/
Vielleicht klärt sich das ja mit etwas konkreteren Beispielen ...

 Stefan

.
.
.
Hallo Stefan,
.
danke für die umgehende Reaktion.
.
Ok, das ist mir vielleicht ein wenig aus dem Ruder gelaufen.
(Heute ist Sonntag und ich habe einfach drauflosgeschrieben :-)
.
Ich konkretisiere das heute Abend nochmal auf die wesentlichen Punkte,
die Du angesprochen hast.
.
.
.
Bis später
.
.
Drupi
.
.
.

.
.
.
Hi Stefan
.

.
Klar kann ich das,
allerdings würde ich weniger von K r i t i k sprechen,
als von Bedenken!
Bis jetzt bin ich zufrieden mit Drupal; hochzufrieden!
Ich habe nie etwas anderes hier geschrieben.
Der Wechsel von 6 auf 7 war lediglich viel zu aufwendig.
.
Dieser Wechsel von 6 auf 7 lässt mich fürchten,
dass von 7 auf 8 zu wechseln noch problematischer wird.
.
BEDENKEN
1.
Zuviele Module werden im Kernel integriert
die zuvor individuell aufladbar waren.
.
2.
Durch diesen Umstand
schwerfälligeres und unübersichtlicheres System,
mit ungenutzten Funktionen
(auf welches die individuell notwendigen,
im Kernel trotzdem nicht enthaltenen Module,
dann ja noch zusätzlich aufgeladen werden müssen).
.
3.
Keine technologische Betreuungssicherheit
der Drupalvorgänger und deren Drupalmodule.
(siehe PS.! *)
.
.
VORBEDINGUNG UNSERES WEBAUFTRITTS

.
Als gemeinnützige Vereinigung
sind wir auf das 1-Terrabyte-Volumen angewiesen,
das wir uns mit anderen vom Senat geförderten Usern teilen müssen,
wozu auch die aufgespielte Datenbank gehört
(Nutzungsbedingung der Finanzierungsvorgabe).
.
Der uns zur Verfügung stehende Provider
bietet auf dem bezahlten Server nur php version 5.4.1 an.
Ab dem 2. Halbjahr wird die Version 5.4.3 auf dem Server laufen.
Erst für den Jahreswechsel ist evtl. 5.5 angekündigt,
was mit den anderen Mitnutzern jedoch abgeklärt werden muss,
ansonsten wird eine solche Installation nicht stattfinden
(Wir haben > 300 GB auf dem Server laufen).
Als Grund für die Weiterführung der alten Version
wurde bis jetzt u.a. der Entwicklungsstopp von php-Version 6 angegeben
(was ich für eine Ausrede halte).
.
Nun kann man ja nicht sagen,
dass die 5.4er-Versionen die unaktuellsten sind,
insbesondere auf offentlich-rechtlich geförderten Servern.
Aber für das kommende Drupal reichen sie nun mal nicht.
Und das geht mittlerweile allen öffentlich-rechtlich geförderten
mit Drupal betriebenen Projekten so.
(Das sind allein im Raum Berlin etwa 1.200
- darunter die Bibliotheksdatenbank mit den angeschlossenen Büchereien,
die sich gerade von Drupal verabschieden und neue Lösungskonzepte suchen)
Kaum jemand hat Bock, sich privat neben der Förderung
irgendwoanders Webspace holen zu müssen
und mit der Webseite dann zu Testzwecken
von einem Server zum anderen umzuziehen.
.
.
KERNPROBLEM VERSIONSWECHSEL

.
Ich fragte ja schon:
Kann ich eine unter Drupal-7.7 betriebene Site
mittels eines Wechsels auf Drupal 8
durch einfaches Upgraten der Version weiterbetreiben?
(Klar, dass einiges nachgearbeitet werden müsste)
.

.
Ich lasse mich überraschen :-))))
.
UPGRADE

.
Das von Dir als funktionell einwandfrei bezeichnete Migrate!
.
Bisher habe ich da noch nicht soviel Positives darüber gehört,
wenn es um umfangreiche Seiten ging.
Aber wie gesagt:
Bei mir scheitert es ja momentan schon allein am php.
Wo kann ich nachlesen, was da inzwischen funktioniert
und wo es bei Migrate noch Engpässe gibt?
.
.
.
===> Beste Sonntagsgrüße aus Berlin
.
.
Drupi
.
.
.
.
.
.
.
.
.
.
*) PS.:
Hinsichtlich der im Thread zuvor geäußerten Mitarbeit
der uneigennützig tätigen Modulentwickler
könnte man doch eine Art Pool für die Teams schaffen,
in denen sich Interessierte an der Fortführung des Supports eintragen
und die den Mitarbeitern an den Modulen
dann Spendenbeträge zukommen lassen, wenn diese weiterentwickelt werden.
.
Wir haben für das Team eines Moduls gespendet
und dann schlechte Erfahrung gemacht:
Das Modul wurde trotzdem nicht weiterentwickelt :-(
.
.
.

So erst mal schönen guten Abend!

Es ist schön und gut wenn die Entwicklung weiter geht nur in Moment sieht es danach aus, dass einige Kunden von sehr Mega Projekten sich wirklich überlegen... Drupal fallen zu lassen und auf Eigenentwicklung um zusteigen!

Ich selbst werde noch Treu bleiben und so lange wie möglich auf D6 Reiten bzw. habe vor kurzen ein Update durch geführt und es ist positive Verlaufen... nur ein gutes Gefühl hatte ich trotzdem danach nicht. Muss in kürze auch das Theme umstellen auf Responsniv... da wie hier an andere stelle bemerkt... Website bei Google abgewertet werden, die noch kein Responsiv Theme verwenden.

Wie hier schon angesprochen, darf Drupal nicht denn gleich Sch... machen wie Microsoft, Simatic et... bei wirklich Großen Projekten ist es fast nicht möglich auf ein Upgrade und vor allem die größte Gefahr bei Mega Projekten ist Google und Co!
Nehmen wir mal "Die Zeit" die Lesekommentar wurden mit Drupal umgesetzt und der Artikel Teil ist vermutlich eine Eigenentwicklung!
Meine Frage dazu, warum wurde sie nicht auch mit Drupal umgesetzt?

- Angst das die Seite dann bei Google und Co. nicht mehr aufscheint, weil zu viele Änderungen... Urls... Schlagwörter ect...
- oder zu hohe kosten
- zu lange Stehzeit bzw.

Deshalb Reiten wir das Pferd zu Tode... oder wir fangen von vorne an und überlegen uns mal wo wir hin wollen...
www.findart.cc

schönen Abend noch

Andreas

dass Drupal kein 0815 Webseitengenerator ist, sondern eben ein Framework mit CMS-Funktionalität.

Selbst ein aktuelles Joomla setzt PHP 5.5 voraus.

Je nach Umfang ist Drupal auch recht speicherhungrig, was ein professionelles Hosting erfordert.
Dass öffentliche Einrichtungen auch hier hinterherhinken, ist schade, liegt aber nicht an Drupal.

Dass es erst dann zu einer Freigabe des neuen Releases kommt, wenn dieses frei von kritischen Fehlern ist, ist eher ein Qualitätsmerkmal, als ein Mangel.

Hallo Ronald;

Du schriebst (vor immerhin 4 Monaten!):

Na prima :-)

Wenn Drupal 8 dann im Verlauf des Jahrs 2016 aus dem Betastadium heraus ist,
dann wird es zumindest das Qualitätsiegel "Erste Sahne" bekommen.

Was Du über Joomla und php 5.5 sagst ist natürlich richtig.
Das ändert trotzdem nichts daran, dass php 6 Server
für gemeinschaftlich genutzten Webspace so gut wie nicht vorhanden sind.

600 der 1200 öffentlich-rechtlichen und geförderten Webprojekte haben sich von Drupal getrennt.
Auf Druck der öffentlichen Hand hin.
Die mit Literatur und Verlagswesen beschäftigten Institutionen
fahren jetzt eine Schweizer Bibliothekssoftware.
Nun sollen auch die Bildungseinrichtungen nach Maßgabe des Senats umrüsten.
Das sind die fast die gesamten weiteren 50%!
Das war's dann.

Das Prädikat wird Drupal dann nicht mehr viel nützen.

===> Drupi

Warum siehst Du denn eigentlich die Notwendigkeit des Wechsels von Drupal 7 auf Drupal 8 aktuell gegeben? Drupal 7 ist sicherlich noch eine ganze Weile ein akzeptables und supportetes System. Selbst nachdem Drupal 8 dann da ist, bleibt es ja zumindest bis Drupal 9 weiterhin supportet.

Und wenn Du den großen Wechsel zwischen Drupal 7 und 8 scheust, dann wirf doch mal einen Blick auf Backdrop https://backdropcms.org/ - Das kann ein sehr interessantes Projekt werden, neben dem Enterprise-orientierten Drupal 8.

Ein sehr sehr oft formulierter Kritikpunkt in dem sehr langen Posting, der bisher konsequent ignoriert wurde, ist die Frage, warum so viele Module in den Kern wandern mussten, warum man den Weg des schlanken, schnellen erweiterbaren Systems verlassen hat.

Darauf fußt meine Frage: Bisher musste bei einem Sicherheitsupdate immer die gesamte Installation erneuert werden, ca. 2.000 Dateien. Ob nicht die paar veränderten Dateien gereicht hätten?
Wie sieht es nun zukünftig aus, muss ich bei einem Sicherheitsupdate immer alle 13.000 (!) Dateien löschen und in neuer Version hochladen? Bei Drupal 7 kann das ja schon mal im 4 Wochen-Takt vorkommen, und wenn man dann mehrere Seiten pflegt... Ich bezweifle, dass alle bei Update alle 13.000 Dateien geändert werden müssen.

So viel Schmarrn abzusondern?

Ich habe in diversen Foren Trolle erlebt, aber das hier ist schon Spitze.

oder?

Darauf bin ich schon im zweiten Kommentar dieses Threads eingegangen. Es gab dazu viele Diskussionen der internationalen Entwickler-Community auf drupal.org. Leider gab es zu wenig Unterstützung eines schlankeren Kerns. Siehe z.B. die Diskussion "[meta] Make core maintainable" in der ich mich vor 4 Jahren eingebracht hatte. Ich hatte seinerzeit ein Konzept "sehr Schlanker Kern" plus spezial Haupt-Distribution für Anfänger vorgeschlagen, da vor allem das Halten und Hinzunehmen vielr Module damit begründet wurde, daß Drupal immer noch ein CMS mit Standard-Features sein sollte.
Es ist meiner Meinung nach müßig, heute und hier im deutschsprachigen Drupalcenter die jahrealten Entscheidungen der weltweiten Community für Drupal 8 heute zu diskutieren, kurz bevor Drupal 8 nun fertig ist. Wer sich wie ich auch einen schlankeren Kern wünscht, könnte aber dabei zu helfen, daß die Idee vllt. in Drupal 9 Realität wird und sich dafür in Diskussionen auf drupal.org einsetzen.

In der Regel ändern sich insbesondere bei Sicherheitsupdate tatsächlich nur wenige oder gar nur eine Datei. Da reicht es aus, die Datei auszutauschen. Beim einfachen Pfad des allgemeinen Drupal-Updates mit "lade Dir Drupal runter und entpacke die Dateien, lösche alte Dateien, lade die neuen per FTP hoch ..." steigt natürlich die Zeit erheblich beim Komplett-Austausch.
Wenn ich in selten Fällen dazu gezwungen bin, werde ich von Kunden für das Warten bezahlt. Das wiederum ist immer ein gutes Argument auf ein Webspace-Paket abzugraden und vllt. auch gleich den Hosting-Anbieter zu wechseln, bei dem ich wie gewohnt SSH und Drush nutzen kann.
Drush lädt sich die Dateien dann direkt in das Drupal-Verzeichnis auf dem Server, nachdem ich vorher damit ein backup gemacht habe und auch die Update-Routinen starte usw.
Wer ausschließlich geänderte Dateien laden möchte, kann sein Drupal auch direkt mit Git verwalten. Das könnte man dann, wenn man möchte, sogar so organisieren, daß man die Code-Dateien z.B. lokal pflegt und sich dann bei Updates eine Diff-Datei erstellt und dann nur eine Diff-Datei auf den Zielserver lädt und dort applied. Bei dringenden Sicherheits-Updates ist es oft ein guter Weg, vllt. nur den richtigen Patch anzuwenden. Aus dem Grund ist es immer eine gute Idee, sich die Nutzung von Patchen anzueignen.
Ein anderer Weg, der auch Anfängern leichter fallen könnte ist die Verwendung von FTP/SFTP-Programmen, die lokale Ordner mit Ordnern auf Ziel-Servern vergleichen können und dann nur die unterschiedlichen Dateien hochladen ...

Daß übrigens in Drupal 8 Core nun fast 13000 Dateien sind hat nicht so viel damit zu tun, daß nun z.B. Views in den Core gewandert ist. Das liegt vor allem an diversen neuen Technologien unter der Haube. Vor allem die Nutzung des PHP-Framework Symphony und allgemein die Nutzung von mehr objektorientierter Programmierung und passender Konventionen führte zu einer massiven Erhöhung der Datei-Anzahl.

für den Tipp mit dem ftp-Vergleich, das wird wohl meine Lösung sein. Zur Diskussion hast Du natürlich Recht. Es ist schon interessant, wie in der deutschen Community darüber gedacht wird. War es denn wirklich eine Entscheidung der weltweiten Community? Oder der holändischen? Ich hoffe auf D9 ;-)

Grüße
frank