Variable mit Wert im Querystring, aber bei Abfrage "Null"

[Enrico]

Hallo,

wieder einmal bin ich auf eure Hilfe angewiesen bei der Lösung eines Problems, das ich leider sehr ausführlich beschreiben muss, damit (hoffentlich) alles klar wird.

Ausgangspunkt ist die Datei "Index.php", in die dynamisch, je nach Bedarf, weiterer Code eingebunden wird.

Die via get übergebenen Parameter werden in der Datei "Index.php" mit folgendem Code ausgewertet (auch um nicht erlaubte Eingaben herauszufiltern):

  
   $Parameter = array ("Hauptmenue", "Untermenue", "Untermenue2", "Aktion", "Suche", "Nr", "Groesse", "Farbe");  
  
   $Whitelist = array ("/^Hauptmenue=\d{1,2}$/",  
                       "/^Untermenue=\d{1}$/",  
                       "/^Untermenue2=\d{1}$/",  
                       "/^Aktion=[A-Za-z]*$/",  
                       "/^Suche=\d{1}$/",  
                       "/^Nr=\d{1,2}$/",  
                       "/^Groesse=\d{1}$/",  
                       "/^Farbe=\d{1,2}$/");  
  
   foreach ($_GET as $Schluessel => $Wert)  
   {  
      for ($i = 0; $i < count ($Parameter); $i++)  
      {  
         if ($Schluessel == $Parameter[$i])  
         {  
            $ZuPruefen = $Parameter[$i] . '=' . $Wert;  
  
            if (preg_match ($Whitelist[$i], $ZuPruefen))  
               if ($_GET[$Parameter[$i]] !== null)  
                  $$Parameter[$i] = $_GET[$Parameter[$i]];  
         }  
      }  
   }  

Über PHP binde ich in die Datei "Index.php" u.a. auch externe JavaScript-Dateien ein und baue zudem nachfolgende JavaScript-Funktion auf.
Beides wird ebenfalls nur bei Bedarf eingebunden:

  
   echo '<script src="../JS/ArtikelDetails.js" type="text/javascript"></script>';  
   echo '<script type="text/javascript">';  
  
   echo "function Senden ()";  
   echo "{";  
   echo "Groesse, Farbe;";  
  
   if (isset ($Untermenue2) && $Untermenue2 !== "")  
      echo 'document.location.href = "Index.php?Hauptmenue=' . $Hauptmenue . '&Untermenue=' . $Untermenue . '&Untermenue2=' . $Untermenue2 . '&Nr=' . $Nr . '&Groesse=" + Groesse + "&Farbe=" + Farbe + "&Aktion=ArtikelWarenkorb"';  
   else  
      echo 'document.location.href = "Index.php?Hauptmenue=' . $Hauptmenue . '&Untermenue=' . $Untermenue . '&Nr=' . $Nr . '&Groesse=" + Groesse + "&Farbe=" + Farbe + "&Aktion=ArtikelWarenkorb"';  
  
   echo "}";  
  
   echo "</script>";  

Ich habe deshalb diese Methode gewählt, da ich beim Absenden eines Formulars mehrere Werte benötige, die auf der einen Seite über PHP ermittelt und auf der anderen Seite über JavaScript (Übergabe von Werten zweier Auswahllisten) übergeben werden.

In der vorher angesprochenen JavaScript-Datei ermittle ich u.a. die Werte zweier Auswahllisten, danach arbeite ich mit diesen Werten weiter

  
   Groesse = "";  
   Farbe   = "";  
  
   function PreisErmitteln(Typ)  
   {  
      Groesse, Farbe;  
  
      [...]  
  
      Preis1  = Groesse.options[Groesse.selectedIndex].value;  
      Groesse = Groesse.selectedIndex - 1; // Wegen "Größe?" als erste Option  
  
      Preis2 = Farbe.options[Farbe.selectedIndex].value;  
      Farbe  = Farbe.selectedIndex - 1; // Wegen "Farbe?" als erste Option  
  
      [...]  
   }  

Letztendlich erhalte ich in der Adressleiste von Firefox nach Absenden des Formulars über die Funktion "Senden ()", siehe oben, auf jeden Fall beispielsweise folgenden Querystring:

