Migration auf aktuelle PHP und MySQL Version scheitert

[Gandalf]

Bedingt durch Umstellung auf höhere Versionen von PHP und MySQL teste ich derzeit das Migrationsszenario und scheitere am Ende.

Alte lauffähige Umgebung:
- PHP 4.3.4
- MySQL 4.0.18
- Conpresso 4.1.2

Neue Umgebung:
- PHP 5.4.19
- MySQL 5.5.32
- Conpresso 4.1.6

Vorgehensweise:

1. Sicherung Ordnerstruktur conpresso komplett
2. Sicherung der MySQL Daten mit MySQLdumper
3. Übetragen der Daten auf den neuen "Server" (in meiner Testumgebung sind jeweils XAMPP Versionen im Einsatz)
4. Anlegen der Datenbank und Import der Daten in MySQL -> fehlerfrei und Stichproben bestätigen dies
5. Aufruf des derzeit noch unter 4.1.2 laufenden Conpresso Auftritts -> keine Fehlermeldungen nur weißes Bild im Browser, selbes Ergebnis beim Aufruf des Backends
6. "Drüberkopieren" aller Dateien vom 4.1.6 Conpresso
7. Aufruf des Conpresso Auftritts -> jetzt werden die Inhalte der PHP Dateien im Browserfenster angezeigt, selbes Ergebnis beim Aufruf des Backends

Ich habe zum Test mal eine leere Conpresso 4.1.6 Installation durchgeführt
- diese verlief fehlerfrei und ich kann das Backend fehlerfrei aufrufen/einloggen etc.

Nun verstehe ich dieses Verhalten nicht, wer könnte mir den notwendigen Denkanstoß geben? Die scharfe Umstellung erfolgt im Dezember 2013.


Gruß Gandalf

[MarkusR]

zu 5.) das liegt am seit PHP 5.4 nicht mehr unterstützten import_request_variables
zu 7.) Du schreibst nichts von Modulen oder Anpassungen. Sollte es solche geben (die am Ende nicht mal in der Liste der Module für PHP 5.4 und CPO 4.1.6 stehen), dann wurden da ggf. Shorttags verwendet, die Du erst auf der neuen Umgebung erlauben müsstest (falls im neuen PHP überhaupt noch zulässig) oder durch korrekte PHP-Tags ersetzen müsstest.
Ein typischer Vertreter dieser Art ist: mod_guestbook/_include/abbc/abbc.lip.php, die durch mod_guestbook includet wird und somit zu diesem Fehler führt. Ist aber nicht die einzige in diesem leider veralteten Modul...

[Gandalf]

Hallo Markus,

es müsste doch möglich sein, einen alten Auftritt mit den neuen MySQL und PHP Versionen lauffähig zu bekommen. Wenn ich doch eine komplett neue Installation mit 4.1.6 (conpresso) auf den o. g. Grundlagen durchführe, dann komme ich ja z. B. ins Backend.

Wenn ich hingegen meine Version von 4.1.2 auf 4.1.6 update, dann bekomme ich Probleme, dass verstehe ich nicht.

Ich setze zu der Grundinstallation von conpresso ausschließlich das Gästebuch und das Kontakt Modul ein. Zudem eine separate Kalenderlösung.

Auch mal die Frage an balu: Die Entwicklung von PHP und MySQL gehen ja unaufhaltsam voran, sollte ich damals auf das falsche Pferd gesetzt haben, sprich solange es Provider gibt die die Uraltversionen von PHP und MySQL vorhalten (es werden ja immer weniger) dann läuft das CMS, aber auf aktuellen Version scheitert dies.

Es wäre fast schon tragisch, wenn ich mich nach einer neuen Lösung umsehen müsste, der Aufwand wäre ja immens groß, die derzeitigen Inhalte einzupflegen.

Ich wünsche mir (ja es ist bald Weihnachten) dass die Migrationen reibungslos klappt, denn conpresso ist ja ziemlich verbreitet und alle Nutzer werden in Kürze auf diese Probleme stoßen.

Wie könnte ich dazu beitragen? Meine PHP Kenntnisse sind sehr oberflächlich, aber ich könnte durchaus Testszenarien durchführen.


Packen wir es an!

Gruß Gandalf

[MarkusR]

es müsste doch möglich sein, einen alten Auftritt mit den neuen MySQL und PHP Versionen lauffähig zu bekommen.

ja, sicher, deshalb wird das hier ja schon seit über einem Jahr hoch- und runterdiskutiert, Lösungen bereitgestellt und Hilfesuchenden ausführlich geholfen.

