Crossgrade LEPTON CMS zu WBCE CMS

Als vor einigen Jahren mehrere Entwickler aus der WebsiteBaker-Community zu LEPTON CMS – einen Fork von WebsiteBaker – wechselten, habe auch ich neue Sites mit LEPTON realisiert und etliche alte Sites auf LEPTON umgestellt. Inzwischen nutze ich für (sehr) kleine Sites aber lieber WBCE, einen weiteren aber deutlich jüngeren Fork von WebsiteBaker. Und da es einfacher ist, Standard-Lösungen nicht für verschiedene CMS vorzuhalten, alte LEPTON-Versionen nicht unter PHP 7 laufen und es inzwischen in jeder neuen Major-Version von LEPTON „breaking changes” gibt, wuchs der Wunsch, LEPTON-Sites auf WBCE zu migrieren. Während aber alte WebsiteBaker-Sites sehr unkompliziert auf WBCE umgestellt werden können, gibt es für alte LEPTON-Sites keinen offiziellen Migrationspfad. Es geht aber, wenn man bereit ist einige Schmerzen in Kauf zu nehmen. In diesem Artikel möchte ich mal meine Erfahrungen bei der Migration von LEPTON auf WBCE beschreiben.

Dies soll keine Schritt-für-Schritt-Anleitung für das Crossgrade von LEPTON auf WBCE sein – stattdessen notiere ich nachfolgend mal die Probleme auf die ich bei der Migration zwischen den beiden Content Management Systemen gestoßen bin und meine Lösungen dazu. Die Komplikationen können auf anderen Installationen ganz Andere sein und da ich bislang erst eine Site von LEPTON auf WBCE umgestellt habe, fehlen mir auch verlässliche Erfahrungswerte. Darüber hinaus mag mir die Tatsache in die Karten gespielt haben, dass die von mir behandelte Site ursprünglich eine WebsiteBaker-Installation war, welche irgendwann später auf LEPTON umgestellt wurde. Möglicherweise waren dadurch noch einige Dateien und Datenbank-Einträge an Ort und Stelle, wo sie auch WBCE erwartet. Zudem war die betroffene Site in meinem Fall noch eine mit einer LEPTON 1.x-Version – ob die sich LEPTON 2, 3 oder gar 4 ebenso auf WBCE überführen lassen ist mindestens ungewiss.

Ausgangslage

Bei der betroffenen Site handelte es sich um eine alte WebsiteBaker 2.8.3-Seite, die später auf LEPTON 1.3.2 umgestellt wurde. Diese Site sollte nun auf WBCE 1.3.3 ge-crossgradet werden.

Vorbereitungen

Auch wenn das WBCE-Update-Skript offiziell LEPTON nicht als Ausgangs-CMS akzeptiert, bin ich doch in der Vorbereitung der Update-Anleitung von WBCE gefolgt:

• Backup der LEPTON-Website erstellt (Dateien und Datenbank – wichtig!)
• auf Grundlage dieses Backups eine lokale Kopie der Site angelegt und zum Laufen gebracht (kann man sich ggf. auch sparen aber ich arbeite lieber an einer lokalen Kopie als direkt „am offenen Herzen” der Live-Site)
• neueste Version von WBCE herunter geladen
• config.new.php und favicon.ico im WBCE-Download entfernt
• verbleibene Dateien und Ordner aus dem WBCE-Download in die LEPTON-Site kopiert (Ordner vervollständigen, Dateien ersetzen)
• Außerdem: PHP-Version auf 7.2 umgestellt (war zuvor 5.6)

Damit war alles vorbereitet, um mit der eigentlichen Arbeit zu beginnen.

config.php anpassen

Da die config.php von LEPTON etwas ander aussieht als die von WBCE, habe ich diese zunächst auf eine WBCE-übliche Form gebracht. Dafür habe ich mir eine config.php aus einer anderen WBCE-Site kopiert und dann dort die Konfigurationsdaten angepasst. Wer gerade keine andere WBCE-Installation als Vorlage zur Verfügung hat, here we go:

<?php

define('DB_TYPE', 'mysql');
define('DB_HOST', 'localhost');
define('DB_NAME', 'lorem');
define('DB_USERNAME', 'username');
define('DB_PASSWORD', 'password');
define('TABLE_PREFIX', 'lep_');

define('WB_URL', 'http://example.com');
define('ADMIN_DIRECTORY', 'admin'); // no leading/trailing slash or backslash!! A simple directory only!!

require_once(dirname(__FILE__).'/framework/initialize.php');

WBCE-Update-Skript

Wie in der Update-Anleitung von WBCE geschrieben, habe ich im nächsten Schritt Das Update-Skript unter /install/update.php aufgerufen. Wie nicht anders erwartet, brach dieses jedoch mit der Meldung ab, das gefundene CMS sei nicht für das Update von (bzw. Crossgrade auf) WBCE geeignet. Also habe ich zunächst die Stelle im Update-Skript entfernt (auskommentiert), in der die Prüfung stattfindet:

