PHP 7.4 support

MyOOS [Dumper]ist ein Sicherungsprogramm für MySQL-Datenbanken. Damit können Sicherungskopien der Daten (Forum, Shop, Blog, usw.) erstellt und bei Bedarf auch wieder hergestellt werden. Besonders bei Web-Space ohne Shell-Zugang bietet sich MyOOS [Dumper] als sinnvolle Alternative an.
r23
Beiträge: 2623
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

PHP 7.4 support

Beitrag von r23 »

Hallo,

mit der Veröffentlichung vom 14.09.2010 sollte MySQL Dumper auch mit PHP 7.4 funktionieren.

Dank geht an Feuer-sturm, der die Warnung einreichte.
https://github.com/r23/MyOOS/issues/8

Weitere Informationen über die heutige Veröffentlichung
viewforum.php?f=16

Aktuelle Versionen gibt es immer über GitHub
https://github.com/r23/MyOOS/releases

Viele Grüße

Ralf
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

Hi Ralf

Ich habe den kompletten MSD Source des aktuellen Releases 2.4.20 mal durch mein Prüfsystem geschickt. Dieses System habe ich eigentlich für phpBB Erweiterungen entwickelt und das System steuert mehrere Analysetools für die primären Bereiche phpBB und PHP sowie für die sekundären Bereiche CSS und JS. Aber mit einem undokumentierten Kniff kann man damit auch jedes beliebige PHP Projekt prüfen lassen.

Der Bericht zeigt auch deutlich, dass der gesamte Source eigentlich eine Grundsanierung bräuchte. Aber ich denke, dass ist für diejenigen die an aktuellen PHP Projekten arbeiten und MSD nutzen, eher keine neue Information. :wink:

Mich interessierte mehr wie es um die Kompatibilität der spezifischen PHP Versionen bestellt ist und wie es bei der cross-compatibility (ich weigere mich, das ins Deutsche zu übersetzen ^^) aussieht. Nach dem Bericht zu urteilen, sieht es hier richtig gut aus, zumindest bis einschliesslich 7.4. Ich kann momentan nicht höher testen, da das Modul für 8.0 des Analysetools noch nicht verfügbar ist.

Das was gemeldet wird, sind fast nur Schönheitsfehler, echte Fehler gibt es nur sehr wenige und die haben eher keinen Einfluss auf aktuelle MOD Installationen. Ich schau mir aber den Source an den entsprechenden Stellen genauer an und behebe die gemeldeten Fehler, damit wir hier ein durchgängig sauberes Ergebnis bekommen.
r23
Beiträge: 2623
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Re: PHP 7.4 support

Beitrag von r23 »

Hallo,
LukeWCS hat geschrieben: 21.02.2021, 15:57 Der Bericht zeigt auch deutlich, dass der gesamte Source eigentlich eine Grundsanierung bräuchte.
ja ... danke für den Test.
LukeWCS hat geschrieben: 21.02.2021, 15:57 Nach dem Bericht zu urteilen, sieht es hier richtig gut aus, zumindest bis einschließlich 7.4. Ich kann momentan nicht höher testen, da das Modul für 8.0 des Analysetools noch nicht verfügbar ist.
Die aktuellen IDEs von NetBeans und Eclipse IDE for PHP sehen zurzeit auch noch keine Probleme.
LukeWCS hat geschrieben: 21.02.2021, 15:57 Das was gemeldet wird, sind fast nur Schönheitsfehler
gerne beseitigen, wenn man die Möglichkeit hat.

Wenn die Aufgabe für einen zu viel wird, eben auch erklären, was wie gemacht werden muss... ich denke, man findet dann hier Hilfe bei der Umsetzung.

Schönes Wochenende

Ralf
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

Hi
r23 hat geschrieben: 21.02.2021, 19:54 Die aktuellen IDEs von NetBeans und Eclipse IDE for PHP sehen zurzeit auch noch keine Probleme.
NetBeans habe ich zwar ebenfalls installiert, mich aber noch nicht ausführlich damit beschäftigt. Für meine PHP Projekte nutze ich momentan noch lieber NP++, weil mir die Editor-Fähigkeiten von NetBeans zu eingeschränkt sind. Ansonsten bin ich auch IDEs gewöhnt, aber in Bezug auf Compilersprachen.
gerne beseitigen, wenn man die Möglichkeit hat.

