Update - wie vorgehen?

[Bousquet]

Hallo,

ich habe aktuell noch ein vB 4.2.2 PL6 laufen, denn auf meinem Server ist nur eine alte Version von PHP (5.2.13).

Nun habe ich einen neuen Server mit PHP 7.0.27 und möchte mein Forum auf diesen Server umziehen. Dazu habe ich das Forum auf den neuen Server geladen, aber leider hat das nicht funktioniert. Die User bekamen folgendes:

Sie wurden aus folgendem Grund gesperrt:
Es wurde keine Begründung angegeben.

Ende der Sperre:

und ich gleich einen Haufen Emails, verärgert oder besorgt, je nach Charakter des Users...

Ich kam nicht ins ACP.

Wie gehe ich am Besten vor? Den Update-Prozess auf dem alten Server machen?

[Boothby]

Warten wir mal am besten bis Jörg kommt, der kennt sich am besten aus in diesen Dingen. Beim Serverwechsel gibt es so einige Sachen zu beachten, insbesondere bei den Einstellungen der Datenbank, dass die nicht plötzlich auf utf-8 läuft und die alte noch auf latin1, böse Falle.

Grundsätzlich würde ich empfehlen, das Update auf dem alten Server zu machen, um eine Fehlerquelle von vorne herein auszuschließen. Das wird aber an der alten PHP-Version scheitern.

Also warten wir gespannt bis Jörg kommt. ;-)

[Bousquet]

Hallo Stefan und danke für Deine Antwort.

Die alte Datenbank ist in latin1_swedish_ci , die auf dem neuen Server auch.

Ist es eher ein php - Problem ?

- - - Aktualisiert - - -

Ich habe jetzt noch mal in anderen Threads gelesen.

Vor dem Update sollte ich

1. Alle fremden Addons deaktivieren
2. Blog und CMS aktivieren

Stimmen diese Infos?

[Boothby]

Es müssen Kollation und Zeichensatz entsprechend der Ursprungs-DB gesetzt werden, z.B.

CREATE DATABASE vbdb 
  CHARACTER SET = 'latin1'
  COLLATE = 'latin1_swedish_ci'

Dann sollte im Datenbank-Dump geprüft werden, ob die Tabellen und Felder (hierbei bin ich mir unsicher, ob notwendig) nicht auch einen falschen Zeichensatz abbekommen haben und dies entsprechend mit passendem Texteditor geändert werden. Beim Aus- und Rückspielen des Dumpes lassen sich auch Default-werte vorgeben.

mysqldump -u root -p --opt --quote-names --skip-set-charset --default-character-set=latin1 vbdb > vbdb.sql
mysql -u root -p --default-character-set=latin1 vbdb < vbdb.sql

ungetestet, da von Google geklaut und angepasst.

[Jaydee]

Danke für den Vertrauensbonus, Stefan.
In der Tat sehe ich aber ebenfalls gewisse Schwierigkeiten durch Inkompatibilitäten:
Auf Server A ist es die zu alte PHP Version für das aktuellere vBulletin, und auf Server B ist es genau umgekehrt, solange man das Update nicht hinbekommt.

Das ACP solltest Du eigentlich spätestens durch die "tools.php" trotzdem wieder betreten und das Upgrade-Script starten können, das habe ich aber in der Konstellation selber noch nicht getestet, mag sein, dass der Vorgang dann dennoch abbricht.

Ergo: Nach Möglichkeit würde ich das komplette Update zunächst lokal vornehmen, am besten mit einem Testserver, bei dem man die PHP-Versionen 5.x und 7.x leicht wechseln kann (MAMP oder WampServer).
Erst wenn das komplett ist, die Dateien und den Dump auf den neuen Server übertragen. Bzw. mindestens den fertigen Dump, die Dateien kannst Du trotzdem via FTP aus dem Paket hochschaufeln. Wichtig ist ja die aktualisierte Datenbank.

Die alte Datenbank ist in latin1_swedish_ci , die auf dem neuen Server auch.

- - - Aktualisiert - - -


Vor dem Update sollte ich

1. Alle fremden Addons deaktivieren
2. Blog und CMS aktivieren

Stimmen diese Infos?

Hm, Punkt 1. nicht zwangsläufig, alte Add-ons sollten eigentlich keinen Konflikt beim vB-Update bewirken. Aber zur Sicherheit kannst Du das ja tun.
Punkt 2. ist auf jeden Fall richtig, ja. Andernfalls kann es in den letzten Versionen zu Fehlermeldungen (und ggf. Abbrüchen) kommen, daher diese Empfehlung der Aktivierung. Danach kannst Du sie wieder deaktivieren, falls gewünscht Das gilt natürlich nur für die vB-Suite, beim reinen Forum hast Du diese Add-ons eh nicht.

