WordPress and Magic Quotes
This is crazy, and based on a post called WordPress and PHP magic quotes: you want to run me crazy! by Stefano Lissa. I’m writing a plugin prototype for WordPress that uses the new Facebook Graph API to post stuff to my wall on Facebook (upcoming blog post). The original Facebook PHP SDK comes in very handy when working with the Facebook API, and I had quite some fun using it, but..
I’ve been trying to figure this out for hours! I had code working outside WordPress and once I pumped it into a plugin it suddenly stopped authorizing me. I had to dig through the facebook.php code to figure out what’s happening, and here it is. The getSession() method uses the get_magic_quotes_gpc function and strips the slashes from the $_COOKIE superglobal if it’s switched on. Of course, that’s the correct logic supporting both php 5 and php 6, but not WordPress.
I looked through the latest (3.0.1) WordPress core code and was quite surprised to see a function called wp_magic_quotes(). Oh my god, thought I! Commented as: Add magic quotes and set up $_REQUEST ( $_GET + $_POST ).
What the hell is that? Okay, let’s see:
$_GET = add_magic_quotes($_GET); $_POST = add_magic_quotes($_POST); $_COOKIE = add_magic_quotes($_COOKIE); $_SERVER = add_magic_quotes($_SERVER);
How does that sound? So all my apps, plugins, external libraries working with server variables (like Facebook does with cookies) are not allowed to use the magic quotes function? This means that working with WordPress, we must initially assume that all these are quoted, no matter what the php settings are. I don’t even know what question to ask here, perhaps: Is this the way things are done? Why?
To be honest this is getting me a little frustrated. Not by the fact that they’re slashing the whole input (although I don’t see a reason to) but, heh, I’ve been coding based on WordPress for over two years now, and never came across anything like this. Did I miss something in the Getting Started guide? ;) Anyways, the easiest way to get this working is to replace your get_matic_quotes_gpc function with 1, which says it is always switched on.
Eh, Monday morning disappointment ;) Cheers, and thanks for sharing the post!
Essentially WordPress sets environment for its own convenience, rwithout regard for WP-unspecific code. I don't think it is good or bad by itself, but it is definitely something to keep in mind when you start plugging unrelated code.
Makes epic conflicts. :)
It's good to setup an environment for yourself and work there.. yourself ;) But WordPress is an open platform which has quite a good plugin architecture, which means that they welcome foreign code. Ugh, it's Tuesday already and I'm still disappointed :D
The general consensus is that while it would be great to remove the emulation of magic quotes, we couldn't without a huge backwards compatibility issue on our hands.
Here's a thread from wp-hackers back in May about this, which covers the pitfalls in more detail. http://lists.automattic.com/pipermail/wp-hackers/…
Thanks for the link Andrew, interesting stuff there in the lists, quite some disappointment there too as expected, but.. Damn, $_SERVER, $_COOKIE, $_GET, $_POST and $_REQUEST are predefined server variables, and they're there to use, not alter.
So backward compatibility. Right. But why was it that way in the first place? Was it somebody's mistake that's been around for years? I guess the correct way would be to use some class, perhaps static, and encourage users to use that class and rewrite their plugins. Server::COOKIE['my-cookie'] or whatever.
My point is that it's not fair to the rest of us ;) I literally spent hours to figure it out and had no idea it was related to magic quotes!
Cheers ;) and keep up the good work back there!
I would love for WordPress to not need to alter such variables, but there are huge discrepancies across server setups. We literally have an entire function dedicated to repairing the $_SERVER variable (wp_fix_server_vars() in wp-includes/load.php).
We've always been stuck with difficult choices as it relates to ensuring that we are compatible with as many server setups as possible. Some of the things we've done, such as our HTTP and Filesystem abstraction layers, are solid examples of needing to develop one-size-fits-all solutions. Adopting magic quotes internally (more than five years ago) may not have been the best approach, but that's only apparent in hindsight.
Even on a system with magic quotes off, the only choice is to continue to escape everything, providing that extra security to plugins, many of which are not developed by those particularly familiar with best security practices. The difficulties in integration with other bases of code is, I think, a small if unfortunate price to pay.
I freaking wish the PHP developers would make _GET, _POST etc read-only!
Seems pointless to argue about this in WP mailing list wp-hackers. There needs to be other API or something to get stuff in non-magic quoted format so people can graciously get rid of that stupidity in WP core.
GRR!
Well, that's something that has to be implemented in PHP, not WordPress, and would make sense too!
I agree with Ciantic. They could at least add a wp_remove_magic_quotes function, or maybe add a settings value to disable the wp_magic_quotes function, so I can decide to disable it for my install of WP and deal with the incompatible plugins myself. This makes writing new plugins a real pain. I thought we have seen the last of magic quotes with it being removed from PHP 6, but now I have to deal with that again in WP. What a pain in the ass.
My lord. I spent the last 5 hours playing with my XAMPP server trying to figure out why slashes were being added even though magic quotes were off…those WP developers, man…
No. Those PHP developers, man. This is an upstream thing. Our hands are mostly tied.
Ah…read your commented above, makes sense.
did they force you to solve the escaping issue this way?
as you and others also mentioned, wordpress could provide a proper infrastructure for accessing the request variables instead of overwriting the superglobals.
IMO the roadmap is clear: create a proper interface for handling user input, start marketing it, update the docs and the examples to teach the newcommers to use this, and after a while, fix or drop those plugins which can't keep up with the trends.
Tyrael