/* FOLGENDEN BLOCK AUSKOMMENTIERT:
if (version_compare($old_wb_version['VERSION'], '2.7', '<')) {
    status_msg('<br />WebsiteBaker version below 2.7 can´t be updated to WBCE.<br />Please update your WB version to 2.7 before upgrading to WBCE in a second step!', 'warning', 'div');
    echo '</td></tr></tbody></table></div></body></html>';
    exit();
}
*/

Danach lief das Update-Skript durch. Natürlich mit etlichen Fehlermeldungen, allerdings nichts total Dramatisches – daher habe ich das hier erstmal ignoriert. Es war mir ja klar, dass es mit dem Ausführen des Update-Skripts allein nicht getan ist und Nacharbeiten nötig sind. Und um die geht es jetzt.

Änderungen an der Datenbank

Nach dem ersten Login-Versuch am WBCE-Backend hagelt es mehrere Fehlermeldungen – größtenteils weil bestimmte PHP-Konstanten wie etwa DEFAULT_TIMEZONE nicht wie von WBCE erwartet bereit standen. Es wurde auch nur das Menü des Backends angezeigt, alles Andere fehlte infolge der zahlreichen Fehler. Also habe ich im Code gesucht, wo diese Konstanten definiert werden und woher sie ihre Werte bekommen. Dabei stellte sich heraus, dass einige von WBCE erwartet Datenbankfelder in der vormaligen LEPTON-Installtion schlicht nicht zur Verfügung standen. Nachfolgend also die SQL-Kommandos zum Ergänzen der fehlenden Felder bzw. zum umbenennen vorhandener (z.B. im SQL-Tab in phpMyAdmin eingeben). Wichtig hier: Der Table-Präfix – in meinem Fall „lep_“ – muss ggf. angepasst werden, damit er zu jeweiligen Installation passt. Dieser Präfix ist in der config.php definiert und auch daran erkennbar, dass jede Tabelle in der Datenbank damit beginnt.

1. default_timezone Eintrag in Tabelle „lep_settings“ ergänzen

INSERT INTO `lep_settings` (`setting_id`, `name`, `value`) 
VALUES ('106', 'default_timezone', '7200');

2. smart_login Eintrag in Tabelle „lep_settings“ ergänzen

INSERT INTO `lep_settings` (`setting_id`, `name`, `value`) 
VALUES ('108', 'smart_login', 'true');

3. timezone Spalte in Tabelle „lep_users“ ergänzen

ALTER TABLE lep_users
ADD COLUMN timezone int(11) NOT NULL DEFAULT '0';

Danach einmal aus dem Backend ausloggen und neu einloggen, damit eine neue Sitzung erstellt und die Einstellungen neu aus der Datenbank gelesen werden.

Aufräumen

Nach diesen Änderungen lief die Website – sowohl Frontend als auch Backend (nach der Umstellung auf das WBCE Flat Backend Theme) – weitestgehend wieder. Der WYSIWYG-Editor von LEPTON „FCKEditor” machte zwar noch Probleme, aber durch die Umstellung auf die mit WBCE mitgelieferte neue Version „CKEditor” (ohne F am Anfang) lief auch der wieder. Soweit so gut. Nun gab es nur noch ein paar Fehler in eingesetzten Modulen, allerdings infolge der nun höheren PHP-Version und nicht direkt wegen der Migration auf WBCE. Insbesondere die Module des von mir sehr geschätzten Entwicklers Ralf Hertsch haben infolge seines tragischen Todes vor ein paar Jahren keine Updates mehr erhalten und waren ausnahmslos nicht unter PHP 7.2 lauffähig. In Fall der betroffenen Site waren das aber nur Hilfsmodule wie ImageTweak und dessen Abhängigkeiten (kitFramework, Dwoo etc.) und nicht zwingend für den Betrieb der Site notwendig – ich habe diese also einfach deinstalliert. Andere Module wie etwa Foldergallery oder Members habe ich entweder mit neuen Versionen aus dem Addon-Repository von WBCE aktualisiert oder die Problemstellen (infolge unter PHP 7 nicht mehr exisitenter Funktionen) händisch korrigiert. Da das bei jeder Site – je nach eingesetzten Modulen – anders sein wird, möchte ich an dieser Stelle da nicht näher drauf eingehen.

Ich hoffe das hilft dem Einem oder Anderem mit selbiger Aufgabenstellung, Probleme bei der Migration von LEPTON auf WBCE zu lösen oden bei der Lösungssuche in die richtige Richtung zu denken. Eine Blanko-WBCE-Installation als Referenz bei Vergleichen in der Datenbank hilft auf jeden Fall.

Solltet jemand weitere Problemlösungen für diese Aufgabe parat haben, schreibt es gern in die Kommentare.

Update, 5.4.2019 – Nötige Änderungen am Frontend-Template

Florian wies im Thread des WBCE-Forums darauf hin, dass nach der Umstellung auf WBCE der Aufruf der class.secure.php LEPTON-Templates entfernt werden muss. In meinem Fall war das nicht nötig, da die betroffene Site ja zuvor eine WebsiteBaker-Site war und somit noch ein WebsiteBaker-Template (ohne Aufruf der class.secure.php) nutzte – welches ohne weitere Anpassungen unter WBCE funktionierte. Für dedizierte LEPTON-Templates gilt aber:

