PHP 7 - impliciete conversie van array naar string

[Sinna]

PHP 7.x deed een impliciete conversie van array naar string als de opgeroepen functie een string verwachtte, bv. bij htmlspecialchars().

Nu PHP 7.x al een tijdje EOL is, loop ik soms nog tegen PHP Fatal Errors als volgende aan:

Uncaught TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given

Ik los het voorlopig op door

Code: Selecteer alles

$value

ter vervangen door

Code: Selecteer alles

(is_array($value)? implode($value): $value)

maar vrees dat dit niet sluitend is.

Ik zou daarom graag weten hoe PHP < 8.0 die impliciete conversie deed. Ik vind daar echter geen info omtrent terug of ik gebruik de verkeerde zoektermen.
Hoe hebben jullie dat aangepakt? (Een) online bron(nen) zijn welkom.

[Splitter]

is dat niet gewoon een fout van je code?
ik geloof niet dat htmlspecialchars ooit een array wilde....
het is misschien mogelijk dat er een optie was in de ini file, maar dat weet ik niet dadelijk, gezien ik het nooit heb nodig gehad.

je oplossing lijkt trouwens wel correct (genoeg) te zijn: je checkt of het een array is, en in dat geval maak je er een string van,
waarna je het wel aan htmlspecialchars kan voeren.

al lijkt me dat nog niet de béste oplossing: je zou eigenlijk moeten kijken waarom je uberhaupt met een array zit die je aan htmlspecialchars zou willen geven,
want vermoedelijk ben je ergens in de volgordes iets fout aan het doen.

stel dat het gaat over form input:

- eerst in javascript de basics checken
- dan submitten
- dan de values die gesubmit worden (strings) aan specialchars voeren
- dan verwerken en eventueel in een DB gooien

als je eerst de gesubmitte input gaat verwerken en eindigt met een array, en dan pas aan specialchars gaat geven loopt het mis.

[Sinna]

Ik zit te klooien in code die ik niet zelf geschreven heb, nl. HTML QuickForm (niet HTML QuickForm2) wat als package gebruikt wordt binnen Chamilo.
Idealiter stap ik over naar QuickForm2 maar QuickForm lijkt niet zomaar inwisselbaar voor QuickForm2.

Chamilo zelf is officieus PHP 8 compatibel (volgens Yannick Warnier, de lead developer). Aangezien PHP 7 al sinds eind november 2022 EOL is, wil ik die eigenlijk niet meer in productie-omgevingen toepassen.
Nu ik deze reactie schrijf, realiseer ik me dat ik alsnog op een niet-langer ondersteunde versie draai (PHP 8.0). Zomaar PHP 8.0 voor PHP 8.2 inwisselen lijkt mij zonder de nodige voorgaande testen niet aangewezen, zeker gezien de miserie met de overstap van PHP 7.4 naar PHP 8.

Onder PHP 7 deed de software het gewoon, vandaar dat ik een impliciete conversie vermoed maar die graag geëxpliciteerd zag.

[Splitter]

php is over de jaren heen wel veel matuurder en strikt geworden (een heel verschil tov php3, waar ik destijds mee begonnen ben)

in principe doet (deed?) php implicit type casting (het gaat het type van je variable bepalen adhv de inhoud ervan)
bv als je zegt x = 1 dan zal php dat als int zien, je hoeft niet (int) x = 1 te doen.

ik weet niet of dat ooit van toepassing was tussen array & string conversies, gezien ik nooit in die situatie gezeten heb (zorgde altijd dat de waarde van het juiste type was voor ik het ergens aan doorspeelde)

misschien dat "type juggling", "type casting" en "implicit casting" je verder op weg kunnen helpen met je zoektocht.

onthou wel ook dat php snel evolueert in versies, en hoewel je ondertussen best minimaal op php 8.2 kan zitten, zitten er nog tal van hostings op een php7x versie (of zelfs lager....)


edit:

volgens chatgpt zou het gedrag van htmlspecialchars in 7 & 8 gelijk gebleven zijn (zoals ik dacht):

In both PHP 7 and PHP 8, passing an array to htmlspecialchars() results in a warning being generated and the function returning NULL. It's important to pass a string to this function, not an array.

mogelijks zit er dus ergens een andere functie in de code die de vertaling voorheen deed en nu niet meer (correct) werkt.