[PHP / MySql] Waarde niet geplaatst i.c.m. Netscape 7.

[Speedpete]

Ik heb een script dat alle waarden uit een gesubmit formulier leest, en aan de hand hiervan een query voor MySql opbouwt.

De query bestaat uit een id per gebruiker (resp_nr), een pagina waar deze was gebleven (resp_page) en verder alle ingevulde velden. Zie ook het volgende stukkie code:

PHP:

    $nextpage = $HTTP_POST_VARS['nextpage'];
    $query = "update $table set resp_page='".$nextpage."'";

    foreach($HTTP_POST_VARS as $var=>$value)
    {
        $value = str_replace(",",".",$value);
        $value = makeSafe($value);

        if($var != "nextpage" && 
                   $var != "Submit" && 
                   $var != "resp_nr" && 
                   $var != "Reset" && 
                   (ereg(".", $value) == 1))
        {
            $query = $query.", $var='$value'";
        }
    }

    $query = $query." where resp_nr=$resp_nr";
    $result =  mysql_db_query($db,$query);

Alle script worden vanuit een vb-proggel gegenereerd en $db en $table zijn van tevoren reeds bepaald. De makeSafe functie gooit een string door een reeks handelingen heen om de uiteindelijke verwerking (via odbc naar spss) niet in de war te sturen.

Wat is nu het probleem? Zodra ik met Netscape 7 (mijn no.1 browser) het zaakje invul wordt resp_page niet opgeslagen, de overige variabelen wel. Als ik hierna dan de query laat printen op het scherm, krijg ik netjes:

code:

update juniorhigh set 
    resp_page='result_2.php', 
    VAR1='1', 
    VAR2='20', 
    VAR3='1', 
    VAR4='1', 
    VAR5='1', 
    VAR6='4', 
    VAR7='4' 
    where resp_nr=55

Deze query copy-pasten naar MySql geeft netjes resulaat en plaatst de waarde resp_page wel gewoon.

Wat is het probleem? Ligt dit aan Netscape ofzo In Internet Explorer 5.5 en 6 werkt alles wel goed namelijk. Daarnaast komt dit probleem tegelijk met het niet meer kunnen posten in diverse fora... kapt NS de eerste waarde af, of moet ik bij mijzelf te raden gaan? Alvast bedankt....

[ Voor 10% gewijzigd door Speedpete op 20-05-2003 09:55 . Reden: query verneukte layout... ]

[Verwijderd]

Misschien support netscape vb niet

[Speedpete]

Verwijderd schreef op 20 mei 2003 @ 10:05:
Misschien support netscape vb niet

Het is een losse app in VB die alles genereerd

In principe is m'n systeem zo:

VB --> Mysql Definitie + PHP pagina's --> ODBC + SPSS 10/11

[Bosmonster]

Hou er ook rekening mee dat Netscape 7 een extreem verouderde en buggy Mozilla versie gebruikt.. (1.0 de eerste stable versie dus)

Waarom gebruik je niet gewoon een recente Mozilla build? (1.3.1 is de laatste).

[ Voor 10% gewijzigd door Bosmonster op 20-05-2003 10:10 ]

[crisp]

Gebruik je toevallig in je form GET en POST vars door elkaar (GET vars in je action bijvoorbeeld)?

[Speedpete]

Bosmonster schreef op 20 mei 2003 @ 10:09:
Hou er ook rekening mee dat Netscape 7 een extreem verouderde en buggy Mozilla versie gebruikt..

Waarom gebruik je niet gewoon een recente Mozilla build? (1.3.1 is de laatste).

Goeie... zal zo eens kijken of ik Mozilla kan installen...

[Speedpete]

crisp schreef op 20 mei 2003 @ 10:17:
Gebruik je toevallig in je form GET en POST vars door elkaar (GET vars in je action bijvoorbeeld)?

Alle waarden zijn POST. Er is ook het een en ander in sessies maar daarmee wordt niks gedaan i.c.m. queries.

[dusty]

