Undefined variable

**kapitaeniglo** · 22.01.2003, 23:57

aehn .... das sind warnmeldungen die du erhaelst oda ????

also variablen sollten schon initialisiert werden ...
oft werden nur die fehlermeldungen in der php.ini unterdrueckt ... also besser gesagt bei vielen installationen gibt er WARNUNGEN nicht aus ... sondern nur fehler ....
haste da ne neuere version von wamp dir geholt???

mfg
kapitaeniglo

http://www.php-resource.de/forum/sho...threadid=12383

hab da mal ne aeltere diskussion hervorgekrammt ... wenn es warnungen sind findest dort wo du was aendern musst .....

**callt** · 23.01.2003, 00:04

Nein,
Ich habe die Version wampp13cs.
Dieselbe die ich zu Hause benutze.
Auf meinem Server bei Puretec funktioniert alles.
Auch auf Linux Red Hat habe ich den geschriebenen Code geladen. Ohne Probs.

Das was ich hier sehe ist mir echt neu.

Mit @$var funktioniert natürlich alles, aber ich will nicht etwa 50 Dateien mit etwa 10000 Zeilen Code mit@@@@@@ umschreiben.

callt

**callt** · 23.01.2003, 00:09

OK das wars

http://www.php-resource.de/forum/sh...&threadid=12383

hab da mal ne aeltere diskussion hervorgekrammt ... wenn es warnungen sind findest dort wo du was aendern musst .....

Das wars.

das Forum ist echt supercool

Danke nochmal

callt

**kapitaeniglo** · 23.01.2003, 00:34

aber um nochmal zu erwahnen ... korrekt ist mein vorschlag dort nicht ... gut wenn deine projekte bei puretec etc. laufen wirste wahrscheinlich dort NIE probleme mit haben, da puretec sich hueten wird die warnungen einzuschalten

.....

solltest also wenn es geht deine variablen (vor allem die arrays) initialiseren ...

mfg
kapitaeniglo

@hilfe hier im forum:
jau ... da kann ich dir nur zustimmen ....

**martin_de** · 23.01.2003, 00:58

die in dem verlinkten thema empfohlene mothode ist nicht sinnvoll.

es hängt zwar tatsächlich mit dem error_reporting() zusammen, nur behebt das herabsetzen desselben nicht das eigentliche problem.
es wird nur versteckt.

uninitailisierte variablen bieten häufig manipulations und angriffsmöglichkeiten auf das script, die im schlimmsten fall zu schweren sicherheitslücken führen.

wenn du dein script sauber programmiert hättest, würden diese warnungen nicht angezeigt werden, ganz gleich bei welchem error_reporting().
ich kann dir nur raten, dein script nochmals komplett zu überarbeiten und an aktuelle php techniken anzupassen - auch wenn das etwas zeit in anspruch nimmt.

ausserdem kann man den error_reporting() level direkt im script angeben und sollte dies auch immer tun.
das mit dem ändern der einstellungen in der php.ini wie in dem verlinkten thema beschrieben ist wenig sinnvoll bei lokalen installationen.
wenn - dann könnte man das auf einem öffentlichen webserver ändern.

aber wie gesagt, die php.ini einstellung kann man ignorieren, da man das immer direkt im script angeben sollte (naja... eigentlich MUSS!).

am besten direkt nach dem einleitenden
<?php

PHP-Code:


<?php



error_reporting (E_ALL);



.....

E_ALL bedeutet, dass alle fehler, warnungen, hinweise...was auch immer ausgegeben werden. während der programmierung sollte man das auch immer so angeben um alle fehler/probleme sofort zu entdecken.

wenn das script dann später irgendwo im einsatz ist, ist es sinnvoll das error_reporting() etwas herunterzusetzen.

error_reporting (E_ERROR | E_WARNING | E_PARSE);

ist hier der standard.

warum sollte (MUSS!) man das direkt im script angeben?

ganz einfach.

wenn es im script nicht angegeben ist, wird die einstellungen aus der php.ini verwendet. wenn man das script nur für sich selbst nutzt mag das kein problem sein. wenn man es aber veröffentlicht, dann wird es unter den verschiedensten php konfigurationen laufen und wie da die einstellungen zur fehlerausgabe aussehen weiß man nie...

**goth** · 23.01.2003, 01:26

Trotz allem sollte man auf seinem Entwicklungs-System möglichst viele Meldungen anzeigen lassen ... das hilft immens bei der Fehlersuche!

Undefined variable