Wenn die Aufgabe für einen zu viel wird, eben auch erklären, was wie gemacht werden muss... ich denke, man findet dann hier Hilfe bei der Umsetzung.
Hier mal einen Screenshot der Übersicht des besagten Berichts. Bei Interesse kann ich den vollständigen Bericht zur Verfügung stellen.

MOD 5.0.0-dev:
PicPick_2021-02-23_11-57-01.png
PicPick_2021-02-23_11-57-01.png (135.05 KiB) 8143 mal betrachtet
PSSE ist klar, dass betrifft primär die Struktur des Sources und der hat schon viele Jahre auf dem Buckel. Dazu kommt, das PSSE ein Regelsatz aus dem phpBB Umfeld ist und die Regeln sind recht streng. Genauer gesagt sind sie eigentlich moderat, aber Programmierer die es nicht gewöhnt sind mit Analysetools zu arbeiten, betrachten das eher als streng.

Was die Kompatibilität angeht: Im Prinzip sind das nur sehr wenige Fehler, die aber eben bei jeder PHP Version relevant sind. Manches ist simpel zu beheben, bei anderen Dingen muss ich erstmal genau verstehen, was da gemacht wird, bevor ich das korrigieren kann. Ich programmiere in PHP auch erst seit 2018.

Wenn man den Bericht im Detail anschaut, wird eine Frage besonders relevant: Bis zu welcher PHP Version müssen wir die Kompatibilität beachten? Laut meiner gestrigen Recherche, ist PHP 5 noch weiter verbreitet, als ich dachte. Auf jeden Fall sollte MOD noch mindestens 5.6 unterstützen, laut Statistik. Aber muss MOD auch noch ältere Versionen unterstützen? Bei phpBB zum Beispiel spielt PHP 5 keine (grosse) Rolle mehr, hier ist das Minimum bei PHP 7.1. Zumindest wenn phpBB 3.3 eingesetzt werden soll. Ich denke bei MOD müssen wir PHP <5.6 nicht mehr beachten, oder wie siehst du das?

Und was VariableAnalysis angeht: Nun, ich wollte aus der Source-Bereinigung jetzt keine Lebensaufgabe machen. :lol: Es würde schon genügen, wenn MOD einen ordentlichen Kompatibilitätsbericht vorweisen kann.

edit: Und zum Vergleich die Übersicht des Berichts zur letzten offiziellen Version von MySQLDumper.

MSD 1.24.4:
PicPick_2021-02-23_12-56-45.png
PicPick_2021-02-23_12-56-45.png (135.49 KiB) 8140 mal betrachtet
Das zeigt sehr deutlich welche Arbeit bereits in MOD steckt, insbesondere was die Kompatibilität angeht.
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

Die Einzelheiten der meisten Fehler sind soweit geklärt. Es gibt jedoch eine Sache, bei der ich Hilfe benötige bevor ich anfange:

Code: Alles auswählen

		else
		{
			if (ini_get('safe_mode') == 1)
			{
				$nextphase=( extension_loaded("ftp") ) ? 10 : 9;
			}
			else
				$nextphase=$phase + 2;
			echo $lang['L_INSTALL_STEP2FINISHED'];
			echo '<p>&nbsp;</p>';
			echo '<form action="install.php?language=' . $language . '&phase=' . $nextphase . '" method="post" name="continue"><input type="hidden" name="connstr" value="' . $connstr . '"><input class="Formbutton" style="width:360px;" type="submit" name="continue2" value=" ' . $lang['L_INSTALL_STEP2_1'] . ' "></form>';
			echo '<script language="javascript">';
			echo 'document.forms["continue"].submit();';
			echo '</script>';
		}
Die INI Direktive "safe_mode" ist laut Doku seit 5.3 veraltet und seit 5.4 entfernt. Das heisst im obigen Abschnitt wird das folgende effektiv gar nicht mehr ausgeführt:

Code: Alles auswählen

				$nextphase=( extension_loaded("ftp") ) ? 10 : 9;
Ich habe nie mit PHP 5.3/5.4 gearbeitet und von daher weiss ich nicht, wie man das behandeln soll. Auch darauf basiert meine Frage, ob wir 5.3/5.4 überhaupt noch berücksichtigen müssen.

edit: Der BBCode für "code" verhält sich hier sehr sonderbar, da stimmt wohl etwas nicht so ganz.
r23
Beiträge: 2623
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Re: PHP 7.4 support

