[PHP] Magic quotes staat nog aan?

[_Thanatos_]

Ik draai een linux server met PHP 5.4, en volgens de documentatie en alle 18 miljard blogposts daarover zou magic quotes niet alleen uit moeten staan, het zou niet eens meer mogen bestaan. Je hoort er geen last meer van te hebben.

Echter, als ik een " submit en die oplepel uit $_POST (of z'n tegenhanger), dan staat daar doodleuk een backslash bij. Een string van twee karakters echt. Dus magic quotes lijkt nog aan te staan, maar het was het verwijderd?

get_magic_quotes_gpc() geeft dan ook false terug. get_magic_quotes_runtime() is ook false. get_magic_quotes_sybase() bestaat niet (zal wel in een extensie zitten).

Uhh, lolwut?

Zoeken op google had ik net zo goed niet kunnen doen, want iedereen zegt dat je magic quotes uit moet zetten... Maar die feature bestaat niet meer! Grmbl!

En nu?

[Matis]

Misschien state ik the obvious, maar heb je apache2 al herstart?

edit; Ik zie net dat vanaf php 5.4 magic quotes niet eens meer bestaat. Weet je zeker dat je die versie draait? bron: http://www.php.net/manual/en/security.magicquotes.what.php

Wat zegt php_info?

[ Voor 64% gewijzigd door Matis op 17-04-2013 22:32 ]

[Gomez12]

Hoe wordt die post geproduceert?

Is het niet simpelweg je browser oid die het escaped?

[DNB]

Gebruik je niet toevallig eenofander framework dat dit doet? Bijvoorbeeld Wordpress voert standaard addslashes uit op $_POST/$_GET/$_REQUEST

[_Thanatos_]

Misschien state ik the obvious, maar heb je apache2 al herstart?

De hele server zelfs (vanwege updates, maar apache2 daarmee dus ook )

Weet je zeker dat je die versie draait?

Ja.

Wat zegt php_info?

Dat ik 5.4 draai.

Maar jongens, die get_magic_quotes* functies geven false terug. Dus welke versie ik ook heb, magic quotes zou niet toegepast moeten worden, en het gebeurt toch.

Verder nog:

Hoe wordt die post geproduceert?

Gebruik je niet toevallig eenofander framework dat dit doet?

In de url staat: index.php?val=""

PHP:

var_dump($_GET['val']);
echo $_GET['val'];

Resultaat:

code:

string(4) "\"\""
\"\"

In de ruwe HTML source zie ik die backslashes ook.

Een string van 4 karakters dus, en niet twee zoals ik meegaf in de url. Zelfde laken en pak voor POST variabelen. Dus nee, geen framework die dingen omklust.

[Pizzalucht]

Weet het niet zeker, maar zou het kunnen dat Suhosin dit doet?

[Verwijderd]

Probeer voor de grap het eens via ini_get .. dus ini_get('magic_quotes_gpc'). Ik heb weleens meegemaakt dat de functie andere waarden teruggaf dan ini_get

[_Thanatos_]

Helaas helaas, ik heb geen Suhosin geinstalleerd en de ini_get manier geeft ook geen soelaas:

PHP:

var_dump(extension_loaded('suhosin'));
var_dump(ini_get('magic_quotes_gpc'));

Beide false...

/edit
En wat blijkt? WordPress loopt op eigen houtje magic quotes te doen
Wie had dat gedacht, want dit is geen plugin ofzo. Mijn code draait los van wordpress, en toch plast WP er nog even overheen. Erger nog: WP rapporteert niet dat magic quotes terug zijn, je moet het maar magischerwijs weten (pun intended). En wanneer de klotskoppen van WP dit gedrag aanpassen, kun dáár ook niet op controleren.

Ik heb al een bug ingediend. Of WP daar als de donder mee op wil houden.

Ook erg is dat als magic quotes in PHP aan staat, gaat WP ze eerst weghalen, en daarna weer toevoegen. Epic fail

[ Voor 59% gewijzigd door _Thanatos_ op 18-04-2013 21:24 ]

[Bolukan]