Nochmal für Dich persönlich:
1.) Erlaube Shorttags oder ändere Shorttags in richtige PHP-Tags (der verursachende Code im Gästebuch ist 10 Jahre alt!)
2.) Das von Dir verwendete Gästebuchmodul ist nicht mit PHP 5.4 und höher kompatibel. Wende Dich dazu an den Entwickler, führe die notwendigen Änderungen selbst durch oder wähle z.B. eine Lösung mit mod_form
3.) Wenn Du mit CPO 4.1.2 weiter arbeiten willst, dann suche in _include/common.inc.php die Zeile
@import_request_variables('cgp'); // CGP to avoid problems with cookies from other pages
und ersetze sie durch
@extract($_COOKIE); @extract($_GET); @extract($_POST);
außerdem suchst Du in ALLEN Dateien nach
htmlspecialchars(...)
und ergänze es zu
htmlspecialchars(..., ENT_COMPAT, 'ISO-8859-15')

aber allein aus Sicherheitsgründen ist 4.1.2 nicht mehr zu empfehlen... und die Änderungen aus 3.) sind schon in 4.1.6 drin, muss man also nicht selbst machen.

Wenn ich hingegen meine Version von 4.1.2 auf 4.1.6 update, dann bekomme ich Probleme, dass verstehe ich nicht.

das liegt wie gesagt am Gästebuch, für das es kein Update gibt und Du somit auch kein wirkliches Update durchführst.
(das ist wie wenn man sich heute einen 3D-BluRay-Player kauft und sich wundert, warum der keinen Scart-Anschluss für den alten Röhren-Fernseher mehr hat...)
mod_contact ist übrigens auch veraltet. Kann ebenfalls durch mod_form ersetzt werden.

Ich persönlich habe schon mehr als ein Dutzend Auftritte (auch mit veralteten Modulen) umgestellt. Ist gar kein Problem und wurde hier schon mehrfach durchgesprochen...

Ich weiß auch, daß das für Dich jetzt unbefriedigend ist. Ich verstehe selbst nicht warum die Provider einen zum Umstieg zwingen müssen.
Sehr einfach ist ein Providerwechsel (viele verzichten auf PHP 5.4), ein billiger vServer (die auch alle noch mit max. PHP 5.3 laufen) oder gleich ein eigener Server...

solange es Provider gibt die die Uraltversionen von PHP und MySQL vorhalten (es werden ja immer weniger) dann läuft das CMS, aber auf aktuellen Version scheitert dies

Wenn man bei PHP 5.3.27 vom Juli 2013 von einer Uralt-Version sprechen möchte, dann ja.
PHP 5.4 war bei der Entwicklung von CPO 4.1.5 noch unstable, daher ist es schwer möglich gewesen auf den Kampf gegen Umlaute in PHP 5.4 zu reagieren. Das tut nun eben 4.1.6 seit vielen Monaten, aber nicht jene vereinzelten Module, die seit mehreren Jahren nicht mehr weiterentwickelt werden.
Seit Mitte des Jahres wäre übrigens PHP 5.5 die aktuelle Version, Deine 5.4 ist also auch bereits eine "Uralt"-Version...
Bei mir läuft ConPresso bisher ohne Probleme auf PHP 5.5.

[Gandalf]

Hallo Markus,

nun mein neuer Provider sichert mir (derzeit) folgendes zu:

PHP -> 5.3.27
MySQL -> 5.5.30

Haben nun damit lokal (XAMPP) die Migration getestet. Das Update von conpresso 4.1.2 auf 4.1.6 durchgeführt mit folgendem Ergebnis:

- mod_guestbook (4.1.0): läuft fehlerfrei
- mod_search: hier benimmt sich das Modul so, als sei es nicht korrekt aktiviert. Im Backend kommt beim Klick auf die Konfiguration:

Code: Alles auswählen

