HowTo: Update auf CPO+

[MarkusR]

Die Vorbereitungen

Ausgangsbasis:
Ein Webauftritt mit CPO 4.1.6+1 soll auf CPO 4.1.6+4.0 upgedatet werden.
Das Vorgehen ist das Gleiche wie beim Update eines originalen CPO 4.1.6 oder älter auf eine aktuelle ConPressoPlus-Version!
Dabei soll von PHP 7.3.5 auf PHP 8.1.8 umgestellt werden.

Vorarbeit:
Zuerst werden Daten und Datenbank komplett gesichert um diese Daten auf den neuen Server zu übertragen, Dateivergleiche durchführen zu können und natürlich ein Backup zu haben.
Für das PHP-Update ist relevant, ob beide PHP-Versionen verfügbar und umschaltbar sind.
Sind beide Versionen vorhanden, dann kann das Update durchgeführt werden und dann auf die neue PHP-Version umgeschaltet werden.
Üblicherweise werden aktuell (7/22) auf Hosting-Paketen die PHP-Versionen 7.4, 8.0 und 8.1 angeboten, vereinzelt werden über den "Extended Support" (teils kostenpflichtig) auch ältere Versionen toleriert.

Folgende Dinge müssen vor dem Update geprüft und später beachtet werden:

1. Welche Module sind installiert? Sind davon welche deaktiviert und sogar entbehrlich?
2. Welche Dateien wurden geändert?
3. Gibt es zusätzliche PHP-Dateien?

Bei 1+2 kann der Update-Check von mod_track helfen.
Dies ergibt die Prüfung beim betrachteten Webauftritt:

Modulverzeichnisse
mod_phpinfo
mod_mobile
mod_functions
mod_autologin
mod_search
mod_imagesize
mod_track

Datei-Integrität
Beachten Sie, dass nur die originalen ConPresso-Dateien geprüft werden. Module oder sonstige hinzugefügte Dateien können nicht geprüft werden.

Die folgenden Dateien entsprechen nicht der originalen Prüfsumme und wurden möglicherweise verändert.
_admin/articles.php
_admin/index.php
_admin/login.php
_admin/modules.php
_editor/editor.php
_include/buildpage.inc.php
_include/common.inc.php
_include/db_mysql.inc.php
_include/form_fields.inc.php
_include/lang/deutsch/common.inc.php
_include/member.inc.php
_include/parser.php
_include/secure.php
_include/sessiondb.inc.php
_include/translation.inc.php
_includesite/i_file_upload.php
_includesite/i_manage_files.php
_rubric/loadfooters.php
_rubric/loadheaders.php
_skin/conpresso/common-skin.php
mod_search/includes/inc_search_function.inc.php

Bei den Datei-Änderungen gilt es anschließend durch Vergleich mit den Originalen festzustellen, was geändert wurde, was dies bewirkt und ob diese Änderung für den weiteren Betrieb erforderlich ist oder ggf. in CPO+ schon vorhanden oder sogar optimiert ist. Das ist recht einfach, wenn man schon immer Änderungen dokumentiert hat.
Bei den Modulen sind ebenfalls eventuelle Änderungen durch Vergleich mit den Originalen zu prüfen. Außerdem sind die Moduleinstellungen zu dokumentieren!
Die Moduleinstellungen kann man durch Speichern als HTML-Datei einfach dokumentieren.
Für den Dateivergleich gibt es zahlreiche spezialisierte Tools, diese zeigen auch im Original nicht vorhandene Dateien (Punkt 3), die meist das größte Kopfzerbrechen bereiten.

