login  Naam:   Wachtwoord: 
Registreer je!
 Forum

leeg maken form na submit / doorsturen naar pagina (Opgelost)

Offline IndexS - 24/03/2016 17:47
Avatar van IndexSMySQL interesse Ik heb een form wat prima werkt. Nu loop ik echter tegen 1 probleem aan en 1 vraag.

Probleem:
Nadat form verstuurd is, blijven de velden ingevuld. Ik zou graag willen dat na het verzenden de inputvelden leeg zijn. Ik las iets over $_POST=array(); en dat heb ik geprobeerd maar heeft niet geholpen. Iemand een oplossing?

Vraag:
Na het versturen kan ik een echo geven dat het gelukt is. Deze melding komt dan onder het formulier te staan. Een andere manier is om na het versturen een andere pagina te openen. werkt prima met
php code - Bekijk de code zonder highlighting - Klap code in 
  1. echo "<script>window.parent.location='http://www.google.nl';</script>";


Is het ook mogelijk om na het verzenden een melding te krijgen dat het verstuurd is en dat daarna een andere pagina geopend wordt?

Plaatscode: 142495

10 antwoorden

Gesponsorde links
Offline Thomas - 24/03/2016 20:02
Avatar van Thomas Moderator Ik zou persoonlijk van het POST/redirect/GET patroon gebruik maken.

Kort door de bocht komt dit neer op het scheiden van de volgende acties:
1. het weergeven van het formulier, mogelijk met eerder ingevoerde informatie ingeval er bij de validatie (stap 2) fouten optraden;
2. het verwerken van het formulier, waarbij je eerst je invoer valideert voordat je deze gegevens verder verwerkt, er kunnen dan twee dingen gebeuren:
a. validatie mislukte: sla de eerder ingevulde gegevens (tijdelijk) op in een sessie en stuur de gebruiker terug naar het formulier met een indicatie dat er iets mis was (bijvoorbeeld ?errors=1 ofzo); hierbij is het wel zo (gebruikers)vriendelijk om bij de velden aan te geven wat er precies fout was zodat iemand snel zijn/haar gegevens kan verbeteren
b. validatie is geslaagd: verwerk het formulier verder en stuur de gebruiker door naar een
3. succes/bedankpagina, die je vertelt dat het opslaan/verwerken succesvol was, en wat er mogelijk verder van een gebruiker verwacht wordt of wat er verder gaat gebeuren

Teken hierbij aan dat er in stap 2 totaal geen output wordt geproduceerd en je na uitvoer van validatie (en eventueel verwerking) altijd wordt doorgestuurd of teruggestuurd; omdat enkel in deze actie $_POST inhoud heeft verkleint dit de kans op dubbelposts et cetera al een stuk.

Toegegeven, door de introductie van dit patroon ontstaat er ook wat overhead (omdat je mogelijk gegevens tijdelijk moet "redden" in je sessie) maar de algehele flow door je applicatie wordt beter door het compleet scheiden van deze acties. En ziet er dan ook een stuk minder uit als spaghetti(code) .

Dan nog wat kanttekeningen:
* Gebruik if ($_SERVER['REQUEST_METHOD'] == 'POST') { ... } in plaats van if (isset($_POST['een_of_ander_post_veld'])) { ... }

* overweeg om een CSRF token of andere voorziening (CAPTCHA?) in te bouwen om misbruik van je formulier te voorkomen

* overweeg om gebruik te maken van een mail library zoals PHPMailer omdat wanneer je zelf MIME mailtjes bouwt er nogal veel dingen mis kunnen gaan

Dit alles zou je kortweg kunnen samenvatten onder het devies "verdeel en heers".
Offline IndexS - 26/03/2016 13:36
Avatar van IndexS MySQL interesse Bedankt voor de uitleg!

Ik heb de de isset($POST[]) aangepast.
Ik maak gebruik van captcha maar dat had ik uit het voorbeeld weggelaten.

PHPMailer heb ik nog niet gebruikt maar zal daar eens induiken.

Is er een code voorbeeld van de PRG methode? Ik snap het idee wel, maar vind het lastig om het ook te verwerken in de code. Zal google eens raadplegen, maar mocht iemand een goed voorbeeld hebben dan hoor ik het graag.