in IE werkt het wel in netscape niet, dan ligt het niet aan de code ofwel soms?

Ik heb gehoord dat willem hem erg graag in W&G wou hebben dus komt ie:

Move P&W -> W&G

[Bosmonster]

Oftewel, post eens de HTML die het formulier post... want dat is het enige dat door de browser afgehandeld wordt en dus voor een fout zou moeten kunnen zorgen

[Verwijderd]

doet dit het wel?
en post eens hoe je het form post...

PHP:

<?
    $nextpage = "result_2.php";
    $query = "update $table set resp_page='".$nextpage."'"; 

    foreach($HTTP_POST_VARS as $var=>$value) 
    { 
        $value = str_replace(",",".",$value); 
        $value = makeSafe($value); 

        if($var != "nextpage" && 
                   $var != "Submit" && 
                   $var != "resp_nr" && 
                   $var != "Reset" && 
                   (ereg(".", $value) == 1)) 
        { 
            $query = $query.", $var='$value'"; 
        } 
    } 

    $query = $query." where resp_nr=$resp_nr"; 
    $result =  mysql_db_query($db,$query);
?> 

[Speedpete]

Bosmonster schreef op 20 May 2003 @ 11:02:
Oftewel, post eens de HTML die het formulier post... want dat is het enige dat door de browser afgehandeld wordt en dus voor een fout zou moeten kunnen zorgen

Je bedoelt het html-formulier?? Da's vrijwel onleesbaar (door genereren uit proggel) maar dit is wat het formulier inhoudt:

code:

<form name="questionnaire" method="post" action="handle.php">
<input type="hidden" name="nextpage" value="result_2.php"></input>

In welk jaar bent u geboren?
19 <input onChange="checkField(this,20,90,'',0)" 
       onKeyUp="checkField(this,20,90,'',1)" 
       type="text" name="VAR2" size="2" maxlength="2"></input>

Hoeveel kinderen uit uw gezin zitten in het voortgezet onderwijs?
<input type="radio" name="VAR7" value="1">0 kinderen</input>
<input type="radio" name="VAR7" value="2">1 kind</input>
<input type="radio" name="VAR7" value="3">2 kinderen</input>
<input type="radio" name="VAR7" value="4">3 kinderen of meer</input>

<input type="Submit" name="Submit" value="Ok"></input>

</form>

Het javascript dat aangeroepen wordt, controleerd of het meegegeven veld (this) een waarde bevat hoger dan 20, lager dan 90... Het script is het probleem niet want dat werkt perfect onder elke browser....

Verwijderd schreef op 20 May 2003 @ 11:04:
doet dit het wel?
en post eens hoe je het form post...

PHP:

<?
    $nextpage = "result_2.php";
    $query = "update $table set resp_page='".$nextpage."'"; 

    foreach($HTTP_POST_VARS as $var=>$value) 
    { 
        $value = str_replace(",",".",$value); 
        $value = makeSafe($value); 

        if($var != "nextpage" && 
                   $var != "Submit" && 
                   $var != "resp_nr" && 
                   $var != "Reset" && 
                   (ereg(".", $value) == 1)) 
        { 
            $query = $query.", $var='$value'"; 
        } 
    } 

    $query = $query." where resp_nr=$resp_nr"; 
    $result =  mysql_db_query($db,$query);
?> 

Geen verschil. Daarnaast kan ik de var. nextpage niet hard er in zetten, het idee is dat er een vragenlijst is van zeg 10 pagina's, die allemaal gebruik maken van 1 database-interface script.

[ Voor 51% gewijzigd door Speedpete op 20-05-2003 11:25 . Reden: layout... ]

[Bosmonster]

Snap niet waarom de PHP code bekeken wordt.

We zitten nu in W&G, omdat het een CLIENTSIDE browser probleem is. De PHP-code heeft daar dus bar weinig mee te maken...

Ga eens simpel na met print_r($_POST) Wat je binnen krijgt van de browsers.