Übrigens ist der fettmarkierte Teil Deines Zitats nur die sog. "Collation", nicht der Zeichensatz (Charset) der Datenbank. Dieser ist aber im Zweifelsfall wichtiger und sollte bei alter wie neuer Datenbank/Server identisch sein. Das gilt aber unabhängig von der vB- und PHP-Version.

[Bousquet]

Hallo Jörg,

das kann ich nicht lokal testen, mein Internetzugang gibt solche Datenmengen nicht her, vor allem nicht im Upload. Ich wohne in der Pampa ... zweistellige GB geht leider nicht.
Von Server A zu Server B schieben jedoch ist kein Problem und dauert nur kurze Zeit.

Wie kann ich das auf meinem neuen Server testen? Denn da muss es ja funktionieren.

Das tools.php kenne ich nicht. Vielleicht habe ich da was verpasst. Was tut es und wie kann ich das nutzen?

Danke für eure Hilfe!

- - - Aktualisiert - - -

Hallo Jörg,

es gibt also bei Datenbanken "collation" und "charset".
Ich benutze phpmyadmin und den Unterschied habe ich nicht verstanden.

Auf meinem alten Server werden DB mit uft8_general_ci angelegt, auf dem neuen uft8mb4_unicode_ci.

Viele Grüsse Antje

[Jaydee]

Hallo Antje,

da schau, nun kenne ich Dich (also den Nick) schon so viele Jahre und realisiere erst heute, dass Du "weiblicher Natur" bist. Das war mir gerade völlig neu *schäm*.

Also das Problem ist zunächst Deine recht alte Version (4.2.2) des vB, diese lief nur bis maximal PHP 5.4.
Umgekehrt sind aber die heutigen Versionen um 4.2.5 vor allem auf PHP 7.x ausgelegt.
Das steht jetzt im Konflikt, daher würde ich empfehlen, das Update "schrittweise" durchzuführen.
Also zunächst auf dem ALTEN Server bis hart an die Grenze zu einer PHP 7 tauglichen Version herangehen und dort stoppen.

Dann den ganzen Quatsch rüber ziehen auf den neuen Server und dort mit einer Version fortfahren, die SOWOHL 5.6.x als auch 7.0.x (und aufwärts) tauglich ist.
Das wird in dem Fall die einzige Chance sein, es "sauber" hinzubekommen. Das Problem liegt darin, dass der Break bei PHP genau zwischen diesen Versionen lag.

Zur tools.php: Diese findest Du im Ordner "do_not_upload" Deines vB-Pakets, die Datei müsste auf den Server (admn-Verzeichnis) geladen werden und damit kannst Du diverse Funktionen ausführen, u.a. den Datastore zurück setzen bzw. Dir Zugang zum ACP verschaffen (geht dann erst wieder nach Entfernen dieser Datei).
Auch Cookie-Pfade kannst Du damit löschen und ähnliche Dinge.

Zum Unterschied Zeichensatz und Collation: Das hatte ich einige Male detalliert auch hier im Forum beschrieben, aber auf die Schnelle: Ein Charset ist wirklich ein "Zeichensatz", also die Basis, wie ein Server / eine Datenbank Schriftzeichen, Sonderzeichen, Ziffern usw. darstellt und verwaltet.
Da ist der Standard heute UTF-8, da dieser ausreichend alle gängigen nationalen Schriftzeichen abdeckt.

Die Collation (oder deutsch geschrieben auch "Kollation") ist lediglich das "Sortier-Regelwerk" innerhalb eines Zeichensatzes, bzw. sollte auf dessen Basis ausgewählt werden.
Das erkennst Du beispielsweise am Zusatz "_ci" am Ende (was für "case insensitive" steht), im Gegensatz lautet der Zeichensatz z.B. nur "Latin1" ohne weiteren Zusatz.

Und der sollte auf beiden Seiten identisch sein, also kurz: Wenn z.B. ein mit UTF-x erstellter Datensatz später per Latin/ISO-xxx ausgelesen/verarbeitet wird, gibt es Chaos.

[Boothby]

Vielleicht solltest du den ganzen Umzugsstress gleich dazu verwenden, die Software zu wechseln. vB4 ist eh tot und wird nicht weiter entwickelt und vB5 ist keine Zukunftsoption, da einfach zu schlecht. Und die meisten freien und kommerziellen Softwareanbieter haben Importscripte für vBulletin 3/4/5. Bei XenForo, was wir nun nutzen, haben wir die Chance auch gleich genutzt, auf utf8 umzusteigen.

[Bousquet]

Hallo und Danke an Stefan und Jörg für die Tipps. Ich arbeite mich langsam durch.