Alvast bedankt!
Offline Thomas - 26/03/2016 14:20 (laatste wijziging 26/03/2016 14:22)
Avatar van Thomas Moderator Aan deze methode kun je meerdere invullingen geven.

Zo zou je bijvoorbeeld kunnen kiezen voor een aanpak met losse bestanden:
/contact/index.php
/contact/verwerken.php
/contact/succes.php

Maar ook zou je dit in één script kunnen stoppen.

Hierbij zou je de volgende overweging mee moeten nemen:
Als je kiest voor een aanpak met losse bestanden kopieer je waarschijnlijk een heleboel layout van de hoofdopmaak van je website. Wanneer je hier dan een wijziging in door wilt voeren dan is deze verspreid over meerdere bestanden en mag je deze wijziging dus ook meerdere keren toepassen, wat nogal inefficiënt en foutgevoelig is. Het zou dus beter zijn om een website-omvattend stramien te hebben voor de opbouw van je pagina's, waarbij je onderscheid maakt tussen de hoofdlayout (in de vorm van één maintemplate) en de verschillende pagina-typen (de "content" binnen de hoofdlayout).

Dit voert in principe veel verder dan de geschetste methode, maar op het moment dat je echt dynamische websites gaat bouwen zul je op een zeker moment tot de realisatie komen dat je een aantal uitdagingen tegelijkertijd zult moeten tacklen. Een efficiënte opbouw van de webpagina (van de oorspronkelijke request tot en met de uiteindelijke HTML output) is eigenlijk een van de belangrijkste pijlers van een dynamische website.

In deze generieke oplossing zitten dan ook voorzieningen dat de hoofdlayout niet gegenereerd wordt wanneer een pagina-type (bijvoorbeeld een contactformulier) geen output produceert, bijvoorbeeld in de verwerkstap van een formulier.
Bedankt door: IndexS
Offline IndexS - 26/03/2016 17:54 (laatste wijziging 27/03/2016 12:25)
Avatar van IndexS MySQL interesse Ik heb nu het volgende:

index.php -> formulier met layout
actie.php -> controle en verzenden via phpmailer
csrf.php -> verzorgt token
bericht.php -> inhoud formulier omgezet in $inhoud

Na verzenden worden de velden geleegd. Dit werkt nu prima. Dus ik laat de PRG maar even zitten voor nu.

Nu moet ik alleen nog zien dat het formulier weer met mPDF wordt omgezet naar een pdf bestand.

Ik knutsel nog even verder.


*** EDIT ***

Ik heb geprobeerd om de mPDF te combineren met PHPMailer. De email wordt verzonden, er zit ook een pdf bestand bij maar deze kan niet geopend worden, geeft aan dat het bestand niet ondersteund wordt of dat het beschadigd is.

Dit is de code:
php code - Bekijk de code zonder highlighting - Klap code in 
  1. if ($send_letter) {
  2.         $letter = iconv("UTF-8","UTF-8//IGNORE",$letter);
  3.         include("../mpdf/mpdf.php");
  4.         $mpdf=new \mPDF('c','A4','','' , 0, 0, 0, 0, 0, 0); 
  5. 	$mpdf->SetDisplayMode('fullpage');
  6.  
  7. 	//write html to PDF
  8.         $mpdf->WriteHTML($letter);
  9.  
  10.        $content = $mpdf->Output('', 'S');
  11.  
  12. $content = chunk_split(base64_encode($content));
  13. $filename = "Vlees-".date("d-m-Y_H-i",time()); //Your Filename with local date and time
  14.  
  15.  
  16. 		$sendmail = true;
  17. 		if ($sendmail) {
  18. 			require dirname(__FILE__)."/phpmailer/PHPMailerAutoload.php";
  19. 			require dirname(__FILE__)."/message.php";
  20. 			$mail = new PHPMailer;
  21. 			$mail->isSendmail();
  22. 			$mail->IsHTML(true);
  23. 			$mail->From = $name;
  24. 			$mail->CharSet = "UTF-8";
  25. 			$mail->FromName = "J-forms";
  26. 			$mail->Encoding = "base64";
  27. 			$mail->ContentType = "text/html";
  28. 			$mail->addAddress($your_email, $your_name);
  29. 			$mail->Subject = $your_subject;
  30. 			$mail->Body = $letter;
  31. 			$mail->addStringAttachment($content, $filename,  'base64', 'application/pdf');
  32.  
  33. 		}
  34. }


