While loops werken niet meer na update php?
En op geen enkele site werken de while loops nog lijkt het nu wel.
Ik denk dus dat dit aan de update ligt.
Ik heb even een phpinfo gemaakt op http://corjapin.nl/server.php
Is er iemand die hier iets geks ziet?
Hier een voorbeeld van een select query die in plaats van 4 resultaten, dus maar 1 resultaat weergeeft.
Ook zonder limit geeft hij maar 1 resultaat.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
$query = "SELECT * FROM berichten ORDER BY id DESC LIMIT 4";
$stmt = mysqli_query($connection, $query);
while ($data = mysqli_fetch_array($stmt,MYSQLI_ASSOC))
{
?>
<li class="col-md-3 col-sm-6 col-xs-12">
<div class="thumbnail">
<a href="page.php?id="<?php echo $data['id']; ?>"><img width="250" height="250" alt="<?php echo $data['title']; ?>" src="<?php echo $data['image']; ?>"></a>
<div class="caption">
<h3><a href="page.php?id="<?php echo $data['id']; ?>"><?php echo $data['title']; ?></a></h3>
<p><?php echo nl2br(substr($data['message'],0,150)); ?>.....</p>
<a href="page.php?id=<?php echo $data['id']; ?>" class="btn btn-link" role="button">Lees meer</a>
</div>
</div>
</li>
<?php
}
?>
$query = "SELECT * FROM berichten ORDER BY id DESC LIMIT 4";
$stmt = mysqli_query($connection, $query);
while ($data = mysqli_fetch_array($stmt,MYSQLI_ASSOC))
{
?>
<li class="col-md-3 col-sm-6 col-xs-12">
<div class="thumbnail">
<a href="page.php?id="<?php echo $data['id']; ?>"><img width="250" height="250" alt="<?php echo $data['title']; ?>" src="<?php echo $data['image']; ?>"></a>
<div class="caption">
<h3><a href="page.php?id="<?php echo $data['id']; ?>"><?php echo $data['title']; ?></a></h3>
<p><?php echo nl2br(substr($data['message'],0,150)); ?>.....</p>
<a href="page.php?id=<?php echo $data['id']; ?>" class="btn btn-link" role="button">Lees meer</a>
</div>
</div>
</li>
<?php
}
?>
Gewijzigd op 23/02/2020 14:32:36 door Stefan van Iwaarden
Anyhow:
- weet je zeker dat er meer dan 1 resultaat is?
- heb je al wat errorlogging aangezet om te kijken of er dingen foutgaan?
- en/of heb je errorlogs geinspecteerd?
- heb je de HTML-broncode van de pagina bekeken? misschien gaat je code ergens onderuit met een foutmelding?
Met het volgende trap ik misschien een open deur in maar: er gebeurt iets onverwachts, je krijgt maar 1 resultaat terwijl dit er meerdere moeten zijn. Je zult dan eerst op onderzoek uit moeten gaan naar wat er misgaat. Hiervoor heb je informatie nodig die je meer kan vertellen over de toestand van bovenstaande code. Pas als je een oorzaak hebt kun je toe naar een oplossing.
Zo zou je in bovenstaande code heel simpel kunnen nagaan hoeveel resultaten $stmt heeft met num_rows().
Dan zou je bovenaan je code het volgende kunnen zetten:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
error_reporting(E_ALL);
ini_set('display_startup_errors', true);
ini_set('display_errors', 'stdout');
?>
error_reporting(E_ALL);
ini_set('display_startup_errors', true);
ini_set('display_errors', 'stdout');
?>
Mogelijk vallen er dan nog wat andere lijken uit de kast die je ook of wellicht eerst zult moeten oplossen.
NB: mogelijk loont het ook de moeite om jezelf vertrouwd te maken met de object georienteerde schrijfwijze van mysqli. Dit scheelt je op zijn minst wat typewerk ;).
Gewijzigd op 23/02/2020 14:42:57 door Thomas van den Heuvel
Dank voor je reactie.
met num_rows geeft hij wel als aantal '4' weer, dus dat klopt.
De errors gaven alleen een fout op de while waar de tweede parameter stond, die heb ik weggehaald, en nu geen errors meer.
Maar dat lost het probleem niet op.
Het zit dus wel ergens in de while loop lijkt het.
Code (php)
1
echo "<pre>".print_r($data,true)."</pre>";
Wat zie je dan?
Maar vreemder nog, hij geeft dan ook ineens alle 4 de records gewoon weer op de normale manier?
Gewijzigd op 23/02/2020 15:17:35 door - Ariën -
Haal ik de print_r weer weg, dan weer maar 1 resultaat.
Maar het is ook niet alleen op deze pagina, maar alle pagina's op elke site op deze server.
Daar zag ik ook een <iframe> staan van een audioplayer, en daar liep de hele boel op vast blijkbaar.
Dit weggehaald uit het database record, en hij doet het...
Uit interesse: Welke audioplayer?
Ik ben ooit een audioplayer gezien die in een playlist serieus ajax-requests in een loop uitvoerde, en alle JS-scripts ook steeds opnieuw inlaadde.
Code (php)
1
<iframe width="1" height="1" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/728567077&color=%23f51417&auto_play=true&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true&visual=true"></iframe
Gewijzigd op 23/02/2020 16:07:09 door - Ariën -
--> Filter input en escape output.
- Ariën - op 23/02/2020 16:06:52:
Geen XSS dus, dat is ook niet iets voor het bekende SoundCloud.
Laat ik het anders verwoorden: de huidige opzet stelt XSS in staat. Het feit dat het aan een "veilige" bron refereert is niet echt relevant. Dit soort sites kunnen ook misbruikt worden voor dit soort aanvallen dus wat dat betreft zou je geen enkele externe bron zondermeer moeten vertrouwen.
Zoals @Frank aanhaalt dient je output veilig te zijn, ontdaan van mogelijke JavaScript fratsen. Dus tenzij je de auteurs van deze berichten vertrouwt en ook kunt identificeren, is het wellicht beter om een andere manier te vinden om hetzelfde te bereiken. Bijvoorbeeld door een soort van UBB-tag: [soundcloud]skelermusic/ava[/soundcloud], waarbij jouw systeem zelf de omzettingen naar iframes et cetera verzorgt, zodat de controle aan jouw kant ligt.
En zo'n aanpak heeft meteen een ander pluspunt: nu is het zo dat als iemand een sluitingshaak mist dat dan je hele site in puin ligt. Als je alle output onschadelijk maakt en deze zelf verzorgt gebeurt dat ook niet meer.
Als je de opzet wijzigt van html naar een php echo met toevoeging van een voorafgaande while loop wordt het een handelbaarder verhaal
Gewijzigd op 24/02/2020 18:17:26 door Yoop Overmaat
Yoop Overmaat op 24/02/2020 18:12:46:
Het probleem komt weg uit het feit dat je statische html binnen de dynamiek van een php-script probeert te mixen
Nou nee, meer het feit dat je niet uit kunt gaan van een kloppende syntax. En daarbij heb je geen controle over wat dit vervolgens doet (AJAX-calls die cookies stelen et cetera).
Yoop Overmaat op 24/02/2020 18:12:46:
en dat komt niet goed want er wordt van de diverse uitkomsten slechts de eerste mogelijkheid weergegeven in jouw opzet van het verhaal.
Dit volg ik niet.
Yoop Overmaat op 24/02/2020 18:12:46:
Als je de opzet wijzigt van html naar een php echo met toevoeging van een voorafgaande while loop wordt het een handelbaarder verhaal
Dit maakt niet zoveel uit denk ik. PHP en HTML zijn en blijven onlosmakelijk met elkaar verbonden. Dit is enkel een (abstractie)laag die je hier tussenmetselt, het resultaat blijft hetzelfde. Bedoel je met bovenstaande quote het (verder) scheiden van logica en weergave? Je zult dan nog steeds een knoop moeten doorhakken over wat de content uiteindelijk mag doen. Volledige HTML weergeven? Beperkte HTML weergeven? Enkel platte tekst?
Het escapen van alle output, het beperken van de HTML-mogelijkheden of dit compleet verbieden door gebruikmaking van een surrogaat (UBB-achtige tags) gaat je waarschijnlijk een stuk verder helpen. Of een WYSIWYG-editor die je op de vingers tikt of simpelweg niets doet wanneer je deze ongeldige HTML probeert te voeren, maar dan heb je dus nog steeds het probleem van de mate van betrouwbaarheid van de bron.
Dit is een afweging die de topicstarter zal moeten maken en op grond daarvan zullen beperkingen qua output-functionaliteit opgelegd moeten worden.