Prüfung der Datei-Änderungen
Dafür enpacke ich das Original-Archiv in ein lokales Verzeichnis und lade die Dateien des Webauftritts in ein weiteres lokales Verzeichnis. Diese (s.o. Datei-Integrität) werden nun mit einem Dateivergleichstool abgeglichen, das die genauen Änderungen anzeigt. Teilweise sind es nur ergänzte oder nach Änderungen vergessene Leerschritte oder Leerzeilen und können ignoriert werden, teilweise korrigieren sie aber auch Fehler oder rüsten Funktionen nach. Wer den Sinn einer Änderung nicht erkennt sollte hier aufhören und jemanden mit dem Update beauftragen!
Um zu beurteilen, ob eine Änderung in der neuen Version noch eingepflegt werden muss, sollte man einen Blick in die neuen Dateien werfen, dies kann aber auch beim Versuch die Änderungen in diese neuen Dateien zu übernehmen erfolgen. Ich persönlich prüfe lieber frühzeitig, um nicht mittendrin überrascht zu werden.

Ergebnisse der Prüfung
_admin/articles.php -> mod_instantupload, break statt continue viewtopic.php?f=17&t=4743
_admin/index.php -> mod_autologin
_admin/login.php -> mod_autologin
_admin/modules.php -> break statt continue viewtopic.php?f=17&t=4743
_editor/editor.php -> ereg_replace() wird zu preg_replace()
_include/buildpage.inc.php -> mod_mobile
_include/common.inc.php -> force ISO
_include/db_mysql.inc.php -> mysqli support
_include/form_fields.inc.php -> mod_instantupload
_include/lang/deutsch/common.inc.php -> Sprachergänzungen
_include/member.inc.php -> mod_autologin
_include/parser.php -> mod_imagesize
_include/secure.php -> mod_autologin
_include/sessiondb.inc.php -> session garbage collection
_include/translation.inc.php -> Defaultsprache Deutsch
_includesite/i_file_upload.php -> mod_imagesize
_includesite/i_manage_files.php -> mod_imagesize
_rubric/loadfooters.php -> mod_mobile
_rubric/loadheaders.php -> mod_mobile
_skin/conpresso/common-skin.php -> CPO+
mod_search/includes/inc_search_function.inc.php -> FIX for PHP7 - ereg() replaced by stripos()

Hierbei sind grüne Einträge Änderungen, die in CPO+ definitiv bereits integriert sind und somit keine manuelle Anpassung mehr erfordern oder die gar nicht übernommen werden sollen, es bleibt also nur ein Bruchteil.
Rote Einträge sind Änderungen, die nicht übernommen werden sollen.

Das alles bis hierhin war nur Vorbereitung, es ist noch nichts passiert!
Aber man hat einen Eindruck, wie groß der Aufwand wird, weiß hoffentlich, was man wirklich behalten will und kann bei Problemen den bisherigen Zustand rekonstruieren oder einfach zurücksetzen.

[MarkusR]

Zwischenüberlegung: PHP-Update

Das eigentliche Update ist unabhängig von den PHP-Versionen, da auch neuere CPO-Versionen auf alten PHP-Versionen laufen (ab ~ 5.2/5.3), die eigentlich gar nicht mehr im Einsatz sind bzw. sein sollten.
Umgekehrt sind neue PHP-Versionen aber oft der Auslöser/Veranlasser für ein Update, weil ältere CPO-Versionen nicht auf neueren PHP-Versionen laufen.

Das liegt daran, dass Einstellungen durch die PHP-Updates geändert werden (auf die der Nutzer oft keinen Einfluss hat), einzelne Funktionen (meist aus Sicherheitsgründen) entfernt werden und die Toleranz für nachlässiges Programmieren immer weiter reduziert wird.
Letzteres erzeugt meist den größten Aufwand.
PHP hat seine Beliebtheit dadurch gewonnen, dass es im Vergleich zu anderen Programmiersprachen sehr einfach zu Ergebnissen führte und man sich um Dinge wie Variablendeklaration nicht kümmern musste, die einfach "On-the-fly" genutzt wurden. Das führte aber auch zu zahlreichen Sicherheitsrisiken, daher werden hier zunehmend die Zügel angezogen, was eine konsequentere Code-Entwicklung bedingt.
Dies wird eigentlich schon seit Jahren mittels "Notice"-Ausgaben den Nutzern mitgeteilt und hätte zum Handeln führen können, aber in der Regel werden diese lästigen Hinweise (standardmäßig) abgeschaltet statt beachtet, bis diese in aktuellen PHP-Versionen zu "Warnings" werden und die Seiten nicht mehr funktionieren.