[ Voor 21% gewijzigd door Bosmonster op 20-05-2003 11:34 ]

[crisp]

waar komt $resp_nr nu eigenlijk vandaan? een sessie of zo? ik zie 'm namelijk niet terug in het form...

[Speedpete]

Ow... $resp_nr komt wel uit de sessie.. foutje.. Maar resp_nr werkt gewoon... en al plaats ik 10x in de query dat $resp_page een waarde heeft, deze wordt nooit geset...

[Bosmonster]

Of aangezien resp_page niet opgeslagen wordt... waar komt $nextpage vandaan?

Speedpete schreef op 20 May 2003 @ 11:40:
Ow... $resp_nr komt wel uit de sessie.. foutje.. Maar resp_nr werkt gewoon... en al plaats ik 10x in de query dat $resp_page een waarde heeft, deze wordt nooit geset...

Maar je snapt wel dat uitvoer van php-code op de SERVER nooit beinvloed kan worden door de BROWSER?

Wel de waarden die je krijgt van de browser, vandaar de print_r($_POST).

[ Voor 75% gewijzigd door Bosmonster op 20-05-2003 11:43 ]

[crisp]

Bosmonster schreef op 20 May 2003 @ 11:41:
Of aangezien resp_page niet opgeslagen wordt... waar komt $nextpage vandaan?
[...]

hier:

code:

<input type="hidden" name="nextpage" value="result_2.php"></input>

btw w3c:

17.4 The INPUT element

Start tag: required, End tag: forbidden

[ Voor 8% gewijzigd door crisp op 20-05-2003 11:46 ]

[Speedpete]

Ja ik begrijp dat de uitvoer van de server niet door de browser beinvloed wordt.

print_r($_POST) geeft echter geen uitvoer... ligt het probleem daar dan? print_r($HTTP_POST_FILES) geeft namelijk wel wat. De uitvoer die ik dan krijg (print_r + query)


Array
(
[nextpage] => result_2.php
[VAR1] => 1
[VAR2] => 34
[VAR3] => 1
[VAR4] => 1
[VAR5] => 1
[VAR6] => 4
[VAR7] => 4
[Submit] => Ok
)

update juniorhigh set
resp_page='result_2.php',
VAR1='1',
VAR2='34',
VAR3='1',
VAR4='1',
VAR5='1',
VAR6='4',
VAR7='4'
where resp_nr=1111

[Speedpete]

crisp schreef op 20 May 2003 @ 11:45:
...

btw w3c:


[...]

Argh.. net gewend om die end-tag te gebruiken ... kan ik weer terug... naja... ff search en replace gedaan en wat betreft de uitvoer maakt het niets uit.. de waarde krijg ik nog steeds niet...

[Bosmonster]

Ik zie toch een goeie query in je vorige reply?

[crisp]

accepteert je browser wel cookies? Het kan natuurlijk zijn dat je Netscape zo is ingesteld dat 'ie geen cookies lust, waardoor je sessie natuurlijk niet bewaard blijft.

en waarschijnlijk draai je een PHP versie >4.0 en < 4.1.2 aangezien $_POST niet werkt, maar $HTTP_POST_VARS wel

[ Voor 27% gewijzigd door crisp op 20-05-2003 12:18 ]

[Speedpete]

crisp schreef op 20 mei 2003 @ 12:17:
accepteert je browser wel cookies? Het kan natuurlijk zijn dat je Netscape zo is ingesteld dat 'ie geen cookies lust, waardoor je sessie natuurlijk niet bewaard blijft.

en waarschijnlijk draai je een PHP versie >4.0 en < 4.1.2 aangezien $_POST niet werkt, maar $HTTP_POST_VARS wel

Versie klopt, maar cookies worden niet eens gebruikt, al slikt ie ze wel..

Ik ga nog eens rondturen in m'n scripts...

[crisp]

Speedpete schreef op 20 May 2003 @ 12:21:
[...]


Versie klopt, maar cookies worden niet eens gebruikt, al slikt ie ze wel..