http://localhost/[...]/Index.php?Hauptmenue=4&Untermenue=0&Nr=0&Groesse=1&Farbe=4&Aktion=ArtikelWarenkorb

Wenn ich nun, zu Testzwecken, über echo die Variablen "Groesse" und "Farbe" ausgeben lasse, dann wird mir nur der Wert der Variablen "Groesse" ausgegeben, aber nicht der Variablen "Farbe". Es wird mir aber auch keine Fehlermeldung ausgegeben, d.h. die Variable "Farbe" ist "Null", ohne dass ich aber irgendwelche weiteren Zuweisungen für diese beiden Variablen treffe.

Vor den testweisen Ausgaben habe ich keine einzige Anweisung, in der diese beiden Variablen auch nur erwähnt werden.

Mit FireBug habe ich noch nie gearbeitet, da ich mit diesem Addon absolut nicht zurecht komme, falls dies zur Lösungsfindung beitragen sollte, was ich aber ausschliessen kann, da die Adressleiste ja dagegen spricht, dass bei der Übergabe/Übermittlung ein Fehler vorliegt.

Könnt ihr mir anhand meiner Angaben bei der Lösung des Problems helfen, warum die Variable "Farbe" keinen Inhalt hat, nachdem sie korrekt übergeben worden zu sein scheint?

Danke und Gruß,
Enrico

[ChrisB]

Hi,

Letztendlich erhalte ich in der Adressleiste von Firefox nach Absenden des Formulars über die Funktion "Senden ()", siehe oben, auf jeden Fall beispielsweise folgenden Querystring:

http://localhost/[...]/Index.php?Hauptmenue=4&Untermenue=0&Nr=0&Groesse=1&Farbe=4&Aktion=ArtikelWarenkorb

Dann hast du auch $_GET['Farbe'] mit dem Inhalt "4".

Wenn ich nun, zu Testzwecken, über echo die Variablen "Groesse" und "Farbe" ausgeben lasse, dann wird mir nur der Wert der Variablen "Groesse" ausgegeben, aber nicht der Variablen "Farbe". Es wird mir aber auch keine Fehlermeldung ausgegeben, d.h. die Variable "Farbe" ist "Null", ohne dass ich aber irgendwelche weiteren Zuweisungen für diese beiden Variablen treffe.

var_dump($_GET) direkt am Stringanfang zeigt das, was das Script tatsächlich per GET bekommen hat. Alles weitere ist das, was du verbrochen hast.

MfG ChrisB

[Der Martin]

Hallo,

var_dump($_GET) direkt am Stringanfang ...

du meintest selbstverständlich am _Script_anfang.

Ciao,
 Martin

[hotti]

hi,

Deine Idee mit einer Liste von Schlüsselparametern ist sehr gut. Du machst jedoch einen systematischen Fehler, weil Du mit Deiner Schleife jeden in $_GET stehenden Paramater befragst. Lege daher die Schleife nur über Deine in Whitelist definierten Schlüsselparameter.

Beachte dann, dass bei

?foo=0

eine Kontrolle
if($_GET['foo'] !== NULL)

oder eine Kontrolle
if(isset($_GET['foo']))

in beiden Fällen TRUE ergibt. Frage daher ab, ob der Wert des Parameters eine Länge strlen() größer 0 hat. Auf NULL musst Du jedoch immer vorher testen.

Hotti

[Enrico]

Hallo Hotti,

weil Du mit Deiner Schleife jeden in $_GET stehenden Paramater befragst
Lege daher die Schleife nur über Deine in Whitelist definierten Schlüsselparameter

Ich möchte $_GET auch komplett prüfen und brauche, da ich auch zwei Arrays habe, ja doch auch zwei Schleifen, oder? Eine für $_GET, eine fürs Durchlaufen des Whitelist-Arrays, um auch zu erkennen, ob das Whitelist-Array durchlaufen wurde.

Oder habe ich hier einen Denkfehler?

Gruß
Enrico

[dedlfix]

Tach!

Ich möchte $_GET auch komplett prüfen

Welche Notwendigkeit siehst du denn darin, das komplette $_GET zu prüfen, inklusive aller Werte, die dir da jemand anzuhängen versucht, und exklusive dem, was weggelassen wurde?

