[CON-1499] Programmierfehler bringen Moduloutput zum Absturz

[homtata]

Hallo,

normalerweise springt der Moduloutputcode ja von grün auf rot, wenn sich Programmierfehler einschleichen und der fehlerhafte Code ist weiterhin sichtbar. Bestimmte Kombinationen führen aber dazu, dass nach dem Speichern der Quellcode nicht mehr angezeigt wird, auch wenn er im Modulordner noch in der Output-php-Datei liegt.

Ich habe das schon mit verschiedenen Fehlern hingekriegt, aber leider habe ich nicht gleich alle protolliert. Eine Version davon habe ich in Erinnerung und kann das auch reproduzieren.

Angenommen, man möchte ein Array bearbeiten und den Value-Wert "überschreibbar" machen, geht das durch ein zusätzliches Fragezeichen vor $value, also so:

Code: Alles auswählen

 foreach ( $yourarray AS $key => &$value ) 

Setzt man das "&" versehentlich for "$key" und speichert, wird der Code wie gesagt nicht mehr zurückgelesen:

Code: Alles auswählen

 foreach ( $yourarray AS &$key => $value ) 

LG

[josh]

Hi,

Das geht

Code: Alles auswählen

<?php
$pic = array();

$pic[] = 'test';
?>

Hier geht nichts mehr:
Fatal error: Cannot use [] for reading in /srv/www/web82/web/contenido/includes/functions.mod.php(214) : eval()'d code on line 5

Code: Alles auswählen

<?php
$pic = array();

$pic[] >= 'test';
?>

josh

[Faar]

Aber... wer macht auch $pic[] >= 'test'; ?

[josh]

Hallo Faar,

na ein verschreiberli darf nicht das Fenster unbrauchbar machen.
Da gibt es offensichtlich auch noch anderen Code den das Fenster nicht verträgt.

Im Beschreibungsfenster bringen Hochkomma auch was durcheinander.
Z.B. 'tolles Modul' bewirkt ein durcheinander im linken Frame bei den Modulen.

Das ist sicher alles nicht so tragisch weil man ja die Module in den files ändern kann.
Sollte aber doch beim Update behoben werden.

josh

[dominik.ziegler]

Wir werden uns das noch einmal anschauen bzgl. der Namen und dem fehlerhaften Code. Uns ist das bisher noch nicht passiert, ggf. liegt das auch an einer bestimmten Konstellation in der Server-Konfiguration.

[Faar]

Hallo Faar,

na ein verschreiberli darf nicht das Fenster unbrauchbar machen.

Hallo josh,

im ersten Blick gesehen natürlich nicht.
Eigentlich sollte man beim Code schreiben bereits eine Fehlerbehandlung einbauen und überlegen, ob das Programm dann abbrechen soll oder weiter laufen muss und in beiden Fällen eine Meldung ausgibt.
Aber hier scheint noch keine derartige Fehlerbehandlung vorzuliegen, weil es einfach ab bricht.

Ja eigentlich...
Aber ich erwische mich auch noch ab und zu dabei, wenn es dringend ist, Code erstmal lauffähig zu machen und mir vorzunehmen, den später zu überarbeiten... was dann manchmal vergessen wird.
Und meistens merkt man erst durch Userfeedback, an was man alles nicht gedacht hat beim Programmieren.

[dominik.ziegler]

Normalerweise sollte CONTENIDO das Modul entsprechend speichern und dann die "Ampel" rot einfärben. Wieso das in dem konkreten Fall nicht funktioniert hat werden wir uns entsprechend anschauen.

[frederic.schneider_4fb]

Das Problem tritt in der Tat nur in ganz bestimmten Fällen auf und nicht bei allen Syntax-Fehlern. Jedenfalls liegt es am eval-Aufruf in Zeile 214 der functions.mod.php-Datei. Man kann das Problem temporär auch umgehen, indem man in Zeile 214 bspw. schreibt:

Code: Alles auswählen

$output = eval(conHtmlentities($code));

Dies ist jedoch kein Workaround, da das Htmlentities (oder auch ein SpecialChars) dazu führt, dass gar kein Code mehr gültig validiert wird. Wir werden weiter nach einer Lösung suchen, womöglich geht mittel- bis langfristig nichts daran vorbei, die gesamten Mod-Tests ohne ein eval auszuführen.

[frederic.schneider_4fb]

Ein Zwischenstand: Wir haben eine Lösung gefunden, die in der neuen Version 4.9.1 beinhaltet sein wird. Die Änderungen sind etwas umfangreicher.