Migration von Joomla 2.5.x zu 3.x

Bewertung:  / 22
SchwachSuper 

Zielstellung

In einer kurzen Anleitung soll beschrieben werden, wie man ein Joomla-2.5.x-Projekt zu Joomla 3.x migriert oder upgradet, was dabei zu beachten ist, und wie evtl. Stolperfallen umgangen werden können.

 

Grundwissen

Zunächst ist wichtig zu wissen, dass man eigentlich erstmals von einer Migration gar nicht reden kann. Denn üblicherweise ist eine Migration sehr viel aufwändiger und nicht mit einfachen Installationen erledigt. Meist sind spezielle Nacharbeiten notw. Jedoch haben uns die Joomla-Entwickler diese Migration so leicht gemacht, dass man eigentlich von einem Upgrade sprechen kann. Wer sein Joomla-Projekt schon bisher immer regelmäßig per Updates aktuell gehalten hat, kennt die Arbeit mit dem Joomla-Installer. Genau der kann auch für das Upgrade auf 3.x verwendet werden.

 

Notwendige Vorbereitungen

Systemvoraussetzungen

Bevor überhaupt ein Upgrade gemacht werden kann, sollte man sich über die Systemvoraussetzugen für Joomla 3.x informieren (php > 5.3, Server im Modus: magic_quotes off, siehe dazu auf dem Joomla.Org-Server.

Bei vielen gelingt das Upgrade nicht und man liest in Foren dann alle möglichen Fehlermeldungen und umständliche notwendige werdende manuelle Korreturmaßnahmen. Weiße Seiten im Backend obwohl das Frontend sauber läuft. Empfehlungen per Datenbank-Fix-Button die Datenbank zu bereinigen, obwohl dieser Button gar nicht erreichbar ist; verschwunde Admin-Menüs, Dublicate Entry - Fehler bei Schreibversuchen in die Datenbank, fof-Library-Versionskonflikte in Zus.hg. mit Akeeba u.s.w....
Meine Erfahrungen zeigen, dass schon nach dem ersten Upgrade-Fehlschlag die Probleme eigentlich erst losgehen. Denn ein dann erfolgtes Restore, schafft oft nicht die notwendige Basis für einen weitere dann erfolgreichen Versuch, sondern verschlimmert die Situation in ein unbeherrschbares Chaos (s. dazu unten Fehlerquelle Akeeba-Backup). Um das von vorn herein zu vermeiden, sollte man möglichst schon mit dem ersten Anlauf erfolgreich sein. Nachfolgend deshalb weitere Hinweise die man sicherheitshalber vorher berücksichtigen sollte.

  • Beschränkte Scriptlaufzeit. Das ist meines Erachtens einer der Hauptstörquellen die beim Upgrade dazwischenfunken. Leider wird keine entsprechende Fehlermeldung gesendet, so das man das oft nicht, oder den Fehler ganz wo anders vermutet. Sie sollten unbedingt, wenigestens für die Zeit des Updates, die Scriptlaufzeit für php hochsetzen. In der php.ini folgends eintragen: max_execution_time: 120. Wenn der Zugriff auf die php.ini durch Ihren Provider nicht erlaubt wird kann man das auch über einen Eintrag in die .htaccess erreichen: php_value max_execution_time 120. In Ihrem J!Projekt können Sie unter den PHP-Einstellungen den aktuellen Wert und den Erfolgt Ihrer Modifikation überprüfen.
  • Zu wenig Speicher: Ebenfalls sollte der Wert memory_limit auf vernüftige 256MB gesetzt werden. Mag sein, dass weniger genügt, gehen Sie aber auch hier wenigstens für die Zeit des Updates auf Nummer Sicher. Die Werte können ja anschließend wieder zurückgesetzt werden.
  • Ausgabepuffer ausschalten: Unter Joomla 3 wird empfohlen den output_buffering auf off zu stellen (siehe auch zu weiterführenden Erklärungen). Auch das ereichen Sie über einen entspr. Eintrag in die php.ini.


Joomla 2.5 aktuellste Updates

Zu empfehlen ist prinzipiell zunächst die Version von Joomla 2.5.x auf die aktuell verfügbare, letzte Version zu bringen. Im Oktober 2014 verfügbar 2.5.27, also mindestens diese. Da im Dezember 2014 die Long-Term-Unterstützung für Joomla 2.5 ausläuft, wird so viel nicht mehr kommen.
Also am besten über Erweiterungen > Joomla Aktualisierung die Updates einspielen.

Aktualisierung der Erweiterungen

Dann ist es wichtig die installierten Komponenten und sonstige Erweiterungen auf ihre Joomla-3.x-Tauglichkeit zu prüfen. Dazu sollte man auf die jeweiligen Entwicklerseiten gehen und sich informieren ob die letzte Version schon Joomla 3.x-Unterstützung anbietet. Meistens ist bei gut gepflegten Extensions der Fall gegeben, dass diese in einer Versionsnummer sowohl unter 2.5 als auch 3.x laufen. Das ist der Idealfall. Dann sollte man diese Updates ggf. einspielen und deren Funktion noch mal testen.

Über den Menüpunkt Erweiterungen > Erweiterungen sollte unter den Registern Datenbank und Überprüfen sichergestellt werden, dass alle durch Updaten schon notwendig gewordenen Anpassungen durchgeführt wurde, also z.B. Plugins aktualisiert wurde oder Datenbank-Strukturen modifiziert wurde.

Ist das Template Joomla-3.x-tauglich?

Auch diese Fragen muss beantwortet sein, bevor man das Upgrade durchführen kann. Wenn man Glück hat, nutzt man bereits ein Joomla-Template, welches so wie oben für Erweiterungen beschrieben, für beide Versionen nutzbar ist. Anderenfalls sollte man dies entweder durch ein Update erst erreichen, oder man schaltet zunächst auf das Joomla-Standard-Template zurück um dann später in der neuen Joomla-Version das Template 3.x-tauchlich zu machen. Wer selbst das Template erstellt hat, wird das beste Verfahren kennen, alle anderen sollten sich an ihre Template-Entwickler wenden.

Rechte entschärfen

Bei meinen Projekten habe ich wichtige, sicherheitskritische Dateien und Pfade zusätzlich durch Minderung der Schreibrechte geschützt. Dateien sollten für das Upgrade mindestens 640 haben. Wenn man das nicht beachtet, kann bei der Installation nicht jede Datei neu geschrieben werden, und das hat dann katastrophale Folgen.

Backup erstellen - Backup erstellen - Backup erstellen

Nun ist es Zeit vor dem nächsten entscheidenden Schritt noch mal eine Sicherung des Projektes durchzuführen (z.B. per Akeeba-Backup), für den Fall, dass doch etwas schief geht.

Hierzu ein wichtiger Hinweis für eine mögliche Stolperfalle. Sollte irgend etwas schief laufen beim Upgrade, dann müssen wir über den Akeeba-Kickstart das Projekt wieder herstellen. Hierbei kommt es ziemlich sicher zu einer Fehlermeldung in der Form: "500 - JHtmlBehavior: :mootools nicht unterstützt". Die Ursache hierfür ist, dass die neu Joomla-Version Dateien installiert, die im Backup-Archiv der alten Joomla-Version nicht vorhanden waren. Beim Projektaufruf nach dem Restore werden diese ja nicht gelöscht, sondern liegen nach wie vor im Projekt. Joomla bindet diese ein und nutzt diese Scripte und es kommt zu Konflikten. Folglich ist es unbedingt notwendig, bevor ein Restore gemacht wird, die gecrashte neue Joomla-Version vollständig aus dem Projektpfad zu löschen.

 

Das eigentlich Joomla-Upgrade

Ja, es ist tatsächlich so, die Vorbereitungen sind die Hauptarbeiten, das Upgrade ist dann schnell erledigt. Bevorzugt sollte dafür immer die Komponente Joomla!-Aktualisierung benutzt werden. Nur in Ausnahmefällen, wenn man über die Aktualisierung nicht weiter kommt, kann man auch über den Joomla-Erweiterungsinstaller aktualisieren.

Zunächst lädt man sich das aktuelle Update-Package von der Joomla-Seite (z.B. für die Version 3.3.6) herunter. Ideal ist die Installation aus eine Verzeichnis auf dem Webserver in das man das Installtionsarchiv entpackt hat. Das beschleunigt die eigentliche Installation und man erhält unwahrscheinlicher einen Fehler wg. evtl. Überschreitung der Scriptlaufzeit. Außerdem hat man eine Fehlerquelle weniger, wg. evtl. Schreibrechte.


Prüfen wichtiger Einstellungen zum Abschluss

  • Template allen notw. Sites zuweisen
  • Komponente-Updates installieren
  • Discover + DB Fix

 

Problembehandlung

Das Akeeba-Backup-Problem

Sollte das Upgrade schieflaufen und man stellt den Ursprungszustand wie vor dem Upgradeversuch wieder her, z.B. per Akeeba-Restoring, dann löscht Akeeba beim Restore nicht die aus dem Upgrade-Versuch hinzugekommenen Tabellen. Akeeba überschreibt nur die Tabellen, die Bestandteil des Backups sind und kümmert sich nicht um andere Tabellen.

D.h. entweder:

  • Bevor ein Restore gemacht wird, sollte man z.B. per phpMyAdmin die komplette Datenbank löschen, also alle Tabellen vollständige löschen!
  • Alternativ kann man auch nach dem Restore die "zu-viel-Tabellen" manuell löschen, bevor der nächste Upgrade-Versuch unternommen wird.

Jedenfalls, die nachfolgenden Tabellen dürfen nach einem Backup auf einem J!2.5-Projekt und vor einem erneuten Upgrade-Versuch nicht mehr vorhanden sein, weil sonst beim Upgrade auf J!3.x dublicate entries angemahnt werden und die Installation nicht sauber durchläuft:

  • #__contentitem_tag_map
  • #__content_types
  • #__tags
  • #__ucm_base
  • #__ucm_content
  • #__ucm_history
  • #__postinstall_messages

Über nachfolgenden SQL-Befehl kann man z.B. per phpMyAdmin o.g. Tabellen mit einem Ruck löschen.

DROP TABLE `#__contentitem_tag_map`, `#__content_types`, `#__tags`, `#__ucm_base`, `#__ucm_content`, `#__ucm_history`;

 

Das Redirect-Links - Problem

Es gibt Projekte die sich einfach nicht migrieren lassen, der Update-Proess-Statusbalken bleibt einfach bei 82.7% stehen und der Vorgang kann nicht abgeschlossen werden. Hier ist die Ursache eine evtl. zu große Datenbank. Ja, auch dann wenn Sie glauben, dass Sie im Projekt doch gar nicht so viele Daten haben. Übeltäter könnte dann hier die #__redirect_links - Tabelle sein. Hier werden sämtliche Adressen gespeichert mit denen das Projekt mal aufgerufen wurde, auch 404-Einträge. Über die Zeit können sich enorm viele DS anreichern. Ich hatte ein Projekt mit 250.000 Datensätzen und einer Tabellengröße von 150MB.

Hier hilft nur, diese Tabelle vorher zu bereinigen. Leider hat beim mir ein komplettes Leeren der Tabelle immer dazu geführt, dass das Projekt im Frontend nicht mehr aufrufbar war, weshalb ich offensichtlich nicht mehr gebauchte Links per SQL entsorgt habe. Einen anderne Weg habe ich bisher nicht gefunden. 

Es gibt Forenbeiträge die sich zum Bereinigen der #__redirect_links äußern. Hier wird erwähnt die Komponente Umleitungen zu deaktiven oder einfach nur das Umleitung-System-Plugin. Beides konnte nicht verhindern, dass mein Projekt bei leerer Tabelle nicht funktionierte. Wie man diese Tabelle vollständig bereinigt, ist also noch ein Rätsel.

So habe ich diese z.B. bereinigt:

DELETE FROM `j2ms_redirect_links` WHERE hits = 1
DELETE FROM `j2ms_redirect_links` WHERE old_url like '%-detail%';
DELETE FROM `j2ms_redirect_links` WHERE old_url like '%/zwei%';

 

Links zum Thema:

Lesen Sie unbedingt auch diesen sehr ausführlichen Beitrag von mir zum Thema Migration: Projekt migrieren oder besser ein neues aufsetzen.

 

Wenn Ihnen dieser Beitrag geholfen und viel Zeit gespart hat, zeigen Sie sich erkenntlich: Über eine Klick auf Google+1 oder Rückmeldungen freue ich mich, zeigt es mir doch, dass sich die viele Mühe für die Beitragerstellung gelohnt hat. Schenken Sie auch den Produktwerbungen Ihre Beachtung, denn darüber refinanziere ich meine Aufwand.

 

Kommentare (10)

  • Gast - ronald

    Hallo<br /><br />ich habe mit interesse dein blog gelsen und auch alles so befolgt, wie du es beschrieben hast. dennoch bleibt er bei etwa 80% stehen und ich finde im gesamten netz keine lösung dazu...<br /><br />dennoch danke für deinen beitrag!<br />vielleicht hast du ja auch in der zeit neuere infos?<br /><br />gruß ronald

  • Meine Erfahrungen mit der Migration haben gezeigt, dass es doch eine ganze Menge Widrigkeiten geben kann, die eine saubere Migration verhindern. Man muss da mit viel Fantasie und Intuition an verschiedensten Stellen nach Ursachen suchen. Für die Sache mit den Redirect-Links habe ich etliche Stunden gebraucht. <br /><br />Schau Dir mal Deine Datenbank an, ob da nicht evtl. noch andere auffällig große Tabellen enthalten sind.

  • Gast - Jochen

    Toller Beitrag, weil er nicht nur die Idealsituation berücksichtigt, sondern Vorsorge für allerlei Widrigkeiten empfiehlt, die in der Idealwelt nicht bekannt sind. Danke dafür!<br /><br />Bei "Hier wird erwähnt die Komponente Umleitungen zu deaktivern oder einfach nur das Umleitung-System-Plugin. Beides konnte nicht verhindern, dass mein Projekt bei leerer Tabelle funktionierte."<br />fehlt da ein "nicht" vor dem "Funktionierte"?

  • Jepp, danke, wurde bereinigt.

  • Gast - Stephan Schiwy

    Hallo,
    ich war leider auch zu blauäugig bei der Migrationsvorbereitung.
    Mein "white-screen of death" habe ich in soweit eingekreist, dass ich weder im Backend, noch im Frontend ein Standardtemplate zugewiesen habe.
    Wenn ich dies jetzt im Backend für Site & Admi mache (1 von 6 als Standard zuweise) bekomme ich zwar eine Erfolgsmeldung, aber der gelbe Stern wird in der Templateübersicht nicht gesetzt und das Ergebnis ist immer noch "weiße Schrift auf weißem Grund" (site). Die Bedienung des Backends ist ohne Template auch nicht sehr glücklich. Ich bin wenigstens einen Schritt weiter als im englischsprachigen Forum. Hat wer einen Tip für mich?

  • Gast - Christian

    Hallo,

    danke für deinen Beitrag, Das war sehr hilfreich, hätte das sonst nicht hinbekommen. Übeltäter war bei mir das oben beschriebene Akeeba Problem und eine Komponente, die Ärger machte (Advanced Module Manager).

  • Gast - Marcus

    Habe das mit dem Akeeba versucht, wollte das Backup von STrato (Originalseite) auf bplaced üertragen. Nach 2 Stunden habe ich das Restore auf bplaced sein lassen. Ich tendiere zur kompletten neuinstallation oder anderes CMS System

  • Entmutigt? Na ja, es gibt doch ne Menge Stolperfallen auf dem Weg zum Erfolg, um die J!Migration hinzubekommen. Einfach machen die es einem nicht. Habe schon mehrere Kundenprojekt anhoben und mittlerweile so meine Erfahrungen gesammelt. Ob neu aufsetzen oder Umstieg ist als Option auch nicht immer der beste Weg, meistens noch aufwändiger. Und beim neuen System warten nur andere Probleme?

  • Gast - Jon

    Ganz ehrlich, je komplexer und verwurschtelter die Seite, desto weniger lohnt sich doch so eine automatisierte Vorgehensweise. Die Zeit, die man dafür investiert, kann man auch sinnvoller nutzen. Ich mache meinen Kunden i.d.R. ein neues System, übernehme den Content per copy-paste aus den beiden Backends und mache lieber ein paar optische Verbesserungen. Dieses Rumgefriggel muss man sich meiner Meinung nach nicht antun. Dann sitze ich lieber ein paar Stunden länger dran, habe dafür aber einen schönen Workflow und noch Spaß an der Arbeit.

  • Ihre Aussage und Herangehensweise ist nachvollziehbar. Bei kleineren Projekten mache ich das auch lieber so. Es gibt aber große Projekt mit vielen tausend Beiträgen und/oder Produkten etc. Da kehrt sich dieser Ansatz ins Negative. Prinziell entscheide ich in jedem Fall neu, wie ein Projekt zu migrieren ist. Speziell zu diesem Thema habe ich hier auch schon einen Beitrag verfasst: Projekt migrieren oder besser ein neues aufsetzen.

Einen Kommentar verfassen

Als Gast kommentieren

0
Deine Kommentare erfordern die Moderation durch den Administrator
Nutzungsbedingungen.

Verwandte Beiträge

Suche - Kategorien
Suche - Inhalt
plg_search_attachments
VM - Search, Virtuemart Product

Ihr Warenkorb

 x 
Ihr Warenkorb ist noch leer.

Anmeldung