Lauf durch das, was du sicherstellen willst und schau aufgrund dieser Information nach, ob das in $_GET enthalten ist oder nicht.

und brauche, da ich auch zwei Arrays habe, ja doch auch zwei Schleifen, oder?

Nein. Ob etwas in einem Array enthalten ist, kann man anders abfragen, als zu Fuß alle Elemente anzuschauen: z.B. isset(), empty(), array_key_exists(), array_search().

dedlfix.

[Enrico]

Hallo dedlfix,

Welche Notwendigkeit siehst du denn darin, das komplette $_GET zu prüfen

Ich sehe schon, ich muss hier weiter ausholen.

Die Index.php ist bei mir die Schaltzentrale, in der, je nach übergebenen $_GET-Parametern und jeweiligem Inhalt, alle weiteren Aktionen gesteuert werden:

Die Variablen $Hauptmenue, $Untermenue und $Untermenue2 steuern beispielsweise die Anzeige der (Unter-)Menüs und die jeweils einzubindende Seite, während $Aktion, wie die Bezeichnung schon impliziert, weitere Aktionen regelt (Anzeige des jeweiligen Sortiments, Anzeige der Artikeldetails zu Artikel $Nr, Hinzufügen des aktuell angezeigten Artikels $Nr in der $Groesse und $Farbe zum Warenkorb,...)

Gruß,
Enrico

[Matthias Apsel]

Om nah hoo pez nyeetz, Enrico!

Welche Notwendigkeit siehst du denn darin, das komplette $_GET zu prüfen

Ich sehe schon, ich muss hier weiter ausholen.

Du solltest die Parameter prüfen, die du erwartest und keine weiteren.

http://example.com?selfhtml&ist&die&beste&seite&admin=true sind Parameter, die dir irgendwelche Bösewichte anhängen wollen.

Matthias

[Enrico]

Hallo Matthias,

Du solltest die Parameter prüfen, die du erwartest und keine weiteren

Die Menueparameter sind für die Darstellung der Menüs nach dem Anklicken der Menüpunkte zuständig. Die brauche ich somit immer und muss sie damit auch immer abfragen, auch weil der aktive Menüpunkt anders dargestellt wird und somit auch den Standort anzeigt.

(Gibt es weitere Synonyme für "damit" und "somit"?)Oo.

Die Einbindung der dem aktuell ausgewählten Menüpunkt entsprechenden Seite wird auch hierüber gesteuert.

Über $Aktion steuere ich die aktuelle Seite feiner.

Ich könnte natürlich schon die Prüfung der Variablen $Aktion von den Variablen $Hauptmenue, $Untermenue und ggfs. $Untermenue2 abhängig machen, aber das bläht den Code, meiner Meinung nach, nicht unerheblich auf.

All diese/eure Überlegungen zielen natürlich auch darauf ab, den Code zu optimieren/sinnvoller zu programmieren, liefern aber nicht den Grund dafür, warum $Farbe nicht angezeigt wird bzw. "null" ist, ohne Fehlermeldung.

Sakra, sakra...

Gruß
Enrico

[Der Martin]

Hallo,

(Gibt es weitere Synonyme für "damit" und "somit"?)Oo.

deshalb, daher, also, folglich, ... ;-)

All diese/eure Überlegungen zielen natürlich auch darauf ab, den Code zu optimieren/sinnvoller zu programmieren, liefern aber nicht den Grund dafür, warum $Farbe nicht angezeigt wird bzw. "null" ist, ohne Fehlermeldung.

Du hast auch immer noch nicht nachgesehen (oder uns zumindest nicht daran teilhaben lassen), was denn ein var_dump($_GET) zutage fördert, obwohl ChrisB schon ganz am Anfang indirekt danach fragte. Denn dort fängt die Spur an, wenn man sie systematisch verfolgen möchte.

Ciao,
 Martin

[Enrico]

Hallo Martin,

Du hast auch immer noch nicht nachgesehen (oder uns zumindest nicht daran teilhaben lassen)

Sorry, klar...

var_dump ($_GET) liefert mit (in aufbereiteter Form):