Das mit dem tools.php hatte ich nicht mehr auf dem Schirm, danke für den Hinweis

Auf einem Testserver (Cent OS 7.4 mit php 5.4 und 7.0) lief es so:

• Update auf vB 4.2.3 funktionierte, mit php 5.4
• Update auf vB 4.2.4 gibt folgende Fehlermeldung beim Aufruf von http://www.xtestforumx.de/forum/install/upgrade.php Parse error: syntax error, unexpected '=', expecting ')' in /home/testforum/public_html/forum/includes/functions_misc.php on line 759 Ging auch mit Umstellung auf php 7 nicht.
• Direkt mit 4.2.5 hat es funktioniert. Also 4.2.4 übersprungen. Dieses Update (4.2.5) hat den Prozess wieder aufgenommen, wo das 4.2.4 abgebrochen hat, und hat auch die 4.2.4 Updates gemacht. Alles ging gut zu Ende (die Anzeige hat manchmal nicht gestimmt, sie stand still). Nach dem Schliessen der Seite wurde der Prozess jedoch jedes Mal wieder dort aufgenommen, wo er abgebrochen war. Am Ende war alles OK.

Dies und das muss ich noch testen, sieht aber gut aus :-) Keine Umlautprobleme, Bilder werden angezeigt, neue können hochgeladen werden.

Nun kommt https dran ....

Viele Grüsse Antje

- - - Aktualisiert - - -

[Bousquet]

Vielleicht solltest du den ganzen Umzugsstress gleich dazu verwenden, die Software zu wechseln. vB4 ist eh tot und wird nicht weiter entwickelt und vB5 ist keine Zukunftsoption, da einfach zu schlecht. Und die meisten freien und kommerziellen Softwareanbieter haben Importscripte für vBulletin 3/4/5. Bei XenForo, was wir nun nutzen, haben wir die Chance auch gleich genutzt, auf utf8 umzusteigen.

Hallo Stefan,

mein Forum ist uralt (seit 2000), und die Mehrheit unserer User ist nicht besonders technikaffin. Ich habe 2011 von wBB2 zu vB 4 gewechselt, und es gibt einige User, die reden immer noch von "im alten Forum ging das aber..."
Als ich damals die Forensoftware gewechselt habe, hatte ich über einen Monat Stress. Manche User stellten sich an, als hätte ich deren Wohnzimmer neu möbliert ohne sie zu fragen
Das tu ich mir jetzt nicht ohne Not an.

Ausserdem finde ich das vB 4 gar nicht so schlecht. Es hat jahrelang zuverlässig funktioniert und hat alles, was wir brauchen. Naja fast. Für die Smartphones nutzen wir Tapatalk, darüber bin ich nicht ganz glücklich. Gibt es eigentlich eine App für vB4? Dafür würde ich auch etwas bezahlen.

Viele Grüsse Antje

PS: Ich möchte auch noch hinzufügen, dass ich hier immer freundliche und kompetente Hilfe bekommen habe. Das weiss ich sehr zu schätzen!!

[Jaydee]

Diese User kenne ich auch zur Genüge, die gibt es in wohl allen Foren.
Sie tun dann wirklich so, als hätte man "IHR Zuhause" komplett auf den Kopf gestellt und sie würden sich nicht mehr zurechtfinden. Selbst ein neuer Style reicht da oft schon aus.
Zum Glück ist das aber meist die Minderheit.

Zu Tapatalk gibt es leider keine Alternative, außer einem reponsiven Design (was wiederum vB 4 nicht ist).
Ich nutze es trotzdem nirgendwo mehr, auch wenn die neue Version ja angeblich Datenschutz-konform sein soll. Da es aber die gesamte Arbeitsweise dieser Software ja trotzdem nicht ist (Umsetzung über deren Server, USA, Auslesung von PNs usw.), traue ich persönlich dem Braten nicht mehr.
Bisher hat sich auch noch kein User darüber beschwert, ich hatte da mit "richtig Trouble" gerechnet...

[Bousquet]

Hallo,

ich schreibe jetzt einfach hier weiter, mit neuen Fragen. Wenn es besser ist, einen neuen Thread zu öffnen, sagt mir bitte Bescheid.

Also das vB 4.2.5 läuft jetzt mit php 7.0.27 auf dem neuen Server (dedizierter rootServer). 5.5.56-MariaDB

Aktuell habe ich das Problem, dass beim Posten der Beitrag häufig nicht direkt veröffentlicht wird, sondern der Server sagt

"Bitte warten Sie - Ihre Antwort wird gespeichert."
Dann wartet man...
Oder man bekommt die Abfrage, ob man die Seite verlassen möchte, was man mit JA beantworten muss, dann wird gespeichert.

