[#443] function cDeprecated * ergänzung

[emergence]

contenido\includes\functions.general.php

hmm... etwas aussage kräftigere fehlermeldung kann nicht schaden... zb bei welcher url der fehler aufgetreten ist...

nach

Code: Alles auswählen

    $msg = "Deprecated call: " . $function_name . "() [" . basename($stack[0]['file']) . "(" . $stack[0]['line'] . ")]: ";
    if ($message != '') {
        $msg .= "\"" . $message . "\"" . "\n";
    } else {
        $msg .= "\n";
    }

folgendes ergänzen...

Code: Alles auswählen

    $msg .= ($_SERVER['SERVER_PORT'] == '443' ? 'https' : 'http').'://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']."\n";

[Faar]

All die schönen Posts hätten auch noch in github geschrieben werden können
https://github.com/CONTENIDO/CONTENIDO/issues
Oder gleich als Pullrequest fertig gestellt

[emergence]

hatte noch nie zeit mich mit github zu spielen...

[Faar]

hatte noch nie zeit mich mit github zu spielen...

Manche arbeiten damit.

[McHubi]

Also von meiner Seite aus einfach mal ein "Danke" an emergence.

[Faar]

Also von meiner Seite aus einfach mal ein "Danke" an emergence.

Ja, kann man schon sagen.

[xmurrix]

Danke, das ist eine gute Idee. Danke auch dir Faar, für das Anlegen des Tickets in GitHub.

Wir sollten das aber auch gleich in cWarning(), cError() und cLogError() machen, damit alle einheitliche Logeinträge erstellen.
Auch sollte man nicht auf gewisse $_SERVER Indizes zugreifen, ohne vorher zu prüfen, ob sie existieren.

Im CLI-Kontext gibt es z. B. keine $_SERVER['HTTP_HOST'] oder $_SERVER['REQUEST_URI'].

Allerdings sehe ich das nicht als einen Fehler, sondern eher als eine Ertweiterung.

[emergence]

CLI kontext verwende ich nicht...

dann vorher einfachen einen check ob die variable existiert...
=> isRunningFromWeb() verwenden...

[Faar]

Danke auch dir Faar, für das Anlegen des Tickets in GitHub.

Hab gerade eine ordentlich Erkältung, danach geht vielleicht mehr.

[Oldperl]

Servus,

erst mal danke @emergence
Schön Dich wieder mal durch's Forum fegen zu sehen.

ja, die Meldungen gehören überarbeitet. Wobei ich mir die Frage stelle, warum wir dort nicht gleich auf das vorhandene Fehlersystem von PHP aufsetzen, sondern ein "eigenes Süppchen" mit direktem Eintrag ins Errorlog kochen?

Gibt es dafür einen Grund?

Man könnte doch die Fehlermeldung auch per Error-Handler übergeben, oder? https://www.php.net/manual/de/function. ... andler.php
So kann man dann die Fehlermeldungen auch per PHP-Einstellungen abschalten, was gerade im produktiven Betrieb dafür sorgt, dass das Errorlog nicht unnötig gefüllt wird.

Gruß aus Franken

Ortwin

[emergence]

wie gesagt das war als ergänzung/erweiterung zu sehen...

grundsätzlich
der vorschlag das zu normen und via error_handler zu machen, ist eine gute idee...

mir gings hauptsächlich darum, die fehler des mandanten leichter fixen zu können...
zb ich benötige fast immer die info bei welcher url trat das problem auf... und das macht einfach sinn...

btw. wo ist das $cfg setting für 'cache' 'path' versteckt... ?

[Oldperl]

btw. wo ist das $cfg setting für 'cache' 'path' versteckt... ?

Für das Backend dort in der $cfg und für das jeweilige Frontend in der $cfgClient

Gruß aus Franken

Ortwin

[emergence]

ähm, bezieht sich auf classes/class.session.php

Code: Alles auswählen

$path = parse_url($url, PHP_URL_PATH);
$path = cRegistry::getConfigValue('cookie', 'path', $path);

das ist dort so definiert...
in den config.misc.php oder config.php ist nix vorgesehen wo man es per default platzieren sollte/könnte...
hätte man da eine zb auskommentierte position, wüsste man wo man es platzieren müsste...

ich fange persönlich nix damit an, dass der cookie path /contenido/ ist und nicht /
durch das setting muss ich die class.session.php nicht modifizieren...

[Oldperl]

Ok, also es gibt keinen $cfg-Value mit dem Namen 'cookie', weder als Einzelwert noch als Array.

An besagter Stelle geht es da aber auch nicht um einen vorkonfigurierten Wert, sondern um die Möglichkeit den Cookie-Pfad manuell setzen zu können. Normalerweise wird der Wert über parse_url ermittelt, und als Default-Wert bei getConfigValue gesetzt.
Irgendwo habe ich mal gelesen, dass es damit Probleme geben könnte, und deshalb wurde meines Wissens diese Möglichkeit den Pfad per $cfg-Variable fest zu setzen eingebaut.

Und es geht hier eben auch nicht nur um den Wert im Backend, sondern auch den jeweiligen Wert in den Frontends, je nachdem welche $url 2 Zeilen vorher genommen wird. Diese kann ich dann, wenn gewünscht, für jedes Frontend gesondert über den Eintrag in eine config.local.php ändern.

Gruß aus Franken

Ortwin

[xmurrix]

...in den config.misc.php oder config.php ist nix vorgesehen wo man es per default platzieren sollte/könnte...
hätte man da eine zb auskommentierte position, wüsste man wo man es platzieren müsste...

Der Cookie-Pfad wird im Backend auf '/contenido/' und im Frontend auf '/cms/' (oder '/{mandanten_ordner_name}/') gesetzt.
Hat man aber Clean-URLs im Frontend, funktioniert das nicht, daher gibt es seit dem 05.03.2019 die Änderung in der cSession, mit der man über eine Konfiguration `$cfg['cookie']['path']` den Wert setzen kann, z. B. auf '/'.

Die Information zur `$cfg['cookie']['path']` ist auch in der `class.session.php` als Kommentar angegeben. Natürlich kann man das auch in die `config.misc.php` übernehmen, damit auch jeder es gleich findet. Allerdings muss man dann sicherheitshalter extra darauf hinweisen, dass diese Änderung nicht in die `config.misc.php`gehört, sondern in die `<CLIENT>/data/config/<ENV>/config.local.php`. Vermutlich hat man es deshalb nicht in die `config.misc.php` reingenommen, weil das da nichts zu suchen hat.