Beitrag von r23 »

LukeWCS hat geschrieben: 23.02.2021, 17:35

Code: Alles auswählen

				$nextphase=( extension_loaded("ftp") ) ? 10 : 9;
Ich habe nie mit PHP 5.3/5.4 gearbeitet und von daher weiss ich nicht, wie man das behandeln soll. Auch darauf basiert meine Frage, ob wir 5.3/5.4 überhaupt noch berücksichtigen müssen.
MyOOS Dumper benötigt die Verzeichnisse ~/work ... sind diese nicht vorhanden - werden diese erstellt.

Unter Safemode konnte PHP keine Verzeichnisse erstellen (vereinfacht). Massenhoster hatten in der Regel Safemode aktiv.

Unter Savemode konnte PHP mit der FTP Erweiterung / Modul dann Verzeichnisse erstellen. Sollte die FTP Erweiterung nicht vorhanden sein, musste der Anwender die Verzeichnisse selber erstellen und diese mussten für PHP beschreibbar sein.

Der Safemode Bereich kann gelöscht werden. PHP Anwender mit alter PHP Version können die Original MySQL Dumper Version besser verwenden.

Der Hauptunterschied zwischen PHP 5.3 / 5.4 und PHP 5.6 ist die Verwendung von MYSQL in PHP.

Die Datenbank wurde vor 5.6 mit mysql
https://www.php.net/manual/de/book.mysql.php

oder einem der anderen Driver verbunden
https://www.php.net/manual/de/set.mysqlinfo.php

Mit 5.6. kam MySQLi https://www.php.net/manual/de/book.mysqli.php

Das Projekt kann nur MySQLi und hat keinen Bezug zu mysql. Alle Code Basis vor 5.6 kann gelöscht oder nicht beachtet werden.

Für < PHP 5.6 Anwender gab / gibt es die Original MySQL Dumper Version.

Die Analyse Tool Grafiken sehen sehr interessant aus...

Viele Grüße

Ralf
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

Moin Ralf ^^
r23 hat geschrieben: 23.02.2021, 21:52 Unter Savemode konnte PHP mit der FTP Erweiterung / Modul dann Verzeichnisse erstellen. Sollte die FTP Erweiterung nicht vorhanden sein, musste der Anwender die Verzeichnisse selber erstellen und diese mussten für PHP beschreibbar sein.
Das heisst, MSD hat die Ordner per FTP Login erstellt, weil der direkte Weg nicht ging. Trickreich, aber auch traurig das sowas mal notwendig war.
Der Safemode Bereich kann gelöscht werden.
Okay, das würde bedeuten, das man in install.php eigentlich die Abschnitte "case 9", "case 10" und "case 11" komplett entfernen könnte. Nach meinem letzten Beitrag habe ich einfach den Trigger für den kompletten safe-mode-Pfad der Installation stillgelegt, also auskommentiert. Gelöscht habe ich erstmal nüscht.
PHP Anwender mit alter PHP Version können die Original MySQL Dumper Version besser verwenden.
...
Für < PHP 5.6 Anwender gab / gibt es die Original MySQL Dumper Version.
Zu dieser Erkenntnis (und Hoffnung) kam ich nach meinem letzten Beitrag ebenfalls. Gut, dann kann man auch ein paar alte Zöpfe abschneiden. Den Fokus von MOD auf PHP 7 und 8 zu richten, ist eh sinnvoller.
Die Analyse Tool Grafiken sehen sehr interessant aus...
Manche Werkzeuge muss man sich selber schaffen. :)

Es gibt im Bericht prinzipiell nur 4 primäre Probleme was die Kompatibilität angeht. Die kommen dann teilweise mehrfach im Source vor. Vor deiner Antwort habe ich schon mal 2 Probleme behoben, die für mich zweifelsfrei waren. Nach deiner Antwort - mit Aha-Effekt - habe ich das dritte Problem behoben, also den "safe_mode" Pfad der Installation. Bleibt noch ein Problem übrig und das fällt unter Cross-Compatibility.

