PHP Documentation Bug?

[TS]

Hello,

ich bin mir jetzt nicht sicher, ob ich die Ungenauigkeit in der Doku als Bug melden sollte. Außerdem ist mir das Meldeverfahren zu kompliziert :-O

Für die Funktion date() wird unter datetime.format der Parameter 'I' (Capital I) mit den Rückgabewerten 1 oder 0 beschrieben. Es wird aber ein String '1' oder '0' zurückgegeben, was durchaus zu Fehlern in der Auswertung führen kann.

Ich habe mich zumindest erst gewundert, dass meine str_mez()-Funktion nicht funktionieren wollte, weil ich den Vergleich mit '===' durchgeführt hatte.

Ist schon kompilziert genug, die Parameter zu finden. Früher standen die direkt bei date().

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

nein, das ist kein Bug in der Doku, nur in deinem Verständnis der Funktion.

date(string $format, ?int $timestamp = null): string

date_format(DateTimeInterface $object, string $format): string

D.h. es kommt immer ein String zurück, und in allen Beispielen steht es ohne Anführungszeichen.

Es muss aber auch ein String sein, wie sonst sollen kombinierte Formate wie "d.M.Y" funktionieren? Du kannst nicht erwarten, dass die Rückgabe je nach Formatsymbol eine Zahl oder ein String ist.

Rolf

[MudGuard]

Hi,

Du kannst nicht erwarten, dass die Rückgabe je nach Formatsymbol eine Zahl oder ein String ist.

Gibt doch genügend PHP-Funktionen, die je nach Situation unterschiedliche Typen zurückgeben.

Ein häufiger Fall ist, daß im Fehlerfall ein boolean (false) geliefert wird, im Normalfall ein Objekt (z.B. bei den mysqli-Funktionen, die entweder false liefern oder die gefundenen Zeilen).

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo MudGuard,

<typeXY> | false

was ebenfalls ein Hirnfurz ist, der sich nur durch die Historie entschuldigen lässt. Das schlimmste sind ja die APIs, bei denen im <typeXY>-Typ falsy-Werte enthalten sind.

Letztlich ist das ein der Performance geschuldetes Erbe aus den 60ern.

Ein sauberes API sollte genau einen Rückgabetyp haben, und wenn sich Fehlerwerte nicht als typgerechte Rückgabe formulieren lassen, dann muss es halt eine Exception sein (die es früher in PHP nicht gab), ein out-Parameter (auch nicht wirklich sauber), oder eine Rückgabestruktur mit Success-Code und Rückgabewert. Kostet alles mehr oder weniger Performance, ja. Aber das ist ein Argument, das mindestens 30 Jahre hinter seiner Zeit ist.

Das gilt auch für null: The Billion Dollar Mistake

Rolf

[MudGuard]

Hi,

<typeXY> | false

was ebenfalls ein Hirnfurz ist,

ich hab nicht gesagt, daß ich das gut finde.

Aber dadurch sind PHPler trainiert, auf verschiedene Rückgabetypen zu reagieren …

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@Rolf B

<typeXY> | false

was ebenfalls ein Hirnfurz ist, der sich nur durch die Historie entschuldigen lässt.

Solchen oder gar noch schlimmeren Hirnfurz gibt es auch in jQuery:

console.log(typeof $('html').attr('lang', 'tlh')); // "object"
console.log(typeof $('html').attr('lang'));        // "string"

Und der lässt sich nicht durch Historie entschuldigen.

😷 LLAP

[Rolf B]

Hallo Gunnar,

nein, da bist Du im Irrtum.

Methodenüberladung

Meine Kritik wäre hier eigentlich nur, dass man durch Zuweisen von null ein Synonym zur removeAttr Methode geschaffen hat. Das ist schwammig.

Ansonsten ist es durchaus gängig, dass getter den gewünschten Wert liefern und setter-Methoden ihr this, um Chaining zu ermöglichen.

Rolf

[Gunnar Bittersmann]

@@Rolf B

nein, da bist Du im Irrtum.

Methodenüberladung

Nein, kein Irrtum. Ich halte die Methodenüberladung in jQuery für Hirnfurz.

Ansonsten ist es durchaus gängig, dass getter den gewünschten Wert liefern und setter-Methoden ihr this, um Chaining zu ermöglichen.

Es ist aber nicht gängig, Getter und Setter gleich zu benennen.

😷 LLAP

[Rolf B]

Hallo Gunnar,

welche Benennung von Gettern und Settern in welchen Sprachen idiomatisch ist, da kann ich nicht hinreichend mitreden. In jQuery hat mich diese Überladung nie gestört.

• In C# gibt es eine eigene getter/setter-Notation, so dass der Gebrauch aussieht als würde ich ein Field lesen oder schreiben.
• In Java sind get... und set... Methoden üblich.
• In PHP - hm. Eigentlich sollte das PSR-12 adressieren, tut es aber nicht.
• In JavaScript kann ich über einen property descriptor Ähnliches erreichen. jQuery tut das nicht, weil es dann für jedes denkbare Attribut ein JS Property erzeugen müsste.
• Observables in knockout.js liefern bei Aufruf ohne Argument den Wert (getter) und bei Aufruf mit Argument ändern sie den Wert (setter)

