gpc_magic_quotes

btw, since at this point in time most web applications are AJAX I suspect you will find that a large amount of the $_POST data being sent to WordPress is in json strings and thus, will have to have the escapes removed from it before it is ever fed to a database (if it is ever fed to a database).

So any small amount of protection you think you are giving by escaping all $_POST content is effectively neutured just by the nature of modern webapp development which includes sending data to servers in JSON strings.

Just get rid of it, prepared statements are the right way to protect against SQL injection and make escapes completely un-necessary.

https://core.trac.www.ads-software.com/ticket/18322

So it’s a messy and long problem, but it’s not ‘normal’ magic quotes, it’s WordPress magic quotes. It’s not quite the same thing.

A solution I’m using for my plugin, none of my AJAX is done through the WordPress way. It is faster on execution and a lot easier to completely bypass the WordPress stuff for AJAX. And it is easier to debug.

So what I’m doing

<?php
$PPOST = $_POST;
// Now load WordPress settings and stuff
require('../../../wp-load.php');

That gives me a pristing copy of $_POST that has not been mangled in any way by wordpress.

-=-

Some people who bypass the WordPress AJAX API say you can get even more speed by using SHORTINIT but I found that breaks some of my stuff, so I don’t use that.

We reject all plugins from www.ads-software.com that call wp-load directly these days (so there may be some stragglers out there, but we try to educate them as we can).

Here’s the boilerplate why:

Including wp-config.php, wp-blog-header.php, wp-load.php, or pretty much any other WordPress core file that you have to call directly via an include is not a good idea and we cannot approve a plugin that does so unless it has a very good reason to load the file(s). It is prone to failure since not all WordPress installs have the exact same file structure.

Usually plugins will include wp-config.php or wp-load.php in order to gain access to core WordPress functions, but there are much better ways to do this. It’s best if you tie your processing functions (the ones that need but don’t have access to core functions) into an action hook, such as “init” or “admin_init”.

Please consult the Plugins API reference for more information: https://codex.www.ads-software.com/Plugin_API

If you’re trying to use AJAX, please read this: https://codex.www.ads-software.com/AJAX_in_Plugins

For other possibilities, or to better understand why we disallow this, read this: https://ottopress.com/2010/dont-include-wp-load-please/

If you’re trying to use it because you need to access WordPress functions outside of WordPress, we’d actually much rather you didn’t do that at all. Your plugin should be inside WordPress, only accessible to people who are logged in and authorized, if it needs that kind of access. Your plugin’s pages should be called via the dashboard like all the other settings panels, and in that way, they’ll always have access to WordPress functions.