Aber mal vorab der aktuelle Stand nachdem die ersten 3 Probleme behoben waren:
PicPick_2021-02-24_00-30-53.png
PicPick_2021-02-24_00-30-53.png (79.66 KiB) 8125 mal betrachtet
Das letzte (4te) Problem betrifft "htmlspecialchars()". Das kommt sehr oft vor und hier fehlt überall die Kodierung. Kann ich das auf UTF-8 setzen, oder kann das Probleme machen? Dieser letzte Punkt ist aber jetzt auch nicht mehr so wichtig. Mit dem Ergebnis oben im Bild habe ich persönlich mein Ziel prinzipiell schon erreicht.
r23
Beiträge: 2623
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Re: PHP 7.4 support

Beitrag von r23 »

Hallo,
LukeWCS hat geschrieben: 24.02.2021, 00:58 Das heisst, MSD hat die Ordner per FTP Login erstellt, weil der direkte Weg nicht ging. Trickreich, aber auch traurig das sowas mal notwendig war.
Das Problem war einfach, dass du auf dem Server mal eben in fremden Installationen die Daten lesen konntest. Zum Beispiel haben alle PHP Installationen die Session in das Temp Verzeichnis geschrieben.

Durch den Safemode durften die Scripte nicht mehr endlos auf dem Server laufen. PHP durfte nur in einem gesicherten Verzeichnis bleiben.

Es war auf dem Server eine sinnvolle Erweiterung unter PHP 4.x. Und mit FTP auf dem Server was machen, war einfach cool.
LukeWCS hat geschrieben: 24.02.2021, 00:58 Okay, das würde bedeuten, das man in install.php eigentlich die Abschnitte "case 9", "case 10" und "case 11" komplett entfernen könnte.
ich denke ja...
LukeWCS hat geschrieben: 24.02.2021, 00:58 Manche Werkzeuge muss man sich selber schaffen. :)
.
Aber mal vorab der aktuelle Stand nachdem die ersten 3 Probleme behoben waren:
Sieht sehr gelungen aus...
LukeWCS hat geschrieben: 24.02.2021, 00:58 Das letzte (4te) Problem betrifft "htmlspecialchars()". Das kommt sehr oft vor und hier fehlt überall die Kodierung. Kann ich das auf UTF-8 setzen, oder kann das Probleme machen?
Hier im Team hatten wir mal einen russischen Entwickler. Er hatte mit UTF-8 Probleme und verwendete Windows-1252
https://de.wikipedia.org/wiki/Windows-1252

Ein Heidenspaß...

Das Projekt verwendet UTF-8.
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

r23 hat geschrieben: 24.02.2021, 02:00 Das Problem war einfach, dass du auf dem Server mal eben in fremden Installationen die Daten lesen konntest. Zum Beispiel haben alle PHP Installationen die Session in das Temp Verzeichnis geschrieben.

Durch den Safemode durften die Scripte nicht mehr endlos auf dem Server laufen. PHP durfte nur in einem gesicherten Verzeichnis bleiben.
Ja, diese Infos habe ich ansatzweise auch gefunden, als ich mich über den safe_mode informieren wollte. Wie wird das mit neueren PHP Versionen gelöst, also ab 5.4? Oder wird das heutzutage gar nicht mehr über PHP geregelt, sondern über den Server selbst? Ich hatte irgendwo die Info gelesen, dass das oben beschriebene Problem eigentlich nicht die Aufgabe von PHP sei. Ich konnte (kann) das nicht näher bewerten, weil mein erster Kontakt auf Seiten der Programmierung von PHP erst bei 5.6 war. Das heisst mein Kenntnisstand ist hier sehr oberflächlich/lückenhaft.
Hier im Team hatten wir mal einen russischen Entwickler. Er hatte mit UTF-8 Probleme und verwendete Windows-1252
https://de.wikipedia.org/wiki/Windows-1252

Ein Heidenspaß...


Glaube ich sofort. Vor allem Programmierer die schon seit Jahrzehnten programmieren, dürften Kodierungprobleme zur Genüge kennen. Ich habe übrigens auch die Fünf vorne dran, wie du. :wink: Viele Programmiersprachen, viele Plattformen, viele Einsatzgebiete und schlussendlich schlicht Software-Evolution, weil sich alles rasant weiterentwickelt. Da sind Kodierungsprobleme immer allgegenwärtig.

Also lieber nicht UFT-8 setzen? Es wurde übrigens durchaus auch bei MSD schon direkt UFT-8 definiert und zwar im SQL-Browser Code.