Array (6)
(
|    ['Hauptmenue'] = String(1) "4"
|    ['Untermenue'] = String(1) "0"
|    ['Nr'] = String(1) "0"
|    ['Groesse'] = String(1) "1"
|    ['Farbe'] = String(1) "4"
|    ['Aktion'] = String(16) "ArtikelWarenkorb"
)

Scheint alles ok ^^

Gruß,
Enrico

[Der Martin]

Hallo,

var_dump ($_GET) liefert mit (in aufbereiteter Form):

Array (6)
(
|    ['Hauptmenue'] = String(1) "4"
|    ['Untermenue'] = String(1) "0"
|    ['Nr'] = String(1) "0"
|    ['Groesse'] = String(1) "1"
|    ['Farbe'] = String(1) "4"
|    ['Aktion'] = String(16) "ArtikelWarenkorb"
)

Scheint alles ok ^^

in der Tat, ja. Ich hätte eventuell mit einem Problem bei der Groß/Kleinschreibung gerechnet.
Gut, jetzt wäre zu prüfen, ob $Farbe unmittelbar nach der foreach-Schleife der Parameter-Prüfung existiert.

Und wenn auch das passt, dann wird sie wohl irgendwo im Script überschrieben. Kreise durch Debug-Ausgaben an strategisch sinnvollen Stellen den Knackpunkt ein. Mehr kann man von hier aus nicht sagen.

Ciao,
 Martin

[Enrico]

Hallo Martin,

hmm, wenn ich $Farbe direkt mittels $_GET['Farbe'] einlese, dann klappt es.

Dann muss der Fehler irgendwo im eigentlichen Auslesen der $_GET-Variablen und Erzeugen der weiterzuverwenden Variablen liegen, auch wenn hier keine Schreibfehler etc vorliegen ^^

Gut, ich begebe mich wieder auf die Suche :-|

Eure Hilfe hat mir auf jeden Fall schon mal weitergeholen.

Gruß,
Enrico

[Enrico]

*knirrrrrsch* Hallo,

jetzt wollte ich das ganze Konstrukt aufdröseln und die Prüfungen von bestimmten Voraussetzungen abhängig machen und... ...jetzt funktioniert es nicht mehr:

  
   if (isset ($_GET['Hauptmenue']))  
   {  
      if ($_GET['Hauptmenue'] !== null && strlen ($_GET['Hauptmenue'] > 0))  
      {  
         if (preg_match ("/^d{1,2}$/", $_GET['Hauptmenue']))  
            $Hauptmenue = $_GET['Hauptmenue'];  
         else  
            $Hauptmenue = 0;  
      }  
      else  
         $Hauptmenue = 0;  
   }  
   else  
      $Hauptmenue = 0;  

Die preg_match-Prüfung schlägt jetzt immer fehl.

Warum hat sie dann ursprünglich funktioniert?

Gut, ich prüfe jetzt nur den Wert und nicht mehr das zusammengesetzte Konstrukt, aber warum haut es jetzt nicht mehr hin?

Auch ein (nicht erforderlicher) Cast mittels "(int)" brachte keine Änderung.

Enrico

[Der Martin]

Hallo,

if (preg_match ("/^d{1,2}$/", $_GET['Hauptmenue']))
Die preg_match-Prüfung schlägt jetzt immer fehl.

kommt drauf an, was du erwartest. Das obige Muster erwartet genau ein- oder zweimal den Kleinbuchstaben 'd'.

Ciao,
 Martin

[Enrico]

Hallo Martin,

sappralot, was ein versehentlich wegrationalisierter Backslash alles ausrichten kann... ^^

Jetzt klappt's, danke Dir :-)

Gruß,
Enrico

[Kai345]

[latex]Mae  govannen![/latex]

if (isset ($_GET['Hauptmenue']))
   {
      if ($_GET['Hauptmenue'] !== null && strlen ($_GET['Hauptmenue'] > 0))
      {
         if (preg_match ("/^d{1,2}$/", $_GET['Hauptmenue']))
            $Hauptmenue = $_GET['Hauptmenue'];
         else
            $Hauptmenue = 0;
      }
      else
         $Hauptmenue = 0;
   }
   else
      $Hauptmenue = 0;

  
Der Vergleich ($\_GET['Hauptmenue'] !== null...) ist überflüssig, da dies bereits durch isset() getestet wird (Determine if a variable is set and is not NULL). Gleiches gilt für strlen, da ein leerer Wert so oder so spätestens am nächsten Schritt (preg\_match) scheitern wird.  
  