Das muss RAUS:

// include class.secure.php to protect this file and the whole CMS!
if (defined('WB_PATH')) {	
	include(WB_PATH.'/framework/class.secure.php'); 
} else {
	$oneback = "../";
	$root = $oneback;
	$level = 1;
	while (($level < 10) && (!file_exists($root.'/framework/class.secure.php'))) {
		$root .= $oneback;
		$level += 1;
	}
	if (file_exists($root.'/framework/class.secure.php')) { 
		include($root.'/framework/class.secure.php'); 
	} else {
		trigger_error(sprintf("[ <b>%s</b> ] Can't include class.secure.php!", $_SERVER['SCRIPT_NAME']), E_USER_ERROR);
	}
}
// end include class.secure.php

Das sollte stattdessen REIN:

//Must be: Prevent from direct access:
if(!defined('WB_URL')) {
	header('Location: ../index.php');
	exit(0);
}

Zusätzlich zu Florians Hinweis fiel mir gerade noch Folgendes ein: In WebsiteBaker-Modulen – und auch in frühen LEPTON-Modulen – wurde häufig das Vorhandensein der PHP-Konstante MOD_FRONTEND_CSS_REGISTERED geprüft. Diese Konstante war dort nur dann vorhanden, wenn im Template die Funktion register_frontend_modfiles('css') aufgerufen wurde, welche die Stylesheets der Module einbindet. Wenn MOD_FRONTEND_CSS_REGISTERED also vorhanden war, wusste das Modul dass sein Stylesheet korrekt geladen wurde und im Frontend zur Verfügung steht. Als Fallback, wenn MOD_FRONTEND_CSS_REGISTERED nicht vorhanden ist und das Modul daher annehmen musste, dass das Stylesheet nicht korrekt eingebunden wurde, gaben Module häufig den Inhalt des Stylesheets direkt in das HTML aus, als s.g. Internal Styles. Unter WBCE steht die Konstante MOD_FRONTEND_CSS_REGISTERED aber generell nicht zur Verfügung, auch wenn register_frontend_modfiles('css') im Template aufgerufen wurde und alte Module schreiben somit ihre Styles immer in das HTML, welche dann Vorrang gegenüber Styles im Stylessheet des Templates haben und dadurch ein fehlerhaftes Aussehen verursachen können. Um das zu verhinden muss man – wenn man diese älteren Module weiter nutzen möchte – die Konstante nach dem Aufruf von register_frontend_modfiles('css') im Template selber definieren. Zum Beispiel so:

if (function_exists('register_frontend_modfiles')) {
    register_frontend_modfiles('css');
    // prevent old modules from outputting their CSS file contents directly (!) into html
    define('MOD_FRONTEND_CSS_REGISTERED',true);
}

Update, 5.4.2019 – Problembehebung bei falscher Darstellung von Umlauten

Sollten nach dem Rück-Umzug der lokal auf WBCE umgestellten Site Probleme mit der Darstellung von Umlauten auftreten, kann es helfen den Zeichensatz für die Datenbankverbindung konkret in der config.php zu definieren:

define('DB_CHARSET','utf8');

Update, 23.10.2019 – Problembehebung: Medienbrowser zeigt keine Dateien an

Bernd wies mich in den Kommentaren auf ein Problem hin, welches mir bislang selber garnicht aufgefallen war: Nach dem Crossgrade auf WBCE werden unter „Medien“ keine Dateien mehr angezeigt. Es sind zwar alle Ordner sichtbar, diese scheinen jedoch leer zu sein (keine Panik: die sind nicht wirklich leer!). Wie er richtig schrieb, liegt das daran, dass LEPTON in der Datenbank-Tabelle lep_settings (der Präfix lep_ kann bei euch auch anders sein), im Schlüssel rename_files_on_upload erlaubte Dateiendungen für den Upload (und die Darstellung im Medienbrowser) auflistet, WBCE aber an gleicher Stelle eine Liste verbotener Dateiendungen erwartet. Unter LEPTON steht da u.a.  jpg, gif sowie png als erlaubte Dateiendungen drin. Aber da WBCE an aben dieser Stelle die Liste verbotener Endungen erwartet, führt das dazu, dass unter WBCE Bilddateien mit eben diesen Endungen nicht angezeigt werden (und auch nicht über den Medienbrowser hochgeladen werden können).

Die Lösung ist aber ganz einfach: In der Tabelle lep_settings, Schlüssel rename_files_on_upload, wird der (falsche) Wert aus der LEPTON-Zeit …

jpg,jpeg,gif,gz,png,pdf,tif,zip

… durch den korrekten Wert für WBCE ersetzt (habe ich aus einer „sauberen” WBCE-Installation rausgesucht):

ph.*?,cgi,pl,pm,exe,com,bat,pif,cmd,src,asp,aspx,js

Das geht auch bequem über das WBCE-Backend: Grundeinstellungen → Servereinstellungen → im Feld  „Diese Dateitypen nicht hochladen”.

Besten Dank an Bernd für den Hinweis!