Verschiebung der Einstellung alter PHP-Versionen & Info zur neuen Webserverplattform

[rp_df]

Und schlecht entwicklelte, d.h. nicht updatefähige Software ist schlicht schlecht entwickelt.

Sollte beispielsweise PHP8 eine Reihe Breaking Changes mitbringen (was außerhalb Deines Einflussbereiches liegt) und Dein Code nicht mit vertretbarem Aufwand kompatibel zu machen sein, dann hast Du also "schlicht schlecht entwickelte Software" erstellt. Wenn Du nicht 5 Jahre vor den PHP-Core-Entwicklern weißt, wo die Reise hingeht, bist Du ein schlechter Einwickler...

Für individuelle größere Projekte in PHP wird man in der Regel auf MVC-Frameworks wie Laravel, CakePHP, Symfony, Yii, etc setzen, weil es keinen Sinn macht, das Rad jedes mal neu zu erfinden. Die älteren Versionen waren nicht PHP7.3-kompatibel und die neueren Versionen haben irgendwann Breaking-Changes bekommen. Ein Update alter Software auf die neue Framework-Version ist dann häufig wirtschaftlich nicht mehr darstellbar. Generell ändern sich im Laufe der Zeit einfach Architekturen und Paradigmen. Das man das als Update in älterer Software sinnvoll nachrüsten kann, ist völliger Unsinn.

Domainfactory hat erstmals am 29.05.2019 per Newsletter die Abschaltung von PHP 5 angekündigt. Am 04.09.2019 wurde erstmals ein konkreter Termin genannt. Je nachdem wie man rechnen möchte, hatte man dann 6 oder 9 Monate Zeit. Das reicht nicht, um komplexe Projekte bei mehreren Kunden neu aufzusetzen. Es hat auch hier dazu geführt, das teure Zwischenschritte oder Umzüge erfolgten. Die wären nicht erfolgt, wenn gleich klar gewesen wäre, dass die Abschaltung erst in 12-18 Monaten erfolgt. Dann wäre genug Zeit gewesen, um die Projekte gleich neu aufzusetzen. Am 16.09.2019 wurde mitgeteilt, dass PHP 5 auch sofort abgeschaltet wird, sollten darin Sicherheitslücken gefunden werden. Da wurde die Pistole auf die Brust gesetzt und man musste damit rechnen, dass PHP5-Projekte schon morgen nicht mehr laufen. Wichtige Unternehmensprojekte auf Basis PHP5 waren damit eigentlich von heute auf morgen nicht mehr bei DF zu betreiben.

Angesichts der aktuellen dramatischen Lage in der Welt erscheint mir der PHP Abschalt Termin von dF doch arg unwichtig...

Aber dann doch so wichtig, dass Du Dich dazu auslassen und jeden Satz einzeln sezieren musst. Keine weiteren Fragen...

[Gast]

Sollte beispielsweise PHP8 eine Reihe Breaking Changes mitbringen (was außerhalb Deines Einflussbereiches liegt) und Dein Code nicht mit vertretbarem Aufwand kompatibel zu machen sein, dann hast Du also "schlicht schlecht entwickelte Software" erstellt. Wenn Du nicht 5 Jahre vor den PHP-Core-Entwicklern weißt, wo die Reise hingeht, bist Du ein schlechter Einwickler...

5 Jahre vorher ist doch vollkommen polemisch. Zu (Individual-) Software gehört eben auch, regelmäßige Pflege und Updates. Das war im Grunde schon immer so. Es gab und wird Breaking Changes geben. Und ich nehme mich da übrigens nicht aus. Ich habe schon eine Menge schlechtern Code geschrieben, der weder professionell noch updatefähig war. Problem daran war nie, dass es Updates seitens der System gab, sondern das ich immer aus finanziellen Gründen (der Kunde will alles aber hat kaum Geld) "gepfuscht" und dann auch sorglos ohne Wartungsvereinbarungen (ach, das brauchen wir doch nicht...) habe. Und natürlich hatte und habe ich stets eine Lernkurve zu meistern. Und ja, das ist in meinen Augen schlechte Software, denn Software ist eben keine Hardware, die in Metall gemeißelt ist. Die Anpassbarkeit ist doch gerade ein Vorteil von digitalen Inhalten!