Ist die Seite noch ohne Fehler oder Warnmeldungen nutzbar, dann kann man das Update wie im folgenden beschrieben sehr einfach durchführen und dann die PHP-Version umschalten. Vereinzelt erlauben Provider nur für einen begrenzten Zeitraum (30 Minuten bei Strato) das Zurückschalten auf veraltete PHP-Versionen, daher sollte sich eine umfassende Prüfung direkt anschließen!

Unabdingbar ist das Aktivieren der sichtbaren Ausgabe von Fehlern!
Dies ist eine PHP-Einstellung, die entweder mittels Kontrollzentrum des Providers, php.ini, htaccess oder ini_set()-Befehl vorgenommen werden kann. Später kann diese wieder deaktiviert werden, da diese Ausgaben von Hackern interpretiert werden können.

Sollte wegen der PHP-Version ein Wechsel des Servers/Providers notwendig sein, dann sind die Dateien der lokalen Sicherung dorthin zu übertragen, wofür manchmal auch hilfreiche Migrations-Tools angeboten werden.
Wichtig ist natürlich auch der Transfer der Datenbank, die die eigentlichen Inhalte enthält. Bei großen Spüngen in der Version sollte man auf folgendes achten:
Export der Datenbank mit möglichst ausführlichen Codes!
Beim weit verbreiteten phpmyadmin wählt man daher "Angepasst" statt "Schnell" und dann

• "Spaltennamen bei jedem INSERT Schlüsselwort verwenden / Beispiel: INSERT INTO tbl_name (col_A,col_B,col_C) VALUES (1,2,3)", also die erste und ausführlichste Version. Dies erleichtert bei der Fehlersuche das Lesen und das Retten verlorener Daten. Allerdings wird die SQL-Datei größer.
• "Binäre Spalten in hexadezimaler Schreibweise exportieren (zum Beispiel wird aus "abc" 0x616263)" MUSS man deaktivieren, weil sonst Umlautplobleme auftreten, wenn mit der neuen Version eine andere Codierung genutzt wird.

Die Sicherungen von mod_backup machen dies als Default.

Diese SQL-Datei wird auf dem neuen Server importiert.

Haben sich die Zugangsdaten zur Datenbank geändert, dann sind diese in der Datei _cfg/db.inc.php anzupassen!

Wird der transferierte Auftritt jetzt bereits aufgerufen, dann können diverse Fehlermeldungen auftreten und Umlaute falsch dargestellt werden, was weitere Fehlermeldungen verursacht.
Das ist aber kein Grund zur Panik, denn das eigentlich Update kommt ja noch.
Das erleben aber viele ConPresso-Nutzer, wenn der Provider unangekündigt Updates vornimmt.

[MarkusR]

Das Update

A) Nun werden die aus dem Archiv extrahierten Dateien der neuen CPO-Version per FTP auf den Server übertragen.
Dabei ist das Verzeichnis _setup entweder nicht mit zu übertragen, nach dem Upload zu löschen oder die Rechte zu entziehen.
Werden Module verwendet, die nicht zum Umfang von ConPressoPlus gehören, dann sind, insofern dort auch ein Update erfolgen soll/kann, auch diese Dateien auf den Server zu kopieren.

Betrachtet man den Auftritt (Nur gucken! Noch nicht versuchen damit zu arbeiten!), dürften die Umlaut-Probleme bereits beseitigt sein. Fehlermeldungen oder Warnmeldungen sollten auch deutlich weniger sein oder ganz verschwinden.