Und da hört's bei mir dann auf.

Rolf

[dedlfix]

Tach!

Gibt doch genügend PHP-Funktionen, die je nach Situation unterschiedliche Typen zurückgeben.

Welche Funktionen betrifft das denn außer dem boolean für Fehlerzustände?

dedlfix.

[dedlfix]

Tach!

Ich habe mich zumindest erst gewundert, dass meine str_mez()-Funktion nicht funktionieren wollte, weil ich den Vergleich mit '===' durchgeführt hatte.

Welchen Grund gab es denn für die extra Typsicherheit?

dedlfix.

[TS]

Hello,

Ich habe mich zumindest erst gewundert, dass meine str_mez()-Funktion nicht funktionieren wollte, weil ich den Vergleich mit '===' durchgeführt hatte.

Welchen Grund gab es denn für die extra Typsicherheit?

antrainierte Paranoia?

Glück Auf
Tom vom Berg

[TS]

Hello,

und noch ein Hirnfurz...

Ich bekomme es einfach nicht mehr hin, dass mir mein PHP 7.4.3 Modulversion im Apachen Fehlermeldungen auf dem Bildschirm anzeigt.

Was habe ich bisher noch nicht gefunden? Wo muss ich fummeln?

<?php  ### errors.php ###

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL | E_STRICT);

echo "Fehlerbehandlung"; 

1 = 5;

?>

Der Parse-Error wird zwar brav ins error_log geschrieben, aber auf den Schirm bekomme ich ihn nicht.

In der .htaccess habe ich es auch schon versucht.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Ich bekomme es einfach nicht mehr hin, dass mir mein PHP 7.4.3 Modulversion im Apachen Fehlermeldungen auf dem Bildschirm anzeigt.

Probier es mit Laufzeitfehlern.

Was habe ich bisher noch nicht gefunden? Wo muss ich fummeln?

Bei Fehlern, die vor dem Scriptstart auftreten, wie solche Syntaxfehler in der Parse-Phase, gibt es keine Ausgabe, nur einen PHP-ErrorLog-Eintrag und das was dein Apache bei einem 500er ausgibt.

dedlfix.

[TS]

Hello,

Ich bekomme es einfach nicht mehr hin, dass mir mein PHP 7.4.3 Modulversion im Apachen Fehlermeldungen auf dem Bildschirm anzeigt.

Probier es mit Laufzeitfehlern.

Die werden angezeigt.
ein $counter++ auf einen vorher nicht initialisierten $counter gibt bei aktivierter Ausgabe eine Notice im Display.

Was habe ich bisher noch nicht gefunden? Wo muss ich fummeln?

Bei Fehlern, die vor dem Scriptstart auftreten, wie solche Syntaxfehler in der Parse-Phase, gibt es keine Ausgabe, nur einen PHP-ErrorLog-Eintrag und das was dein Apache bei einem 500er ausgibt.

Bei welchem Versionswechsel ist das denn geändert worden?

Dann kann man jetzt also PHP flüssig nur noch mit Zweischirmlösung oder mit IDE entwickeln.

Kaum guckt man/fra mal eine Pandemie lang nicht hin, schon funktioniert nichts mehr so wie früher :-O

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

weiß nicht, ob das hilft, aber du könntest die display_startup_errors Meldung über .htaccess oder direktes Editieren der PHP.INI setzen. Wenn Du sie mit ini_set setzt, kommt sie bei einem Parse-Error nicht zum Zuge, weil PHP das Script gar nicht erst startet.

Eine weitere Möglichkeit ist, das Hauptscript so schlank wie irgend möglich zu halten und den größten Teil per include reinzuziehen. Dann fallen Parse-Fehler erst auf, wenn der include ausgeführt wird.

Ich wollte das gerade bei mir etwas nachstellen (FastCGI PHP unter IIS), aber aus irgendeinem verrückten Grund setzt der mir display_errors immer auf On, egal was ich in die .ini schreiben (ja, es ist die richtige .ini, ja, die Zeilen sind nicht auskommentiert und ja, ich habe den FastCGI-Prozess neu gestartet). Selbst ein Miniscript, das außer phpinfo() nichts tut, hat display_errors auf On. Der Master Value folgt der Einstellung in php.ini, wenn ich ändere, aber der Local Value bleibt On. Whut? Hab jetzt keine Zeit, danach zu suchen.

Update:
user_ini.filename = ".user.ini"

ARGH - da hatte ich mal mit gespielt.

Rolf

[dedlfix]

Tach!

user_ini.filename = ".user.ini"

Ja, die .user.ini ist eine Möglichkeit, Werte zu ändern, die aber bei der Ausführung als Apache-Modul nicht zur Verfügung steht. Da geht nur die .htaccess als Per-Dir-Konfiguration.

Generell sollte man aber versuchen, PHP nicht als Apache-Modul laufen zu lassen. Es gibt mit FPM eine gute Alternative, die getrennte Prozesse und damit auch getrennte Nutzer bei der Ausführung unterschiedlicher Projekte erlaubt.