Ansonsten ist die gesamte Konstruktion extrem umständlich.  
  
~~~php
$Hauptmenue = 0;  
if (isset ($_GET['Hauptmenue']) && preg_match ("/^d{1,2}$/", $_GET['Hauptmenue']))  
{  
    $Hauptmenue = $_GET['Hauptmenue'];  
}

reicht vollkommen aus, wenn keine weiteren alternativen Zweige vorhanden sind (und ich jetzt keinen Denkfehler drin habe)

Stur lächeln und winken, Männer!
Kai

[Enrico]

Hallo Kai,

Danke für Deine Antwort.

Habe das Konstrukt jetzt entsprechend entschlackt und noch einen Backslash vor das Pattern gesetzt und jetzt ist erst mal alles in Ordnung, erst mal ;-)

Gruß
Enrico

[Kai345]

[latex]Mae  govannen![/latex]

$Hauptmenue = 0;

if (isset ($_GET['Hauptmenue']) && preg_match ("/^d{1,2}$/", $_GET['Hauptmenue']))
{
    $Hauptmenue = $_GET['Hauptmenue'];
}

  
Hier könnte man dann noch die Inkonsistenz des Datentyps beseitigen, denn entweder steht in `$Hauptmenue`{:.language-php} eine Zahl (0) oder eine Zeichenkette mit dem Wert von `$_GET['Hauptmenue']`{:.language-php}  
  
Also falls der Wert von $Hauptmenue immer eine Zahl sein soll:  
  
   ` $Hauptmenue = intval($_GET['Hauptmenue']);`{:.language-php}  
  
Hiermit fängt man auch gleich invalide Werte ab (z.B. wenn jemand Dinge wie  
  
.../Index.php?Hauptmenue=Hallo  
  
übergibt), denn intval() gibt bei ungültigen Werten 0 zurück, was hier praktischerweise genau der Vorgabe für `$Hauptmenue`{:.language-php} entspricht.  
  
Das einzige, was dann noch zu testen wäre, ist der Bereichsgültigkeit der Zahl, denn ich vermute, daß  
  
.../Index.php?Hauptmenue=36262822  
  
oder  
  
.../Index.php?Hauptmenue=-4711  
  
tendenziell eher nicht gewünscht sind ;)  
  
Stur lächeln und winken, Männer!  
Kai  

-- 
`var jQuery = $(hit);`{:.language-javascript}  
Unsere Identität entnehmen Sie bitte dem beigefügten Auszug aus den Personenstandsbüchern. Gegen die Assimilierung in unser Kollektiv ist nach dem ABGB (§666, Abs. 3/IV) kein Rechtsmittel zulässig. Wir bitten um Ihr Verständnis.  
  
[SelfHTML-Forum-Stylesheet](http://selfhtml.knrs.de/#h_stylesheet)  

[dedlfix]

Tach!

$Hauptmenue = 0;

if (isset ($_GET['Hauptmenue']) && preg_match ("/^d{1,2}$/", $_GET['Hauptmenue']))
{
    $Hauptmenue = $_GET['Hauptmenue'];
}

> Hier könnte man dann noch die Inkonsistenz des Datentyps beseitigen, denn entweder steht in `$Hauptmenue`{:.language-php} eine Zahl (0) oder eine Zeichenkette mit dem Wert von `$_GET['Hauptmenue']`{:.language-php}  
  
Macht ja nichts, das ist PHP, da muss der Typ nicht unbedingt stimmen. Die Zahl wird sicher über einen Link oder ein Formular ins $\_GET gelangen, was heißt, dass sie als String irgendwo im HTML- oder Javascript-Code stehen muss. Eine Umwandlung nach Integer bringt an dieser Stelle keinen Vorteil.  
  

> Also falls der Wert von $Hauptmenue immer eine Zahl sein soll:  
>    ` $Hauptmenue = intval($_GET['Hauptmenue']);`{:.language-php}  
> Hiermit fängt man auch gleich invalide Werte ab (z.B. wenn jemand Dinge wie  
> .../Index.php?Hauptmenue=Hallo  
> übergibt),  
  
Kann ja nicht, weil der RegExp das nicht durchlassen würde.  
  

> denn intval() gibt bei ungültigen Werten 0 zurück, was hier praktischerweise genau der Vorgabe für `$Hauptmenue`{:.language-php} entspricht.  
> Das einzige, was dann noch zu testen wäre, ist der Bereichsgültigkeit der Zahl, denn ich vermute, daß  
> .../Index.php?Hauptmenue=36262822  
> oder  
> .../Index.php?Hauptmenue=-4711  
> tendenziell eher nicht gewünscht sind ;)  
  