Warning: include(C:\Temp\xampp_1.7.7\htdocs\conpresso//includes/inc_options.inc.php) [function.include]: failed to open stream: No such file or directory in C:\Temp\xampp_1.7.7\htdocs\conpresso\mod_search\edit.php on line 31

Warning: include() [function.include]: Failed opening 'C:\Temp\xampp_1.7.7\htdocs\conpresso//includes/inc_options.inc.php' for inclusion (include_path='.;C:\Temp\xampp_1.7.7\php\PEAR') in C:\Temp\xampp_1.7.7\htdocs\conpresso\mod_search\edit.php on line 31

Hier fehlt letztlich ein korrekter Inhalt der Variable $activeModules[$directory]['directory'].

Im Frontend kommt der Hinweis, dass das Modul deaktiviert wäre und folgende Fehler:

Code: Alles auswählen

Warning: Division by zero in C:\Temp\xampp_1.7.7\htdocs\conpresso\_include\function.php on line 309

Warning: Division by zero in C:\Temp\xampp_1.7.7\htdocs\conpresso\_include\function.php on line 310

Hier die betreffenden Zeilen der Funktion "string_next_page", ($perpage ist < 1 oder NULL):

Code: Alles auswählen

$pages      = floor(($total+$perpage-1)/$perpage); // no of pages
    $activePage = floor($first/$perpage);              // actual ("active") page

- mod_contact: Im Frontend nur der Hinweis, dass das Modul deaktiviert sei. Im Backend wird es als aktiviert angezeigt, jedoch fehlt der dazugehörende Eintrag im Navigationsmenü. Vermutlich auch hier das selbe Problem wie bei mod_search.


Wo könnte ich ansetzen?


Gruß Gandalf

P.S.: Ja ich weiß, dass ab PHP >= 5.4 (mal sehen wann mein Provider hier umschaltet) meine Module wohl nicht mehr laufen werden. Für den Anfang muss der jetzige Auftritt erst einmal laufen, dann begebe ich mich an die Umsetzung ggf. mit mod_form...

[MarkusR]

Notiere Dir die Einstellungen der betroffenen Module, deaktivere und deinstalliere sie... wirklich!
Dann installiere sie erneut, aktiviere sie und ergänze die Einstellungen.

Die Modulschnittstelle schreibt viele Infos in die Moduleinstellungen, ggf. sind da Leichen vorhanden...

Es gibt eigentlich keinen Grund für Probleme mit mod_search, ich nutze es zu Testzwecken auch mit XAMPP. Die finalen Tests finden aber immer auf "richtigen" Webservern statt, weil dies ja die Zielplattform ist.

[Gandalf]

Danke Markus, das war ein guter Ansatz, mit weiteren händischen Anpassungen, im Detail:

- mod_search: deaktiviert- deinstalliert - neuinstalliert - aktiviert -> KLAPPT

- mod_contact: deaktiviert - deinstalliert - neuinstalliert (dazu VORHER in der setup.php für das Erstellen der Tabelle "cpo4_mod_contact" den Parameter TYPE= geändert in ENGINE=) - aktiviert , dann:

- von Hand per phpmyadmin die Tabelle cpo4_mod_contact manuell befüllt, hier die Spalten RECIPIENTS und SETTINGS. Wobei SETTINGS auch im Backend korrekt befüllt werden konnte, aber RECIPIENTS leider nicht, da in der recipient.php die $_GET Anweisungen stehen...

- dann das korrekte Template wieder zugeordnet mit vorherigem Löschen des default Kontakttemplate

Evtl. auf die Schnelle einen Tipp, wie die $_GET Anweisungen für PHP 5.3 und höher korrekt lauten müssten?

Gruß Gandalf

[MarkusR]

Ich habe eine für PHP 5.4 und CPO 4.1.6 lauffähig gemachte mod_contact-Version.

Keine Ahnung was ich damals angepasst habe... war auch noch eine beta-Version.

In recipient.php kommt es vor allem auf die Zeile
$action = $_REQUEST['action'];
an...

[Gandalf]

Chapeau!

mit Deinen Anpassungen klappt es.

TIPP: Ersetze in der Setup.php in Zeile 138 "TYPE=" mit "ENGINE=", dann läst sich das Modul mit MySQL 5.x installieren.


Gruß Gandalf

[MarkusR]

Im Grunde ist es immer simpel.

Wenn ein GET-Aufruf nicht klappt, dann schaut man in der URL nach den übergebenen Parametern und in der Zieldatei, ob diese direkt oder über das $_GET- pder $_REQUEST-Array angesprochen werden.
Bei POST-Aufrufen schaut man sich das aufrufende Formular im Quelltext an, Parameter notieren und prüft dann in der aufgerufenen Datei ob diese direkt oder über das $_GET- pder $_REQUEST-Array angesprochen werden.

Durch die Änderung

suche in _include/common.inc.php die Zeile
@import_request_variables('cgp'); // CGP to avoid problems with cookies from other pages
und ersetze sie durch
@extract($_COOKIE); @extract($_GET); @extract($_POST);

dürften die meisten Module auch ohne das weiter laufen.

Erst für PHP 5.4+ müssen dann auch alle htmlspecialchars und htmlentities umgeschrieben werden.

Du könntest Deine Version mit Captcha und allen Änderungen und Verbesserungen hier bereitstellen. semf (seventy-soft.de) hat das Modul zur allgemeinen Weiterentwicklung freigegeben...