Für diejenigen die hier mitlesen: Damit kein falscher Eindruck entsteht, wiederhole ich nochmal was ich zu Beginn geschrieben habe:
Das was gemeldet wird, sind fast nur Schönheitsfehler, echte Fehler gibt es nur sehr wenige und die haben eher keinen Einfluss auf aktuelle MOD Installationen.
Die eigentliche Arbeit bezüglich Kompatibilität wurde längst geleistet, von Ralf und anderen. Was wir hier noch besprechen, ist schlicht "Kleinkram", quasi Jammern auf hohem Niveau. Meine Motivation hier ist einfach, im Testbericht im Bereich Kompatibilität ein vollständig "grünes" Ergebnis zu bekommen. Technisch notwendig ist das aber Stand heute nicht.
r23
Beiträge: 2623
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Re: PHP 7.4 support

Beitrag von r23 »

LukeWCS hat geschrieben: 24.02.2021, 12:06 Ja, diese Infos habe ich ansatzweise auch gefunden, als ich mich über den safe_mode informieren wollte. Wie wird das mit neueren PHP Versionen gelöst, also ab 5.4? Oder wird das heutzutage gar nicht mehr über PHP geregelt, sondern über den Server selbst? Ich hatte irgendwo die Info gelesen, dass das oben beschriebene Problem eigentlich nicht die Aufgabe von PHP sei. Ich konnte (kann) das nicht näher bewerten, weil mein erster Kontakt auf Seiten der Programmierung von PHP erst bei 5.6 war. Das heisst mein Kenntnisstand ist hier sehr oberflächlich/lückenhaft.
Mit PHP 5 kam Sicherheit in das System. Zumindest wurde mehr über Sicherheit gesprochen. PHP war oft auch noch ein Apache Model. Wenn man dort einen Fehler im PHP Script hatte, schoss man nicht nur die PHP Anwendung ab, sondern gleich den Server mit. Wir hatten zum Beispiel in einem Script einen Counter eingebaut, dieser zählte wie oft eine Seite (Datensatz) aufgerufen wurde. :)

Der Systemadmin von einem Massenhoster rief den Kunden an und sagte: Dies geht so nicht, Sie schreiben in der Stunde über 1500 mal in die Datenbank... und dann noch mit einem UPDATE...

Da PHP selbst keine SESSION kannte - entwickelten zwei namhafte Entwickler eine PHP Klasse.... Es war zu der Zeit üblich, dass man im Kassenbereich schon mal die Daten von Dritten sah: "Sind Sie nicht Luke? Melden Sie sich hier an?" lol...

Kristian Köhntopp schrieb damals in die PHP FAQs der Newsgroup
safe_mode ist nicht sicher: Ein Fehler in der popen() -Funktion ist erst mit 3.0.14 korrigiert worden, ein weiterer Fehler in der mail() -Funktion erst in 3.0.15. Spätere Versionen von PHP hatten weitere Lücken. Man sollte stattdessen die CGI-Version in einem chroot-Environment verwenden und mit setrlimit noch weitergehende Einschränkungen definieren.
http://www.php-faq.de/q-konfiguration-safe-mode.html

LukeWCS hat geschrieben: 24.02.2021, 12:06 Also lieber nicht UFT-8 setzen? Es wurde übrigens durchaus auch bei MSD schon direkt UFT-8 definiert und zwar im SQL-Browser Code.
Nein wir verwenden UTF-8 ...

Smarty verwendet

bei case 'integer': case 'float':

Code: Alles auswählen

            $results = htmlspecialchars((string)$var);
und bei case 'string':

Code: Alles auswählen

            $results = htmlspecialchars('"' . $results . '"', ENT_QUOTES, Smarty::$_CHARSET);
Zeile ab 71
https://github.com/r23/MyOOS/blob/maste ... nt_var.php


In Zeile 182
https://github.com/r23/MyOOS/blob/maste ... .class.php

Code: Alles auswählen

    public static $_CHARSET = SMARTY_RESOURCE_CHAR_SET;

Dies hat natürlich etwas ...

LukeWCS hat geschrieben: 24.02.2021, 12:06 Meine Motivation hier ist einfach, im Testbericht im Bereich Kompatibilität ein vollständig "grünes" Ergebnis zu bekommen. Technisch notwendig ist das aber Stand heute nicht.
Überhaupt kein Problem. Das Thema hat etwas mit Qualität zu tun. Das Projekt hat einen HOHEN Qualitätsanspruch. Auch, wenn wir diesen zurzeit nicht überall erfüllen. Das System ist ja im produktiven Einsatz. D.h. wenn ein Kunde bei mir einen Blog haben möchte, suche ich nicht lange rum, sondern verwende das Projekt hier.