B) Nun werden die während der Vorbereitung dokumentierten Änderungen der Originaldateien in die neuen Dateien eingearbeitet.
Sollten diese Änderungen zu einer Modifikation oder einem Modul gehören empfiehlt es sich dabei die Installationsanleitung parallel zu betrachten, weil es hier ggf. neue Vorgehensweisen oder Optimierungen gibt.
Wirft man ab und zu einen Blick auf den Webauftritt, dann erkennt man schnell Fehler durch Tippfehler oder fehlende Kommas, Semikolon oder Klammern und kann diese sofort korrigieren, vorausgesetzt die Bildschirmausgabe von Fehlern und Warnmeldungen wurde wie empfohlen aktiviert.

C) Nun kann man sich einloggen und zuerst die Systemeinstellungen prüfen, korrigieren und ergänzen und SPEICHERN.

D) Nun prüft man die Einstellungen der Module (anhand der bei der Vorbereitung dokumentierten Einstellungen), korrigiert oder ergänzt diese und klickt bei JEDEM danach auf SPEICHERN.
Bei großen Versionssprüngen kann es erforderlich sein sich über die Default-Einstellungen der neuen Versionen zu informieren, weil diese bei neuen Optionen natürlich nicht aus den alten Einstellungen abgelesen werden können.

E) Nun kann die PHP-Version umgestellt werden
Treten Fehler auf, dann sind diese zu untersuchen (siehe unten) und ggf. weitere Anpassungen vorzunehmen.
Treten keine Fehler auf, dann kann die Bildschirmausgabe der Fehler wieder deaktiviert werden.

Damit sollte das Update abgeschlossen sein und alles funktioneren... bis zum nächsten Update!

[MarkusR]

Typische Fehler und die Lösung (hoffentlich)

In meinem Fall traten Fehler durch ein (noch) nicht weiterentwickeltes und in ConPressoPlus nicht enthaltenes Modul auf

Warning: Undefined array key "showMobile" in /var/www/vhosts/domain.de/httpdocs/mod_mobile/common-module.inc.php on line 129

Damit kann man sich ganz einfach die Fehlerstelle ansehen.

"Undefined array key", "Undefined variable" oder "Undefined index" sind typische Fehler, die durch PHP >= 8 auftreten.
In diesem Fall wurde versucht ein Cookie auszulesen, dass noch gar nicht gesetzt ist.

Lösung: Bei Prüfungen nicht direkt auf den zu erwartenden Wert prüfen sondern zuerst die Existenz des/der Arrays/Keys/Variable prüfen!

In diesem Fall wird

Code: Alles auswählen

if ($_COOKIE['showMobile'] == 'true') $mod_mobile = true;
if ($_COOKIE['showMobile'] == 'false') $mod_mobile = false;

ergänzt zu

Code: Alles auswählen

if (isset($_COOKIE['showMobile']) && $_COOKIE['showMobile'] == 'true') $mod_mobile = true;
if (!isset($_COOKIE['showMobile']) || $_COOKIE['showMobile'] == 'false') $mod_mobile = false;

Eine weitere Lösung ist, wenn es nicht externe Werte wie ein Cookie oder übergebene Parameter sind, diese am Anfang der Datei zu initialisieren/definieren, wobei die CPO-Funktion initVar() hervorragende Dienste leistet, da diese ein versehentliches Überschreiben verhindert.

Im Frontend wird eine weitere Fehlermeldung gezeigt:

Warning: Undefined variable $mobileTemplateSet in /var/www/vhosts/domain.de/httpdocs/mod_mobile/buildpage.inc.php on line 32

Hier wird an den Anfang der Datei (vor der genannten Zeile 32) noch folgendes ergänzt

Code: Alles auswählen

initVar($mobileTemplateSet, false);

Und eine weitere Fehlermeldung

Warning: Undefined array key 2 in /var/www/vhosts/domain.de/httpdocs/_include/printnavigation.inc.php on line 105

Hier wird es nun interessant, da es sich um eine Kerndatei von ConPresso handelt. Hier wurde also noch keine Anpassung vorgenommen, weil dieser Fehler weder gemeldet wurde noch bei meinen Tests aufgetreten ist. Dieser muss also noch auf die ToDo-Liste für CPO+!

