Ik ben bezig met een site met meerdere invulvelden.
Nu gebruik ik !empty om te kijken of er lege posts zijn.
Dit ziet er zo uit:
<?php
if(!empty($_POST['onderwerp'])){
$sql = "INSERT INTO ptas(vak_afkorting,Periode,Klas,Schooljaar,Toets,Onderwerp,Duur,Weging_rapport,Weging_se,Toetsvorm,Tijdsverlenging,Herkansing,Gebruikte_methode,Inleverdatum,Toelichting,Methode_toevoegen)
VALUES('$afkorting','$periode','$klas','$schooljaar','$toets','$onderwerp','$duur','$rapport','$schoolexamen','$vorm','$tijdsverlenging','$herkansing','$methode','$inleverdatum','$toelichting','$methode_toevoegen')";
mysqli_query($mysql,$sql)
or die("De insertquery op de database is mislukt!".mysqli_error($mysql)." $sql");
echo"Het pta is ingevoerd!";
}
else{
echo"1 of meerdere velden zijn niet ingevuld!";
}
?>
Als het onderwerp niet ingevuld wordt, krijg je de melding "1 of meerdere velden zijn niet ingevuld!".
Maar als dit gebeurt, worden alle andere ingevulde velden weer leeggemaakt en moet je alles weer opnieuw invullen.
Weet iemand hoe ik ervoor kan zorgen dat de oude waardes blijven staan en dat ik alleen het onderwerp moet invullen?
Alvast bedankt
Zolang er enkel alleen nog maar geen POST-request heeft plaatsgevonden, kan je die $_POST-waardes nog steeds echo'en in de value-attributen van je velden. Controleer wel met isset() of ze bestaan.
Ik neem wel aan dat je alle waardes netjes escapes met mysqli_real_escape_string().
Nee. Waarden die escaped zijn voor databasegebruik zijn alleen voor de database bruikbaar. Die kunnen niet in het formulier gezet worden. Hiervoor is andere escaping nodig met htmlspecialchars. Htmlspecialchars is weer niet geschikt voor gebruik in de database, dus je zult beide apart moeten toepassen. Zie daar waarom het zo snel zo pijnlijk wordt om zinloos variabelen te maken.
Het kan wel, maar dan moet je de processen even van elkaar scheiden.
Je zou het volgende kunnen overwegen.
Test eerst of de ingevoerde inhoud correct is
1 Niet correct? Terug naar formulier, informatie is dat nog voorhanden
2 Wel correct? Nu pas gaan escapen en wegschrijven naar de database.
Okay waar te beginnen. Er worden hier zoveel zaken met voeten getreden...
Om allereerst antwoord te geven op je vraag: het is inderdaad mogelijk om de POST-waarden terug te plaatsen in het formulier, maar dat is alleen mogelijk als je het weergeven van het formulier combineert met het verwerken van het formulier, en dat is uit oogpunt van nette en overzichtelijke code schrijven niet zo fantastisch. Idealiter scheid je deze twee stappen, want het zijn echt twee verschillende acties: het een houdt zich bezig met het weergeven van een formulier in een HTML-document, en het ander betreft het verwerken van gePOSTe data.
Dan over dit HTML-document. Dit moet een kloppend HTML-document zijn. De <html>-tags staan wel op hele vreemde plaatsen en de <body>-tags ontbreken in het geheel. Indien een HTML-document niet kloppend is is er vervolgens geen enkele garantie dat de rest van je HTML werkt zoals je zou verwachten. Zorg dus dat je HTML op orde is/komt.
Een veelgebruikte -en nette- manier voor formulier-verwerking is het POST/redirect/GET patroon. Concreet wijst de POST-action naar een aparte URL die het formulier verwerkt en daarna doorstuurt (indien de validatie en verwerking succesvol was) of terugstuurt (indien de validatie niet slaagde). Hierbij twee aandachtspunten:
1. hier zul je dus over meerdere pagina's informatie moeten onthouden zodat je deze weer terug kunt plaatsen in het formulier indien er fouten waren;
2. er wordt gesproken over validatie: het is dus zaak om EERST al je DATA te inspecteren alvorens je deze probeert weg te schrijven naar je database; indien de DATA klopt kan deze de database in, indien de DATA niet klopt zou je teruggestuurd moeten worden naar het formulier met een toelichting wat hier niet aan klopt zodat deze informatie gecorrigeerd kan worden
En hoe zorg je er dan voor dat informatie wordt onthouden over meerdere pagina's? Stop het in $_SESSION, bij voorkeur in een sub-array voor formulierdata, bijvoorbeeld: $_SESSION['forms']['pta'] ofzo. Hierbinnen zou je ook nog onderscheid kunnen maken tussen de feitelijk ingevoerde data en bijbehorende foutmeldingen (respectievelijk subarrays 'data' en 'errors' ofzo). Vervolgens flag je de URL waarin het formulier wordt weergegeven, bijvoorbeeld met ?errors=1, wat vervolgens een trigger is om een mededeling te doen dat er iets foutging en dat er data in je sessie zit waarmee je het formulier initialiseert met eerder ingevoerde data.
Tot slot: het is altijd zaak om output te escapen. Hoe je dit doet, hangt van de context af.
In HTML gebruik je htmlspecialchars(), en in SQL gebruik je real_escape_string() in combinatie met quotes, want het een is niet veilig zonder het ander.
En als je zoiets hebt van "poeh dat is wel erg veel moeite voor iets relatief simpels" dan heb je misschien gelijk, maar het voegt ook een heleboel toe:
- gebruikersgemak en gebruiksvriendelijke interfaces
- geen troep in je database
en dat betaalt zich binnen een mum van tijd weer terug.
Idealiter voer je dit truukje niet elke keer opnieuw uit als je een formulier moet bakken maar schrijf je eenmalig de bouwstenen voor het creëren van pagina's en het bouwen van formulieren zodat je niet elke keer het wiel opnieuw hoeft uit te vinden. En als je daar geen zin in hebt, laat je dan een Content Management Systeem (CMS) aanmeten die dit al voor een groot deel voor jou heeft geregeld.
>> Vervolgens flag je de URL waarin het formulier wordt weergegeven, bijvoorbeeld met ?errors=1
Waarom dan niet in je sessie kijken of er een foutmelding is? Waarom een flag? (Het kan wel, maar ik vraag me af waarom je daarvoor kiest als je toch al een sessie gebruikt.)
Omdat je op die manier expliciet in de "fout toestand modus" schiet. En het is in eerste instantie bedoeld als hulpmiddel om (buiten je formulier) iets visueels te tonen, bijvoorbeeld:
<?php
if (isset($_GET['errors'])) {
?><div class="error">Er is iets misgegaan. Controleer je invoer en probeer het nogmaals.</div><?php
}
// ... hier dan je formulier
?>
De initialisatie van je formulier-data, als je dit meer in classes gaat gieten, heeft verschillende bronnen:
1. bij het initieel laden van de formulier pagina kan dit een array zijn met defaults;
2. bij het verwerken van het formulier is dit doorgaans $_POST;
3. en bij het falen van validatie en terugkeren in het formulier is dit $_SESSION.
Zo'n URL-variabele kan je helpen met het nemen van de beslissing waar deze data vandaan moet komen en is ook nodig om onderscheid te kunnen maken tussen geval #1 en #3.
Je zou je validatie ook (deels) naar de client kunnen brengen (javascript), dat geeft vaak een betere "user experience" voor de gebruiker (een rood veld als je iets vergeet, of in ieder geval een alert voor verzenden). De velden blijven dan gewoon zoals ze waren, en de gebruiker kan de input corrigeren.
Op de server hoef je de controle dan alleen nog "voor de zekerheid" over te doen (iemand heeft javascript disabled, of zit gewoon te hacken). De afhandeling hoeft in die gevallen dan "minder mooi" te zijn.
Nog even een duit in het zakje mbt de discussie hierboven: Ik gooi alle meldingen in een array in de session (meldingstekst + type = algemeen, waarschuwing, fout, enz). Zodra er dan een pagina getoond wordt (dat kan dus pas de GET na een POST+redir zijn) wordt deze lijst met meldingen aan de HTML toegevoegd (en daarna dus geleegd).
Ik zeg niet dat het niet kan wat jij aangeeft. Ik vraag me alleen dus af waarom op die manier. In jouw voorbeeld zou ik de URL kunnen aanroepen met error flag terwijl er helemaal geen error is (wat bij slechte coding zou kunnen leiden tot een error). Session is betrouwbaarder dan een externe parameter dus vandaar dat ik me afvroeg of je daar een specifieke reden voor had.
