Im ersten Teil haben wir gesehen, dass es etliche Hürden bei der Migration von einer komplexen Joomla 1.0 Installation nach Joomla 1.5 gibt.
Wir setzen gleich an:
Migrationsskript wurde nicht geladen
Trotz der Meldung Import erfolgreich, wurde das Migrations-SQL-File nicht geladen. Ich sehe mir die Textdatei im Editor an und vergleiche es mit der Datenbank. Hierin gibt es einige "INSERT INTO" Befehle auch der Tabellen-Präfix sieht korrekt aus.
Es fängt an mit der Tabelle jos_migration_backlinks, diese ist im PhpMyAdmin leer, in der SQL-Migrationsdatei nicht. Gut, ich spiele die Datei mit dem Import-Befehl des PhpMyAdmin ein.
Erstmal kommt ein Fehler: INSERT INTO jos_migration_backlinks...#1062 - Duplicate entry '69' for key 1
Ich sehe in der Datenbank in der Tabelle jos_migration_backlinks nach...gut da stehen schon ein paar Sachen drin...aber alle Umlaute fehlen, bzw. danach fehlt der Rest. In der sql-Datei sehen die Umlaute alle korrekt aus.
Leeren der Datenbank und nun manuell versucht über den Reiter "SQL":
Hat geklappt! jos_categories und alle anderen Tabellen, z.B. jos_content wurden versucht nach dem gleichen Prinzip aufzuspielen.
Bei jos_content kam dann im PhpMyAdmin die Fehlermeldung:
import.php: Missing parameter: import_type
import.php: Missing parameter: format
Dort steht:
2.8 I get "Missing parameters" errors, what can I do?
Here are a few points to check:
- In config.inc.php, try to leave the $cfg['PmaAbsoluteUri'] directive empty. See also FAQ 4.7.
- Maybe you have a broken PHP installation or you need to upgrade your Zend Optimizer. See http://bugs.php.net/bug.php?id=31134.
- If you are using Hardened PHP with the ini directive varfilter.max_request_variables set to the default (200) or another low value, you could get this error if your table has a high number of columns. Adjust this setting accordingly. (Thanks to Klaus Dorninger for the hint).
- In the php.ini directive arg_separator.input, a value of ";" will cause this error. Replace it with "&;".
- If you are using Hardened-PHP, you might want to increase request limits.
- The directory specified in the php.ini directive session.save_path does not exist or is read-only.
Gehen wir auf Fehlersuche.
- In config.inc.php, try to leave the $cfg['PmaAbsoluteUri'] ist nicht gesetzt, also leer.
- Maybe you have a broken PHP installation or you need to upgrade your Zend Optimizer. See http://bugs.php.net/bug.php?id=31134.
Betrifft PHP 4.3.9/PHP 4.3.10, ich verwende PHP Version 5.2.6-1+lenny3 - If you are using Hardened PHP with the ini directive varfilter.max_request_variables set to the default (200) or another low value, you could get this error if your table has a high number of columns. Adjust this setting accordingly. (Thanks to Klaus Dorninger for the hint).
Directive ist nicht in php.ini gesetzt - In the php.ini directive arg_separator.input, a value of ";" will cause this error. Replace it with "&;".
Directive ist nicht in php.ini gesetzt, also Standard "&" - If you are using Hardened-PHP, you might want to increase request limits.
Hier wirkt evtl. der Suhosin Patch vom Hardened PHP-Project - The directory specified in the php.ini directive session.save_path does not exist or is read-only.
Der Pfad ist beschreibbar, sonst wären dort auch keine Session-Daten bereits drin.
Scheinbar ist hier alles in Ordnung. Versuchen wir es in kleinen Schritten...erstmal den ersten Datensatz einfügen. Geklappt.
Jetzt zwei weitere...auch in Ordnung, jetzt vier weitere, ok,...wir wagen es bis Datensatz 20...Bammmm das war zuviel.
Also nochmal in kleineren Schritten...siehe da. Es funktioniert. Das kann aber nicht die Lösung sein.
Die Request Limits des Hardened PHP hochsetzen
Auf dem Server ist der Suhosin Patch 0.9.6.2 installiert. Was hat das auf sich?
Suhosin is an advanced protection system for PHP installations. It was designed to protect your servers on the one hand against a number of well known problems in PHP applications and on the other hand against potential unknown vulnerabilities within these applications or the PHP core itself.
Es gibt eine Variable suhosin.request.max_vars
Ich sehe mal im error_log vom Apache nach, dort logged das PHP hinein:
ALERT - configured request variable value length limit exceeded - dropped variable 'sql_query'
Aha, demnach diese Einschränkung. Ich google danach und komme zum Ergebnis, dass auch andere schon ein Problem mit den Resourcen-Beschränkungen bei der Installation von Joomla haben. Diese Einträge habe ich der php.ini hinzugefügt:
suhosin.request.max_vars = 500;
suhosin.post.max_vars = 500;
Man sollte vorher überprüfen, wie die Variablen heißen. Manchmal nennen die sich auch hphp.request.max_vars und hphp.post.max_vars.
Apache neustarten und in der phpinfo kontrollieren.
Das war es aber nicht. Also nochmal genau lesen "request variable value length" exceeded.
suhosin.request.max_value_length steht bei mir auf 65000. Erhöhen wir doch mal den Wert in der php.ini (und das gleiche für die Post-Variablen) und starten den Apache nochmals neu:
Volltreffer. Hatte ihn um Faktor 1000 erhöht. Das war wohl etwas übertrieben, aber hatte zum Erfolg geführt.
Das scheinen wohl sinnvolle Werte zu sein:
suhosin.post.max_vars = 1500
suhosin.post.max_value_length = 500000
suhosin.request.max_vars = 1500
suhosin.request.max_value_length = 500000
Weiter geht es mit dem SQL-Dump einspielen. Die jos_modules wird vorher noch geleert, sonst meckert das PhpMyAdmin.Alle anderen Tabellen werden geprüft, ob dieseleer sind, um den SQL-Dump eingespielt zu bekommen.
Halleluja, es kommt die Meldung
Ihr SQL-Befehl wurde erfolgreich ausgeführt.
Login ins Joomla Backend
Hmmm...langsam werde ich stutzig...immer noch keine Module, Komponenten, Beiträge geladen.
Dem Fehler auf der Spur
Die Vermutung liegt nahe, dass bei der Migration noch andere Probleme aufgetreten sind. In der configuration.php bestätigen wir das. Wir versuchen es einfach nochmal. Die längste Zeit haben wir uns bisher mit den PHP Limits beschäftigt. Also: Neuinstallation von Joomla 1.5
Joomla 1.5 zweiter Versuch
Diesmal war die Datenbank korrekt angegeben. Dennoch wurden keine Inhalte durch das Migrationsskript eingespielt. Also kein Erfolg.
Versuchen wir es per Hand...
Installation in eine weitere frische Datenbank Test3.
Welche Tabellen sind angelegt worden?
jos_banner
jos_bannerclient
jos_bannertrack
jos_categories
jos_components
jos_contact_details
jos_content
jos_content_frontpage
jos_content_rating
jos_core_acl_aro
jos_core_acl_aro_groups
jos_core_acl_aro_map
jos_core_acl_aro_sections
jos_core_acl_groups_aro_map
jos_core_log_items
jos_core_log_searches
jos_groups
jos_menu
jos_menu_types
jos_messages
jos_messages_cfg
jos_migration_backlinks
jos_modules
jos_modules_menu
jos_newsfeeds
jos_plugins
jos_polls
jos_poll_data
jos_poll_date
jos_poll_menu
jos_sections
jos_session
jos_stats_agents
jos_templates_menu
jos_users
jos_weblinks
In welchen tabellen existieren schon Einträge?
jos_components
jos_core_acl_aro
jos_core_acl_aro_groups
jos_core_acl_aro_sections
jos_core_acl_groups_aro_map
jos_groups
jos_migration_backlinks
jos_modules
jos_modules_menu
jos_plugins
jos_templates_menu
jos_users
Welche Tabellen leeren wir und schieben die Inhalte per Hand rein?
jos_categories
jos_sections
jos_menu
Bei jos_modules sehen wir sofort, dass es hierzu Problemen kommen kann, da die IDs schon vergeben wurden. Wir gehen direkt in die SQL-Anweisungen und weisen neue IDs bei den Modulen zu, die noch nicht in der Spalte module gelistet sind. Module, die bereits gelistet sind löschen wir aus den SQL-Anweisungen.
Damit bekommen wir alle Module in die Liste der Site-Module.
Die Menüstruktur hat sich im Backend leider nicht verändert. Hier fehlen einfach die Referenzen, die Menü-IDs stimmen nicht mehr und insgesamt ist das ganze sehr frustrierend.
Einfacher ist es in meinen Augen, ab diesem Moment die Site komplett neu aufzubauen.
Immerhin lassen sich die Seiteninhalte recht gut mit Copy&Paste in das System herüberkopieren.
Jetzt sind bereits 10h an Migrationszeit vorbei und das Joomla 1.5 ähnelt noch nicht im Geringsten der alten Site. Liebe Joomla-Entwickler. Hier haben wir einen echten griff ins .... gemacht. Bitte das nächste mal einen anderen Weg gehen, der leichter ist. Das wäre ein Grund, sich um ein anderes CMS zu kümmern. Vielleicht bieten die Entwickler von Drupal oder Serendipity einen Migrator???
Viel Spaß noch beim Migrieren...
Bookmarks:
Delicious Facebook Google Yahoo Mr. Wong Linkarena Digg