Iemand een aanwijzing voor me waar het fout gaat?

Alvast bedankt!
Offline Thomas - 27/03/2016 15:30 (laatste wijziging 27/03/2016 15:35)
Avatar van Thomas Moderator Je zou eens kunnen kijken naar de broncode van de uiteindelijke mail. Het hoofd Content-Type lijkt mij multipart/mixed, omdat je mail is opgebouwd uit verschillende zaken. Het kan dus liggen aan het feit dat je zegt dat je mail enkel "text/html" is, maar mogelijk is PHPMailer zelf zo intelligent dat deze het Content-Type van het mailtje (de envelop) zelf aanpast naar iets anders op het moment dat je attachments gebruikt.

Dan rest er nog de mogelijkheid dat het PDF-document zelf op een of andere manier niet (meer) goed opgesteld is. Ik raad je aan dit in afzondering te testen, los van mail (separation of concerns). Je zou je script bijvoorbeeld tijdelijk kunnen aanpassen zodat het PDF-document direct geserveerd wordt (en er in eerste instantie helemaal geen mail wordt verstuurd).

Op deze manier kun je in ieder geval bepalen waar het precies fout gaat (zit het in de PDF zelf, of in de manier waarop je het e-mailbericht opstelt), wat het opsporen+oplossen waarschijnlijk ook wat makkelijker maakt.
Offline IndexS - 27/03/2016 16:20 (laatste wijziging 27/03/2016 16:25)
Avatar van IndexS MySQL interesse Ik heb nu
$content = chunk_split(base64_encode($content));
$mail->ContentType = "text/html";
verwijderd en dan krijg ik een email binnen met een pdf die ik kan openen.
Alleen de pdf is helemaal leeg.
De invoer wordt wel in het mailtje zelf weergegeven maar wordt nog niet in de pdf gezet.

Het werkt wel als ik de code zoals in mijn eerste bericht gebruik en geen gebruik maak van de PHPMailer.

Er gaat dus iets mis met het omzetten van de invoer naar pdf.  
Offline Thomas - 27/03/2016 23:36
Avatar van Thomas Moderator
Citaat:
Er gaat dus iets mis met het omzetten van de invoer naar pdf.

Dat kun je pas met zekerheid zeggen als je de PDF in afzondering bekijkt lijkt mij?

En als je de chunk_split/base64_encode eens achterwege laat (oftewel regel 12 in commentaar zet)? Mogelijk faciliteert PHPMailer dit zelf in de transportlaag ofzo (dit het ik zo gauw niet kunnen achterhalen maar is het proberen waard), zoals hier min of meer op wordt gehint.

En anders zul je de PDF verder onder de loep moeten nemen. En eerst zekerheid verkrijgen dat hier niets mis mee is.
Offline IndexS - 28/03/2016 00:30
Avatar van IndexS MySQL interesse Ik had die regel al verwijderd en daarna kreeg ik pdf binnen, maar leeg.
Nu heb ik de mPDF gedeelte verplaatst naar bericht.php en nu wordt de pdf wel gevuld met de invoer.

Dat werkt nu dus uiteindelijk. Nu alleen de pdf opmaak nog in orde maken. Ik heb als achtergrond een image, maar die valt nu over de rest heen. Ik zie dus geen invoer als ik de achtergrond instel.

In mijn eerste opzet zonder de PHPMailer werkte dat wel, dus nu dat nog proberen op te lossen en dan lijkt het me dat het werkt zoals gewenst.
Offline Thomas - 28/03/2016 14:46
Avatar van Thomas Moderator Uhm. Is het daarmee dan ook enkel een mPDF vraagstuk geworden? De PDF wordt nu correct verstuurd? De oorzaak van het niet-correct verzenden was dus mogelijk dubbele encoding?
Offline IndexS - 28/03/2016 17:04
Avatar van IndexS MySQL interesse De oorzaak was gedeeltelijk dubbele encoding. Die zorgde ervoor dat de pdf beschadigd verstuurd werd. De andere oorzaak was dat het mPDF gedeelte in een verkeerde php bestand stond. Hierdoor werd het bestand wel aangemaakt maar was er niks om erin te zetten. Werkt nu allemaal prima, net het achtergrond probleem ook opgelost.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Actieve forumberichten
© 2002-2024 Sitemasters.be - Regels - Laadtijd: 0.223s