dedlfix.

[dedlfix]

Tach!

Bei Fehlern, die vor dem Scriptstart auftreten, wie solche Syntaxfehler in der Parse-Phase, gibt es keine Ausgabe, nur einen PHP-ErrorLog-Eintrag und das was dein Apache bei einem 500er ausgibt.

Das wollte ich eigentlich anders sagen: Es gibt keine Möglichkeit, die Ausgabe im Script zu beeinflussen, weil es ja wegen des Syntaxfehlers gar nicht zum Laufen kommt. Anders ist das bei Fehlern in include-Dateien, deren Code ja erst zur Laufzeit hinzugefügt wird. Da können vor dem include ausgeführte Konfigurationsanweisungen wirken.

Ich hab mich auch etwas verwirren lassen. Fehlermeldungen zur Syntax werden weiterhin ausgegeben. Der 500er, den ich sah, kam von den Anweisungen in der .htaccess. Ohne diese gab es problemlos eine Anzeige des Syntaxfehlers, weil meine php.ini entsprechend konfiguriert war.

dedlfix.

[dedlfix]

Tach!

Ich hab mich auch etwas verwirren lassen. Fehlermeldungen zur Syntax werden weiterhin ausgegeben. Der 500er, den ich sah, kam von den Anweisungen in der .htaccess. Ohne diese gab es problemlos eine Anzeige des Syntaxfehlers, weil meine php.ini entsprechend konfiguriert war.

Nachtrag: In der .htaccess muss man on/off statt 0/1 schreiben, sonst gibt es den besagten 500er.

dedlfix.

[Rolf B]

Hallo dedlfix,

im IIS geht's nicht, aber der Apache hat doch in der .htaccess die Möglichkeit, PHP.INI Einstellungen zu überschreiben, oder?

Ein php_flag display_startup_errors on sollte dann doch eigentlich greifen und keinen HTTP 500 auslösen. DEN sollte es erst beim Start von PHP geben, dann aber mit Anzeige des Errors.

Wie macht der Häuptling das eigentlich? Generiert der eine temporäre .user.ini?

Unter Windows hab ich gerade gesehen, dass man in der Registry PHP Settings pro Pfad unterbringen kann. Urgh - sehr gut versteckt.

Rolf

[dedlfix]

Tach!

Wie macht der Häuptling das eigentlich? Generiert der eine temporäre .user.ini?

Nein, die .user.ini kam erst viel später auf, weil man auch als CGI-Ausführung eine Konfiguration per Dir haben wollte. Als CGI-Konfiguration hatte man nur die globale php.ini oder diejenige im Verzeichnis des Startscripts.

Der Unterschied zwischen php.ini und .user.ini ist, dass alle .user.ini-Dateien vom Startverzeichnis bis zum DocumentRoot berücksichtigt werden. Von der php.ini wird nur das Exemplar im Startverzeichnis gelesen (oder die globale, wenn keine lokale existiert).

Im Apachen kann man PHP als Modul oder als externes CGI ausführen lassen. Im IIS geht nur CGI. Wie genau der Apache die .htaccess-Konfiguration an den PHP-Teil weitergibt, entzieht sich meiner Kenntnis, ist aber auch nicht weiter relevant.

dedlfix.

[Rolf B]

Hallo Tom,

als weitere Option zur .htaccess:

Überprüf mal mit phpinfo() deine Einstellung für user_ini.filename. Wenn da ein Dateiname drinsteht (Default ist .user.ini), kannst Du damit eine INI Datei festlegen, die zusätzlich zur zentralen php.ini einbezogen wird. PHP sucht die in dem Ordner, aus dem es das PHP Script lädt, und von da an in der Verzeichnishierarchie nach oben bis zum DOCUMENT_ROOT der Webseite (hab ich ja gerade leidvoll erfahren).

Eine user.ini zum Debuggen sähe so aus:

error_reporting = E_ALL
display_errors = On
display_startup_errors = On

Man muss dann ggf. noch user_ini.cache_ttl verkleinern (also die Zeit in Sekunden, die PHP die user.ini cached). Der Default ist 300, also 5 Minuten, und das ist etwas viel für kurzfristige Änderungen.

Dann kann man jetzt also PHP flüssig nur noch mit Zweischirmlösung oder mit IDE entwickeln.

Zitat 2546

Also ja, mit Betonung auf flüssig. Zwei Schirme sind nicht unbedingt erforderlich, ein einzelner 32:10 Bildschirm mit 42 Zoll tut's auch 😉. Spaß beiseite, ein einzelner Schirm sollte auch gehen, es wird nur unübersichtlich. Auf einem Tablet würde ich es nicht versuchen wollen. Eine IDE ist aber immer eine gute Idee. VS Code ist sehr zu empfehlen (bzw. es gibt auch Derivate davon ohne MS Telemetrie).

Ich muss hier für mich jetzt nur endlich mal versuchen, den PHP Debugger ans Laufen zu bekommen, daran bin ich bisher immer gescheitert und debugge per verbose logging…

Rolf

[dedlfix]

Tach!

als weitere Option zur .htaccess:

Überprüf mal mit phpinfo() deine Einstellung für user_ini.filename.

Das ist exklusiv. Entweder PHP als Apache-Modul, dann .htaccess, oder PHP als CGI, dann .user.ini (oder php.ini im Verzeichnis).

dedlfix.

[TS]

Hello,

ein Pluspunkt nachträglich für das Zitat.

Aber bitte nicht vergessen:
auch viele kleine und sehr kleine "Bildschirme" sollten neben dem Entwicklerplatz liegen...

Glück Auf
Tom vom Berg

[TS]

Hello Dedlfix,

Ich bekomme es einfach nicht mehr hin, dass mir mein PHP 7.4.3 Modulversion im Apachen Fehlermeldungen auf dem Bildschirm anzeigt.

Probier es mit Laufzeitfehlern.

Was habe ich bisher noch nicht gefunden? Wo muss ich fummeln?

Bei Fehlern, die vor dem Scriptstart auftreten, wie solche Syntaxfehler in der Parse-Phase, gibt es keine Ausgabe, nur einen PHP-ErrorLog-Eintrag und das was dein Apache bei einem 500er ausgibt.

Mit der Einstellung

  php_value error_reporting 32767

in der Konfiguration (z. B. .htaccess) werden auch die Parse-Errors angezeigt:

 Parse error: syntax error, unexpected '=' in /var/www/html/errors.php on line 9

Siehe Wiki PHP Error Reporting

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

die 64 (E_COMPILE_ERROR) tut's vermutlich auch.

32767 = 111111111111111   E_ALL
   64 = 000000001000000   E_COMPILE_ERROR

Rolf

[TS]

Hello Rolf,

die 64 (E_COMPILE_ERROR) tut's vermutlich auch.

32767 = 111111111111111   E_ALL
   64 = 000000001000000   E_COMPILE_ERROR

Ich hätte das auch vermutet. Aber leider bleibt da die Seite weiß.
Es muss also noch einen Schalter geben, der dafür verantwortlich ist.

Oder unwahrscheinlich: das Errorsystem hat einen Bug ;-P

Glück Auf
Tom vom Berg

[TS]

Hello,

die 64 (E_COMPILE_ERROR) tut's vermutlich auch.

32767 = 111111111111111   E_ALL
   64 = 000000001000000   E_COMPILE_ERROR

Ich hätte das auch vermutet. Aber leider bleibt da die Seite weiß.
Es muss also noch einen Schalter geben, der dafür verantwortlich ist.

Oder unwahrscheinlich: das Errorsystem hat einen Bug ;-P

Es reicht die

4 = 000000000000100    E_PARSE (int) 	
                       Compile-time parse errors. Parse errors 
                       should only be generated by the parser. 

Ich habe die "Versuchsanordnung" noch bereit. Da werde ich es für die Debug-Empfehlungen noch weiter sortieren.

Nur die Parse-Errors anzeigen zu lassen, ist mMn ziemlich unsinnig.

Schöner wäre es, wirklich alle Fehler vor dem Produktivbetrieb finden zu können. Nur das ist vermutlich nicht möglich, ohne die Anwendung mit allen Varianten vorher komplett durchzuspielen.

Ich würde mich freuen, wenn wir das Thema fürs Wiki deshalb noch zuende bearbeiten könnten, soweit das überhaupt möglich ist.

Was ich damit meine: welche Einstellung sollte man im Produktivbetrieb beibehalten? Es wäre ja auch unsinnig, vorhersehbare (provozierte) Fehler ins Log schreiben zu lassen, die ohnehin im Programm abgefangen werden sollten: z. B. Locking, Anlegen und Löschen von Dateien, usw.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Schöner wäre es, wirklich alle Fehler vor dem Produktivbetrieb finden zu können. Nur das ist vermutlich nicht möglich, ohne die Anwendung mit allen Varianten vorher komplett durchzuspielen.

Selbst dann nicht, denn Laufzeitfehler, wie nicht erreichbare Datenbank, kann man nicht ausschließen.

Man muss schon wissen (oder nachlesen), welche Laufzeitfehler auftreten können, und eine Strategie zum Behandeln solcher Fehler erstellen.

Was ich damit meine: welche Einstellung sollte man im Produktivbetrieb beibehalten?

Es gibt je eine php.ini für die Entwicklung und für Produktion, die man einfach nehmen kann. Die relevanten Direktiven sind darin auch sehr gut erklärt.

Es wäre ja auch unsinnig, vorhersehbare (provozierte) Fehler ins Log schreiben zu lassen, die ohnehin im Programm abgefangen werden sollten: z. B. Locking, Anlegen und Löschen von Dateien, usw.

Für den Fall vorhersehbarer Meldungen, die man trotz Behandlung nicht wegbekommt, gibt es den @-Operator.

dedlfix.

[TS]

Hello,

Schöner wäre es, wirklich alle Fehler vor dem Produktivbetrieb finden zu können. Nur das ist vermutlich nicht möglich, ohne die Anwendung mit allen Varianten vorher komplett durchzuspielen.

