MODUL: Adminer Datenbank-Verwaltung im Backend

[Q]

[...]
Gibt es keinen horizontalen Scrollbalken? Mit den Pfeiltasten kann ich nach rechts scrollen.

Ja. 

[noRiddle (revilonetz)]

[...]
Da fragt sich jetzt natürlich,  da ja schon seit Ende 2018 PHP5 den Status "End of life" hat, ob man beim nächsten Shopupdate nicht die Mindestanforderung für PHP, auf sagen wir mal Version 7.1 setzen sollte, zumal wir seit Ende November 2020 bereits bei PHP8 angelangt sind, und man annehmen darf, siehe -> hier, dass mit dem nächsten Shopudate auch PHP8 unterstützt wird. Im hier geposteten konkreten Fall würde das bedeuten, dass man für die empfohlene Funktion "random_bytes() " , da sie in PHP7 immer vorhanden ist, keine Alternative braucht.

https://www.php.net/supported-versions.php

PS:
Das endlose Pflegen veralteter PHP-Versionen bindet meiner Meinung nach Entwickler-Ressourcen die man für wichtigeres und besseres einsetzen könnte.
[...]

Naja, da hast du sicherlich Recht, aber Entwickler-Ressourcen binden solch simple Fallbacks ja nun nicht wirklich.
Es gibt halt auch noch viele modified-User die auf billigem Shared-Hosting liegen und da weiß man nie..., muß das modified-Team entscheiden.

Gruß,
noRiddle

[D.L.]

Habe das Modul testweise über MMLC installieren wollen. Im Shop eines Kunden wie auch bei meinem Testshop gab es nach dem Download dann ne weisse Seite (ein PHP Error wurde dabei nicht erfasst).
Ursache war der offen gelassene PHP Tag in
/includes/extra/configure/hp_adminer_dba_tool.php
Nach dem Fix darin lief alles. Beide Shops laufen mit PHP 7.3.

[D.L.]

Die Ursache muss anderswo liegen, normalerweise sollten offene PHP Tags kein Problem sein, eher solche verhindern..

[hpzeller]

Hallo D.L.

Danke für die Info, aber bist du sicher, dass der offen gelassene PHP Tag die Ursache der weissen Seite war?
Ich frage das vor dem Hintergrund des folgenden Zitats, welches von hier -> https://www.php.net/manual/de/language.basic-syntax.phptags.php stammt.

Wenn eine Datei nur PHP-Code enthält, ist es besser, den schließenden PHP-Tag am Ende der Datei wegzulassen. Dies verhindert, dass versehentlich Leerzeichen oder neue Zeilen nach dem schließenden Tag eingefügt werden, was unerwünschte Effekte verursachen kann, da PHP mit der Ausgabe beginnt, obwohl der Programmierer an dieser Stelle des Skripts nicht die Absicht hat, eine Ausgabe zu senden.

Gruss
Hanspeter

[D.L.]

Hallo Hans Peter,
ja eben, der kann eigentlich nicht die Ursache darstellen.
Ganz klären konnte ich das noch nicht. Nach dem Löschen vom MMLC und erneuter Installation musste ich auch zunächst die .htaccess anpassen da auf einmal die index.php nicht mehr geladen wurde (404).

Schöne Grüsse - Daniel

[hpzeller]

Hallo D.L.,

sorry, ich hatte deine Antwort#18 noch nicht gelesen als ich meine Antwort#19 geschrieben habe.

Gruss
Hanspeter

[noRiddle (revilonetz)]

Auf meiner Test-Umgebung mit PHP 8 läuft die vorliegende Erweiterung anstandslos (ohne MMLC installiert).

Eine weiße Seite ohne Fehler in den Logs ist dubios.
D.L., schalte mal unter
Backend => Erw. Konfiguration => Logging Optionen
"Error Reporting" auf 'Admin'. Vielleicht gibt es dann Hinweise.

Gruß,
noRiddle

[RobinTheHood]

Guten Abend,

wenn ich eine Datei (nennen wir sie mal 'test.php') in /includes/extra/configure/ lege und in der Datei nur

Code: PHP  [Auswählen]

<?php

steht , ohne Leerzeichen oder Zeilenumbruch, gibt es einen Fehler, da 'require_once' diese Datei nicht laden kann. In /includes/configure.php in

Code: PHP  [Auswählen]

foreach(auto_include(DIR_FS_CATALOG.'includes/extra/configure/','php') as $file) require_once ($file);