Für individuelle größere Projekte in PHP wird man in der Regel auf MVC-Frameworks wie Laravel, CakePHP, Symfony, Yii, etc setzen, weil es keinen Sinn macht, das Rad jedes mal neu zu erfinden. Die älteren Versionen waren nicht PHP7.3-kompatibel und die neueren Versionen haben irgendwann Breaking-Changes bekommen. Ein Update alter Software auf die neue Framework-Version ist dann häufig wirtschaftlich nicht mehr darstellbar. Generell ändern sich im Laufe der Zeit einfach Architekturen und Paradigmen. Das man das als Update in älterer Software sinnvoll nachrüsten kann, ist völliger Unsinn.

ist das nicht genau das generelle Problem? Alle verlassen sich auf andere (aufgeblähte Frameworks mit x Abhängigkeiten), die das bestimmt lösen. Spannend dazu ist im weitesten Sinne ein Vortrag von fefe: https://media.ccc.de/v/36c3-10608-da...klich_spektrum . Du schreibst selbst: es ist "unwirtschaftlich" ein Update zu machen bei Breaking Changes. Warum? Wenn die Alternative darin besteht, alles neu zu machen, dann doch wohl nicht.
Diese starke Vernetzung / Nutzung von externen Tools könnte auch ein / das Problem sein. Vielleicht ist ein Fehler in einer composer Komponente das digitale corona?
Ich denke, darin liegt eine große Herausforderung unserer Zeit.

Domainfactory hat erstmals am 29.05.2019 per Newsletter die Abschaltung von PHP 5 angekündigt. Am 04.09.2019 wurde erstmals ein konkreter Termin genannt. Je nachdem wie man rechnen möchte, hatte man dann 6 oder 9 Monate Zeit. Das reicht nicht, um komplexe Projekte bei mehreren Kunden neu aufzusetzen. Es hat auch hier dazu geführt, das teure Zwischenschritte oder Umzüge erfolgten. Die wären nicht erfolgt, wenn gleich klar gewesen wäre, dass die Abschaltung erst in 12-18 Monaten erfolgt. Dann wäre genug Zeit gewesen, um die Projekte gleich neu aufzusetzen. Am 16.09.2019 wurde mitgeteilt, dass PHP 5 auch sofort abgeschaltet wird, sollten darin Sicherheitslücken gefunden werden. Da wurde die Pistole auf die Brust gesetzt und man musste damit rechnen, dass PHP5-Projekte schon morgen nicht mehr laufen. Wichtige Unternehmensprojekte auf Basis PHP5 waren damit eigentlich von heute auf morgen nicht mehr bei DF zu betreiben.

Weiterhin stimme ich zu, dass die Kommunikation alles andere als gut war. Doch das der PHP Support für ältere Versionen seitens der PHP Entwickler eingestellt wurde, war auf anderen Stellen vorher kommuniziert worden und ist auch nicht in der Verantwortung von dF.
Auch ich habe meine Weihnachtsferien verschoben und aufgrund des Termins die Feiertage mit Updates und Auswechseln alten Codes verbracht. War nicht toll, mich stört einfach nur, dass der Anspruch rüber kommt, dF müsste das anders machen. Ich sehe die Verantwortzung für nicht oder schlecht updatefähige Software tatsächlich bei uns Entwicklern. Natürlich können wir auch selbst Systeme aufsetzen, welche die alte PHP Versionen nutzen. Das verbietet doch niemand. Aber genau da Risiko können und wollen wir eben nicht eingehen, verlangen es aber von anderen.

Aber dann doch so wichtig, dass Du Dich dazu auslassen und jeden Satz einzeln sezieren musst. Keine weiteren Fragen...

Der Abschalttermin ist mir da egal. Jedoch schaue ich hier oft rein, ob es etwas neues zu dem Thema neue Plattform gibt. Und ich mag einfach nicht mehr "wegschauen", wenn ich etwas als ungerecht kommuniziert empfinde.
Vielleicht ist noch wichtig: ich greife weder Dich noch andere an. Zumindest ist das nicht meine Intention. Ich halte es aber inzwischen auch nicht mehr für zieilführend, dF anzugreifen.
Und ich seziere keine Sätze (warum diese Wortwahl?) sondern versuche nur, sinnvoll zu antworten. Das gelingt zumindest mir in Abschnitten besser.