Beispiel. Mein typischer Kunde hier weiß gar nicht, ob er überhaupt Internet kann. Schreiben für das Internet ist nicht alle eine Erfüllung. Auch der Distanzhandel funktioniert nicht für jeden. Für diesen Kunden erstellen wir in wenigen Minuten eine Umgebung - und sichern unsere Installation mit MYOOS Dumper. Der Kunde kann in alle Ruhe ausprobieren, die Seite zerschießen... egal... er kann mit dem MYOOS Dumper eben den kostenpflichtigen Zustand ohne Kostenaufwand selber wiederherstellen. (lassen)

So funktioniert dies in den letzten Jahren so - so wird es hoffentlich in den nächsten Jahren funktionieren.

und in ein paar Wochen hat er auch einen Online-Shop , der verkauft.

Ich freue mich über Verbesserungen. *immer*

Danke für den Bericht per Mail. habe ich erhalten und lese mich ein.

Beste Grüße

Ralf
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

Bezüglich safe_mode habe ich jetzt testweise nicht nur den Trigger, sondern gleich den kompletten Pfad stillgelegt und einige Tests ausgeführt. Also jeden Code deaktiviert, der unmittelbar vom safe_mode Trigger abhängig ist. Dann habe ich zwei Situationen bei der Installation simuliert:

  • Schreiben in config.php nicht möglich
  • Anlegen der Verzeichnisse nicht möglich
In allen Fällen werden trotz deaktiviertem safe_mode Pfad entsprechende Fehlermeldungen seitens MOD ausgegeben. Also wie erwartet, da die entsprechenden Code Stellen auch danach aussahen. Aber Theorie und Praxis sind immer zwei verschiedene Dinge, insbesondere bei fremden Programmen die man nicht selbst geschrieben hat. Darum Tests durchgeführt.

Dabei ist ein weiterer PHP Fehler in Erscheinung getreten und der Fehler war schon bei MSD vorhanden: Wenn das Schreiben in die config.php nicht möglich ist, sollte eine entsprechende Fehlermeldung erscheinen. Da erscheint auch eine, allerdings nicht die, die beabsichtigt war, sondern direkt ein PHP Fehler. Der Grund ist eine Sprachvariable die gar nicht existiert. Aber das zeigt, dass die Probleme bei der Installation bezüglich Schreibrechte wohl wirklich der Vergangenheit angehören, denn sonst hätte das schon längst jemandem auffallen müssen.
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

PR #16 (für MOD 5.0.1) hat jetzt folgenden Stand:
PicPick_2021-02-25_18-42-55.png
PicPick_2021-02-25_18-42-55.png (79.83 KiB) 8065 mal betrachtet
Zum Vergleich der Stand davor:
PicPick_2021-02-23_11-57-01_.png
PicPick_2021-02-23_11-57-01_.png (120 KiB) 8065 mal betrachtet
r23
Beiträge: 2623
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Re: PHP 7.4 support

Beitrag von r23 »

LukeWCS hat geschrieben: 25.02.2021, 12:00 Aber Theorie und Praxis sind immer zwei verschiedene Dinge
Herzlichen Dank für die Optimierungen und Verbesserungen. Ich habe diese eben in das Projekt übernommen und werde am Freitag 26.02 die neue Version veröffentlichen.

Wunderbare Arbeit!

Viele Grüße

Ralf
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

Alles klar. :)

Warte mit dem Update noch. Ich habe einen weiteren PHP Fehler entdeckt. Versuch mal im SQL-Browser die Suche zu benutzen... Ist bereits behoben, ich schau was ich sonst noch finde. Ansonsten gibts morgen früh einen Mini-PR mit dem Fix für die SQL Suche. :wink:
LukeWCS
Beiträge: 34
Registriert: 01.02.2021, 14:45

Re: PHP 7.4 support

Beitrag von LukeWCS »

Guten Morgen (gilt noch knapp ^^)

Als Ergänzung zum PR: in den Releases ist im msd Ordner der Projektordner von NetBeans enthalten, der gehört eigentlich nicht zum MOD Paket und sollte über .gitignore ausgeschlossen werden. Ein solcher Eintrag existiert zwar schon, der bezieht sich jedoch nur auf einen Unterordner des NB Ordners.
Antworten