Selbst dann nicht, denn Laufzeitfehler, wie nicht erreichbare Datenbank, kann man nicht ausschließen.

Das kann man aber vorhersehen und daher abfangen!

Man muss schon wissen (oder nachlesen), welche Laufzeitfehler auftreten können, und eine Strategie zum Behandeln solcher Fehler erstellen.

Genau. Sag ich doch. Dafür benötigt es eine Ideen-Hilfe, an was man bei der Programmierung denken sollte.

Was ich damit meine: welche Einstellung sollte man im Produktivbetrieb beibehalten?

Es gibt je eine php.ini für die Entwicklung und für Produktion, die man einfach nehmen kann. Die relevanten Direktiven sind darin auch sehr gut erklärt.

(Links?) Muss ich mir genauer ansehen, in wieweit es auch Programmierempfehlungen dafür im Netz (und in unserem Wiki) gibt, um diese Möglichkeiten optimal nutzen zu können.

Es wäre ja auch unsinnig, vorhersehbare (provozierte) Fehler ins Log schreiben zu lassen, die ohnehin im Programm abgefangen werden sollten: z. B. Locking, Anlegen und Löschen von Dateien, usw.

Für den Fall vorhersehbarer Meldungen, die man trotz Behandlung nicht wegbekommt, gibt es den @-Operator.

Lies bitte erst einmal genauer, bevor Du antwortest.

Glück Auf
Tom vom Berg

[dedlfix]

Tach!

Man muss schon wissen (oder nachlesen), welche Laufzeitfehler auftreten können, und eine Strategie zum Behandeln solcher Fehler erstellen.

Genau. Sag ich doch. Dafür benötigt es eine Ideen-Hilfe, an was man bei der Programmierung denken sollte.

Einfach zusammengefasst: Beschreibung der Funktionen lesen, insbesondere die möglichen Rückgabewerte und das Verhalten in Ausnahmefehlern.

Es gibt je eine php.ini für die Entwicklung und für Produktion, die man einfach nehmen kann. Die relevanten Direktiven sind darin auch sehr gut erklärt.

(Links?)

Jede übliche PHP-Installation.

Lies bitte erst einmal genauer, bevor Du antwortest.

Sehr guter Tipp. Woran erkenne ich, ob ich genau genug gelesen habe?

dedlfix.

[TS]

Hello,

Einfach zusammengefasst: Beschreibung der Funktionen lesen, insbesondere die möglichen Rückgabewerte und das Verhalten in Ausnahmefehlern.

Das reicht leider nicht. Man muss sich auch die textuellen Meldungen für jeden Fehlerfall beschaffen, um ihn qualifiziert behandeln zu können.

Lies bitte erst einmal genauer, bevor Du antwortest.

Sehr guter Tipp. Woran erkenne ich, ob ich genau genug gelesen habe?

Ich bitte um Verzeihung. Mein explizites Beispiel zum Text kam erst nach deinem Posting.

Aber als Profi hättest Du auch schon ohne Beispiel wissen können, was ich mit

Was ich damit meine: welche Einstellung sollte man im  
Produktivbetrieb beibehalten? Es wäre ja auch unsinnig,  
vorhersehbare (provozierte) Fehler ins Log schreiben zu  
lassen, die ohnehin im Programm abgefangen werden sollten:  
z. B. Locking, Anlegen und Löschen von Dateien, usw.  

gemeint habe ;-P

Glück Auf
Tom vom Berg

[TS]

Hello,

(Links?) Muss ich mir genauer ansehen, in wieweit es auch Programmierempfehlungen dafür im Netz (und in unserem Wiki) gibt, um diese Möglichkeiten optimal nutzen zu können.

Das sieht mir bei meiner Installation noch ziemlich mühselig aus:

Loaded Configuration File 	/etc/php/7.4/apache2/php.ini 

Und darin finde ich dann z. B. die Empfehlungen:

; display_errors
;   Default Value: On
;   Development Value: On
;   Production Value: Off

; display_startup_errors
;   Default Value: Off
;   Development Value: On
;   Production Value: Off

; error_reporting
;   Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
;   Development Value: E_ALL
;   Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT

; log_errors
;   Default Value: Off
;   Development Value: On
;   Production Value: On

Hier nur der Ausschnitt zum Thema Fehlerbehandlung und Meldungen.

Im weiteren Teil ist das dann irgendwo eingestellt. Wie kann man als Übersicht vermutlich am einfachsten mit phpinfo() nachsehen.

Eine alternative php.ini (außer für CLI) kann ich leider bei meiner Installation nicht finden. Das wird vielen Anderen auch so gehen. Da muss man sich also leider durchhangeln.

Glück Auf
Tom vom Berg

[TS]

Hello,

Ich würde mich freuen, wenn wir das Thema fürs Wiki deshalb noch zuende bearbeiten könnten, soweit das überhaupt möglich ist.

Was ich damit meine: welche Einstellung sollte man im Produktivbetrieb beibehalten? Es wäre ja auch unsinnig, vorhersehbare (provozierte) Fehler ins Log schreiben zu lassen, die ohnehin im Programm abgefangen werden sollten: z. B. Locking, Anlegen und Löschen von Dateien, usw.

