Das wird alles sehr eng. Wir haben Shopware 5.5.10 im Einsatz, da Shopware 5.6 oder 6 durch fehlender MySQL 5.7 Unterstützung nicht geht.
Auf Shopware 5.5 läuft maximal PHP 7.2. Das könnt ihr einfach nicht kurzfristig abschalten! Und alles nur, weil MySQL 5.7 (welches seit 2013 gibt) nicht zur Verfügung steht!
@DF: macht es doch ganz einfach: stellt offiziell MySQL 5.7 auf der aktuellen Plattform zur Verfügung und ihr (mit Aufsetzen und Testen der neuen Plattform) und wir Usern (Umstellen auf die neue Plattform) gewinnen nochmal gut Zeit und es wird alles entspannter!
Wir prüfen intensiv mehrere Applikationen (auch Shopware) aktuell und werden nach der Prüfung entsprechende Entscheidungen treffen was wir in Bezug auf Datenbanken und Versionen dieser anbieten. Ich möchte da jetzt nicht orakeln, es ist aber gut möglich, dass sich da noch Änderungen ergeben.
Mit Techniken wie Docker sollte das grundsätzlich kein Problem darstellen...
Ja, das ist grundsätzlich richtig. Wir wollen die Strukturen da so übersichtlich wie möglich halten und haben immer die Anforderung, dass über das Kundenmenü eine Administration möglich ist. Gleichwohl wollen wir natürlich auch, dass möglichst alles bei uns läuft. Docker ist eine verdammt spannende Technologie diesbezüglich. Wir sehen die neue Webserverplattform diesbezüglich auch als Beginn an, wo es viele Möglichkeiten für einen Ausbau gibt. Aber klar, es muss das grundsätzliche Setup passen und bevor wir hier sagen, dass wir es endgültig so machen, sind wir noch insoweit flexibel.
Macht aber hin mit der Überprüfung (eigentlich ist diese ja überflüssig, da längst bekannt ist welche neuere Software bereits neueres MySQL (oder ein anderes SQL) brauchen, aber derzeit nicht bei DF genutzt werden kann. Wie lange die PHP Versionen von der PHP Foundation unterstützt werden steht auch fest: https://www.php.net/supported-versions.php. Auch haben schon einige DF laut Forum gekündigt oder haben es vor. Ihr müsst einfach mal durchrechnen: jetzt etwas Geld in die Hand nehmen und neues MySQL auf der aktuellen Plattform anbieten oder wenn wir irgendwann auf die neue Plattform alles ganz toll sein soll, aber weitere Bestandskunden gegangen sind. Dann kommt ja noch die Migration von der alten auf die neue Plattform mit ungewissen Problemen hinzu.
Hinweis: wir haben jetzt nicht den kleinsten Tarif bei euch und werden auch immer nervöser!
Seit ihr dann jetzt noch im Zeitplan für Q1 2020 (Ende März)?
Ihr müsst einfach mal durchrechnen: jetzt etwas Geld in die Hand nehmen und neues MySQL auf der aktuellen Plattform anbieten oder wenn wir irgendwann auf die neue Plattform alles ganz toll sein soll, aber weitere Bestandskunden gegangen sind.
wir sind seit Wochen direkt am handeln....in dieser Woche alleine 3 Auftritte wegen fehlender mySQL 5.7-Unterstützung weggezogen, 2 weitere wegen fehlendem Lets-Encrypt. Wenn wir demnächst unsere DF-Server konsolidieren dürften wir eine Menge Geld sparen.
Macht aber hin mit der Überprüfung (eigentlich ist diese ja überflüssig, da längst bekannt ist welche neuere Software bereits neueres MySQL (oder ein anderes SQL) brauchen, aber derzeit nicht bei DF genutzt werden kann.
Im Rahmen der neuen 64-Bit-Tarife wird das für die Veröffentlichung geprüft. Kommt gleichzeitig mit der neuen Webserverplattform, die die neuen 64-Bit-Tarife dann auch nutzen.
Wir müssen mehrere Anforderungen erfüllen. Dazu gehören:
es müssen viele verschiedene Skripte mit der Datenbankversion laufen
innerhalb der Skripte möglichst viele alte und neue/supportete Versionen
es soll insgesamt zukünftig orientiert sein und Optionen für die Zukunft bieten (keine Sackgassen oder Problemfelder die heute schon absehbar sind)
möglichst nur eine Version für alles, da mehrere Versionen immer Probleme und großen Aufwand machen, wie wir in der Vergangenheit immer wieder gesehen haben bzw. eine Weiterentwicklung blockiert
Wie lange die PHP Versionen von der PHP Foundation unterstützt werden steht auch fest: https://www.php.net/supported-versions.php. Auch haben schon einige DF laut Forum gekündigt oder haben es vor. Ihr müsst einfach mal durchrechnen: jetzt etwas Geld in die Hand nehmen und neues MySQL auf der aktuellen Plattform anbieten oder wenn wir irgendwann auf die neue Plattform alles ganz toll sein soll, aber weitere Bestandskunden gegangen sind. Dann kommt ja noch die Migration von der alten auf die neue Plattform mit ungewissen Problemen hinzu.
Hinweis: wir haben jetzt nicht den kleinsten Tarif bei euch und werden auch immer nervöser!
Seit ihr dann jetzt noch im Zeitplan für Q1 2020 (Ende März)?
Es liegen zur Zeitplanung noch keine weiteren Details vor. Sobald es die gibt, melden wir uns. Wir möchten eine durchdachte Lösung veröffentlichen und tun das so schnell wie möglich in Ihrem und unserem Interesse
2 weitere wegen fehlendem Lets-Encrypt. Wenn wir demnächst unsere DF-Server konsolidieren dürften wir eine Menge Geld sparen.
Ja, das mit den Kosten für Zertifikate ist heftig. Ich habe nur drei Domains und müsste für zwei vom Tarif nicht erfasste Domains extra Zertifikate kaufen, die mehr kosten als sonst der ganze Basic-Tarif (plus Laufzeit 2 Jahre). Pro Domain 3 EUR...hm, was machen da Webmaster, die 5 oder 10 Websites haben?
Wenn die Resellertarife später folgen versucht bitte die SSL-Problematik zu lösen, zuminsest sollte in jedem RP-Kundenacccount ein Zertifikat kostenfrei enthalten sein. (Also bei z.B. 100 RP-Kunden entsprechen 100 kostenfreie Zertifikate). Im Grunde so wie bei den Endkundentarifen, da hat auch jeder Kunde ein kostenfreies Zertifikat.
Jap! Als alle Kunden das kostenpflichte Zertifikat "geschluckt" hatten, sind die Preise noch mal kräftig angestiegen, wenn man 12 Monate verlängert. Völlig unhaltbar- Fast alle Hoster bieten ein Zertifiakt kostenfrei an!
Wie bereits so oft, frage ich mich, wer bei Ihnen für das Marketing zuständig ist, Donald Duck? Kann sich von Ihnen nur einer im Ansatz vorstellen, welche Klimmzüge wir als Agentur in den letzten Wochen leisten mussten, weil Sie die Leute seit Monaten mit dem Hinweis auf die Abschaltung alter PHP Versionen nerven (Mal abgesehen davon, dass kein normaler Mensch weiß, was PHP überhaupt ist und jeder Kunde uns danach fragt)? Sicher haben Sie nun gemerkt, dass alle Leute mit älteren Websites, die keinen Bock auf einen oft teuren Relaunch Ihrer Websites haben, zu anderen Anbietern, wie IONOS wechseln, weil die noch PHP 5.6 anbieten. Auch wenn es dort nur einen Extended PHP Support für 7,81 Euro im Monat gibt und der Support dort ebenso unterirdisch ist, wie die Server selbst, ist es wenigstens eine Option. Nun kurz vor Torschluss einfach mal zu schreiben, dass Sie es nun doch nicht machen, versetzt uns und unsere Kunden nicht in helle Begeisterung. Ein kleiner Trost wäre es gewesen, wenn Sie wenigstens für die Zukunft eine verbindliche Aussage zu dem Thema getroffen hätten, aber das passiert in Ihrer Mail leider nicht, sondern ist genauso wage, wie Ihre sonstige Kundenpolitik. .
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...
"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!
Jap! Als alle Kunden das kostenpflichte Zertifikat "geschluckt" hatten, sind die Preise noch mal kräftig angestiegen, wenn man 12 Monate verlängert. Völlig unhaltbar- Fast alle Hoster bieten ein Zertifiakt kostenfrei an!
Also kostenfreie Zertifikate verlange ich nicht direkt. Am Ende geht es um die Gesamt Kostenstruktur. Allerdings ist die mehrfache Preiserhöhung (2x nacheinander nahezu verdoppelt) durchaus als gierig zu bezeichnen. Zumal die Zertifkate wenn ich das richtig sehe aus der eigenen Konzerngruppe kommen und sicherlich keine 4,99 Euro im Monat in der "Produktion" kosten.
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...
Ich kann den Frust verstehen aber ganz ehrlich: der entstandene Aufwand ist nicht die Schuld von dF. Es wurde vermutlich über Jahre bei den Kunden an Updates gespart in dem Gedanken, dass das immer so weitergeht. Aber schon vor Jahren wurde das Ende von alten PHP Versionen angekündigt. Das es da einen Abschaltung geben wird hätten alle Verantwortlichen erahnen können. Und schlecht entwicklelte, d.h. nicht updatefähige Software ist schlicht schlecht entwickelt. Das es oft so ist, verstehe ich. Aber die tausende von Euro hat domainFactory nicht zu verantworten.
Ich kann den Frust verstehen aber ganz ehrlich: der entstandene Aufwand ist nicht die Schuld von dF. Es wurde vermutlich über Jahre bei den Kunden an Updates gespart in dem Gedanken, dass das immer so weitergeht. Aber schon vor Jahren wurde das Ende von alten PHP Versionen angekündigt. Das es da einen Abschaltung geben wird hätten alle Verantwortlichen erahnen können. Und schlecht entwicklelte, d.h. nicht updatefähige Software ist schlicht schlecht entwickelt. Das es oft so ist, verstehe ich. Aber die tausende von Euro hat domainFactory nicht zu verantworten.
Das meine ich auch nicht (die Website war übrigens nict von uns), aber der Termindruck wäre nicht nötig gewesen!
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. 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. Ich kann auch nicht sagen, dass es ab dem 01.05.20 keinen Dieseltreibstoff mehr in Hessen gibt und alle kaufen sich neue Autos oder lassen die alten teuer umbauen und am 27.04. gebe ich dann bekannt, dass es nun doch weiterhin Diesel geben wird. Hier sollten Sie als Unternehmen an einer so wichtigen Schnittstelle schon etwas Verantwortung übernehmen und nicht sagen: " Das ist doch Ihre Schuld und Dieselautos sind sowieso nicht gut für die Umwelt". Wenn ein Wald- und Wiesen-Hoster, wie ******* das mit dem extended Support hinbekommt, sollte das ein Hoster wie DF locker hinbekommen.
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. 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. Ich kann auch nicht sagen, dass es ab dem 01.05.20 keinen Dieseltreibstoff mehr in Hessen gibt und alle kaufen sich neue Autos oder lassen die alten teuer umbauen und am 27.04. gebe ich dann bekannt, dass es nun doch weiterhin Diesel geben wird. Hier sollten Sie als Unternehmen an einer so wichtigen Schnittstelle schon etwas Verantwortung übernehmen und nicht sagen: " Das ist doch Ihre Schuld und Dieselautos sind sowieso nicht gut für die Umwelt". Wenn ein Wald- und Wiesen-Hoster, wie ******* das mit dem extended Support hinbekommt, sollte das ein Hoster wie DF locker hinbekommen.
Es ist nicht die Schuld des Websitebesitzers, wenn Sie Ihn mit einer Deadline zur Neuerung nötigen, ...
Mit Aussagen wie genötigt wäre ich vorsichtig. Das ist eine unnötige Dramatisierung und stimmt schlicht nicht. Der Kunde kann ja auch zu einem der Anbieter mit Extended Support wechseln. Wenn mein Bäcker einfach keine Dinkelbrötchen mehr anbietet, dann kann ich in Zukunft Weizenbrötchen kaufen oder wenn ich da eine Unverträglichkeit habe, einen anderen Bäcker suchen.
...denn es gibt durchaus Uraltsysteme, die laufen und sicherheitstechnisch so geblockt sind, dass es für den Kunden kein Problem gibt.
Wirklich? Auf einem SharedHosting System mit PHP 4 haben Sie da alles geblockt, was an PHP Sicherheitslücken eventuell bisher unerkannt da ist? Das fällt mir schwer, zu glauben.
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.
Das kann sein, und dennoch ist das die Verantwortung des Kunden und der früheren Programmierer*innen, ein System so geschaffen zu haben, dass es nicht aktualisierbar ist. Und das in dem Wissen, dass sich ständig System ändern und entwicklen. Das kann fast schon als Fehlkauf bzw. Fehlplanung seitens des Kunden beschrieben werden.
Entgegen anderer Provider haben Sie keinen extended Support angeboten, sondern mit einem festen Abschalttermin gedroht.
Domainfactory hat nicht gedroht (ist diese Wortwahl wirklich sinnvoll für Sie?) sondern einen Abschalttermin angekündigt, wie es andere Anbieter auch getan haben. Und ja, es gibt noch Anbieter, die das anders sehen und Extended Support anbieten. Aber das ist doch keine Verpflichtung des Webhosters, Extended Support anzubieten! Ich biete auch keinen Windows 3.1 support mehr an. Es gibt einfach Grenzen und die legt jeder Anbieter selbst fest. Der Markt wird es schon regeln...
Ich kann auch nicht sagen, dass es ab dem 01.05.20 keinen Dieseltreibstoff mehr in Hessen gibt und alle kaufen sich neue Autos oder lassen die alten teuer umbauen und am 27.04. gebe ich dann bekannt, dass es nun doch weiterhin Diesel geben wird. Hier sollten Sie als Unternehmen an einer so wichtigen Schnittstelle schon etwas Verantwortung übernehmen und nicht sagen: " Das ist doch Ihre Schuld und Dieselautos sind sowieso nicht gut für die Umwelt". Wenn ein Wald- und Wiesen-Hoster, wie Ionos das mit dem extended Support hinbekommt, sollte das ein Hoster wie DF locker hinbekommen.
Also der Vergleich mit Diesel und Autos ist an der Stelle m.E. unzulössig und damit sinnlos darüber zu schreiben. Aber übrigens: ja, es ist die Schuld von Diesel Autos und vor allem deren Hersteller, dass sie die Umwelt verpesten und es ist die Schuld derer, die solche Autos kaufen und nutzen ;-) Da sollte der "Verbraucher" durchaus mal Verantwortung übernehmen. Wer denn sonst?
Dass die Kommunikation in der ganzen Sache sehr schlecht war und dass es aus Sicht vieler psychologisch sicherlich besser gewesen wäre, wenn zu dem Abschalttermin auch wirklich "abgeschaltet" worden wäre, ist klar. Das hat auch dF eingeräumt und sehe ich auch so. Auch ich habe mich da veralbert gefühlt und bin nun aber doch froh, alle Altlasten der Projekte umgestellt zu haben. Und ganz ehrlich: ohne Termin hätte ich viele Proijekte heute und auch in x Jahren noch nicht umgestellt. Mensch ist eben durchaus bequem... Damit es in Zukunft nicht so weit kommt, aktualisieren wir nun stetig die Projekte, das ist letzlich für alle Beteiligten sinnvoll.
In diesem Sinne hoffe ich, dass Sie eine Lösung für Ihren Frust finden. Angesichts der aktuellen dramatischen Lage in der Welt erscheint mir der PHP Abschalt Termin von dF doch arg unwichtig...
Kommentar