Bei mir reicht es, einen Zeilenumbruch oder ein Leerzeichen in diese Datei hinzuzufügen oder schon gehts. Es könnte ein Bug in PHP selbst sein.

Mit besten Grüßen
Robin

[hpzeller]

Hallo Robin,

das ist sehr interessant was du schreibst, persönlich habe ich das Tool schon etliche male per MMLC mit PHP/7.4.25  installiert und dabei hat es immer funktioniert (also keine weisse Seite diesbezüglich), aber es könnte vielleicht auch an der PHP-Version liegen. Wenn ich deine Antwort richtig interpretiere, würde es, um das Problem zu beheben, genügen wenn in der Skriptdatei mindestens '<?php //'  anstatt '<?php' steht?

Gruss
Hanspeter

[RobinTheHood]

Hallo Hanspeter,

das sollte gehen, besser wäre ein Zeilenumbruch.

Den Bug gibt es bei mir in PHP 7.1, PHP 7.2 und PHP 7.3
(alle weiteren PHP Versionen habe ich nicht getestet)

So kann man es selbst ausprobieren, ohne MMLC und ohne modified:

file1.php

Code: PHP  [Auswählen]

<?php
require_once('file2.php');
echo 'test';

file2.php

Code: PHP  [Auswählen]

<?php

(Dahinter kein Leerzeichen und kein Zeilenumbruch)

Folgender Fehler kommt, wenn man file1.php aufruft:
Parse error: syntax error, unexpected end of file in .../file2.php on line 1

Sieht die file2.php wie folgt aus, kommt kein Fehler:

Code: PHP  [Auswählen]

<?php
// Zeilenumbruch

Im ersten Fall interpretiert der PHP Parser den Code so, als würde hinter <?php direkt etwas stehen, z. B. <?phpecho 'test'; hier würde es auch einen Fehler geben, da es zwischen <?php und echo 'test' kein Leerzeichen gibt. Der White-Space Character (Leerzeichen, Zeilenumbruch) hinter <?php scheint wichtig zu sein.

Mit besten Grüßen
Robin

[hpzeller]

Hallo Robin,

herzlichen Dank für deine Info.
Habe es getestet, mit PHP/7.2.34 und PHP/7.3.32 kommt es zum Fehler, mit PHP/7.4.25 und PHP/8.0.12 aber nicht.

Gruss
Hanspeter

[RobinTheHood]

Hallo Hanspeter,

sehr schön. Das ist ja auch interessant zu wissen.

Die ein schönes Wochenende
Robin

[noRiddle (revilonetz)]

Kannte ich auch noch nicht, interessante Info. Vielen Dank euch beiden.

Mit D.L.s Problem dürfte das allerdings nichts zu tun haben denke ich.
1. hat er keine Fehlermeldung und 2. ist das File um welches es geht doch nie leer, bzw. nicht mit lediglich einem öffnenden php-tag bestückt.

Gruß,
noRiddle

[RobinTheHood]

Hallo noRoddle,

das er/man keine Fehlermeldung bekommt liegt meiner Ansicht daran, dass der Fehler auftaucht, bevor das Error Reporting im Shop initialisiert wird. Da es sich um ein Syntax Error handelt, wird direkt nach dem Fehler die gesamte weitere Script-Ausführung abgebrochen und er/wir erhalten leider keine Ausgabe und kein Log.

/includes/application_top.php

Code: PHP  [Auswählen]

[...]

// set the level of error reporting
@ini_set('display_errors', false);
error_reporting(0);

// configuration parameters
if (file_exists('includes/local/configure.php')) {
  include_once ('includes/local/configure.php');
} else {
  include_once ('includes/configure.php'); <-- IN IDESER DATEI TRITT DER FEHLER AUF
}

[...]

// new error handling
if (is_file(DIR_WS_INCLUDES.'error_reporting.php')) {
  require_once (DIR_WS_INCLUDES.'error_reporting.php'); <-- HIER WIRD ERST DAS ERROR-REPORTING AKTIV
}

[...]

Auf Github hat die Datei nur ein <?php. Direkt nach der Installation, sollte nach meiner Meinung, der PHP Bug zum Tragen kommen, der gleichzeitig auch verhindert, dass das Error-Reporting korrekt initialisiert werden kann.

https://github.com/hpzeller/adminer-dba-tool/blob/master/new_files/includes/extra/configure/hp_adminer_dba_tool.php

Zum .htacces / index.php Problem habe ich keine Idee bis jetzt.

Mit besten Grüßen
Robin