Migration 2.5.28 zu 3.5.1 Fehler bei upgrade

  • Liebe Community,


    ich habe folgendes Problem und ich hoffe ihr könnt mir helfen (bin leider in diesem Forum nich fündig geworden und die gefunden Anleitung: https://forum.joomla.org/viewtopic.php?f=706&t=913699 hat mir auch nicht geholfen. Ich habe mein Joomla 2.5.28 (läuft auf php 5.6.30. , mysql 5.6.19) mit dieser Anleitung auf 3.5.1 upgraden wollen: https://docs.joomla.org/Joomla…Step_by_Step_Migration/de


    Beim durchführen des 9. Punkts in der Anleitung "write files directly" zeiget er mir nach kurzem arbeiten folgenden Fehler an:
    Index column size too large. The maximum column size is 767 bytes. SQL=ALTER TABLE `#__menu` ENGINE=InnoDB;


    Das Upgrade hat also nicht funktioniert, wenn ich wieder ins Kontrollzentrum gehe, sehe ich zwar das Kontrollzentrum von 3.x aber folgenden Fehler.
    Table 'db127335_23.#__postinstall_messages' doesn't exist SQL=SHOW FULL COLUMNS FROM `#__postinstall_messages`


    Habt ihr eine Lösung bzw. eine erprobte Lösung für mein Problem?


    Vielen Dank und liebe Grüße
    Andreas

  • Ich verstehe nicht, warum du nur bis 3.5.1 upgraden möchtest. Aktuell und am sichersten ist 3.8.5.
    Seit 2.5.28 wurde, soweit ich mich erinnern kann in der DB eine Umstellung gemacht. Das war manchmal etwas difiziel. siehe hier MySQL Datenbank-Kollation utf8mb4 versus utf8 in Joomla 3.5
    PHP könnte auch auf 7. umgestellt werden, was Performance verbessern sollte.
    Gruß vom Niederrhein

    • Hilfreich

    Ich habe dieses Problem auch schon gehabt. Der Grund war folgendes:
    - Die db war eine Mariadb
    - die Tabelle #__contentitem_tag_map hat einen Primärschlüssel mit einer Länge von 255 Bytes
    - Mariadb lässt für Schlüssel per Default maximal 767 Bytes zu
    - die Schlüssellänge wird bei utf8mb4_unicode_ci deutlich grösser als 1000 Bytes (4*255)


    Das führt dazu, dass die Erstellung oder Umwandlung der db and dieser Stelle abgebrochen wird. Angemeckert wird aber nicht die betreffende Tabelle, sondern die letzte die fehlerfrei geschrieben worden ist.


    Beim Updaten habe ich mir schon geholfen, indem ich die Schlüssellänge der betroffenen Tabelle (und es ist die einzige, die dieses Problem hat) reduziert habe, auf z.B. 180 Bytes. Danach läuft der Upodate fehlerfrei durch.


    Eleganter wäre es, wenn man in maria.ini ROW_FORMAT=DYNAMIC; setzen könnte, das lässt aber kaum ein Hoster zu (fragen lohnt sich aber).

  • Wenn ein Server oder Webspace zickig sind, migriere ich Kundeninstallationen lokal auf meinem Rechner. Dazu habe ich mir ein XAMPP aufgebohrt. Wenn mir das gelungen ist, lade ich die Installation wieder auf den Server, in ein eigenes Verzeichnis, mit Subdomain, und prüfe dort die Funktionalität. Wenn das läuft, stelle ich die Domain auf das neue Verzeichnis, und nehme die alte Installation vom Server.


    Und wenn das nicht funktioniert, rate ich zu einem Hosterwechsel. Solche Probleme sind sehr selten, selbst bei 08/15 Hostern klappt das meistens ohne Probleme.

  • Wie j!-n vorschlägt, alles lokal transferieren und dort entsprechend CurlY BracketS die maria.ini anpassen. Nach dem Upgrade kann man dann alles wieder online bringen.


    Oder aber die Schlüssellänge[!] der Tabelle anpassen, damit die Umstellung des DB-Zeichensatzes von utf8_general_ci auf utf8mb4_unicode_ci den Schlüssel nicht auf über 767 Bytes anwachsen lässt (4*256=1024).