Ik ga nog eens rondturen in m'n scripts...

stuur je je sessie-id dan mee in de url ofzo?

[Speedpete]

crisp schreef op 20 May 2003 @ 12:21:
[...]

stuur je je sessie-id dan mee in de url ofzo?

Momenteel wel, normaal gesproken gaat alles via cookies, maar ik wilde cookies ff eruithebben...

Probleem heb ik denk ik (gedeeltelijk) ondekt.

Als ik in m'n mysql-log kijk, wordt er na het invullen in Netscape, een query uitgevoerd (dus NA de correcte query) die de waarde resp_page leegmaakt.

Als ik in IE invoer, gebeurd dit niet...

Het vreemde is: er is helemaal geen query die alles leeg maakt... het lijkt alsof de pagina zelf, opnieuw wordt aangeroepen... zie dit:

18 Connect root@localhost on
18 Init DB test
18 Query select resp_nr from juniorhigh where resp_nr=1111
18 Init DB test
18 Query update juniorhigh set resp_page='result_2.php <etc...>
18 Quit
19 Connect root@localhost on
19 Init DB test
19 Query select resp_nr from juniorhigh where resp_nr=1111
19 Init DB test
19 Query update juniorhigh set resp_page='' where resp_nr=1111
19 Quit

22 Connect root@localhost on
22 Init DB test
22 Query select resp_nr from juniorhigh where resp_nr=3333
22 Init DB test
22 Query insert into juniorhigh (resp_nr) values (3333)
22 Init DB test
22 Query update juniorhigh set resp_page='result_2.php', <etc...>
22 Quit

18 en 19 zijn van Netscape, 22 is van IE... weird??

[Speedpete]

GoT it!

vieze oplossing maar nu werkt het wel...

NS roept op de 1 of andere vage manier de pagina nogmaals aan. Hierdoor is de waarde resp_page leeg en wordt deze door middel van een query leeg ingesteld.

Waarom NS het doet? Geen idee, maar ik laat nu door middel van een if-statement checken of de query een lege resp_page heeft, en zo ja: niet uitvoeren die hap. Dan werkt het.

Iedereen bedankt voor de hulp.

[crisp]

Speedpete schreef op 20 May 2003 @ 12:57:
GoT it!

vieze oplossing maar nu werkt het wel...

NS roept op de 1 of andere vage manier de pagina nogmaals aan. Hierdoor is de waarde resp_page leeg en wordt deze door middel van een query leeg ingesteld.

Waarom NS het doet? Geen idee, maar ik laat nu door middel van een if-statement checken of de query een lege resp_page heeft, en zo ja: niet uitvoeren die hap. Dan werkt het.

Iedereen bedankt voor de hulp.

Ik zou het heel vreemd vinden als dat zo zou zijn. En waarom zou dan net dat hidden field opeens leeg zijn, en de rest nog wel gevuld? Zit er niet nog ergens een javascript submit in die pagina ofzo? De complete HTML zou imho toch uitsluitsel moeten kunnen geven, wat je nu doet is enkel symptoon-bestrijding...

[ Voor 9% gewijzigd door crisp op 20-05-2003 13:07 ]

[Speedpete]

crisp schreef op 20 May 2003 @ 13:01:
[...]

Ik zou het heel vreemd vinden als dat zo zou zijn. En waarom zou dan net dat hidden field opeens leeg zijn, en de rest nog wel gevuld? Zit er niet nog ergens een javascript submit in die pagina ofzo?

Het zit niet in het hidden field... de werking van mijn script:

code:

result_1.php [nextpage = result_2.php] --> handle.php 

handle.php --> result_2.php [nextpage = result_3.php]

result_2.php [nextpage = result_3.php] --> handle.php

etc....

result_x.php [nextpage = end] --> handle.php

handle.php : echo "klaar"

Handle staat centraal en wordt aangeroepen door complete, bestaande, pagina's met elk een hidden field met daarin de volgende pagina. Dit hidden field heeft een hard-coded value...