Fängt ja auch der Rexexp ab. Aber man kann den alternativ auch weglassen und stattdessen intval() und eine Prüfung auf > 0 und < 100 nehmen.  
  
  
dedlfix.

[Kai345]

[latex]Mae  govannen![/latex]

Hier könnte man dann noch die Inkonsistenz des Datentyps beseitigen, denn entweder steht in $Hauptmenue eine Zahl (0) oder eine Zeichenkette mit dem Wert von $_GET['Hauptmenue']

Macht ja nichts, das ist PHP, da muss der Typ nicht unbedingt stimmen. [...] Eine Umwandlung nach Integer bringt an dieser Stelle keinen Vorteil.

Prinzipiell richtig. Dann darf man allerdings nirgendwo aus Versehen mit === bzw !== vergleichen.

$Hauptmenue = intval($_GET['Hauptmenue']);
Hiermit fängt man auch gleich invalide Werte ab (z.B. wenn jemand Dinge wie
.../Index.php?Hauptmenue=Hallo
übergibt),

Kann ja nicht, weil der RegExp das nicht durchlassen würde.

Jaja, ist spät... :(

denn intval() gibt bei ungültigen Werten 0 zurück, was hier praktischerweise genau der Vorgabe für $Hauptmenue entspricht.
Das einzige, was dann noch zu testen wäre, ist der Bereichsgültigkeit der Zahl, denn ich vermute, daß
.../Index.php?Hauptmenue=36262822
oder
.../Index.php?Hauptmenue=-4711
tendenziell eher nicht gewünscht sind ;)

Fängt ja auch der Rexexp ab.

Stimmt. Allerdings 99, 98, 97,.... geht wiederum durch, insofern ist eine Prüfung dennoch sinnvoll, allerdings...

Aber man kann den alternativ auch weglassen und stattdessen intval() und eine Prüfung auf > 0 und < 100 nehmen.

wäre das zu bevorzugen, preg_match ist in diesem Fall schon ein wenig wie eine Atombombe zur Maulwurf-Bekämpfung

Stur lächeln und winken, Männer!
Kai

[dedlfix]

Tach!

Macht ja nichts, das ist PHP, da muss der Typ nicht unbedingt stimmen. [...] Eine Umwandlung nach Integer bringt an dieser Stelle keinen Vorteil.
Prinzipiell richtig. Dann darf man allerdings nirgendwo aus Versehen mit === bzw !== vergleichen.

Wer typsichere Vergleiche unüberlegt und ohne Not einsetzt gehört $bestraft. Als Code-Leser stelle ich mir hier die Frage, warum der Typ eine Rolle spielt. Oftmals steht ja auch keine Antwort auf diese Frage als Kommentar daneben. Klar, bei Eindeutigkeiten wie bei strpos() ist das kein Problem, aber in diesem Fall erschlösse sich mir vermutlich nicht so einfach, warum ausgerechnet eine von 0 verschiedene Menü-Nummer typsicher vergleichen werden müsste. Mir fällt da grad kein Anwendungsbeispiel ein.

Aber man kann den alternativ auch weglassen und stattdessen intval() und eine Prüfung auf > 0 und < 100 nehmen.
wäre das zu bevorzugen, preg_match ist in diesem Fall schon ein wenig wie eine Atombombe zur Maulwurf-Bekämpfung

Die Frage ist noch, warum/ob an dieser Stelle überhaupt der Wertebereich verglichen werden muss. Wenn es anschließend darum geht, anhand dieser Zahl ein konkretes Ding auszuwählen, fallen ja sowieso alle Zahlen nebst anderen Werten durchs Raster, die nicht auf ein vorhandenes Ding mappen. Dann wäre auch eine Prüfung auf zweistellige Zahlen nicht sehr sinnvoll, weile eine Menge Fälle damit durchgelassen werden und sowieso noch die spätere Prüfung benötigen.