[Lukas M.]

5 Jahre vorher ist doch vollkommen polemisch.

Nur mal so als Richtwert: Die aktuelle LTS-Version von Contao hat einen Support-Zeitraum von 4,5 Jahren. Da sind Betas und RC übrigens noch nicht dabei, von der Entwicklungsplanung mal abgesehen. So weit hergeholt sind die 5 Jahre also nicht.

[rp_df]

5 Jahre vorher ist doch vollkommen polemisch.

Überhaupt nicht. Ich rede hier generell nicht von schnelllebigen Websites auf Wordpress-Basis, sondern von größeren, individuellen Software-Projekten. Da sind 5 Jahre erwartete Nutzungsdauer schon fast die Mindestanforderung. Ein Cakephp 1.3 wurde beispielsweise 2010 released und bekam bis 2015 Updates. Es wurde aber eben keine Kompatibilität zum 2015 veröffentlichten PHP 7 mehr hergestellt. Ein Yii2 wurde 2014 released. End of life wird erst 2025/26 sein. Das heißt aber nicht zwingend, dass es Kompatibilität zu PHP8 bzw. bis dahin erschienenen Folgeversionen geben wird. Der Support für PHP 7.3 wird aber bereits 2021 enden. Der für PHP 7.4 2022. Woher soll jemand heute wissen wissen, welche Breaking Changes es möglicherweise in PHP 8.1, 8.2, 8.3 geben wird, die sicher bis 2025 released werden? Das hat null mit schlechter Software zu tun, sondern damit, das andere strategische Entscheidungen treffen, die nicht absehbar sind, aber möglicherweise sehr ungünstig für das eigene Projekt ausfallen.

ist das nicht genau das generelle Problem? Alle verlassen sich auf andere (aufgeblähte Frameworks mit x Abhängigkeiten), die das bestimmt lösen.

Sicher gibt es das Problem, das häufig mit Kanonen auf Spatzen geschossen wird. Bei der Hälfte der Wordpress-Installationen mit zig Plugin wird einem schlecht. Bei komplexen Projekten ist es aber sinnvoller, ein etabliertes, verbreitetes Framework zu nutzen. Die Codequalität wird höher, die Bugrate niedriger sein. Die Entwicklung wird schneller gehen und die Kosten werden niedriger sein, als wenn man alles selbst schreibt. Soll die Software z.B. auch Rechnungen im PDF-Format generieren, dann ist es sinnvoller auf eine passende PDF-Bibliothek zu setzen, als sich wochenlang durch die diversen PDF-Spezifikationen zu quälen und eine eigene PDF-Bibliothek zu schreiben (Allein die Spezifikation für PDF 1.7 ist z.B. über 750 Seiten lang).

[Gast]

Überhaupt nicht. Ich rede hier generell nicht von schnelllebigen Websites auf Wordpress-Basis, sondern von größeren, individuellen Software-Projekten. Da sind 5 Jahre erwartete Nutzungsdauer schon fast die Mindestanforderung. Ein Cakephp 1.3 wurde beispielsweise 2010 released und bekam bis 2015 Updates. Es wurde aber eben keine Kompatibilität zum 2015 veröffentlichten PHP 7 mehr hergestellt. Ein Yii2 wurde 2014 released. End of life wird erst 2025/26 sein. Das heißt aber nicht zwingend, dass es Kompatibilität zu PHP8 bzw. bis dahin erschienenen Folgeversionen geben wird. Der Support für PHP 7.3 wird aber bereits 2021 enden. Der für PHP 7.4 2022. Woher soll jemand heute wissen wissen, welche Breaking Changes es möglicherweise in PHP 8.1, 8.2, 8.3 geben wird, die sicher bis 2025 released werden? Das hat null mit schlechter Software zu tun, sondern damit, das andere strategische Entscheidungen treffen, die nicht absehbar sind, aber möglicherweise sehr ungünstig für das eigene Projekt ausfallen.