Handle.php wordt door Netscape 7 2x uitgevoerd. In handle.php staan dus geen waarden, velden, etc. nextpage bestaat dus niet, is leeg, en daarom wordt deze bij de tweede uitvoer van handle.php leeg ingesteld. Vraag me niet waarom, maar zo doet ie het.

toevoeging: nextpage zit altijd in de query, de rest wordt (kan je zien aan m'n openingspost) alleen toegevoegd indien de waarde niet leeg is...

Het is overigens in het geheel een erg mooi systeem, en dankzij die handle kan ik me concentreren op 1 database toegang en hoef ik niet losse scripts achter elke pagina te proppen.

Een vragenlijst bestaat hierdoor bij mij altijd uit [aantal pagina's] + 1...

[ Voor 7% gewijzigd door Speedpete op 20-05-2003 13:11 ]

[crisp]

oftewel met Netscape wordt blijkbaar handle.php nog een keer aangeroepen zonder POST vars.
Hoe redirect je vanuit handle.php naar de nextpage? met een location-header?
staat daar een volledig URL in, of enkel header('location: '.$nextpage); ?

(ook al heb je het probleem nu opgelost, ik ben gewoon nieuwsgierig naar de reden van dit gedrag)

[ Voor 24% gewijzigd door crisp op 20-05-2003 13:18 ]

[Speedpete]

Ik ben ook nieuwsgierig

Ik connect door middel van een javascript-aanroep. Bij alle test die ik heb uitgevoerd was deze aanroep uitgecommentarieerd...

[Bosmonster]

Speedpete schreef op 20 May 2003 @ 13:28:
Ik ben ook nieuwsgierig

Ik connect door middel van een javascript-aanroep. Bij alle test die ik heb uitgevoerd was deze aanroep uitgecommentarieerd...

Je connect dmv een javascript aanroep...

Je bedoelt je gebruikt een javascript redirect? Laat de code dan eens zien

[crisp]

Speedpete schreef op 20 mei 2003 @ 13:28:
Ik ben ook nieuwsgierig

Ik connect door middel van een javascript-aanroep. Bij alle test die ik heb uitgevoerd was deze aanroep uitgecommentarieerd...

mzz, dus jouw test was eigenlijk alleen result_1.php -> handle.php, waarbij handle.php dus verder geen output meer naar de browser genereerd(?).
Strange...
Waarom trouwens redirecten met javascript? Je maakt je script dan wel erg afhankelijk daarvan imho...

Ik zal iig als we er zo niet uitkomen vanavond eens een testcase opzetten thuis.

[ Voor 8% gewijzigd door crisp op 20-05-2003 13:34 ]

[Speedpete]

Bosmonster schreef op 20 May 2003 @ 13:30:
[...]


Je connect dmv een javascript aanroep...

Je bedoelt je gebruikt een javascript redirect? Laat de code dan eens zien

code:

<SCRIPT LANGUAGE="javascript">
    top.location = "result_2.php";
</SCRIPT>

[ Voor 60% gewijzigd door Speedpete op 20-05-2003 13:37 ]

[Speedpete]

crisp schreef op 20 mei 2003 @ 13:33:
[...]

mzz, dus jouw test was eigenlijk alleen result_1.php -> handle.php, waarbij handle.php dus verder geen output meer naar de browser genereerd(?).
Strange...
Waarom trouwens redirecten met javascript? Je maakt je script dan wel erg afhankelijk daarvan imho...

Waarom Javascript? Nooit anders gedaan, werkt altijd al als een tierelier... daarnaast:

Remember that the header() function must be called before any actual output is sent.

Dat wil ik dus niet altijd...

-----

Het probleem is dus, kort omschreven:

-handle leest http_post_vars[] uit en plaatst deze waarden, mits niet leeg, in een query. resp_page valt hier buiten en wordt altijd toegevoegd.
-Hierna voert handle de query uit.
-Indien succesvol: redirecten naar de volgende pagina.

Wat dus gebeurd is dat NS handle.php 2x uitvoerd. Dus de eerste maal is http_post_vars[] gevuld met de data uit de voorgaande pagina, de tweede maal is http_post_vars[] leeg omdat handle.php geen form bevat. Daarom wordt de lege waarde voor resp_page ingevuld.

[ Voor 8% gewijzigd door Speedpete op 20-05-2003 13:39 ]

[Bosmonster]

tis :

top.location.href

location is het location object, href de string-property met de url.

Had je het probleem met Mozilla 1.3.1 trouwens ook nog?

[ Voor 22% gewijzigd door Bosmonster op 20-05-2003 13:39 ]

[Speedpete]

Bosmonster schreef op 20 May 2003 @ 13:38:
tis :

top.location.href

location is het location object, href de string-property met de url.

Had je het probleem met Mozilla 1.3.1 trouwens ook nog?

ow... zal ik in het vervolg wel aanpassen

Het werkte altijd al (elke browser) en ja.. dan controleer je niet of het wel 100% juist is...

[crisp]

Bosmonster schreef op 20 May 2003 @ 13:38:
tis :

top.location.href

location is het location object, href de string-property met de url.

Had je het probleem met Mozilla 1.3.1 trouwens ook nog?

als je in deze context geen property aangeeft, maar enkel het location object, dan zal js automatisch aannemen dat de href property bedoelt wordt. Lijkt me dus niet dat dit het probleem veroorzaakt (plus dat TS aangeeft deze constructie in de test gedisabled te hebben).

Speedpete schreef op 20 mei 2003 @ 13:37:
[...]
Waarom Javascript? Nooit anders gedaan, werkt altijd al als een tierelier... daarnaast:
[...]
Dat wil ik dus niet altijd...

dat is te voorkomen door bijvoorbeeld output-buffering te gebruiken, of je script logischer in te delen

[ Voor 25% gewijzigd door crisp op 20-05-2003 13:46 ]

[Bosmonster]

Ik veronderstelde niet dat dat de oorzaak was Was alleen tipke..

Maaruh.. werkt het onder Mozilla 1.3.1 nou?

Anders ben je er snel achter dat het een oudere Mozilla bug is..

[Speedpete]

Bosmonster schreef op 20 mei 2003 @ 13:45:
Ik veronderstelde niet dat dat de oorzaak was Was alleen tipke..

Maaruh.. werkt het onder Mozilla 1.3.1 nou?

Anders ben je er snel achter dat het een oudere Mozilla bug is..

Mozilla niet meer installed... Doe ik thuis wel, het werkt nu en dat is even het belangrijkste.

Ik wilde overigens toch al over naar Mozilla.. al die AOL zooi etc... Thuis op me pc ff installen want daar werkt netscape 7 al niet lekker.. dus gelijk ons draakje eroverheen Op me laptop draait NS7 prima...

[ Voor 14% gewijzigd door Speedpete op 20-05-2003 13:53 ]

[crisp]

ik heb deze gevonden voor Moz1.1 beta: http://bugzilla.mozilla.org/show_bug.cgi?id=137936

lijkt er wel op nietwaar? even doorlezen..

[Speedpete]

crisp schreef op 20 May 2003 @ 13:54:
ik heb deze gevonden voor Moz1.1 beta: http://bugzilla.mozilla.org/show_bug.cgi?id=137936

lijkt er wel op nietwaar? even doorlezen..

Dat is hum...

[crisp]

Speedpete schreef op 20 May 2003 @ 14:01:
[...]
Dat is hum...

Gezien de reacties en het feit dat de bug nog open is lijkt het me dat het in de laatste versie Mozilla ook nog speelt. Toch geen prettig bugje imho.
Het heeft dus iets te maken met het wel of niet voorkomen van de character encoding in de headers en/of meta tags...

[Bosmonster]

Mwah.. severity critical, target milestone: 1.1 beta

Denk dat ie (grotendeels) opgelost is eerlijk gezegd.