Hallo

ich starte mit einer frischen (und erfolgreichen) Installation von 2.3.5 (die sich jedoch als 2.3.5 RC selbst bezeichnet). Von dort aus sollte man ja, so verstehe ich unsere Doku, problemlos zu jeder höheren Version kommen.

Wenn ich versuche, die update_2.3.5-2.4.php auszuführen, klappt diese nicht:
Error in line 365: This update file doesn't work with the current version.

Um fortzufahren, half ich mir mit einem

UPDATE `mlf2_test_settings` SET `value`='2.3.5' WHERE `name`= 'version'

Das sollten wir irgendwie mal angehen, oder habe ich tatsächlich das falsche 2.3.5 verwendet?

Ich vermute letzteres, obwohl mir bis eben nicht einmal klar war, dass es von der 2.3.5 einen RC gegeben hat. Das ist ja nun auch schon wieder über drei Jahre her.

In der Release-Historie ist von einer solchen Version jedenfalls nichts zu sehen. In der update_2.3.5-2.4.php, die ab der Version 2.3.99.2 benutzt wurde (die folgenden Links führen zu diesem Versionsstand), wird die Version 2.3.5 RC jedoch tatsächlich erwähnt. In den Bedingungen für die einzelnen Schritte wird Version "2.3.5 RC" ebenfalls aufgelistet (Beispiel in Zeile #147). Die Version wird aber im Array $update['version'], welches bestimmt, welche Versionen als Ausgangspunkt des Updates dienen können, nicht aufgelistet.

Das dürfte die Ursache für den Abbruch deines Updates sein. Da außer dir und Alex wohl niemand je den 2.3.5-er RC im einsatz hatte, ist das nie aufgefallen. Zumal dann, wenn die wenigen potentiell Betroffenen, die als Ausnahme meine Annahme bestätigen würden, sich hoffentlich sklavisch an "from version 2.3.5 upwards" (ganz ohne RC) gehalten haben dürften.

Das Update wird nun nicht vorzeitig beendet und ich erhalte die interessante Meldung:
Bitte jetzt die folgenden Dateien/Verzeichnisse der neuen Version (2.4.99.2) hochladen:. Man beachte die Version. Auch in der neuen Tabelle mlf2_test_temp_infos steht nun 2.4.99.2. Der Versuch, nun auf 2.4.99.2 mittels der Datei update_2.4.19.1-2.5.php zu gelangen, scheitert erwartungsgemäß mit:
Error in line 183: This update file doesn't work with the current version.

Das ist sehr komisch. Schon allein der Umstand, dass die Versionsnummer in der Tabelle mlf2_test_temp_infos steht, spricht dafür, dass du ein Update auf mindestens Version 2.4.19 erfolgt ist. Die kannst du nur mit der update_2.3.5-2.4.php durchführen, wir prüfen aber offensichtlich nicht, ob die Zielversion (laut config/VERSION) vom Skript überhaupt abgedeckt ist.

Hier der Code aus der update_2.3.5-2.4.php (Stand: 2.4.20, ab Zeile #365).

// check version:
if(!file_exists('config/VERSION')) {
 $update['errors'][] = 'Error in line '.__LINE__.': Missing the file config/VERSION. Load it up from your script package (config/VERSION) before proceeding.';
}
if (empty($update['errors'])) {
 $newVersion = trim(file_get_contents('config/VERSION'));
 if (compare_versions(array('old' => $settings['version'], 'new' => $newVersion)) !== true) {
 #if ($newVersion <= $settings['version']) {
  $update['errors'][] = 'Error in line '.__LINE__.': The version you want to install (see string in config/VERSION) must be greater than the current installed version. Current version: '. htmlspecialchars($settings['version']) .', version you want to install: '.  htmlspecialchars($newVersion) .'. Please check also if you uploaded the actual file version of config/VERSION. Search therefore for the file date and compare it with the date from the installation package.';
 }
 if(!in_array($settings['version'], $update['version'])) {
  $update['errors'][] = 'Error in line '.__LINE__.': This update file doesn\'t work with the current version.';
 }
}

Die Prüfung erfolgt auf folgendes:

- Ist die Datei config/VERSION vorhanden?
- Ist die Zielversion laut config/VERSION größer als die Ausgangsversion?
- Ist die Ausgangsversion im Array $update['version'] enthalten, also behandelbar?

Was tatsächlich nicht geprüft wird, ist die Frage, ob die Zielversion durch das Skript abgedeckt ist. Wenn du also aus Versehen die config/VERSION der 2.4.99.2 hochgeladen hattest, wird zwar das Forum auf den Stand von Version 2.4.20 (oder was auch immer) gebracht, als Versionsnummer wird aber die Angabe aus config/VERSION benutzt, also eine falsche Angabe eingetragen.

Das ist das einzige für mich denkbare Szenario, wie soetwas passieren kann.

Wenn wir das nicht durch eine entsprechende Implementierung beheben, dann schlage ich vor, dass nur noch eine einzige update-Datei im Downloadpaket liegen darf. In der jetzigen Form funktioniert dies nicht. Ich breche an dieser Stelle ab und starte erneut mit 2.4.20 als Basis.

Dass jetzt noch zwei Skripte vorhanden sind, ist meiner Schludrigkeit zu verdanken. Ich weiß ja, dass ich die update_2.3.5-2.4.php nicht mehr benutzen darf und zu ignorieren habe. Darüber, dass das andere ins schleudern bringt, habe ich nicht nachgedacht.

Auch dieses Update schlägt fehlt.
Database error in line 349: Index column size too large. The maximum column size is 767 bytes. ... Für die Namen (oder besser alle VARCHARs) müsste dies wohl analog getan werden, wenn diese einen Index haben.

Ich habe schon befürchtet, dass ich andere Stellen, die dieses Problem ebenfalls heraufbeschwören, übersehen haben könnte.

Bitte beachte, dass die Änderung auf 128 Zeichen nicht durchgeführt wird, wenn man 2.4.99.1 irgendwie zum Laufen gebracht hat. Das sollte mMn. noch behoben werden.

Sprichst du über die Änderung der Tabelle für Tags?

Was passiert, wenn es einen Namen gab, der bereits länger als 128 Zeichen war? Wird der dann mit dem Change direkt abgeschnitten oder wird das Update dann nicht mehr durchgeführt?

Das habe ich noch nicht probiert, ich befürchte aber, dass der ALTER-Query dann abhängig von der SQL-Server-Konfiguration abgebrochen wird. Die Charset-Änderung ist bei mir ja durchgelaufen und bei dir nicht.

Ich starte erneut mit Version 2.4.20 als Basis, wobei ich Zeile 316 ändere in

 if(!@mysqli_query($connid, "ALTER TABLE `" . $db_settings['userdata_table'] . "` CHANGE `user_name` `user_name` VARCHAR(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT '';")) {

damit wird das Update durchgeführt

Das heißt dann wohl, dass mlf2_userdata.user_name die einzige weitere Spalte ist, die von dem Problem betroffen ist. Bleibt die Frage nach bereits eingetragenen Namen, die länger als 128 Zeichen sind und damit das Update verhindern.

Bitte jetzt die folgenden Dateien/Verzeichnisse der neuen Version (2.4.99.2) hochladen:

...
[Datei]js/admin.js
[Datei]js/admin.min.js
[Datei]js/posting.js
[Datei]js/posting.min.js
...

(hier könnte man js als Order wohl nehmen ums zu vereinfachen)

Da hast du recht.

Die Probleme, die mit B8 kommuniziert wurden, kann ich nicht bestätigen. Ich kann als unregistrierter Nutzer schreiben und antworten, und erhaltet keine Fehlermeldung. Auch die DB-Tabellen werden gefüllt.

Mich hat das auch gewundert. Hat Taurec eventuell doch den Upload irgend eines Skripts vergessen?

Eine frische Installation probiere ich morgen aus.

Danke. War doch gut, dass ich die Veröffentlichung der neuen Version hinausgezögert habe.

Tschö, Auge