dedlfix.

[dedlfix]

Tach!

Noch'n Hinweis:

if (isset ($_GET['Hauptmenue'])) {

if ($_GET['Hauptmenue'] !== null && strlen ($_GET['Hauptmenue'] > 0))

  
In einem $\_GET- oder $\_POST-Eintrag steht (wenn niemand was mutwillig überschreibt) immer ein String (oder ein Array mit Strings). Eine Prüfung auf null ist ein Fehler. Ein Lesezugriff auf einen $\_GET-/$\_POST-Eintrag ergibt nur dann null, wenn der Wert nicht vorhanden ist. Das prüft man jedoch nicht indirekt über einen NULL-Vergleich (weil bei Nichtvorhanden auch noch eine Notice-Meldung erzeugt wird), sondern direkt mit isset() - oder empty(), wenn man gleich noch "0" und Leerstring ausschließen möchten.  
  
  
dedlfix.

[dedlfix]

Tach!

Du solltest die Parameter prüfen, die du erwartest und keine weiteren
Die Menueparameter sind für die Darstellung der Menüs nach dem Anklicken der Menüpunkte zuständig. Die brauche ich somit immer und muss sie damit auch immer abfragen, auch weil der aktive Menüpunkt anders dargestellt wird und somit auch den Standort anzeigt.

Egal, wofür du welche Werte benötigst, stell deine Fragen an $_GET und Konsorten von diesen Werten ausgehend und nicht vom Inhalt von $_GET ausgehend. Nur so kannst du ohne großes zusätzliches Gehampel genau diese benötigten Werte - keinen mehr und keinen zu wenig - prüfen und sicherstellen.

Ich könnte natürlich schon die Prüfung der Variablen $Aktion von den Variablen $Hauptmenue, $Untermenue und ggfs. $Untermenue2 abhängig machen, aber das bläht den Code, meiner Meinung nach, nicht unerheblich auf.

Dein Ansatz an sich ist ja nicht ganz verkehrt, nur eben falschrum aufgezogen,

All diese/eure Überlegungen zielen natürlich auch darauf ab, den Code zu optimieren/sinnvoller zu programmieren, liefern aber nicht den Grund dafür, warum $Farbe nicht angezeigt wird bzw. "null" ist, ohne Fehlermeldung.

Das allein bringt dich zwar im Moment weiter, löst aber deinen Designfehler nicht. Da du deswegen sowieso dein Programm umstricken solltest, lohnt es sich nicht wirklich, im jetzigen noch nach Fehlern zu suchen.

dedlfix.

[hotti]

hi,

weil Du mit Deiner Schleife jeden in $_GET stehenden Paramater befragst
Lege daher die Schleife nur über Deine in Whitelist definierten Schlüsselparameter

Ich möchte $_GET auch komplett prüfen und brauche, da ich auch zwei Arrays habe, ja doch auch zwei Schleifen, oder? Eine für $_GET, eine fürs Durchlaufen des Whitelist-Arrays, um auch zu erkennen, ob das Whitelist-Array durchlaufen wurde.

Oder habe ich hier einen Denkfehler?

Ja. Herz und Seele einer Webanwendung ist eine Parameter Kontrollstruktur PKS. Eine PKS fragt NUR die Schlüsselparemeter ab, welche der Programmierer festlegt. Darüber wird der weitere Ablauf gesteuert, egal nach welchem Design Pattern (MVC, State Transition usw) die Webanwendung gemacht ist.

Anstelle einer gewöhnlichen PKS mit if/elseif/else oder einen Switch über die Schlüsselparameter geht das mit Deiner Schleife (Whitelist), dieselbe Idee habe ich vor vielen Jahren schon umgesetzt, das hat sich bei mir bewährt und wird sich auch bei Dir bewähren ;)

Und jetzt der springende Punkt: Wenn über die PKS oder Deine Schleife über die Whitelist einer der Schlüsselparameter gesetzt ist (nutze isset, Tipp von dedlfix, auch Tipp von mir), ERST DANN fragst Du die restlichen Parameter ab, welche für den weiteren Verlauf Deines Programms notwendig sind.

