Oude php : mysqli + bind_results

[Boudewijn]

Ik zit voor een programmeerding te spelen met een antieke PHP5.5 installatie waar ik een basale query niet op werkend krijg.

De oude code is zoiets als dit:

PHP:

        $result = $sql->query("SELECT naam FROM persons WHERE voornaam like '%$parameter%' OR achternaam like '%$parameter%'");
        print "<ul>";
        while($res = $result->fetch_array(MYSQLI_ASSOC)) {
            print "<li>" . $res['naam'] . "</li>";
        }
        print "</ul>";

Deze code werkt maar is natuurlijk zo lek als een mandje. ik zie dat de code werkt.

Nu wil ik dus omkatten naar een mysqli interface met een prepared statement. Ik kan hierbij niet de PHP-versie veranderen (oude challenge) en zou normaal dat als eerste fixen.


Ik heb nu zoiets als dit gemaakt:

PHP:

        $parameter = "foo";
        $sql = new mysqli("localhost", "X", "Y", "Z");
        $stmt = $sql->prepare("SELECT naam FROM persons WHERE voornaam LIKE ? OR achternaam LIKE ?");
        $stmt->bind_param("ss",$parameter,$parameter);
        $stmt->execute();

        print "<ul>";
        $stmt->bind_result($naam);

        while($stmt->fetch()) {
          print "<li>" . $naam . "</li>";
        }
        print "</ul>";

Gezien de code in snippet1 werkt zou de code in snippet2 ook moeten werken. Niet dus.

Nu heb ik wat zitten debuggen en gekeken naar:

store_results(), dit zou niet nodig moeten zijn en lost het ook niet op
stmt->num_row is sowieso 0 bij mijn code.

Ik verdacht bind_param ervan om niet lekker om te gaan met 2x dezelfde parameter gezien deze by reference wordt doorgegeven.
Dus ik heb zoiets gedaan als $p1= $parameter; $p2 = parameter; $stmt->bind_param("ss",$p1,$p2);


Ik kom er echter niet uit. In een normale situatie zou ik niet met bind_result werken.. maarja. Wie wil me een zet de goede kant op geven?

[borft]

is het niet iets als

PHP:

while ( $row = $stmt->fetch_assoc() ){
    $naam = $row['naam'];
}

Eigenlijk moet je natuurlijk sowieso even checken of je query wel lukt (de execute). Je kunt trouwens ook named parameters binden, dat maakt je query wat leesbaarder dan met de wildcards.


Nu ik er zo over nadenk, zit er geen PDO in PHP5?

[ Voor 55% gewijzigd door borft op 20-04-2020 17:33 ]

[Boudewijn]

borft schreef op maandag 20 april 2020 @ 17:31:
is het niet iets als

PHP:

while ( $row = $stmt->fetch_assoc() ){
    $naam = $row['naam'];
}

Eigenlijk moet je natuurlijk sowieso even checken of je query wel lukt (de execute). Je kunt trouwens ook named parameters binden, dat maakt je query wat leesbaarder dan met de wildcards.


Nu ik er zo over nadenk, zit er geen PDO in PHP5?

Dat had ik dus ook verwacht... maar kennelijk

Fatal error: Call to undefined method mysqli_stmt::fetch_assoc() in /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php on line 59

Heb net ook al gekeken of ik met

error_reporting(E_ALL);
ini_set('display_errors',1);
wat verder ga komen, maar nee dus.

Daarom kom ik tot de conclusie dat die php stack dus oud/rot is ... ik weet alleen zelf te weinig van PHP om te zien waar het exact in zit.

[DJMaze]

@Boudewijn set even bovenin

PHP:

mysqli_report(MYSQLI_REPORT_ALL);

[Groentjuh]

borft schreef op maandag 20 april 2020 @ 17:31:
is het niet iets als

PHP:

while ( $row = $stmt->fetch_assoc() ){
    $naam = $row['naam'];
}

Eigenlijk moet je natuurlijk sowieso even checken of je query wel lukt (de execute). Je kunt trouwens ook named parameters binden, dat maakt je query wat leesbaarder dan met de wildcards.


Nu ik er zo over nadenk, zit er geen PDO in PHP5?

PDO zit ook al in PHP5, dus daar zou de TS ook naar kunnen kijken.

Jouw code lukt niet, want dan zit je op het verkeerde object te fetchen.

PHP:

$res = $stmt->get_result();
while ( $row = $res->fetch_assoc() ){
    $naam = $row['naam'];
}

[Voutloos]

De oude querystring bevat wildcards ('%') om de LIKE value. Ben je die niet gewoon stomweg vergeten?

[MueR]

Voutloos schreef op dinsdag 21 april 2020 @ 07:45:
De oude querystring bevat wildcards ('%') om de LIKE value. Ben je die niet gewoon stomweg vergeten?

^^ dit

[Creepy]

Voorlopig weten we niet meer dan "werkt niet". Wat het resultaat nu precies is, is gokken op dit moment (ok 0 rows, maar foutmelding wel of niet?). Maar als er simpelweg geen resultaat komt dan zou het de vergeten %'s wel eens kunnen zijn idd.

[ Voor 9% gewijzigd door Creepy op 21-04-2020 09:18 ]

[AW_Bos]

Ook zou ik erg hard aanraden om $parameter door $sql->real_escape_string(...) te halen. Je weet nooit wat er in zit, en of een bepaald karakter je query vernachelt.

Dit heet ook wel SQL-injection.

[ Voor 9% gewijzigd door AW_Bos op 21-04-2020 09:37 ]

[MueR]

AW_Bos schreef op dinsdag 21 april 2020 @ 09:37:
Ook zou ik erg hard aanraden om $parameter door $sql->real_escape_string(...) te halen. Je weet nooit wat er in zit, en of een bepaald karakter je query vernachelt.

Dit heet ook wel SQL-injection.

En met prepared statements doet PDO dat zelf, dus vooral niet doen, want dan ga je dubbel escapen.

De *_real_escape_string functie familie is een beetje een overgebleven reliek uit de slechte oude SQL injection tijd waar mensen direct $_POST params in hun queries aan het mikken waren.

[ Voor 18% gewijzigd door MueR op 21-04-2020 09:46 ]

[AW_Bos]

MueR schreef op dinsdag 21 april 2020 @ 09:44:
[...]

En met prepared statements doet PDO dat zelf, dus vooral niet doen, want dan ga je dubbel escapen.

In dat geval heb je gelijk! Maar wie niet aan prepared statements doet, moet wel alert blijven.

[gekkie]

AW_Bos schreef op dinsdag 21 april 2020 @ 09:46:
[...]

In dat geval heb je gelijk! Maar wie niet aan prepared statements doet, moet wel alert blijven prepared statements gaan gebruiken.

FTFY

[AW_Bos]

gekkie schreef op dinsdag 21 april 2020 @ 09:48:
[...]

FTFY

Ik denk dat de eerste twee woorden unstriked horen te zijn , maar het zal vrees ik nog heel lang zo blijven dat mensen kunnen kiezen tussen beide varianten. Prepared is wel robuuster.

[gekkie]

Mjah dat hele escape(), real_escape(), now_really_really_escape_my_shit_please(), het was het toch allemaal uhmm net niet zeg maar.
Moet toegeven dat ik een jaar of 3 ook nog PHP code over gedragen heb gekregen zonder escapes en zonder prepared statements. Maar goed moest toch over naar PHP7, dus gelijk de boel uitgemest en naast prepared statements ook maar eens wat meer input valdidatie er aan geknoopt.

[Rensjuh]

Welke PHP versie heb je precies?
Ik heb zojuist even PHP5.5.9 aan mijn WAMP toegevoegd en een fictief persons tabelletje aangemaakt.
De code die jij hierboven geeft heb ik gekopieerd en geplakt en dit werkt gewoon.

Mogelijk toch nog een verschil in PHP versie die er mogelijk niet lekker mee omgaat?

Voor de zekerheid mijn SQL tabelletje:

SQL:

CREATE TABLE `persons` (
  `id` int(11) NOT NULL,
  `voornaam` varchar(100) NOT NULL,
  `achternaam` varchar(100) NOT NULL,
  `naam` varchar(200) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Met daarin wat fictieve voornamen/achternamen/namen.
Krijg netjes de 2 verwachte records op het scherm.

[Boudewijn]

Allereerst, dank voor jullie antwoorden. Wat een respons

Voutloos schreef op dinsdag 21 april 2020 @ 07:45:
De oude querystring bevat wildcards ('%') om de LIKE value. Ben je die niet gewoon stomweg vergeten?

Ja dat zou je denken, maar https://websitebeaver.com...revent-sql-injection#like

De wildcards worden door de bind gedaan .

MueR schreef op dinsdag 21 april 2020 @ 08:31:
[...]

^^ dit

Nee helaas, zie hierboven.

AW_Bos schreef op dinsdag 21 april 2020 @ 09:37:
Ook zou ik erg hard aanraden om $parameter door $sql->real_escape_string(...) te halen. Je weet nooit wat er in zit, en of een bepaald karakter je query vernachelt.

Dit heet ook wel SQL-injection.

Joh. Het hele stukje puzzle is dus SQLi netjes onmogelijk maken op een oude php versie.
Dat ik op moet letten voor SQLi is mij dan bekend

MueR schreef op dinsdag 21 april 2020 @ 09:44:
[...]

En met prepared statements doet PDO dat zelf, dus vooral niet doen, want dan ga je dubbel escapen.

De *_real_escape_string functie familie is een beetje een overgebleven reliek uit de slechte oude SQL injection tijd waar mensen direct $_POST params in hun queries aan het mikken waren.

Inderdaad dus.

Rensjuh schreef op dinsdag 21 april 2020 @ 10:19:
Welke PHP versie heb je precies?
Ik heb zojuist even PHP5.5.9 aan mijn WAMP toegevoegd en een fictief persons tabelletje aangemaakt.
De code die jij hierboven geeft heb ik gekopieerd en geplakt en dit werkt gewoon.

Mogelijk toch nog een verschil in PHP versie die er mogelijk niet lekker mee omgaat?

Voor de zekerheid mijn SQL tabelletje:

SQL:

CREATE TABLE `persons` (
  `id` int(11) NOT NULL,
  `voornaam` varchar(100) NOT NULL,
  `achternaam` varchar(100) NOT NULL,
  `naam` varchar(200) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Met daarin wat fictieve voornamen/achternamen/namen.
Krijg netjes de 2 verwachte records op het scherm.

Dat is dus ook het deel dat ik er niet aan snap. Ik kan prima iets in elkaar flanzen in PHP (of wat schrijven in Python waar ik veel meer thuis in ben), maar ik snap domweg niet wat hier fout gaat. Het zou heel triviaal moeten zijn (de meeste andere challenges fiets je vrij makkelijk doorheen).

De E_REPORTING optie gooit een waarschuwing uit dat er geen index op de table zit. Lijkt me een performance hit van hier tot tokyo, maar gezien er 3 records ofzo in zullen zitten niet zo'n probleem.

code:

 Fatal error: Uncaught exception 'mysqli_sql_exception' with message 'No index used in query/prepared statement SELECT foo FROM var WHERE bar2 LIKE ? OR bar3 LIKE ?' in /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php:56 Stack trace: #0 /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php(56): mysqli_stmt->execute() #1 /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php(22): search('pagina') #2 {main} thrown in /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php on line 56

Dat helpt me dus ook niet echt. Er zit wat uitleg bij waar PDO duidelijk niet in vermeld wordt en waar 1 resultaat ophalen prima in werkt. Die heb ik nml eerst geimplementeerd:

code:

    function getFoo($id) {
        $sql = new mysqli("localhost", "X", "X", "X");
        $stmt = $sql->prepare("SELECT foo, bar FROM persoon WHERE id = ?");
        $stmt->bind_param("i",$id);
        $stmt->execute();
        $stmt->bind_result($foo, $bar);
        $stmt -> fetch();
        print "<h1>" . $foo . "</h1>" . $foo;

    }

Ik wil geen google hits creeeren voor die challenge dus ik heb de tabelnamen omgekat naar persoon ed, dat kan wellicht niet 100% consistent zijn .

[Rensjuh]

Boudewijn schreef op dinsdag 21 april 2020 @ 12:23:
Allereerst, dank voor jullie antwoorden. Wat een respons


[...]

Dat is dus ook het deel dat ik er niet aan snap. Ik kan prima iets in elkaar flanzen in PHP (of wat schrijven in Python waar ik veel meer thuis in ben), maar ik snap domweg niet wat hier fout gaat. Het zou heel triviaal moeten zijn (de meeste andere challenges fiets je vrij makkelijk doorheen).

De E_REPORTING optie gooit een waarschuwing uit dat er geen index op de table zit. Lijkt me een performance hit van hier tot tokyo, maar gezien er 3 records ofzo in zullen zitten niet zo'n probleem.

code:

 Fatal error: Uncaught exception 'mysqli_sql_exception' with message 'No index used in query/prepared statement SELECT foo FROM var WHERE bar2 LIKE ? OR bar3 LIKE ?' in /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php:56 Stack trace: #0 /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php(56): mysqli_stmt->execute() #1 /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php(22): search('pagina') #2 {main} thrown in /var/www/sql/710af81fccdb443a9de8a73e46775637/index.php on line 56

Dat helpt me dus ook niet echt. Er zit wat uitleg bij waar PDO duidelijk niet in vermeld wordt en waar 1 resultaat ophalen prima in werkt. Die heb ik nml eerst geimplementeerd:

Klopt, die kreeg ik ook maar die kun je skippen.
Welke PHP versie heb je precies?
Dan zal ik die eens op mijn WAMP omgeving er bij zetten en het daarmee testen.
Ik heb het hier nu werkend, dus het zou dan met jouw PHP versie om moeten vallen...
Als dat niet zo is, ligt het dus niet aan de gebruikte PHP versie.

[Boudewijn]

Rensjuh schreef op dinsdag 21 april 2020 @ 12:26:
[...]


Klopt, die kreeg ik ook maar die kun je skippen.
Welke PHP versie heb je precies?
Dan zal ik die eens op mijn WAMP omgeving er bij zetten en het daarmee testen.
Ik heb het hier nu werkend, dus het zou dan met jouw PHP versie om moeten vallen...
Als dat niet zo is, ligt het dus niet aan de gebruikte PHP versie.

5.5.9-1ubuntu4.29

[Rensjuh]

Boudewijn schreef op dinsdag 21 april 2020 @ 12:32:
[...]

5.5.9-1ubuntu4.29

5.5.9 heb ik hier ook maar dan op Windows...
Werkt hier perfect.

PHP:

<?php
mysqli_report(MYSQLI_REPORT_ALL);
error_reporting(E_ALL);
    $parameter = "foo";
    $sql = new mysqli("localhost", "X", "Y", "Z");
    $stmt = $sql->prepare("SELECT naam FROM persons WHERE voornaam LIKE ? OR achternaam LIKE ?");
    $stmt->bind_param("ss",$parameter,$parameter);
    $stmt->execute();

    print "<ul>";
    $stmt->bind_result($naam);

    while($stmt->fetch()) {
      print "<li>" . $naam . "</li>";
    }
    print "</ul>";
?>

Laat je ook niks anders zien?

Dan lijkt het toch alsof het werkt maar er gewoon geen resultaten zijn?
Btw, als ik die mysqli_report op ALL heb staan krijg ik ook geen resultaten.
Comment die eens en kijk dan nog eens?

[Boudewijn]

Rensjuh schreef op dinsdag 21 april 2020 @ 12:37:
[...]


5.5.9 heb ik hier ook maar dan op Windows...
Werkt hier perfect.

PHP:

<?php
mysqli_report(MYSQLI_REPORT_ALL);
error_reporting(E_ALL);
    $parameter = "foo";
    $sql = new mysqli("localhost", "X", "Y", "Z");
    $stmt = $sql->prepare("SELECT naam FROM persons WHERE voornaam LIKE ? OR achternaam LIKE ?");
    $stmt->bind_param("ss",$parameter,$parameter);
    $stmt->execute();

    print "<ul>";
    $stmt->bind_result($naam);

    while($stmt->fetch()) {
      print "<li>" . $naam . "</li>";
    }
    print "</ul>";
?>

Laat je ook niks anders zien?

Dan lijkt het toch alsof het werkt maar er gewoon geen resultaten zijn?
Btw, als ik die mysqli_report op ALL heb staan krijg ik ook geen resultaten.
Comment die eens en kijk dan nog eens?

Nou het gekke is dat de oorspronlijke code wel werkt, dat is deze:

code:

    function search($query) {
        $sql = new mysqli("localhost", "X", "Y", "Z");
        $result = $sql->query("SELECT naam FROM persons WHERE voornaam like '%$query%' OR achternaam like '%$query%'");
        print "<ul>";
        while($res = $result->fetch_array(MYSQLI_ASSOC)) {
            print "<li>" . $res['voornaam'] . "</li>";
        }
        print "</ul>";    
    }

Dit levert dus resultaten op , dus ik weet vrij zeker dat er een valide record in die DB zit.
Dat is dus het rare.

[Rensjuh]

mysqli_report(MYSQLI_REPORT_ALL);
Ook gecomment in je code?

Zoals ik zei, wanneer ik deze aan heb staan zie ik ook niks.

[DJMaze]

Rensjuh schreef op dinsdag 21 april 2020 @ 12:41:
mysqli_report(MYSQLI_REPORT_ALL);
Ook gecomment in je code?

Zoals ik zei, wanneer ik deze aan heb staan zie ik ook niks.

Niet commenten maar aanpassen.
Ik geef niet voor niks een hint met die functie.
Je kan dus ook bitwise andere waardes geven zoals _ERROR en _STRICT.

Aangezien men nooit sql results debugt, gooit mysqli nu lekker exceptions

[ Voor 11% gewijzigd door DJMaze op 21-04-2020 12:52 ]

[Boudewijn]

DJMaze schreef op dinsdag 21 april 2020 @ 12:50:
[...]

Niet commenten maar aanpassen.
Ik geef niet voor niks een hint met die functie.
Je kan dus ook bitwise andere waardes geven zoals _ERROR en _STRICT.

Aangezien men nooit sql results debugt, gooit mysqli nu lekker exceptions

Ik heb hem even op _ERROR gezet maar krijg dus daadwerkelijk geen resultaten. Ook geen errors.
Zouden ze bewust de php-omgeving stuk hebben gemaakt vraag ik me nu af? Dat zou nasty zijn maar eea verklaren.

[Voutloos]

Boudewijn schreef op dinsdag 21 april 2020 @ 12:23:

Ja dat zou je denken, maar https://websitebeaver.com...revent-sql-injection#like

De wildcards worden door de bind gedaan .

Dóór de bind? Hell no. Jij en allleen jij als developer kiest wanneer je een wildcard gebruikt. Dus als je leading en trailing wildcards gedrag wil behouden, moet jij gewoon een string parameter aan die query geven waar de wildcards al in zitten.

In die link worden de wildcards dus in de eerste regel in de string value gezet.

[ Voor 9% gewijzigd door Voutloos op 21-04-2020 13:02 ]

[Voutloos]

Boudewijn schreef op dinsdag 21 april 2020 @ 13:00:
Zouden ze bewust de php-omgeving stuk hebben gemaakt vraag ik me nu af? Dat zou nasty zijn maar eea verklaren.

Mijn wildcard punt was in ieder geval een verschil tussen de 2 snippets. Voor de rest wordt hier weer veeeel te veel gegokt.
(zoals altijd;) )

Vraag het ook eens aan ‘ze’ dan. ‘Zij’ leveren een dienst toch?

[Boudewijn]

Voutloos schreef op dinsdag 21 april 2020 @ 13:00:
[...]
Dóór de bind? Hell no. Jij en allleen jij als developer kiest wanneer je een wildcard gebruikt. Dus als je leading en trailing wildcards gedrag wil behouden, moet jij gewoon een string parameter aan die query geven waar de wildcards al in zitten.

code:

         $query = '%' +$query + '%';
         $sql = new mysqli("localhost", "X", "Y", "Z");
         $stmt = $sql->prepare("SELECT naam  FROM persoon WHERE voornaam LIKE ? OR achternaam LIKE ?");
         $stmt->bind_param("ss",$query,$query);

Dit is wat ik nu heb draaien, en dat levert ook niets op.

Voutloos schreef op dinsdag 21 april 2020 @ 13:00:
In die link worden de wildcards dus in de eerste regel in de string value gezet.

Crap, een paar biertjes en laat op de avond en dat zie je dus niet meer.
Dank dat je me er ff op wijst

[MueR]

Boudewijn schreef op dinsdag 21 april 2020 @ 13:09:
[...]

code:

         $query = '%' +$query + '%';
         $sql = new mysqli("localhost", "X", "Y", "Z");
         $stmt = $sql->prepare("SELECT naam  FROM persoon WHERE voornaam LIKE ? OR achternaam LIKE ?");
         $stmt->bind_param("ss",$query,$query);

Dit is wat ik nu heb draaien, en dat levert ook niets op.

[...]


Crap, een paar biertjes en laat op de avond en dat zie je dus niet meer.
Dank dat je me er ff op wijst

PHP:

$query = '%' +$query + '%';

is dan ook geen geldige code.. Als je errors/notices aan had staan, zou je dit zien:

code:

PHP Warning:  A non-numeric value encountered in <file> on line 3

[Boudewijn]

MueR schreef op dinsdag 21 april 2020 @ 13:25:
[...]

PHP:

$query = '%' +$query + '%';

is dan ook geen geldige code.. Als je errors/notices aan had staan, zou je dit zien:

code:

PHP Warning:  A non-numeric value encountered in <file> on line 3

Zo. Ja. inderdaad. Iets met te vaak python gebruiken. Error logging staat nu weer aan. Goed punt.

Maar goed de query werkt dus nog steeds niet.
Ik ga eens contact met de maker opnemen, volgens mij is dit sowieso niet zo de bedoeling.

[MueR]

Boudewijn schreef op dinsdag 21 april 2020 @ 13:33:
[...]
Maar goed de query werkt dus nog steeds niet.

WAT WERKT ER NIET?

Krijg je een error? Krijg je geen resultaten? En als je die query in phpmyadmin oid knalt?

[Boudewijn]

MueR schreef op dinsdag 21 april 2020 @ 13:35:
[...]

WAT WERKT ER NIET?

Krijg je een error? Krijg je geen resultaten? En als je die query in phpmyadmin oid knalt?

Ik krijg dus geen resultaten. Ik heb geen phpmyadmin op die omgeving, het is een CTF .

[MueR]

Als je er mee kunt connecten, kun je er mee connecten. Het maakt phpmyadmin of mysql workbench of een sql explorer in je IDE geen knal uit.

[Boudewijn]

MueR schreef op dinsdag 21 april 2020 @ 13:41:
Als je er mee kunt connecten, kun je er mee connecten. Het maakt phpmyadmin of mysql workbench of een sql explorer in je IDE geen knal uit.

Dat snap ik prima, maar ik moet deze code uploaden in een formulier. Code wordt geupload en ik kan dan het resultaat bekijken. Heb geen db-toegang en geen commandline toegang.

phpmyadmin is dus GEEN optie.

[SinergyX]

Resultaat in elke vorm? Pak je toch gewoon Adminer ofzo die als singlefile script een complete db manager is?

Krijg je uberhaubt resultaat zonder de LIKE query?

[Woy]

Het is al aangehaald, maar het is vrij duidelijk dat je de wildcards gewoon in je input parameter moet stoppen.

PHP:

$naam = '%' . $naam . '%'

Of natuurlijk gewoon daadwerkelijk in je query concattenaten

SQL:

WHERE voornaam LIKE CONCAT( '%', ?, '%' )

Al weet ik niet of mysql concat op deze manier support, maar dan is er vast een andere mogelijkheid om in mysql om meerdere strings te concatten.

[ Voor 62% gewijzigd door Woy op 21-04-2020 14:01 ]

[Boudewijn]

SinergyX schreef op dinsdag 21 april 2020 @ 13:56:

Krijg je uberhaubt resultaat zonder de LIKE query?

Jazeker dat gaat prima.

Woy schreef op dinsdag 21 april 2020 @ 13:56:
Het is al aangehaald, maar het is vrij duidelijk dat je de wildcards gewoon in je input parameter moet stoppen.

PHP:

$naam = '%' . $naam . '%'

Nav MueR in "Oude php : mysqli + bind_results" deed ik dat dus ook.

Mijn oude code:

code:

         $query = '%' .$query . '%';
         
         $sql = new mysqli("localhost", "A", "B", "C");
         $stmt = $sql->prepare("SELECT voornaam FROM persoon WHERE voornaam LIKE ? OR achternaam LIKE ?");

Dit werkt wel:

code:

$query = "%{$query}%";

Case solved.


Dank voor de hulp.

[Woy]

@Boudewijn nou ben ik niet zo thuis in PHP
maar als

PHP:

$query = "%{$query}%";

werkt dan moet

PHP:

$query = '%' .$query . '%';

Ook werken. Hoe je de variabele samenstelt haalt natuurlijk niet uit, als de waarde maar gewoon goed is.

[Boudewijn]

Ja dat was ook mijn denkrichting, maar deze shell denkt daar dus anders over. Ik snap het ook niet. Soit. Hij is opgelost.

[hackerhater]

Zo'n oude PHP-versie, die al jaren out of support is
Ik hoop dan ten zeerste dat die niet via het internet bereikbaar is.

[Boudewijn]

hackerhater schreef op dinsdag 21 april 2020 @ 17:23:
Zo'n oude PHP-versie, die al jaren out of support is
Ik hoop dan ten zeerste dat die niet via het internet bereikbaar is.

niet direct nee. Dont worry.