Hier wurde also wieder etwas abgefragt ohne dessen Existenz zu prüfen! Diese "Problemchen" dürften sich noch eine ganze Zeit lang zeigen, bis alle Stellen gefunden wurden.

Hier wird nun

Code: Alles auswählen

if ($actLevels[$level]==$v['id']) echo '<li class="active">';

geändert zu

Code: Alles auswählen

if (isset($actLevels[$level]) && $actLevels[$level]==$v['id']) echo '<li class="active">';

Nicht alle Fehler sieht man direkt am Bildschirm (trotz aktivierter Bildschirmausgabe) da sie im HTML-Code keine sichtbare Ausgabe erzeugen, daher lohnt ein Blick in den Seiten-Quelltext und das (sofern verfügbar) PHP-Fehlerprotokoll.

Im Letzteren habe ich weitere Fehler gefunden:

Warning: Undefined variable $cpoSystem in /var/www/vhosts/domain.de/httpdocs/_include/parser_r_url.inc.php on line 69
Warning: Trying to access array offset on value of type null in /var/www/vhosts/domain.de/httpdocs/_include/parser_r_url.inc.php on line 69

Beide Fehler basieren auf der Zeile

Code: Alles auswählen

if ($cpoSystem['PATH_INFO'])  {

Hier könnte man wieder eine Prüfung auf Existenz vorschalten, aber vielleicht doch erst mal überlegen:
Diese Variable PATH_INFO wird von mir gar nicht genutzt und führt sowieso meist nur zu Problemen, wie entsprechende Beiträge im Forum belegen. Aber sie existiert nun mal und wird hier abgefragt. Dabei sollten CPO-Sytemvariablen in einem CPO-System doch nicht unbekannt sein, oder?
Verantwortlich ist hier die Nutzung von Seitentemplates statt Header- und Footerdateien, bei der die Ausgabe durch Funktionen erfolgt und Variablen z.B. durch Globalisierung innerhalb der ansonsten abgeschotteten Funktion zur Verfügung gestellt werden müssen.

Daher macht es hier Sinn die Zeile am Anfang von _include/parser_r_url.inc.php

Code: Alles auswählen

global $content, $key, $parameters, $replacement, $db_nr, $cpoRubrics, $db_rubric_id;

zu ändern in

Code: Alles auswählen

global $content, $key, $parameters, $replacement, $db_nr, $cpoRubrics, $db_rubric_id, $cpoSystem;

Auch dieser Fehler muss noch auf die ToDo-Liste für CPO+!

Und ein weiterer Fehler aus dem Protokoll

Warning: Undefined variable $content in /var/www/vhosts/domain.de/httpdocs/_editor/editor.php on line 482
Warning: Trying to access array offset on value of type null in /var/www/vhosts/domain.de/httpdocs/_editor/editor.php on line 482

Das ist jetzt besonders interessant, da die Variable $content hier eigentlich gar nichts zu suchen hat und ich vorerst vermute, dass diese irgendwann mal aus _include/form_fields.inc.php hierher kopiert wurde, aber eben keinerlei Auswirkungen hatte, da sie hier nicht existiert. Mit PHP 8 wird es aber zum Problem... mal schauen...
Erste Prüfung: Der Code existiert in identischer Form in _include/form_fields.inc.php!

Erste Entscheidung:

Code: Alles auswählen

                foreach ($targets as $v) {
                    printf('<option value="%1$s" %2$s>%1$s</option>',
                    htmlspecialchars($v, ENT_COMPAT, 'ISO-8859-15'),
                    trim($content[$key]['urltarget'])==trim($v) ? 'selected' : ''
                    );
                }

wird geändert zu

Code: Alles auswählen

                foreach ($targets as $v) {
                    printf('<option value="%1$s">%1$s</option>',
                    htmlspecialchars($v, ENT_COMPAT, 'ISO-8859-15')
                    );
                }

also die Problemzeile und zugeordnete Parameter entfernt, da eine Vorauswahl einer Option hier gar nicht benötigt wird.
Auch dieser Fehler muss noch auf die ToDo-Liste für CPO+!

To be continued...