"Man(n) nennt es Pech." - die Chronik 03
Die Chronik der Wiederbelebung der Museen-Seiten - die 4. Woche ist inzwischen fast rum und mein Museen-CMS geht immer noch nicht - nicht mit Gewalt und auch nicht mit Tricks und Workarounds. (es dauerte bis zu 7. Woche)
Ein Programm sticht hervor -
der php-code-sniffer, der "php-Code-Schnüffler".
18.8.2023 - Der "PHP_CodeSniffer-3.7.2"
Hier mein Wissens-Stand am 18.8.2023 - die im Moment aktuelle Restore-VM (virtuelle maschine) für unsere Museen- Seiten läuft gerade mit opensuse 42.3 und php 5.5.14 und die jeweiligen Startseiten der vier Museen werden sogar ausgeliefert (wenn alle vhosts installiert sind).
Das bedeutet, ein für alle Museen gleiches "index.php" Startprogramm kann über php-5 die mysql Datenbank ansprechen und aus den Tabellen die auslieferungsfähigen statischen Startseiten produzieren. Es funktionieren jedoch keine Unterseiten der zweiten Menü-Ebene und im typo3 Backend, das ist meine Redaktions-Umgebung, funktioniert auch einiges nicht, zum Beispiel der Text-Editor für Content-Elemente.
.
Die jetzt anliegende Hauptaufgabe ist (war) die Nachbesserung bzw. die Korrektur der typo3 php-Programme (vorläufig) auf die php 5.5 Umgebung. Der Funktionsumfang der damaligen typo3 Version 4.2.17 überschreitet meinen Bedarf als Redakteur deutlich, ich brauche / verwende nur wenige Teile / Funktionen davon.
Es sind vielleicht 150 bis 300 php Scripte und Klasssen- Definitionen anzupassen. - Seit php 5.2 hat sich nämlich einiges im php-Code geändert. Das alles von Hand zu machen, ist quasi unmöglich. Doch dazu gibt es zum Glück einige intelliegente Hilfen von engagierten php Fans.
Gefunden .......
Zum einen gibt es den "code-schnüffler", den "php_code_sniffer", der den aktuellen php-Status abfragt (bei uns die Version 5.5) und die notwendigen Veränderungen in der jeweiligen php-Datei als Warnung und/oder als Fehler ausgibt. Wenn natürlich bei einer php-Datei von ca. 20 Kilobyte dann mehr als 7200 Warnungen und Fehler auftauchen, kommt regelrecht Frust auf. Doch ein halbautomatischer Reparatur-Versuch belohnt die Mühe.
Dann gibt es sogenannte php Code-Converter. Wir sind immer noch in der freien Software-Welt.
Beginnen wir aber mit dem "PHP_CodeSniffer-3.7.2"
Bei google muß man nach "php-code check" suchen :
Es dauerte doch einige Zeit (eine ganze Nacht), bis ich das "richtige" !!! Suchwort (das ist der google Suchschlüssel) gefunden hatte, um über diesen "Schnüffler" zu stolpern. An den dort vorgeschlagenen Install- Methoden beißt man sich leider über Stunden die Zähne aus. Alles hatte gestimmt, aber es wollte einfach nicht klappen.
Release date: 2023-02-22
Release state: stable
Dependencies: (die sind extrem wichtig)
PHP Version: PHP 5.4.0 or newer - (ich habe 5.5, später 7.0 und dann 7.2)
PEAR Package: PEAR Installer 1.4.0b1 or newer - (habe ich ebenfalls 5.5)
PHP Extension: tokenizer
PHP Extension: xmlwriter
PHP Extension: simplexml (wurde alles über YAST nach-installiert)
und durch wirklich reinen Zufall kommen Sie auf einer erhellenden Forums-Seite auf diese "eine" ganz ganz simple Zeile:
der cli (command line interface - mit Tastatur) - Befehl :
- pear install PHP_CodeSniffer-3.7.2
und das hat bei suse 42.3 mit php5.5 endlich funktioniert - wieder war eine Nacht rum.
Der erste Versuch
mit dieser wirklich einfachen "1-Zeilen Installation" hatte endlich und plötzlich funktioniert und die ersten Tests / Aufrufe waren erfolgreich !!!! - jedenfalls oberflächlich. Denn das Programm zeigt eine Menge Fehler an.
Hier ein Beispiel :
- phpcs /xxx/yyyy/typo3_src-4.2.17/typo3/alt_main.php
FILE: /xxx/yyyy/typo3_src-4.2.17/typo3/alt_main.php
----------------------------------------------------------------------------------------------------
FOUND 405 ERRORS AND 50 WARNINGS AFFECTING 226 LINES
----------------------------------------------------------------------------------------------------
3 | ERROR | [x] Expected 1 space(s) before asterisk; 0 found
4 | ERROR | [x] Expected 1 space(s) before asterisk; 0 found
5 | ERROR | [x] Expected 1 space(s) before asterisk; 0 found
.........
574 | ERROR | [x] Spaces must be used for alignment; tabs are not allowed
574 | WARNING | [ ] Line exceeds 85 characters; contains 92 characters
575 | ERROR | [x] Spaces must be used to indent lines; tabs are not allowed
575 | ERROR | [x] Line indented incorrectly; expected at least 4 spaces, found 1
575 | ERROR | [x] "include_once" is a statement not a function; no parentheses are required
----------------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 390 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------------------------------------
Time: 91ms; Memory: 10MB
#
Fixing the remaining errors requires the intervention of the programmer. Usually, these are errors such as missing correct tags in the class comment.
----------------------------------------------------------------------------------------------------
Doch bezüglich der Korrektur diese fehler muß der Admin erst mal wissen, wie die php Version 5.5 bzw. 5.6.x "tickt". An einer php-Datei habe ich stundenlang Tags erstellt und verändert und immer wieder mehrere Fehler angezeigt bekommen. So geht das also nicht.
Zum "phpcs" gehört das "phpcbf" Reparatur- Programm
Die wichtigste Aussage war aber - das zum phpcs zugehörige Reparatur- Programm !!!!! : PHPCBF kann viele von den Fehlern reparieren
"PHPCBF CAN FIX THE 390 MARKED SNIFF VIOLATIONS AUTOMATICALLY"
Laut der Hilfe-Texte im github Repository
https://github.com/squizlabs/PHP_CodeSniffer erkennt das Programm "phpcs" die aktuell installierte php-Version (sie muß größer sein als php 5.4) und orientiert sich an der dort erwarteten php-Code-Basis.
Warum also jetzt nicht gleich von php 5.2 auf die php-Version 7.2 oder sogar 7.4 upgraden ?
Wenn also die php-Version vom "sniffer" abgefragt wird und danach die code-Fehler gesucht werden, könnte man ja gleich auf eine (angeblich bessere) php-Version 7.x übergehen. Die php-Versionen 7.x seien teilweise doppelt so schnell wie die php-Versionen von 5.5 und 5.6 - so die propagierte Theorie. -------
Doch die Crux liegt im Detail.
Opensuse bietet in der Version Leap 42.3 nur php 5.5 oder php 7.0.x an. Ich habe keine Repos gefunden, die zum Beispiel die php 5.6.40 (das war die allerletzte 5.6 Version) oder ein update von 7.0 php 7.2.x erlauben. Das ist ein ganz schwaches Bild und paßt überhaupt nicht zu der ebenfalls propagierten Flexibilität von Linux und den Sprüchen von opensuse. Aber es geht ja noch viel weiter mit den Problemen.
Also die opensuse 42.3 gleich auf php7.x upgraden
Nach ausführlicher Recherche also die opensuse 42.3 gleich auf php7.x upgraden.
Die Entscheidung ist nicht schwer, mit zypper oder YAST geht das ganz schnell, php-5 deinstallieren, php-7 installieren und ein paar Änderungen in den Apache2 Config Files, ein apache2-Restart und der phpMyAdmin lief sofort. Also ganz toll, wieder ein Fortschritt - dachte ich.
Jetzt die Liste mit den zu verbessernden oder zu convertierenden typo3 Programmen anzeigen lassen und zwecks Dokumentation in eine Excel Tabelle schreiben und mit den beiden Programmen "phpcs" und "phpcbf" abarbeiten bzw. mit pcpcbf teilreparieren. Klingt doch wirklch gut oder ?????
Aber : Ein Misthaufen (php 7.0) kommt selten alleine ......
Denn: ich hatte mich zu früh gefreut. Das bereits unter php 5.5 ausprobierte Code- Schnüffel- Porgramm "phpcs" lief jetzt nicht mehr. Na gut, dann installiere ich das eben nochmal unter php 7.0.x - ist ja nur eine Zeile :
- pear install PHP_CodeSniffer-3.7.2
..... pear findet keinen php-code-sniffer.
Auch gut, probieren wir mal die alternative Installation mit dem Composer. Der Composer läuft auch nicht mehr, ssl Fehler.
Nach über 2 Stunden !!! googeln schreibt jemand in einem ganz fremden zufällig gefundenen Blog oder Forum, die php-Version 7.0.x hat (habe) eine Macke (oder sogar mehrere), da ginge vieles nicht. das sole man bedenken.
Na gut, dachte ich, machen wir doch in der installierten opensuse 42.3 einfach ein Update von der php 7.0 auf php 7.2.x. - Und schon wieder Pech, das geht bei der opensuse 42.3 nicht, es wird nämlich nicht angeboten, obwohl es vielleicht doch ginge.
Die alten Zusatz-Repos sind auch nicht mehr da. Und wenn man eine php 7.2.x für Leap 42.3 findet, ist das nur das php-Grundsystem, die ganzen php 7.2 Zusatzmodule (z.B. für mysql) fehlen. Also das war wieder mal ein so richtiger opensuse-Flop.
Von einem Regenguß in den nächsten .....
Von einem Regenguß in den nächsten, wäre eine Möglichkeit. - Der EDV-Mensch weiß aber, "no risk - no fun". Ein Upgrade auf opensuse 15.0 oder 15.x läßt wieder unerklärliche Probleme erwarten, jedenfalls bei Suse. Ob dann die mysql (mariadb)-Engine mit meinen Datenbank-Dateien noch läuft, ist ein Pokerspiel. Jedenfalls hat sich suse mit dieser Produkt- / Update- Politik nicht mit Ruhm bekleckert.
Die opensuse Hilfs-Foren - viel zu oft nicht hilfreich ....
Wenn echte Zwänge und Nöte einfach ignoriert werden :
Wie bei den aktuellen typo3 Versionen von 2023 ist auch das Getue der Foren-Admins jeweils der Anfang vom Ende. Es gibt bei meinen Recherchen viel zu viele Anwender und Netzwerk- oder Server- Admins, die im hauseigenen Netzwerk eine alte opensuse Version in einer VM (Virtuellen Maschine) benötigen. - Aus welchen Gründen oder Zwängen auch immer, spielt für mich dabei überhaupt keine Rolle (als Beispiel eine Steuersoftware für eine ältere numerische Drehbank oder numerische Fräse). Es wäre und ist vom Pflege-Aufwand und der Datenmenge her ein Klacks, die ehemaligen Repos einfach verfügbar stehen zu lassen.
Und die klugscheißerischen Aufforderungen "mancher" suse-Foren Admins, "nimm einfach die aktuelle Version", ist sowas von daneben und arrogant und überheblich, daß es mich bereits richtig ärgert, wie man seine Fan-Basis so runterputzen kann.
Diejenigen, die diese Fragen an die oder in den Suse-Foren stellen, sind alles gestandene Linux-Admins, die seit mehreren "Dekaden" !!! suse die Stange gehalten hatten. Und sie werden immer weniger. -- merkt das denn "keiner" ?
..... und gleich ein Schwenk (oder ein Schwank?) zu typo3 :
"typo3" zum Beispiel "war einmal" ein 50% Produkt im CMS Bekanntheits-Umfeld von 2004 bis 2010. Im Sommer 2023 hat man nur noch 0,4% an Bekanntheitsgrad ermittelt ...... und von den verbliebenen großen Hostern mit "dedicated root Servern" wird opensuse und typo3 fast überall entsorgt. Warum wohl ?
19.8.2023 - 23.oo - Also volles Risiko - Der Sprung ins kalte Wasser
Da ich die Methoden und Text-Zeilen für Versions-Upgrades bei den DOM-0 Updates und Upgrades alle aufgehoben / archiviert hatte, könnte es zügig gelingen.
Das finale Kriterium ist meine vorhandene mysql Datenbank und dieses "phpcs"- Reparatur-Programm. (Nachtrag : Den php-Converter "Rector" kannte ich da noch nicht.)
unseren www51 Test-Server von Leap 42.3 auf 15.0 upgraden
vorher in /etc/zypp/repos alles weglöschen
die 15.0 Repos anlegen :
zypper ar -n "openSUSE-15.0 OSS" download.opensuse.org/distribution/leap/15.0/repo/oss/ repo-15.0-oss
zypper ar -n "openSUSE-15.0 Non-OSS" download.opensuse.org/distribution/leap/15.0/repo/non-oss/ repo-15.0-non-oss
zypper ar -f -n "openSUSE-15.0 Updates OSS" download.opensuse.org/update/leap/15.0/oss/ repo-15.0-update-oss
zypper ar -f -n "openSUSE-15.0 Updates Non-OSS" download.opensuse.org/update/leap/15.0/non-oss/ repo-15.0-update-non-oss
und testen
zypper --releasever=15.0 lr -u
zypper --releasever=15.0 ref
zypper clean -a && zypper dup
Bildschirmanzeige :
The following 355 NEW packages are going to be installed:
The following 83 packages are going to be REMOVED:
The following 571 packages are going to be upgraded:
The following 180 packages are going to be downgraded:
The following product is going to be downgraded: "openSUSE Leap 42.3"
The following 6 packages are going to change architecture:
571 packages to upgrade, 180 to downgrade, 355 new, 83 to remove, 6 to change arch.
Overall download size: 592.9 MiB. Already cached: 0 B. After the operation, additional 996.4 MiB will be used.
Continue? [y/n/...? shows all options] (y):
und jetzt gehts los um 0 Uhr 55 - diesmal ging es verdammt schnell - in 40 Minuten
und wir haben die php 7.2 Version !
Probieren wir jetzt nochmal die Installation des "code-sniffers" ::
"pear install PHP_CodeSniffer-3.7.2"
WARNING: channel "pear.php.net" has updated its protocols, use "pear channel-update pear.php.net" to update
downloading PHP_CodeSniffer-3.7.2.tgz ...
Starting to download PHP_CodeSniffer-3.7.2.tgz (798,574 bytes)
...........................................................................................................done: 798,574 bytes
install ok: channel://pear.php.net/PHP_CodeSniffer-3.7.2
Der goldene Tip - einer von ganz wenigen guten Tips
und das geht auch :
pear channel-update pear.php.net
Updating channel "pear.php.net"
Update of Channel "pear.php.net" succeeded
Die bittere Wahrheit : Der verborgene und unerwartete Tip, daß die php 7.0.x Version(en) diverse Macken hatte(n) (und Suse einfach - vermutlich deshalb - kein "update auf 7.2 anbot), war Gold Wert und es war auch das Risiko wert, daß unsere mysql engine beim Upgrade hängt oder stirbt.
Die Upgraderei von opensuse nimmt bedenkliche Ausmaße an.
Die nächste Stufe kommt sogleich :
die 15.1 Repos anlegen
Bei der Übernahme auf Ihren Server immer die ganze Zeile markieren !!!!
.
- zypper ar -n "openSUSE-15.1 OSS" download.opensuse.org/distribution/leap/15.1/repo/oss/ repo-15.1-oss
- zypper ar -n "openSUSE-15.1 Non-OSS" download.opensuse.org/distribution/leap/15.1/repo/non-oss/ repo-15.1-non-oss
- zypper ar -f -n "openSUSE-15.1 Updates OSS" download.opensuse.org/update/leap/15.1/oss/ repo-15.1-update-oss
- zypper ar -f -n "openSUSE-15.1 Updates Non-OSS" download.opensuse.org/update/leap/15.1/non-oss/ repo-15.1-update-non-oss
und testen
zypper --releasever=15.1 lr -u
zypper --releasever=15.1 ref
zypper clean -a && zypper dup
Weiter geht es - bzw. fehlt noch :
Die halbautomatische Überarbeitung der alten php programme steht an
Die Chronik-05 mit der Wahrheit ist noch nicht fertig.
Und das kommt auf den Folgeseiten : Erfahrung mit Virtualisierung
Was spricht für XEN und gegen KVM ? Wie ist das mit den Containern und den Raw-Partitionen für neue DOM-U VMs auf NVMe Speichern ?
.