Hier schon mal ein Beispiel:

  $fh = @fopen('testdatei.txt', 'x+');
  $_errormsg = error_get_last();

  echo "<pre>\r\n";
  print_r($_errormsg);
  echo "</pre>\r\n";

Das ergibt beim ersten Aufruf (die Datei testdatei.txt ist noch nicht vorhanden) keinen Fehler, vorausgesetzt alles andere stimmt und PHP darf im Pfad überhaupt eine Datei anlegen.

Beim zweiten Aufruf (die Datei sollte nun vorhanden gewesen sein) ergibt es

Array
(
    [type] => 2
    [message] => fopen(testdatei.txt): failed to open stream: File exists
    [file] => /var/www/html/errors.php
    [line] => 20
)

Wenn man das @ vor der Funktion weglässt, wird zusätlich eine Fehlermeldung generiert, die im Produktivbetrieb in Rohform tunlichst im Log landen sollte und nicht im Browser.

Um diesen "Fehler" hier qualifiziert behandeln zu können, muss man leider den Error-Text auswerten:

if (false !== strpos($_errormsg['message'], 'failed to open stream: File exists')) 
{
    ## Aktionen, wenn die Datei schon existiert hat
    ## ...
} 

Wohin würden im Wiki solche PHP-Praxis-Tipps gehören?

MMn sollte das der Weg für unser PHP-Wiki sein und nicht, was eine Variable ist. Einsteigertutorials gibt es schon genug.

Aber wie man z. B. Namespaces und Closures sinnvoll einsetzen kann, oder wie man PHP-Applikationen netzfähig (also mehrbenutzerfest) macht das findet man kaum irgendwo.

Da wird z. B. immer noch das total unzureichende move_uploaded_ file() vorgestellt, obwohl es gut beschriebene Beispiele gab, wie man es besser macht.

Glück Auf
Tom vom Berg

[Matthias Scharwies]

Servus!

Wohin würden im Wiki solche PHP-Praxis-Tipps gehören?

In ein Tutorial mit klar umrissenem Titel und Lernziel:

1. Aufgabenstellung / Problem
   • benötigte Vorkenntnisse und Anforderungslevel definieren
   • 1-2 Lernziele formulieren
2. Beispiel aufbauen und best practices zeigen
   • Fallstricke aufzeigen
   • erklären, wie man entwickelt und nicht nur Code-Snippets kopiert.

MMn sollte das der Weg für unser PHP-Wiki sein und nicht, was eine Variable ist. Einsteigertutorials gibt es schon genug.

Das kann ich jetzt so nicht stehen lassen! Das war Konsens von 2010-2018, aber …

Aufgrund vieler Nachfragen hatten wir im November 2018 das Einstiegs-Tutorial aus teilweise vorher schon vorhandenden Artikeln zu einem Kurs zusammengefügt. (SELFHTML: Wiki-Push: PHP vom 18.11.2018)

Ich schrub hier: Exkurs: SELFHTML und PHP:

gibt es im Augenblick eben kein zeitgemäßes PHP-Einführungstutorial (Ich hab jedenfalls keins gefunden!). Und deshalb kam das auch immer wieder im Feedback zur Sprache! Anstatt bei den Weblinks vor den verlinkten Tutorials zu warnen, sollten wir eben selbst diese best practices propagieren und vorstellen.

Anlass für den Wiki-Push waren libewinters erste Gehversuche und der Mangel an einem guten Einstiegs-Tutorial. Das von uns verlinkte schattenbaum.net bzw. SelfPHP waren eben nicht mehr empfehlenswert.

Optimal wäre natürlich, wenn man im Grundlagen-Kapitel ein Anwendungsbeispiel finden könnte, in dem man die dort besprochenen Werte und Datentypen einmal praktisch ausprobieren könnte.^[1] In diesem Kapitel gibt es am Ende einen Abschnitt zu Debugging

Inwieweit man das und das 7.Kapitel Fehlerbehandlung noch besser verknüpft, überlasse ich Euch!

Aber wie man z. B. Namespaces und Closures sinnvoll einsetzen kann, oder wie man PHP-Applikationen netzfähig (also mehrbenutzerfest) macht das findet man kaum irgendwo.

Da wird z. B. immer noch das total unzureichende move_uploaded_ file() vorgestellt, obwohl es gut beschriebene Beispiele gab, wie man es besser macht.

Das wäre eine gute Ergänzung zum Einstieg in PHP, der aber auch seine Daseinsberechtigung hat.

Herzliche Grüße

Matthias Scharwies

---

1. Auf dem Webentwicklerkongress 2020 (erinnert ihr euch?) wurde eine Auslosung zu einem Preisausschreiben erklärt. ↩︎

[TS]

Lieber Matthias,

ich persönlich empfinde diese lehrerhafte Darstellung als lästig. Diese Planungen sind bestimmt wichtig, gehören aber in die für den Nutzer unsichtbare Metaebene, aber nicht in die Doku oder Beispielsammlung.

Der Vorteil von HTML ist doch gerade, dass man eng an Themen dranbleiben kann und weiterführende Erklärungen und/oder Diskussionen an den neuralgischen Stellen verlinkt werden können.

