Gisteren ben ik fijn geholpen met een code nu wil ik in deze code een paginanummeringssysteem inbouwen, maar dat gaat me niet goed af. Ik gebruik deze tutorial.
bij openen pagina worden de items uit de databasr geladen. pagina 1 krijg ik met bv 2 items (ingesteld in script), wil ik naar de volgende pagina, dan krijg ik geen items te zien. Wanneer ik terug ga naar de beginpagina krijg ik ook niks meer te zien.
ik vermoed dat het te maken heeft met de:
if($_SERVER['REQUEST_METHOD'] == 'POST')
Als je dan naar een andere pagina gaat, is er geen input meer. Dus is er een lege pagina.
Hoe kan ik het oplossen dat alles wordt ge-post wordt, onthouden wordt?
Kan op verschillende manieren:
Je slaat alles op de server op in een session;
Je slaat alles op in een cookie, wat me niet aangewezen lijkt aangezien de client dit kan uitschakelen;
Of je zet de waardes in je querystring in de link, dit vereist wel dat je ipv $_POST['variabele'] een alternatieve functie of ideaal gezien een classe moet maken om de variabelen op te vragen bv:
Dit is ook beter naar sucurity toe, aangezien je dit altijd kan gebruiken om variabelen op te vragen uit een POST of GET, en deze gegevens zijn van onbetrouwbare bron (de gebruiker)
door het in een klasse te steken kan je het makkelijk hergebruiken en uitbreiden zodat je het bij elk script dat je maakt kan gebruiken
Alleen nu de vraag waarom een classe voor dit stukje? Een simpele functie is toch ook genoeg. Vooral als prienstra niet met classes werkt.
omdat een klasse de code herbruikbaar maakt en makkelijk uit te breiden, zo kan je makkelijk een setVar() functie toevoegen, of een getPost() functie die alle post data ophaalt en hem zuiverd van eventuele SQLinjecties...
Je kan deze classe kopieren naar elke website, elk script dat je wil maken, zeker geen verloren moeite om dit dan even in een klasse te steken
De toekomst van PHP ligt zowizo al bij OOP, dit wordt versterkt door het nieuwe DOM van php 5 en het allomtegewoordig gebruik van XML&webservices.
Trouwens een klasse als deze kan je toch makkelijk implementeren in een proceduraal script, je include gewoon de classe file en gebruikt de statische aanroep naar getVar ipv dat je de $_POST global gebruikt.
@ prienstra: wat het beste / makkelijkste is dat valt binnen jouw persoonlijke keuze, aangezien je de stap naar OOP nog niet gezet hebt is het voor jouw waarschijnlijk makkelijker om de data op te slagen in sessions
Gisteren ben ik fijn geholpen met een code nu wil ik in deze code een paginanummeringssysteem inbouwen, maar dat gaat me niet goed af. Ik gebruik deze tutorial.
(Mijn punt is, zonder nadere uitleg ga ik toch niet je code doorspitten om te raden wat je verwacht en en wat je daadwerkelijk krijgt?)
De fout is vast dat je de variabele $iResults verkeerd hebt gespeld. Ik gok namelijk dat je het aantal resultaten in een variabele genaamd $iResultz hebt zitten; dat kan ik niet zien maar dat zal het vast wel zijn.
Sorry ik doe een beetje lullig.
Je bouwt heel mooi een query op in $sQuerystring, maar misschien ben je wel glad vergeten om mysql_query($sQuerystring) aan te roepen? Wie zal het zeggen.
Nee nou heb ik de fout gevonden: je site is natuurlijk gehackt middels SQL-injectie:
Het kan gewoon van alles zijn... zonder uitleg kan echt niemand je helpen hoor...
"dat gaat me niet goed af"
Wat verwachtte je te zien en wat kreeg je te zien?
Ik heb nog wel een performance tip voor bij de paginering: Google eens op SQL_CALC_FOUND_ROWS, die is reuze handig
Beste TomJansen,
bedankt voor je reactie. De zoekformule werkt gewoon goed.
Maas als ik een paginanummer met vorige - volgende wil toevoegen, gaat het fout.
Bij het kiezen van een volgende pagina krijg ik een lege pagina.
Zoals eerder gepost, vermoed ik dat het ligt aan dat er waardes gepost worden, en dat die niet meegenomen worden.
Als je wil kan ik ook wel eens de gehele script posten.
Oeps, ik ben hier nieuw en moet nog een beetje wennen aan het forum, had totaal niet gezien dat dit al de tweede pagina van de topic is! Foutje...
Je zegt dat het zoeken wel werkt maar als je dan doorklikt naar de volgende pagina dat je dan een lege pagina krijgt.
Kijk zo komen we verder, nou zullen we eens een kijkje nemen naar die paginalinks.
Je pakt de paginanummer, indien present, uit GET.
En je pakt de zoekresultaten uit POST.
Dat gaat de eerste keer goed, dus als de gebruiker net van het formulier kwam.
Want als de gebruiker het formulier invult dan wordt dat opgestuurd middels POST.
De paginanummer wordt dan doorgegeven in de URL, dus die zal beschikbaar zijn in GET.
De zoekcriteria in POST wordt echter niet doorgegeven! Dat gaat verloren.
Sterker nog, de conditie ($_SERVER['REQUEST_METHOD']=='POST') zal false zijn want als de gebruiker op een link klikt, dan is de requestmethode "GET".
Mogelijke oplossingen:
- Inderdaad, mogelijk is het met die sessie. Bij ($_SERVER['REQUEST_METHOD']=='POST') doe je dan de zoekcriteria opslaan in de sessie; en bij else oftewel ($_SERVER['REQUEST_METHOD']=='GET') doe je dan het paginanummer uitlezen uit GET en de zoekcriteria uit de sessie.
Maar dan lijkt me persoonlijk niet het handigste.
- Een andere oplossing zou zijn dat je de zoekcriteria opgeeft via GET. Dan moet je ten eerste het formulier aanpassen zodat het formulier een GET-request genereert i.p.v. een POST-request: je hebt ergens een stukje HTML ongeveer als: <form method="post" action="zoeken.php">. Dan moet je method="post" weghalen of vervangen door method="get".
Ten tweede moet je dan in de zoekscript overal $_POST vervangen door $_GET.
- Nog een andere oplossing zou zijn dat je de zoekcriteria steeds doorgeeft via POST. Als je dan een link naar de volgende pagina schrijft, dan moet dat niet een gewone <a> link zijn, maar een formulier <form method="post" action="url">. Met hidden inputs kan je dan de zoekcriteria doorgeven. Paginanummer kan eventueel in de URL (dus dan komt het in GET), of ook in een hidden input (dan komt het in POST).
En als je nou dit: $aWheres['land'] = $_POST['land'];
vervangt door: $aWheres['land'] = mysql_real_escape_string($_POST['land']);
en hetzelfde bij provincie, plaats, etc... dan is je site meteen beveiligd tegen SQL-injecties :-)