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%';

 

Das JSON-Problem nach der Migration

Einige Anwender beklagen, dass nach der Migration auf manchen Seiten eine Fehlermeldung 
exception 'RuntimeException' with message 'Error decoding JSON data: Syntax error' mit den betroffenen Scripten Json.php, Registry.php, article.php, legacy.php, controller.php, content.php, helper.php, site.php und/oder index.php auftritt. Dieser Fehler wird relevant mit der einem Update von Joomla vermutlich auf Version 3.6.3 und später. Ursache wird sein, dass ab dieser Version die JSON-Verarbeitung anders oder weniger tolerant abläuft. Wenn also ein JSON-String nicht sauber übergeben wird, dann kann darau das Parameter-Objekt nicht korrekte erzeugt werden und es kommt zu diesem Fehler.  

Als Ursache kristallieren sich folgende Bedingungen heraus:

  1. Es erfolgte eine Upgrade auf Joomla mind. Vers. 3.6.3.
  2. Die Fehlerhaften JSON-Daten befinden sicher in Datenbankfeldern und haben sich durch eine frühere Migration eingeschlichen, scheinbar dann wenn man die Migration mit der Erweiterung JUpgrate durchgeführt hat.
  3. Der Fehler macht sich mitunter erst zeitversetzt bemerkbar. Z.B: die Migration von Joomla 2.5. auf bis 3.6.3 erfolgt scheinbar störungsfrei - aber die defekten Daten sind dann schon da, werden aber von Joomla toleriert. Erst bei einem Update z.B. durch ein notw. Sicherheitspatch auf Joomla 3.6.5 kommt es dann zu Crash.

Im Netz kursieren dazu diverse Lösungsvorschläge. Diese zielen i.d.R. darauf ab diese fehlerhaften JSON-Objekte zu finden. Allerdings wurde dort bisher immer nur erkannt, dass leere JSON-Objekte z.B. in der #__modules-Tabelle nicht als {} gefüllt sind, sondern mit {""}. Und das ist nicht JSON-konform und fehlert dann eben. Entsprechend gibt es Lösungsvorschläge per SQL-Queries diese zu suchen und zu ersetzen.

Hier LInks dazu 

Leider zeigte sich bei meinen Projekten, dass das nicht zur Problemlösung führte. Nach aufwendigen Durchsuchen der Datenbanktabellen speziell der #__content-Tabelle zeigte sich eine weitere Auffälligkeit, die dann bei mir die Lösung brachte. Im einigen Feldern war in dem Feld metadata nach dem ansich sauberen Feldinhalt mit dem Json-Objekt noch ein angehängtes tags= enthalten. Klar, dass das fehlerte. 

So sehen die falschen Feldinhalte z.B. aus:

{"robots":"",
"author":"",
"rights":"",
"xreference":""}
tags=

 Daraufhin habe ich mit einer Suchen/Ersetzen-SQL-Abfrage diese Felder bereinigt und schon lief das Projekt sauber:

So findet man diese Fehlerhaften Feldinhalte in der #__content Tabelle:

SELECT * FROM `fhtb_content` WHERE `metadata` like '%tags=%';

So werden diese Fehler bereinigt:

update fhtb_content
set `metadata` = replace(`metadata`,'tags=','')
where `metadata` like '%tags=%'

Nun, auch diese Erfahrung zeigt wieder deutlich. Wenn eine Joomla-Migration scheitert, und davon habe ich nun einige hinter mir, dann sind die Gründe für das Scheitern immer andere. Ohne kreative Ideen, Intuition, Kenntnis über Joomla-Internas und natürlich MySQL und PHP-Kenntnisse kommt man kaum zum Erfolg. Sonstige Erfahrungen in der Migration von Joomla sind i.d.R. wenig wert, weil kaum eine gemachte Erfahrung bei einem anderen Projekt Relevanz hat.

 

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.