Bzgl. der Laufzeit von solchen Projekten bin ich bei Dir, aber wenn ich ein Projekt für 5 Jahre oder mehr anlege, sollte ich eben auch das Thema Updates miteinplanen und ggf. in den 5 Jahren verteilt auch noch einmal das Erstbudget für Updates zurückstellen. Das das nicht immer geht und nicht einfach ist, ist mir auch aus eigener Erfahrung klar. Es ist doch von Anfang an klar, dass es am Zeitpunkt x zu Inkopatibilitäten kommen wird. Eine andere Lösung wäre, ein anderes Hosting zu wählen, d.h. konsequent selbst zu hosten mit abgesicherten Versionen der Entwicklungstools. Ich kann eben nicht vom Standardhoster verlangen, für mehr als 5 Jahre das "Serverimage" einzufrieren.
Mir ging es bei den 5 Jahren um die Aussage "5 Jahre vor den PHP Entwicklern wissen, was kommen wird". Das hielt ich für überzogen.

Sicher gibt es das Problem, das häufig mit Kanonen auf Spatzen geschossen wird. Bei der Hälfte der Wordpress-Installationen mit zig Plugin wird einem schlecht. Bei komplexen Projekten ist es aber sinnvoller, ein etabliertes, verbreitetes Framework zu nutzen.

Volle Zustimmung von mir.

Die Codequalität wird höher, die Bugrate niedriger sein. Die Entwicklung wird schneller gehen und die Kosten werden niedriger sein, als wenn man alles selbst schreibt. Soll die Software z.B. auch Rechnungen im PDF-Format generieren, dann ist es sinnvoller auf eine passende PDF-Bibliothek zu setzen, als sich wochenlang durch die diversen PDF-Spezifikationen zu quälen und eine eigene PDF-Bibliothek zu schreiben (Allein die Spezifikation für PDF 1.7 ist z.B. über 750 Seiten lang).

Klar, das nutze ich auch. Und doch ist es z.B. eine Entscheidung, eine "kostenlose" Open Source Lösung einzuetzen, bei der dann andere aus Eigeninteresse Weiterentwicklungen machen sollen, selbst in die Weiterentwicklung mit einzusteigen, die verwendeten Tools und Bibliotheken deutlich finanziell zu unterstützen oder eben kostenpflichtige Tools mit definierten Supportverträgen, in denen auch die Anpassung an neue Umgebungen zugesichert wird, zu nutzen.

Ich denke, dass es da noch ein Umdenken braucht. Ich zumindest habe zwar das eine oder andere Open Source Projekt mit kleinem Geld finanziell unterstützt, aber das ist kein wirklich signifikanter Rahmen. Warum nicht bei neuen großen Projekten eine Art Lizenzabgabe (besser: Weiterentwicklungsabgabe) für die verwendeten Tools einplanen? Fänd ich sinnvoll, habe ich aber bisher auch noch nicht wirklich gemacht.

[masterframe]

Ich denke ihr sprecht über zwei paar Schuhe.
Bei einem individuellen Software-Projekt welches für den Geschäftsbetrieb essentiell ist und einen Haufen Geld gekostet hat, da setzt man doch nicht wirklich auf Shared Hosting?

In solchen Fällen nimmt man sich besser ne JiffyBox und installiert dort sowas wie CentOS. Auf dieser Grundlage kann man dann schon mal optimistisch in die nächste Jahre blicken.

Dadurch dass man dann auch die Software-Plattform selbst kontrolliert und wartet dürften dann eigentlich keine unvorhersehbaren PHP Updates etc. dazwischen funken.

[Gast]

Ich denke ihr sprecht über zwei paar Schuhe.
Bei einem individuellen Software-Projekt welches für den Geschäftsbetrieb essentiell ist und einen Haufen Geld gekostet hat, da setzt man doch nicht wirklich auf Shared Hosting?

In solchen Fällen nimmt man sich besser ne JiffyBox und installiert dort sowas wie CentOS. Auf dieser Grundlage kann man dann schon mal optimistisch in die nächste Jahre blicken.

Dadurch dass man dann auch die Software-Plattform selbst kontrolliert und wartet dürften dann eigentlich keine unvorhersehbaren PHP Updates etc. dazwischen funken.

Danke für die Klarstellung. Das trifft es im Grunde sehr gut. Im ShredHosting sind die Dinge einfach schneller veränderlich und das muss ich bei meinen Projekten berücksichtigen. Für umfangreiche Individual Software ist das dann nicht geeignet.