Das ist überhaupt nicht klar und führt ausserdem zu Doppelpostings.

Wo könnte der Fehler sein?

Viele Grüsse Antje


PS: Habe gerade die Diskussion in einem anderen Thread gelesen. Könnte das am Editor liegen?

[Jaydee]

Halte ich für eher unwahrscheinlich, die Probleme damit bezogen sich eher auf die Speicherung nach BEARBEITUNG eines Beitrags, meines Wissens nicht sofort beim ersten Absenden schon.

Für mich hört es sich gerade eher so an, als läge es entweder an einem Cache-System des Servers oder an dessen grundsätzlichen Timeout-Zeiten (und damit verbunden den Settings).
Gerade wenn das nur sporadisch und unvorhersehbar auftritt, ist das als Ursache wahrscheinlicher.
Der Editor bringt seine Fehler unter PHP 7 glaube ich eher "konstant".
Es scheint da öfter mal eine zeitliche Verzögerung beim Speichern zu geben, was dann ggf. zu diesen Doppelpostings (unter selbem Timestamp) führen kann. Evtl. hakt der Datenbank-Server da etwas.

[Bousquet]

Hallo,

das ist mein eigener Server, ich kann da alles einstellen was ich will (bzw. hinkriege ). Hardwaremässig ist das wie mein früherer Server, aber eben ein anderes OS und php und DB.

Ich brauche Infos, wie diese Fehler zustande kommen und ich sie beheben kann. Was soll ich überprüfen? Was soll ich ändern?

Hier ein Bild wie es für die User aussieht. Da muss man dann auf "Verlassen" klicken und erst dann wird der Beitrag gepostet. Verwirrend.

Edit: Noch ein Bild wie php7 konfiguriert ist.

php70.png


abfrage.jpg

[Jaydee]

Hm, die file upload size empfinde ich als sehr klein und auch die HTTP post size dürfte ruhig etwas großzügiger sein. Vielleicht steht es damit nicht unmittelbar in Zusammenhang, könnte aber ein Ansatz sein.

Bekommt diese Meldung denn jeder User, oder nur Du? Ich bin gerade nicht sicher, ob die wirklich vom Server kommt.
Ansonsten auch mal die my.ini vom DB-Server checken (Ausführungszeit, max. Paketgröße und solche Dinge).

Da der Fehler ja NACH dem Update auf dem ALTEN Server nicht auftrat, würde ich den Editor wie gesagt fast ausschließen. BEstenfalls die exakte PHP-Version auf dem neuen könnte dann der Grund sein, halte ich aber für eher unwahrscheinlich. Dann müssten alle Betreiber hier mit diesen Versionen das Problem haben.

[Bousquet]

Das Update habe ich direkt auf dem neuen Server gemacht, nachdem ich das auf einem Testserver ausprobiert hatte (ein kleiner um kleines Geld 10E/Monat). Ich habe das nicht auf dem alten Server getestet, das ging ja nicht wegen altem OS php usw.

[Jaydee]

Ok, dann probiere einfach mal testweise aus mit den oben besagten Settings.
Kann man ja ggf. wieder zurück setzen, aber wenn Du alleine auf dem Server und nur mit der einen Anwendung bist, sollten höhere Werte eigentlich keinerlei Probleme bereiten. Setze das einfach mal etwas (ggf. auch deutlich) höher von den Werten.

Lediglich das PHP Standard-Timeout würde ich ruhig so belassen, das ist OK. Längere Zeiten benötigt auch kein vBulletin Script (außer der früheren Datenbank-Sicherung, aber die gibt es längst nicht mehr).

Und noch ein grundsätzlicher Tipp: Wenn es ein Root-Server ist und Du da selber nicht so im Thema bist, suche Dir bitte jemanden, der den vernünftig managed. Ansonsten könnten die möglichen Folgen und evtl. Haftungen fatal sein! Mit Webservern ohne Erfahrung ist nicht zu spaßen.

[Bousquet]

Hallo,

hier an dieser Stelle ein enormes Dankeschön an Pogo. Mit einem Monat Verspätung, wir sind gerade von Familienbesuchen geflutet.

Der Server selbst war nicht das Problem, sondern die Einstellungen im ACP des Forums, insbesondere, was den Emailversand anging. Das hatte auf dem alten Server jahrelang so geklappt (altes vB, altes php, altes OS...) aber nicht mehr nach all den Updates. Pogo hat das innerhalb einiger Stunden in Ordnung gebracht, und der kleine Obulus, den er verlangt hat, war nicht der Rede wert.

Soviel Lobhudelei muss sein, mindestens

Viele Grüsse Antje