Also in meinem Fall liegt das dann hauptsächlich daran, dass der Wartungsvertrag meiner Kunden ein permanentes Upgraden einfach nicht hergibt. Mit ganz wenigen Ausnahmen haben die Kunden bei mir ein Zeitkontingent von 2 Stunden pro Jahr - und das wird in der Regel für andere Aktualisierungen verbraucht.
ich kenn ja die Problematik auch und hab mich auch schon von Kunden getrennt, wenn mein Name irgendwo mit drin steht und ich weiß, das hier Probleme kommen. Eine Partneragentur aus Thüringen hatte zum Jahresende noch 48 solcher alten WB-Installationen upzugraden und nur wenige waren schon eine 2.8.3.
Im kommerziellem Bereich gehe ich da auch mit, aber wenn ein User, vornehmlich aus dem Nachbarland, jetzt mehrere NEU-Installationen mit 2.10.0 macht, geht mir der Hut hoch. 2.10.0 kann PHP 7.1 bis max 7.2.3. Da weiß ich, das der Kollege in zwei Wochen wieder heult.
Ich weiß z.b. das die originale 2.8.2 keine Probleme im Upgrade auf 2.12.1 macht, aber eben nur diese und nicht die Version mit der nächsten Revisionsnummer, die immernoch unter 2.8.2 lief..
Ein grundsätzlicher Tip von mir für die, die noch mit latin1 arbeiten (Blick in die Datenbankverwaltung / Übersicht der Tabellen reicht):
Erst die Konvertierung auf UTF8 abschließen und dann erst upgraden.
Ich weiß, das viele Leute diese Zeichenkonvertierun
g im Upgrade erwarten, dem ist aber nicht so, zu komplex, zu gefährlich.
Wo mich nun eigentlich dieser php Schrott am meisten nervt.
In aller Regel reagiert WB ja auch nur auf solche PHP-Ankündigungen
Mein VBA Code von 2000 läuft doch auch noch und ist wartbar.
funktioniert auch mit PHP-Code. Nur als Beispiel eregi vs preg_match. ersteres mittlerweile entfernt in PHP, Letzteres stand damals aber auch schon zur Verfügung. und je nachdem, was der Modulautor damals verwendet hat, läuft ein Modul heute noch oder eben nicht