[Mecksite]

So dramatisch, wie Sie meine Worte interpretieren, sehe ich die Geschichte nicht. Ebensowenig Ihre Unterstellung, ich würde sie über die aktuelle Corona-Krise stellen. Als Marketingmensch finde ich es halt schade, wenn sich ein Unternehmen, wie DF nicht über die Auswirkungen seiner Kommunikationsstrategie im Klaren ist und agiert, wie ein Startup in den ersten zwei Wochen. Dass irgendwann Server und der Technik umgestellt werden ist kein Problem, es ist nur ein Problem wenn man den Leuten ständig schreibt, so am Soundsovielten ist vorbei und dann ist Pustekuchen. Dass nicht abgeschaltet wurde, ist meiner Überzeugung nach nur passiert, weil DF eine riesige Menge an Kunden abhanden gekommen ist. Alleine meine Agentur hat über 150 Domains und 63 Kunden von DF zu Ionos umgezogen. So etwas darf man zum Glück in Deutschland kritisieren und wird sicher auch bei zukünftigen Entscheidungen, die ähnlich gelagert sind, eine Rolle spielen. Wenn Sie größere Systeme von einem Hoster zum anderen umziehen, werden Sie feststellen, dass es weitaus umfangreicher ist, als einen Bäcker zu wechseln.
Viele Grüße Ralph Meck

[rp_df]

Ich denke ihr sprecht über zwei paar Schuhe.
Bei einem individuellen Software-Projekt welches für den Geschäftsbetrieb essentiell ist und einen Haufen Geld gekostet hat, da setzt man doch nicht wirklich auf Shared Hosting?

Die Einschränkungen hinsichtlich PHP-Versionen betreffen auch Managed Server und nicht nur Shared-Hosting. Ein Root-Server, egal ob als dedizierter, VPS- oder Cloud-Server erhöht den Administrationsaufwand. Man ist eben für alles selbst verantwortlich. Auch wenn Lösungen wie Plesk einem viel Arbeit abnehmen, sprechen wir bei 5 Jahren Betriebszeit über 5.000 bis 10.000 Euro an zusätzlichen Kosten. Man hat eben nicht die Skaleneffekte, die große Anbieter bei der Administration von zigtausenden identischen Servern haben. Der Aufwand für Dinge wie Reputations-Management/De-Blacklisting beim E-Mailversand, Monitoring wird gern übersehen. Den können einem Plesk und Co. nicht abnehmen. Das kann man alles allein aufbröseln. Man kann die Administration auch wieder auslagern, z.B. *********, kann für E-Mail-Versand auf externe Anbieter setzen, usw. das summiert sich über die Jahre aber auch auf genannte Größenordnungen. Am Ende ist es wie immer eine Abwägung. Die fiel hier zuletzt durchaus häufig Richtung Cloud-Server aus. Vor 5 Jahren fiel sie eben noch häufig anders aus.

[masterframe]

Die Einschränkungen hinsichtlich PHP-Versionen betreffen auch Managed Server und nicht nur Shared-Hosting.

Logo, die Software-Plattform bei dF ist in diesen Bereichen identisch. Deswegen sprach ich von einer Jiffy-Box.

sprechen wir bei 5 Jahren Betriebszeit über 5.000 bis 10.000 Euro an zusätzlichen Kosten.

Und? Wenn das gesamte Projekt auch nur 15.000 EUR gekostet hat ist eine kontinuierliche Betreuung für die von dir genannten 10.000 EUR günstig. Denn alternativ stünde ansonsten nach fünf Jahren eine Neuprogrogrammierung an (siehe oben). Ob diese Neuerstellung nach fünf Jahren dann wieder für 15.000 EUR zu haben ist wage ich zu bezweifeln. Daher ist ein Softwarewartungsvertrag häufig die günstigere Lösung als kurzfristig im Monat diese 200 Euronen zu sparen.

[Nils Dornblut]

Applaus hierfür! Hier wurden Urlaube verschoben, damit wir zum 02.03, alles umstellen konnten. Ein Kunde musste mehrere tausend Euro investieren, weil ein Update der Website auf PHP7.2 nicht mehr möglich war etc etc...