Die alte SelfHTML-Doku war vermutlich deshalb so erfolgreich, weil sie sich in einer belehrungsfreien Form dargestellt hat.

Ich bin in den letzten Tagen am Wiki fast verzweifelt, als ich einfach nur meinem Drittel- bis Halbwissen folgend ergänzende Informationen gesucht habe.

Beispiel:

• Welche CSS-Eigenschaften wirken sich auf das <input>-Element aus?
• Welche CSS-Eigenschaften werden vererbt?
• usw.

Möglichst umfassende Stichwort-Indexe, durchsuchbar, hätten helfen können. Wenn es die in der von mir benötigten Form gibt, habe ich sie trotz intensiver Surfsessions nicht gefunden.

Die Diskussion über diesen Themenkomplex wäre mein Wunsch für das nächste Online-Meeting am 02. Februar (?).

Glück Auf
Tom vom Berg

[Matthias Scharwies]

Servus!

ich persönlich empfinde diese lehrerhafte Darstellung als lästig. Diese Planungen sind bestimmt wichtig, gehören aber in die für den Nutzer unsichtbare Metaebene, aber nicht in die Doku oder Beispielsammlung.

I beg to differ. Die Vorlage:Text-Info empfinde ich als knapp (im Vergleich zur MDN). Eine kurze Einleitung ist überall Standard.

Und das, was du als unsichtbare Metaebene bezeichnest, ist eben der rote Faden, der durch die Geschichte, bzw. das Tutorial laufen soll.^[1]

Der Vorteil von HTML ist doch gerade, dass man eng an Themen dranbleiben kann und weiterführende Erklärungen und/oder Diskussionen an den neuralgischen Stellen verlinkt werden können.

Ja, stimmt. Was man vorher wissen muss, muss aber auch vorne verlinkt werden!

Die alte SelfHTML-Doku war vermutlich deshalb so erfolgreich, weil sie sich in einer belehrungsfreien Form dargestellt hat.

Nein, weil's nix anderes gab. Und dann kamen zusätzlich zur Doku lauter Meta-Seiten wie FAQ, etc. Da will keiner mehr hin!

Ich bin in den letzten Tagen am Wiki fast verzweifelt, als ich einfach nur meinem Drittel- bis Halbwissen folgend ergänzende Informationen gesucht habe.

Beispiel:

• Welche CSS-Eigenschaften wirken sich auf das <input>-Element aus?

Äh, alle? Nein, aber HTML/Elemente/input verlinkt auf die beiden Tutorials. Und da hast du dir das „beste“ Beispiel ausgesucht. Eingabefelder oder Radiobuttons? Das geht ganz schön auseinander.

• Welche CSS-Eigenschaften werden vererbt?

Das ist bei jeder CSS-Eigenschaft in der Referenz angegeben.

Möglichst umfassende Stichwort-Indexe, durchsuchbar, hätten helfen können.

• CSS/Schnell-Index
• CSS/Eigenschaften

Wenn es die in der von mir benötigten Form gibt, habe ich sie trotz intensiver Surfsessions nicht gefunden.

Warum gibt es so ein Feedback zu CSS nicht, wenn ihr etwas braucht - dann würde ich gerne zeitnah helfen und, wenn nötig, etwas verbessern. So stehe ich etwas hilflos da und frage mich, was das mit dem PHP-Einstieg und Fehlerbehandlung zu tun hat?

Die Diskussion über diesen Themenkomplex wäre mein Wunsch für das nächste Online-Meeting am 02. Februar (?).

ok!

Herzliche Grüße

Matthias Scharwies

---

1. Als Doku würde ich https://www.php.net/manual/de/index.php ansehen, das haben und wollen wir nicht doppeln. Lose Beispielsammlungen wollen wir imho auch nicht, sondern eben Aufsätze, Abhandlungen vulgo: Tutorials. ↩︎

[TS]

Hello,

mir fehlt die Doku als schnelle Arbeitshilfe.
Dafür muss es mehrere Einstiegspunkte und Pfade geben.

Ein Wiki, dass ich erst selber in meiner Unwissenheit auf passende Information durchsuchen muss, ist lästig, aber nicht hilfreich!

Wir müssen die Einsprungspunkte und die Pfade verbessern!
Außerden müssen bei PHP und JS mehr Tipps-und-Tricks-Artikel her.
Das hat nichts mit "Bildungsleitfaden" zu tun, sondern nur mit interessanten Snippets. Da darf dann auch jeder eine eigene Meinung haben. Kommentare könnte man ja anhängen, wie die UCN bei PHP, oder in einem Blog.

Aber bitte lass uns am 02.02. Online darüber diskutieren! Ich werde beriets eine Stunde vorher versuchen, meinem Client das Discord wieder beizubringen und zur Not auch ins kalte Schlafzimmer an den anderen wechseln.

Mein Zeitdruck steigt momentan leider enorm und Ablenkung gibt es trotzdem schon genug ;-O

Glück Auf
Tom vom Berg

[Matthias Scharwies]

Servus!