Moet je die quotation mark dan niet encoden (%22). Misschien doet de 'browser' dit nu voor je?
probeer dit eens: "index.php?val=" . urlencode("""")

Ook hier terug te vinden: http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1

[ Voor 35% gewijzigd door Bolukan op 18-04-2013 21:39 ]

[Creepy]

Moet je me toch eens uitlegggen hoe een wordpress install code beinvloed die buitenom wordpress draait.... Ik heb het idee dat je toch echt ergens anders overheen zit te kijken of je code wel degelijk door Wordpress wordt uitgevoerd waarbij Wordpress dus de POST actie zelf opvangt. En om dan nu zo te lopen afgeven hoeft dan toch ook weer niet...

[ Voor 19% gewijzigd door Creepy op 18-04-2013 22:10 ]

[PatrickH89]

Blijft natuurlijk waardeloos dat het eerste wat wordpress doet is je input verpesten.

[HollowGamer]

PatrickH89 schreef op vrijdag 19 april 2013 @ 08:06:
Blijft natuurlijk waardeloos dat het eerste wat wordpress doet is je input verpesten.

Ja, het is belachelijk dat een pakket dat jij gratis mag gebruiken, dit doet.

[Cartman!]

Creepy schreef op donderdag 18 april 2013 @ 22:06:
Moet je me toch eens uitlegggen hoe een wordpress install code beinvloed die buitenom wordpress draait.... Ik heb het idee dat je toch echt ergens anders overheen zit te kijken of je code wel degelijk door Wordpress wordt uitgevoerd waarbij Wordpress dus de POST actie zelf opvangt. En om dan nu zo te lopen afgeven hoeft dan toch ook weer niet...

Het lijkt mij inderdaad behoorlijk sterk dat WordPress ineens invloed heeft op een volledig losstaand stuk code. Als dat zo zou zijn dan hebben ze een behoorlijk lek gevonden in PHP volgens mij.

Afgeven op WordPress vind ik ook onnodig, als t zo slecht is..dan schrijf je toch zelf iets

[steffex]

je bent niet de enige met dit probleem: http://stackoverflow.com/...ontinue-to-auto-escape-my

Er wordt ook een oplossing aangedragen.

Misschien toch niet helemaal hetzelfde.

Is er ook nog een andere versie van php aanwezig op je server? Misschien apache iets smerigs uithaalt door de andere php te gebruiken.

[ Voor 31% gewijzigd door steffex op 19-04-2013 09:38 ]

[Janoz]

Het enige wat ik me kan voorstellen is dat er ergens een .htaccess staat met een rewrite rule die ook toegepast wordt op de, in de ogen van de topicstarter, compleet losstaande code. het request zal dan alsnog via wordpress lopen.

[NMe]

Waar zegt 'ie precies dat hij geen Wordpress gebruikte voor die pagina? Ik zie hem in _Thanatos_ in "[PHP] Magic quotes staat nog aan?" alleen zeggen dat er "geen framework dingen omklust" maar hij zegt nergens dat hij 't niet gebruikt.

Verder wel grappig want DNB in "[PHP] Magic quotes staat nog aan?" noemde het WP-probleem al veel eerder.

[Creepy]

@NME:

Wie had dat gedacht, want dit is geen plugin ofzo. Mijn code draait los van wordpress, en toch plast WP er nog even overheen

[FotW]

@Creepy

Hij zegt dat het geen plugin is, niet dat het niet binnen WP draait. Wellicht een zelf geschreven "plugin" die geen gebruik maakt van de WP functions, dat is nu niet duidelijk.

[Janoz]

Vandaar dus ook mijn opmerking dat een (of de) .htaccess er voor (kan) zorg(t/en) dat een rechtstreekse URL naar je eigen pagina alsnog via de WP controler loopt.

[Pizzalucht]

FotW schreef op vrijdag 19 april 2013 @ 11:06:
@Creepy

Hij zegt dat het geen plugin is, niet dat het niet binnen WP draait. Wellicht een zelf geschreven "plugin" die geen gebruik maakt van de WP functions, dat is nu niet duidelijk.

Mijn code draait los van wordpress

[Creepy]

Dus voordat we lekker met z'n allen gaan overleggen over wat er nu precies aan de hand is kunnen we beter even wachten totdat _Thanatos_ uitlegt waarom Wordpress toch de POST opvangt

[_Thanatos_]

Het is een losse php die door een wordpress pagina (een "Page" dus, in WP-termen) wordt aangeroepen. Kennelijk verpest WP ook daarvoor dus de input. God mag weten dus wat ie nog meer omklust (een korte blik op de code doet me vermoeden dat $_REQUEST ook opnieuw opgebouwd wordt, en wel met andere inhoud dan wat PHP standaard aanbiedt.

HollowGamer schreef op vrijdag 19 april 2013 @ 09:11:
[...]Ja, het is belachelijk dat een pakket dat jij gratis mag gebruiken, dit doet.

Inderdaad ja. Gezien het aantal developers en gebruikers, het aantal jaren dat het pakket al bestaat. Er zijn zoveel dingen gratis die beter zijn dan de betaalde tegenhangers. "Gratis" is geen vrijbrief voor crappy functionaliteit.

NMe schreef op vrijdag 19 april 2013 @ 10:37:
Waar zegt 'ie precies dat hij geen Wordpress gebruikte voor die pagina? Ik zie hem in _Thanatos_ in "[PHP] Magic quotes staat nog aan?" alleen zeggen dat er "geen framework dingen omklust" maar hij zegt nergens dat hij 't niet gebruikt.

Verder wel grappig want DNB in "[PHP] Magic quotes staat nog aan?" noemde het WP-probleem al veel eerder.

Daar ben ik me van bewust. Echter zie ik WP niet als framework. Meer als een bij elkaar geveegt bergje functies wat in samenhang een blog moet voorstellen. Dat is prima, maar met dit soort acties ook lastig. Er lijkt immers niets te gebeuren in een pagina die niets aanroept, maar toch gebeuren er dingen op superglobaal niveau, en dat is niet de taak van een stuk script. Daarom, én omdat iedere poging tot navraag aangeeft dat MQ uitstaat, mijn aanname dat WP de oorzaak niet kon zijn.

Misschien ben ik te verwend met echte applicaties. Applicaties zoals je die in IIS kunt aanmaken. Daarmee kun je een stuk code binnenin de directorystructuur van een applicatie isoleren van die applicatie, door de directory als applicatie te definiëren. Ik weet niet of dat de oplossing zou zijn als het mogelijk was, maar feit is wel dat een goeie applicatie zich alleen bemoeit met code die bij die applicatie hoort, en niet de werking van het bovenliggende framework (=PHP) gaat aanpassen.

In elk geval bedankt voor het meedenken

[Pizzalucht]

Je Include dus een PHP script in je Wordpress pagina, dan zit je dus in de scope van Wordpress, dat is logisch.

Misschien kun je php://input gebruiken?

[NMe]

_Thanatos_ schreef op vrijdag 19 april 2013 @ 14:39:
Het is een losse php die door een wordpress pagina (een "Page" dus, in WP-termen) wordt aangeroepen.

Hoe krijg je het klaar om dat een kale PHP-pagina te noemen? Natuurlijk zit je dan in het framework en natuurlijk krijg je dan alle features, ook de dubieuze, mee.

_Thanatos_ schreef op vrijdag 19 april 2013 @ 14:39:
Misschien ben ik te verwend met echte applicaties. Applicaties zoals je die in IIS kunt aanmaken. Daarmee kun je een stuk code binnenin de directorystructuur van een applicatie isoleren van die applicatie, door de directory als applicatie te definiëren. Ik weet niet of dat de oplossing zou zijn als het mogelijk was, maar feit is wel dat een goeie applicatie zich alleen bemoeit met code die bij die applicatie hoort, en niet de werking van het bovenliggende framework (=PHP) gaat aanpassen.

PHP biedt geen mogelijkheid om "magic quotes" toe te passen op alle input zonder de superglobals aan te passen. Verder is het een beetje makkelijk afgeven op WordPress, maar daar zat de fout hier helemaal niet. Die zat erin dat je blijkbaar geen idee had dat je het hele framework in zat te laden.

[ Voor 54% gewijzigd door NMe op 19-04-2013 15:08 ]

[Creepy]

@ _Thanatos_ : Jouw bug is gemarkeerd als duplicate http://core.trac.wordpress.org/ticket/18322 is de originele bug. Wordpress doet dit nu simpelweg altijd, dus je moet er zelf omheen gaan werken of inderdaad zelf php://input zelf gaan uitlezen

[RobIII]

Dom idee van een non-php-devver: kun je niet zorgen dat je eerst de $_REQUEST/$_GET/$_POST/$_WHATEVER even "opzij zet" voordat je WP include?

code:

$my_get = $_GET;
$my_post = $_POST;
$my_request = $_REQUEST;
...
include('/foo/bar/wp_stuff.php');
...
//Gebruik hier lekker je $my_ variablen

Je zou zelfs de originele variablen kunnen 'herstellen', maar dat lijkt me weer gevaarlijk omdat WP klaarblijkelijk wel uitgaan van "slashed"-inhoud.

[edit]
Zoiets:

PHP:

function savevariables() {
  return array(
    'post' => isset($_POST) ? $_POST: null,
    'get' => isset($_GET) ? $_GET: null,
    'request' => isset($_REQUEST) ? $_REQUEST : null,
    'cookie' => isset($_COOKIE) ? $_COOKIE: null,
    'server' => isset($_SERVER) ? $_SERVER: null,
    'session' => isset($_SESSION) ? $_SESSION : null,
    'env' => isset($_ENV) ? $_ENV : null,
    //$_FILES..
    //$_..
    //...
  );
}

$rescued = savevariables();

include('/foo/bar/wp_stuff.php');

var_dump($rescued );

[ Voor 39% gewijzigd door RobIII op 19-04-2013 19:05 ]

[GlowMouse]

RobIII schreef op vrijdag 19 april 2013 @ 18:32:
Dom idee van een non-php-devver: kun je niet zorgen dat je eerst de $_REQUEST/$_GET/$_POST/$_WHATEVER even "opzij zet" voordat je WP include?

code:

$my_get = $_GET;
$my_post = $_POST;
$my_request = $_REQUEST;
...
include('/foo/bar/wp_stuff.php');
...
//Gebruik hier lekker je $my_ variablen

Je zou zelfs de originele variablen kunnen 'herstellen', maar dat lijkt me weer gevaarlijk omdat de PHP functies klaarblijkelijk wel uitgaan van "slashed"-inhoud.

Je moet daarna wel $_GET/etc weer vullen met de $my_get/etc omdat de scope van $_GET anders is dan van $my_get. $_GET is een superglobal die ook binnen een functie beschikbaar is.

[RobIII]

GlowMouse schreef op vrijdag 19 april 2013 @ 18:39:
Je moet daarna wel $_GET/etc weer vullen met de $my_get/etc omdat de scope van $_GET anders is dan van $my_get. $_GET is een superglobal die ook binnen een functie beschikbaar is.

Hangt er maar net van af hoe je 't gebruikt. Je kunt (zie edit) $rescued['get'] gebruiken i.p.v. $_GET (gebruik DI of pass $resqued naar constructors/methods/...) maar je kunt ook, voor de "duur van je code", de superglobals herstellen met de waardes die je 'gered' hebt en als je code aan z'n eind is de meuk die WP ervan gebakken heeft herstellen in de superglobals:

PHP:

//Get original values
$rescued = savevariables();

//Let WP mess it all up
include('/foo/bar/wp_stuff.php'); 

//Save messed up stuff
$wpmeuk = savevariables();

//Set globals back to our rescued values
restoreglobals($rescued);

//Do our stuff here...
//Do our stuff here...
//Do our stuff here...

//We're done: make sure we mess it back up for WP:
restoreglobals($wpmeuk);

Zoiets. Waarbij restoreglobals() natuurlijk weer $_GET = ..., $_POST = ... doet natuurlijk; het omgekeerde van savevariables() dus. _{Zoals je ziet heb ik de naming van de methods ook in lijn gehouden met de naamgeving die PHP gebruikt overal}

Mooi / wenselijk is anders (en 't kan vast nog veel slimmer, heeft PHP niet een resque_values_from_superglobals_before_WP_fucks_them_up() functie? ) maar de praat niet waard. Haal je schouders op, zucht, vloek, mep je rubbereend een keer en suck it up. Een 'workaround' is, zoals je ziet, in een paar minuten in elkaar gedraaid (even aangenomen dat dit werkt; WP doet immers voor zover ik 't begrijp iets soortgelijks).

[ Voor 34% gewijzigd door RobIII op 19-04-2013 22:56 ]

[PatrickH89]

HollowGamer schreef op vrijdag 19 april 2013 @ 09:11:
[...]

Ja, het is belachelijk dat een pakket dat jij gratis mag gebruiken, dit doet.

Dat iets open source is hoeft niet per sé te betekenen dat je alles op de verkeerde plek moet gaan zitten sanitizen, heeft niets te maken met of het gratis is of niet.

[HollowGamer]

PatrickH89 schreef op zaterdag 20 april 2013 @ 13:17:
[...]


Dat iets open source is hoeft niet per sé te betekenen dat je alles op de verkeerde plek moet gaan zitten sanitizen, heeft niets te maken met of het gratis is of niet.

Het woord 'gratis' was misschien niet hier op zijn plaats. Het feit is wel dat TS afgeeft op een pakket waar door developers aan gewerkt in hun vrije tijd. Verder gebruiken gebruikers/developers WP al jaren 'probleemloos'.

Als je echt niet tevreden bent op een pakket, bouw het dan zelf. Of stel (zoals TS ook gegaan heeft) een oplossing voor. Feit is wel dat WP zodanig is gemaakt dat het voor iedereen wel werkt.

[HuHu]

HollowGamer schreef op zaterdag 20 april 2013 @ 13:27:
[...]

Het woord 'gratis' was misschien niet hier op zijn plaats. Het feit is wel dat TS afgeeft op een pakket waar door developers aan gewerkt in hun vrije tijd. Verder gebruiken gebruikers/developers WP al jaren 'probleemloos'.

Er zijn ook mensen die een screenshot van hun scherm nemen en emailen door: een foto van het scherm te maken, die afdrukken, dat inscannen, plakken in Word, uitprinten, fotograferen en middels Whatsapp versturen. Dat het werkt en "probleemloos" wordt gebruikt, wil nog niet zeggen dat het goed is.

[HollowGamer]

HuHu schreef op zaterdag 20 april 2013 @ 14:54:
[...]

Er zijn ook mensen die een screenshot van hun scherm nemen en emailen door: een foto van het scherm te maken, die afdrukken, dat inscannen, plakken in Word, uitprinten, fotograferen en middels Whatsapp versturen. Dat het werkt en "probleemloos" wordt gebruikt, wil nog niet zeggen dat het goed is.

Als je zelf denkt dat er betere oplossingen zijn, dan zou je een aantal dingen kunnen ondernemen:
1. De persoon duidelijk maken d.m.v. rooksignalen. Hoe meer tussenpoos hoe beter
2. De persoon duidelijk maken dat er betere oplossingen zijn, zo ja, duidelijk maken waarom
3. Negeren/aanvaarden
4. Zelf een betere methode ontwikkelen/het 'probleem' omzeilen

Het gaat er bij om dat TS in mijn ogen afgeeft in dit geval op het pakket Wordpress. Er werken veel developers aan, zowel aan de ontwikkeling alsook developers die er websites mee bouwen. Geen enkele 'oplossing' is perfect. Je kan zelf wel actie ondernemen als je zelf een betere oplossing hebt: bug-report, forum, email, etc.

Ik word zelf gewoon een beetje moe om meteen maar iemand een 'prutser', etc. te noemen. We zijn tenslotte allemaal mensen niet waar. We leren elke dag weer bij.

[_Thanatos_]

NMe schreef op vrijdag 19 april 2013 @ 15:03:
[...]Hoe krijg je het klaar om dat een kale PHP-pagina te noemen? Natuurlijk zit je dan in het framework en natuurlijk krijg je dan alle features, ook de dubieuze, mee.

Zo natuurlijk vind ik dat niet. Ik ben niet zo gedreven met PHP, dus hoe moet ik nou weten wat een ge-include script allemaal gratis meekrijgt? Dat kun je noch aan dat script, noch aan de template voor een Page, duidelijk zien.

RobIII schreef op vrijdag 19 april 2013 @ 18:32:
Dom idee van een non-php-devver: kun je niet zorgen dat je eerst de $_REQUEST/$_GET/$_POST/$_WHATEVER even "opzij zet" voordat je WP include?

Nee, daar krijgt een dergelijk script de kans niet voor. Vanaf regel heb je alle dubieuze features te pakken, of je er nou om vraagt of niet.
Een script met alléén dit en verder niets:

PHP:

var_dump($_GET["blaat"]);

Heeft dat probleem al.

HollowGamer schreef op zaterdag 20 april 2013 @ 13:27:
[...]Als je echt niet tevreden bent op een pakket, bouw het dan zelf. Of stel (zoals TS ook gegaan heeft) een oplossing voor. Feit is wel dat WP zodanig is gemaakt dat het voor iedereen wel werkt.

Dat eeuwige "als je het niet aanstaat doe je het zelf maar" argument weer. Serieus? Vinden dat WP beter moet werken mag niet ofzo

HollowGamer schreef op zondag 21 april 2013 @ 12:37:
[...]Het gaat er bij om dat TS in mijn ogen afgeeft in dit geval op het pakket Wordpress. Er werken veel developers aan, zowel aan de ontwikkeling alsook developers die er websites mee bouwen. Geen enkele 'oplossing' is perfect. Je kan zelf wel actie ondernemen als je zelf een betere oplossing hebt: bug-report, forum, email, etc.

Ik word zelf gewoon een beetje moe om meteen maar iemand een 'prutser', etc. te noemen. We zijn tenslotte allemaal mensen niet waar. We leren elke dag weer bij.

Bugreport is dus gedaan. Maar die wordt gelijk afgeketst als "duplicate". Ze snappen dus ook niet dat als er meerdere bugreports over één issue zijn, dat dat de urgentie verhoogt. Ik zal nog es m'n stinkende best doen om die devvers iets duidelijk te maken zeg...

Wat ze ook niet snappen, is dat het grootste probleem is dat WP geen signaal afgeeft dat de magic quotes terug zijn, terwijl alle flags en functies erop wijzen dat ze er niet zijn! Het is nu alsof php tegen me liegt, terwijl het WP is die roet in het eten gooit. Roet ja, wat het zorgt voor een uitkomst uit een standaard test om te kijken of magic quotes aan staan, die gewoon keihard niet waar is.

[Woy]

_Thanatos_ schreef op maandag 22 april 2013 @ 03:05:
[...]
Bugreport is dus gedaan. Maar die wordt gelijk afgeketst als "duplicate". Ze snappen dus ook niet dat als er meerdere bugreports over één issue zijn, dat dat de urgentie verhoogt. Ik zal nog es m'n stinkende best doen om die devvers iets duidelijk te maken zeg...

Dat is natuurlijk geen manier van werken. Dan gaat iedereen duplicates inschieten voor de dingen die ze vervelend vinden om zo meer prioriteit te krijgen. Dan is het bug-track systeem in één keer waardeloos geworden. Dat het een duplicate is is gewoon terecht.

[NMe]

_Thanatos_ schreef op maandag 22 april 2013 @ 03:05:
[...]

Zo natuurlijk vind ik dat niet. Ik ben niet zo gedreven met PHP, dus hoe moet ik nou weten wat een ge-include script allemaal gratis meekrijgt? Dat kun je noch aan dat script, noch aan de template voor een Page, duidelijk zien.

Sorry hoor, maar zo werkt het in elke taal die ik ken. Als jij vanuit het framework een include doet van je pagina dan zit je niet ineens niet meer in je framework. Als je dat niet begrijpt dan heb je niet alleen PHP niet begrepen maar programmeren in zijn algemeen niet. Ik ken geen enkele taal waarbij een include ineens je complete context weggooit.

_Thanatos_ schreef op maandag 22 april 2013 @ 03:05:
Bugreport is dus gedaan. Maar die wordt gelijk afgeketst als "duplicate". Ze snappen dus ook niet dat als er meerdere bugreports over één issue zijn, dat dat de urgentie verhoogt. Ik zal nog es m'n stinkende best doen om die devvers iets duidelijk te maken zeg...

Wat Woy zegt. Hoe wilde jij in hemelsnaam nog overzicht houden in de lijst met bugs en feature requests als dezelfde bug er honderd keer in staat? Het is geen populariteitswedstrijd of idols waarin de bug met de meeste stemmen wint. En zelfs als het dat wel is kun je in veel systemen een bug starren.

Wat ze ook niet snappen, is dat het grootste probleem is dat WP geen signaal afgeeft dat de magic quotes terug zijn, terwijl alle flags en functies erop wijzen dat ze er niet zijn! Het is nu alsof php tegen me liegt, terwijl het WP is die roet in het eten gooit. Roet ja, wat het zorgt voor een uitkomst uit een standaard test om te kijken of magic quotes aan staan, die gewoon keihard niet waar is.

Wat jij niet lijkt te snappen is dat WP niks te maken heeft het "echte" magic quotes. Zij hadden blijkbaar om wat voor maffe reden dan ook die functionaliteit nodig. PHP roept al jaren dat ze van MQ af willen, dus willen ze er om logische redenen niet op vertrouwen dat die functionaliteit bestaat. Dan is de volgende stap om het zelf te repliceren. Het is nogal logisch dat ze PHP vervolgens niet terug kunnen laten geven dat MQ aan staan, want dat is niet zo. Hoe zie je dat überhaupt voor je? Ze kunnen moeilijk PHP zelf gaan hacken om te zorgen dat ini_get of de MQ-functies ineens op hún voorwaarden true returnen in plaats van voor de voorgeprogrammeerde voorwaarden.

Jouw verwachtingen van zowel de programmeertaal als de programmeurs die ermee werken zijn nogal scheef, en dat ligt toch echt aan jezelf.