Viel Erfolg,
Hotti

[dedlfix]

Tach!

$Parameter = array ("Hauptmenue", "Untermenue", "Untermenue2", "Aktion", "Suche", "Nr", "Groesse", "Farbe");

$Whitelist = array ("/^Hauptmenue=\d{1,2}$/",
                       "/^Untermenue=\d{1}$/",
                       "/^Untermenue2=\d{1}$/",
                       "/^Aktion=[A-Za-z]*$/",
                       "/^Suche=\d{1}$/",
                       "/^Nr=\d{1,2}$/",
                       "/^Groesse=\d{1}$/",
                       "/^Farbe=\d{1,2}$/");

Dieses Konstrukt ist recht umständlich. Ein Array mit den Namen als Keys und den Mustern als Values täte es auch und wäre leichter zu pflegen und zu überblicken.

foreach ($_GET as $Schluessel => $Wert)
   {
      for ($i = 0; $i < count ($Parameter); $i++)
      {

Damit erwischt du nur die Werte, die auch übergeben wurden. Wenn du alle Pflichtparameter prüfen willst, brauchst du nun noch eine Extraliste, auf der du die bereits kontrollierten Parameter abhakst und am Schluss prüfst, ob was übrig geblieben ist.

Andersrum, wenn also die Parameterliste durchlaufen und dazu der GET-Parameter geprüft wird, fällt dir auf alle Fälle auf, wenn letzterer fehlt.

if ($Schluessel == $Parameter[$i]) {
            $ZuPruefen = $Parameter[$i] . '=' . $Wert;
            if (preg_match ($Whitelist[$i], $ZuPruefen))

Den Parameternamen brauchst du nicht in der Regexp zu prüfen, den hast du schon vergleichen. Das ist auch nicht sinnvoll, weil du ja eigentlich nur den Wert prüfen willst. Selbst wenn der Parametername nicht richtig groß/kleingeschrieben ist, wäre das (bei dir vermutlich) auch nicht weiter tragisch.

if ($_GET[$Parameter[$i]] !== null)

Das ist eine indirekte Prüfung. Man muss dazu wisssen, dass das Ergebnis beim lesenden Zugriff auf nicht vorhandene Variablen (und Array-Elemente) ein null zurückgibt. Außerdem bringt so ein Zugriff eine Notice-Meldung. Besser ist das Prüfen mit isset() oder empty().

In deinem Fall aber kann an dieser Stelle $_GET[$Parameter[$i]] nicht mehr nicht vorhanden sein, weil du ja schon vorher ... du machst das so umständlich, dass mir die Worte fehlen, die Prüfung zu beschreiben.

Außen vor geblieben sind jedenfalls die Parameter, die gar nicht im GET enthalten waren. Wenn du nun blauäugig auf einen solchen zugreifst, bekommst du eine Notice-Meldung und null.

Wenn ich nun, zu Testzwecken, über echo die Variablen "Groesse" und "Farbe" ausgeben lasse, dann wird mir nur der Wert der Variablen "Groesse" ausgegeben, aber nicht der Variablen "Farbe".

Dann verfolg den Weg zurück bis zu der Stelle, an der er erstellt werden soll.

Es wird mir aber auch keine Fehlermeldung ausgegeben, d.h. die Variable "Farbe" ist "Null", ohne dass ich aber irgendwelche weiteren Zuweisungen für diese beiden Variablen treffe.

error_reporting steht auch aauf E_ALL und display_errors auf on?

Mit FireBug habe ich noch nie gearbeitet, da ich mit diesem Addon absolut nicht zurecht komme, falls dies zur Lösungsfindung beitragen sollte, was ich aber ausschliessen kann, da die Adressleiste ja dagegen spricht, dass bei der Übergabe/Übermittlung ein Fehler vorliegt.

Firebug arbeitet mit dem Ergebnis im Browser, für die PHP-Fehlersuche kann er nichts weiter beitragen. Da reicht zu schauen, ob der Quelltext wie erwartet erzeugt wurde. Firebug ist da eher hinderlich, besonders wenn du das von ihm fehlerkorrigierte zum DOM interpretierten Baum anschaust.

dedlfix.