Submit wird nicht gemeldet
Linuchs
- php
Hallo,
ichg bin fast am Verzweifeln.
Habe eine Adressliste und für jede Adresse (= Zeile) kann eine Checkbox angeklickt werden, um die Adresse in der DB zu markieren.
Nun hängt es ab von der Anzahl der Zeilen, ob der Submit gemeldet wird. Bis 120 Zeilen ist alles klar, bei 130 Zeilen wird er nicht gemeldet.
echo "submit_aen=[".$_POST['submit_aen']."]<br>";
Anzeige neue Seite nach Klick auf Submit bis 120 Zeilen:
submit_aen=[ändern]
bei 130 Zeilen:
submit_aen=[]
Was ist das für ein Effekt?
Gruß, Linuchs
Hi,
Habe eine Adressliste und für jede Adresse (= Zeile) kann eine Checkbox angeklickt werden, um die Adresse in der DB zu markieren.
Nun hängt es ab von der Anzahl der Zeilen, ob der Submit gemeldet wird. Bis 120 Zeilen ist alles klar, bei 130 Zeilen wird er nicht gemeldet.
wird das Formular mit GET oder mit POST versendet?
Da die meisten Browser eine Grenze für die Länge der URL-Zeile haben, können bei GET-Requests mit sehr vielen Parametern ab einer gewissen Position alle nachfolgenden abgeschnitten werden.
Falls das nicht dein Problem ist: Mehr Details, bitte.
Ciao,
Martin
Tach,
wird das Formular mit GET oder mit POST versendet?
aus dem OP: „$_POST['submit_aen']“
mfg
Woodfighter
Hallo,
wird das Formular mit GET oder mit POST versendet?
aus dem OP: „$_POST['submit_aen']“
verdammt, was hab ich denn da an den Augen? Sind das etwa Tomaten? ;-)
Danke für den berechtigten Hinweis,
Martin
Hi,
wird das Formular mit GET oder mit POST versendet?
mit method="post"
Falls das (Grenze für die Länge der URL-Zeile) nicht dein Problem ist: Mehr Details, bitte.
Es sind reichlich Variablen per Post zu übergeben.
Fünfmal hidden für die gesamte form, 11 pro Zeile und ein submit. Bis 123 Zeilen wird der submit übertragen, dann sind es also 1359 Variablen.
Wenn 124 Zeilen abgeschickt werden, kommt der submit nicht mehr mit.
Falls es ein Limit gibt, ist das mit einem OS-Update reingekommen, früher gab es keine Probleme.
Gruß Linuchs.
Hallo,
Es sind reichlich Variablen per Post zu übergeben.
Fünfmal hidden für die gesamte form, 11 pro Zeile und ein submit. Bis 123 Zeilen wird der submit übertragen, dann sind es also 1359 Variablen.
Wenn 124 Zeilen abgeschickt werden, kommt der submit nicht mehr mit.
Per phpinfo() sehe ich max_input_vars = 1000 Bei 1359 Variablen werden wohl nicht alle gesendet, zum Beispiel die nicht angeklickten Checkboxen?
Gruß Linuchs.
Tach,
Per phpinfo() sehe ich max_input_vars = 1000 Bei 1359 Variablen werden wohl nicht alle gesendet, zum Beispiel die nicht angeklickten Checkboxen?
gesendet werden alle, aber PHP verarbeitet sie nicht, eine Maßnahme gegen HashDOS-Attacken.
mfg
Woodfighter
Moin!
Per phpinfo() sehe ich max_input_vars = 1000 Bei 1359 Variablen werden wohl nicht alle gesendet, zum Beispiel die nicht angeklickten Checkboxen?
gesendet werden alle, aber PHP verarbeitet sie nicht, eine Maßnahme gegen HashDOS-Attacken.
Nicht angeklickte Checkboxen werden NICHT gesendet. Das hat mit PHP nichts zu tun, das tun alle Browser schon seit Erfindung des <form>-Tags so.
- Sven Rautenberg
Moin!
Per phpinfo() sehe ich max_input_vars = 1000 Bei 1359 Variablen werden wohl nicht alle gesendet, zum Beispiel die nicht angeklickten Checkboxen?
gesendet werden alle, aber PHP verarbeitet sie nicht, eine Maßnahme gegen HashDOS-Attacken.
Nicht angeklickte Checkboxen werden NICHT gesendet. Das hat mit PHP nichts zu tun, das tun alle Browser schon seit Erfindung des <form>-Tags so.
Ja, deshalb muss ich zu jeder Checkbox ein hidden input machen mit dem "alten" Stand der Checkbox. Nur so merke ich, wenn der Haken aus der Checkbox rausgenommen wurde. Das Rausnehmen wird NICHT gemeldet. Zur Strafe musste ich gestern einen ganzen Tag suchen, warum nur 1000 inputs gemeldet wurden.
Alternative wäre, für jede mögliche Checkbox (gesendet oder nicht) mit dem DB-Eintrag zu vergleichen. Scheint mir aber mehr Resourssen zu schlucken als die zusätzlichen hidden inputs.
Obwohl - die Übertragungszeit für den upload der hidden inputs ist auch nicht zu vernachlässigen. Da mache ich mal einen neuen Faden auf.
Linuchs
Tach!
Alternative wäre, für jede mögliche Checkbox (gesendet oder nicht) mit dem DB-Eintrag zu vergleichen. Scheint mir aber mehr Resourssen zu schlucken als die zusätzlichen hidden inputs.
Obwohl - die Übertragungszeit für den upload der hidden inputs ist auch nicht zu vernachlässigen. Da mache ich mal einen neuen Faden auf.
Du musst da keinen neuen Faden aufmachen, sondern einfach die verschiedenen Varianten messen und dann die für dich günstigere nehmen.
dedlfix.
Tach,
Nun hängt es ab von der Anzahl der Zeilen, ob der Submit gemeldet wird. Bis 120 Zeilen ist alles klar, bei 130 Zeilen wird er nicht gemeldet.
echo "submit_aen=[".$_POST['submit_aen']."]<br>";
Anzeige neue Seite nach Klick auf Submit bis 120 Zeilen:
submit_aen=[ändern]
bei 130 Zeilen:
submit_aen=[]
läufst du vielleicht in ein Limit der PHP-Einstellung (max_input_vars, post_max_size, …)?
mfg
Woodfighter
Moin,
läufst du vielleicht in ein Limit der PHP-Einstellung (max_input_vars, post_max_size, …)?
Teufel, was es nicht alles gibt. Wie bekomme ich die Limits angezeigt und wie erhöhe ich sie?
echo "max_input_vars=[".max_input_vars."], post_max_size=[".post_max_size."]<br>";
meldet
max_input_vars=[max_input_vars], post_max_size=[post_max_size]
Gruß, Linuchs
Tach,
Teufel, was es nicht alles gibt. Wie bekomme ich die Limits angezeigt
http://php.net/manual/en/function.phpinfo.php
und wie erhöhe ich sie?
http://www.php.net/manual/en/configuration.changes.php
mfg
Woodfighter
Moin,
und wie erhöhe ich sie?
Funzt leider nicht.
ini_set( 'max_input_vars', '2222' );
phpinfo();
Steht weiterhin auf 1000.
Linuchs
Hallo,
und wie erhöhe ich sie?
http://www.php.net/manual/en/configuration.changes.php
Funzt leider nicht.
falsch, du bist auf dem Holzweg.
ini_set( 'max_input_vars', '2222' );
phpinfo();
>
> Steht weiterhin auf 1000.
Klar. Wie soll denn bitte eine Einstellung, die du erst \*nach\* dem Start eines Scripts änderst, schon \*vor\* dem Start wirksam sein?
Diese Einstellung kannst du nur wirksam in der php.ini ändern (oder .htaccess).
Ciao,
Martin
--
Husten kann böse Folgen haben.
Besonders im Kleiderschrank.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
Hallo,
ini_set( 'max_input_vars', '2222' );
phpinfo();
> >
> > Steht weiterhin auf 1000.
>
> Klar. Wie soll denn bitte eine Einstellung, die du erst \*nach\* dem Start eines Scripts änderst, schon \*vor\* dem Start wirksam sein?
> Diese Einstellung kannst du nur wirksam in der php.ini ändern (oder .htaccess).
Wenn ich die php.ini ändere, wirkt das dann ohne Apache-Neustart? Ich habe keine Ahnung, wie ich den Apache remote neu starten könnte.
Linuchs
Wenn ich die php.ini ändere, wirkt das dann ohne Apache-Neustart? Ich habe keine Ahnung, wie ich den Apache remote neu starten könnte.
Hat sich erledigt. Sehe gerade, dass ich an /etc/php5/apache2/php.ini per FTP nicht drankomme.
Soll der Provider machen.
Linuchs
Tach!
Sehe gerade, dass ich an /etc/php5/apache2/php.ini per FTP nicht drankomme. Soll der Provider machen.
Der wird dir vermutlich was husten, nur wegen dir an der Systemkonfiguration rumzuschrauben. Wenn er das tut bleibt dir aber immer noch die .htaccess oder .user.ini - je nach Art der PHP-Einbindung (Apache-Modul oder (F)CGI - verrät dir die phpinfo()).
dedlfix.
Tach!
Klar. Wie soll denn bitte eine Einstellung, die du erst *nach* dem Start eines Scripts änderst, schon *vor* dem Start wirksam sein?
Diese Einstellung kannst du nur wirksam in der php.ini ändern (oder .htaccess).
Neben .htaccess kommt ab PHP 5.3 auch noch .user.ini infrage. Beides ist abhängig von der Art der PHP-Einbindung in den Apachen.
In der Tabelle am Seitenanfang ist das, wie ich schon schrieb sehr schön zu sehen, da steht unter Changeable der Wert PHP_INI_PERDIR. Eine Erklärung dazu ist unter der Tabelle verlinkt.
dedlfix.
Tach!
läufst du vielleicht in ein Limit der PHP-Einstellung (max_input_vars, post_max_size, …)?
Wie bekomme ich die Limits angezeigt und wie erhöhe ich sie?
phpinfo(); Im Handbuch steht in der Nähe (irgendwo oben drüber) der Beschreibungen zu jeder Direktive eine Tabelle mit einer Spalte Changable, die aussagt, in welchem Kontext die Direktive geändert werden kann. Diese beiden werden nur außerhalb des Scripts zu ändern sein, denn wenn die Steuerung an das Script übergeben wird, haben die Limits schon zugeschlagen. Zudem gibt es auch noch mögliche Beschränkungen in der Webserverkonfiguration.
Sag mir aber mal, was du unter "gemeldet" verstehst. Dass erwartete Werte im $_POST nicht enthalten sind?
Schau dir auch mal das komplette $_POST mit print_r() oder var_dump() an, ob da was auffälliges zu sehen ist. Ebenso der Quelltext der HTML-Seite (am besten auch mal validieren lassen).
dedlfix.
Hi,
läufst du vielleicht in ein Limit der PHP-Einstellung (max_input_vars, post_max_size, …)?
Und wenn es keine nativen PHP-Einstellungen sind, die hier Schuld tragen – dann käme ggf. noch suhosin in Frage (falls PHP mit diesem Patch läuft) – suhosin.post.max_vars wäre wohl der wahrscheinlichste Kandidat.
MfG ChrisB
Hi,
läufst du vielleicht in ein Limit der PHP-Einstellung (max_input_vars, post_max_size, …)?
Und wenn es keine nativen PHP-Einstellungen sind, die hier Schuld tragen – dann käme ggf. noch suhosin in Frage (falls PHP mit diesem Patch läuft) – suhosin.post.max_vars wäre wohl der wahrscheinlichste Kandidat.
Provider hat max_input_vars deutlich hochgesetzt, Problem bleibt.
Habe ihn gebeten, auch suhosin.post.max_vars hochzusetzen. Schaun mer mal. Ist wie stochern im Nebel.
Linuchs
Hallo,
danke für eure Hilfe.
Mit dem Provider waren drei Durchgänge nötig:
1. max_input_vars auf 100000 gesetzt - kein Erfolg
2. uhosin.post.max_vars auf 100000 gesetzt - kein Erfolg
3. suhosin.request.max_vars auf 100000 gesetzt - jetzt geht es.
Ob suhosin.request.max_vars allein schukd war, weiss ich nicht.
Linuchs
Noch ein Rat:
Falls (oder bevor!) alles versagt (weiter unten lese ich von Dir sowas wie "soll der Provider machen") dann packe alles in key-value-Paare eines Hashes und übertrage den als JSON. Das wäre dann ein einziger String, den Du serverseitig wieder dekodieren kannst.
Das Beste daran: Man kann das sogar zippen! PHP hat für alle denkbaren zip-Methoden auch den Entpacker - Prüfe aber, ob das was bringt.
Damit erreichst Du vor allem, dass Deine Anwendung auch bei "hartleibigen" Providern läuft. Gerade im Bereich des Shared Hostings wirst Du auf viele Einstellungen treffen, die dem Umstand geschuldet sind, dass die Provider natürlich eine versehentliche "DDoS-Attacke" durch die Übertragung zu vieler Daten Richtung Server vermeiden wollen.
Es könnte also durchaus sein, das "jsnonifizieren" (ggf. das nachfolgende Zippen) und das Dekodieren der Daten auf dem Server ist letztendlich die bessere Lösung.