Ein Wiki, dass ich erst selber in meiner Unwissenheit auf passende Information durchsuchen muss, ist lästig, aber nicht hilfreich!

Wir müssen die Einsprungspunkte und die Pfade verbessern!

Ja, aber wie? Das haben wir am 02.02. diskutiert.

Außerden müssen bei PHP und JS mehr Tipps-und-Tricks-Artikel her.
Das hat nichts mit "Bildungsleitfaden" zu tun, sondern nur mit interessanten Snippets. Da darf dann auch jeder eine eigene Meinung haben. Kommentare könnte man ja anhängen, wie die UCN bei PHP, oder in einem Blog.

Das wurde schon mehrmals vorgeschlagen:

• SELF-Forum: Archiv-Kompakt von Matthias Apsel, 15.02.2013
• SELF-Forum: Codeschnipsel-Archiv von Matthias Scharwies, 15.12.2015
• SELF-Forum: Code-Sammlung von Tom, 04.07.2014

Da schreibst Du aber, dass die Snippets alleine nicht reichen:

Da SelfHTML aber Hilfe zum Selbermachen sein soll, sind die Erläuterungen zu den Funktionen, Klassenm, ... und Scripten fast wichtiger, als der Code selbst. Genau diese Erläuterungen haben die Doku von SelfHTML mal groß gemacht.

In PHP gibt's das schon, wird aber nicht so genutzt:

PHP#Threads aus dem Forum

Fazit unserer Diskussion war das Ergebnis, dass du im Juli 2014 genauso geäußert hast.

Ohne Erklärungen sind Snippets alleine eher kontraproduktiv.

Einstiegspunkte

Ich habe kurz gezeigt, wie unsere Portalseiten HTML, CSS und JavaScript aussehen.

Parallel dazu gibt's

• den Schnellindex, den leider keiner pflegt / pflegen kann.
• die Kategorienseiten, die allerdings so technisch aussehen, dass sie nirgendwo prominent verlinkt sind.
  • dort kann man sehen, dass es noch einigen duplicate content gibt (z. B. font-display und font-stretch - ich wollte die Tutorials nicht überlasten).
  • evtl. könnte man per PHP oder JS die Seitennamen auf die Eigenschaften beschränken (das hatten wir bei Glossar:Titel so gemacht, bis wir merkten, dass eine Seite Titelim Hauptnamensraum solche Manipulationen gar nicht nötig hatte.)
  • alternativ könnte man die Kategorie auf die Weiterleitung setzen. Das müsste aber auch wieder manuell passieren.

Wie man sieht, gibt es keine einfache Lösung.

Ich bin dafür, ausgehend von Wie fange ich an? einfach Kurse jeweils am Anfang und am Ende zu verlinken.

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Servus!

Da wird z. B. immer noch das total unzureichende move_uploaded_ file() vorgestellt, obwohl es gut beschriebene Beispiele gab, wie man es besser macht.

Meinst du: /Benutzer:TS/File-Upload#Kontrolliert_speichern?

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo TS,

Um diesen "Fehler" hier qualifiziert behandeln zu können, muss man leider den Error-Text auswerten:

Nein, das sollte man nach Möglichkeit nie tun. Fehlertexte können sich ändern; es ist wahrscheinlich, aber es gibt keine Garantie, dass PHP immer den gleichen Fehlertext wirft. Man sollte sowas also zumindest einmal irgendwie kapseln.

Ich habe das in C# auch schon gemacht (weil der auch nur blindlings eine IOException wirft ohne näher zu begründen, wieso), aber Bauchweh habe ich dabei trotzdem; unter anderem, weil das .net Framework eine deutsche Fassung hat, die auch die Fehlermeldungen eindeutscht.

Die Lösung ist dann eigentlich, präventiv vorzugehen. Wenn Du mit einer existierenden Datei rechnest und diesen Fall separat behandeln willst, solltest Du vorher abfragen (file_exists), ob die Datei existiert. Das ist nicht so performant, weil es zwei Filesystem-Zugriffe sind.

Wo und wie man sowas aufschreibt? Tjaaaa - gutes und sinnvolles Errorhandling gehört zu den komplexeren Themen der Programmierung.

Beachte auch, dass der PHP Teil des Wikis daran leidet, dass keiner von uns wirklich die Mischung aus Qualifikation und verfügbarer Zeit mitbringt, um ihn sinnvoll zu aufzubauen. Deswegen ist diese Abteilung auch eher apokryph.

Rolf

[TS]

Hello,

Um diesen "Fehler" hier qualifiziert behandeln zu können, muss man leider den Error-Text auswerten:

Nein, das sollte man nach Möglichkeit nie tun. Fehlertexte können sich ändern; es ist wahrscheinlich, aber es gibt keine Garantie, dass PHP immer den gleichen Fehlertext wirft. Man sollte sowas also zumindest einmal irgendwie kapseln.

Das muss man/fra bei PHP leider doch tun :-(

Diesen Design-Mangel von PHP beklage ich schon seit über 12 Jahren. Es gibt keine eindeutigen sprachunabhängigen Fehlernumern in PHP.

Glück Auf
Tom vom Berg