Der Aufwand und die Kosten sind ja absolut nicht verschenkt. Klar, hätte man das vorher gewusst, hätte der Urlaub nicht verschoben werden müssen. Leider war das aber erst recht spät absehbar und konnte dann auch erst kommuniziert werden. Dass es da zu einer Verschiebung des Urlaubs kam, tut uns leid und wir bitten für die Unannehmlichkeiten um Entschuldigung.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Ich lese gerade:

"Webspace als Add-on ist nur noch bis zu einer Gesamtgröße von max. 500 GB hinzubuchbar"

Soll das bedeuten, der GESAMTE Server hat maximal 500GB Webspace? ich kann noch meine 730GB, die JETZT aktuell belegt sind, nicht auf 2 Server verteilen!

Das bezieht sich auf Shared Hosting. Beim Managed Hosting gibt es keine Webspace Add-ons und wird es auch zukünftig nicht geben. Hier können durch unterschiedliche Optionen bei den Festplatten verschiedene Webspace-Varianten geschaffen werden.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Da muss ich aber nochmal klar widersprechen. Es ist nicht die Schuld des Websitebesitzers, wenn Sie Ihn mit einer Deadline zur Neuerung nötigen, denn es gibt durchaus Uraltsysteme, die laufen und sicherheitstechnisch so geblockt sind, dass es für den Kunden kein Problem gibt.

Die Termine ein Ende der Lebenszeit von in dem Fall PHP werden nicht durch uns vorgegeben. Unsere Entscheidung ist diesbezüglich, dass wir keine alten nicht mehr unterstützen Versionen von Anwendungen in unseren Systemen haben möchten. Das als Nötigung zu verstehen, halten wir für nicht richtig.

Er hat vielleicht viele individuelle Programmierungen und Inhalte in der Website, die man nur für sehr viel Geld auf ein neues System updaten kann. Entgegen anderer Provider haben Sie keinen extended Support angeboten, sondern mit einem festen Abschalttermin gedroht.

Gedroht haben wir damit nicht. Wir kündigen das seit vielen Monaten an, dass wir die vom Hersteller nicht mehr unterstützten Versionen nicht mehr anbieten werden. "Extended Support" bringt da eigentlich keinen Unterschied, wenn man den dauerhaft anbietet. Das nimmt ja nichts vom Risiko und man könnte es dann auch für alle weiterhin anbieten. Klar, man kann dann schreiben, dass Sicherheitsexperten das beobachten usw., aber hier sollte man auch so ehrlich sein, dass Lücken in den nicht mehr unterstützten Versionen viel weniger bekannt werden. Das Risiko steigt also durchaus dann und unsere Verantwortung spiegelt sich darin wider, dass wir solche Versionen zukünftig nicht mehr anbieten werden, auch wenn es für uns einfacher wäre einen extended Support (oder wie auch immer man den nennt) dann anzubieten und automatisch bei nicht umgestellten Domains zu berechnen.

Mit freundlichen Grüßen

Nils Dornblut

[Martin11]

Nils Dornblut
Gibt es News zur Umstellung auf die neue Serverplattform, wie ist der Stand der Dinge? Oder steht das wegen Corona mehr oder weniger still im Moment?

[Webrockers]

• TCL und Ruby on Rails wird nicht mehr angeboten

Grummel.

Jetzt habe ich gerade meinen früheren DF-Auftrag, den ich an einen anderen Kunden abgegeben hatte, nach Jahren wieder übernommen, spiele Ticket-Ping-Pong mit dem Support zu verschiedenen Thematiken um wieder alles in Gang zu bringen, plane die Zukunft mit dF und bekomme gerade so negative Gefühle, die ich nicht in Worte kleiden möchte.

Zu den Tickets der letzten Tage und einigen Kleinigkeiten der letzten Wochen, gesellt sich:
Seit heute komme ich wieder ins interne Resellerforum und lese mich durch, lerne, dass Jan Enigma abgezogen ist und stolpere nun noch über die Info, dass Ruby / Ruby on Rails irgendwann/bald nicht mehr zur Verfügung stehen wird.

Das triggert mich schon ein bisschen.
Instinktiv möchte ich gerade die Ehre haben.