Enforced magic quotes?

[David Anderson]

Hi,

Today, after a lot of debugging, I came across a fact that after a
decade tinkering with WordPress had somehow escaped me... apparently,
WordPress enforces behaviour as if PHP's (deprecated, now removed)
magic_quotes_gpc was always on. (Not 'always off', as most (all?) other
frameworks... which is what I'd merrily assumed for years).

Codex (http://codex.wordpress.org/Function_Reference/stripslashes_deep)
says that this is " WordPress does this because too much core and plugin
code has come to rely on the quotes being there".

That's rather unfortunate (that WP took the opposite approach to PHP -
PHP decided the long-term solution was "always, permanently off"; WP
decided "always on") - are we stuck with this forever, or is there a
plan to reverse it at some point? Are sane plugin authors doomed (as it
says on http://www.php.net/manual/en/security.magicquotes.whynot.php),
to be permanently having the maintenance/performance burden of WP always
adding unwanted slashes, and then we remove them?

David

[John Blackbourn]

Hi,
Today, after a lot of debugging, I came across a fact that after a decade
tinkering with WordPress had somehow escaped me...

Ouch.

That's rather unfortunate (that WP took the opposite approach to PHP - PHP
decided the long-term solution was "always, permanently off"; WP decided
"always on") - are we stuck with this forever, or is there a plan to reverse
it at some point? Are sane plugin authors doomed (as it says on
http://www.php.net/manual/en/security.magicquotes.whynot.php), to be
permanently having the maintenance/performance burden of WP always adding
unwanted slashes, and then we remove them?

This has been discussed at excruciating length for the past few years.
Welcome to the rabbit hole. Enjoy your stay!

http://core.trac.wordpress.org/ticket/22325
http://core.trac.wordpress.org/ticket/18322

Additionally, WordPress 3.6 will be introducing some new wrapper
functions for dealing with slashes, and various API functions are
being changed to accept unslashed data instead of slashed. See
http://make.wordpress.org/core/2013/02/17/slashing-insanity/ and
http://core.trac.wordpress.org/ticket/21767 for details.

John

[Dion Hulse (dd32)]

Hi,
Today, after a lot of debugging, I came across a fact that after a decade
tinkering with WordPress had somehow escaped me... apparently, WordPress
enforces behaviour as if PHP's (deprecated, now removed) magic_quotes_gpc
was always on. (Not 'always off', as most (all?) other frameworks... which
is what I'd merrily assumed for years).
...snip..

That's rather unfortunate (that WP took the opposite approach to PHP - PHP

decided the long-term solution was "always, permanently off"; WP decided
"always on") - are we stuck with this forever, or is there a plan to
reverse it at some point?

For a bit of history:
When PHP first introduced the magic_quotes feature, it was permanently on,
Then there was an option to disable it (but recommended NOT to disable
magic quotes). WordPress based on the PHP developers guidelines at the
time, decided to ease the pain for Plugin & Theme developers who possibly
weren't PHP experts, and were not aware of edge case installations, chose
to standardise the PHP Environment to a single "sane" environment,
something developers could rely upon.
However, years later, the core PHP Developers realised their mistake, and
that defaulting to off was a much more sane approach, and changed it.. Of
course, that has left WordPress in a difficult spot, as Plugins and Themes
RELY upon WordPress to be quoting things, just turning it off causes all
sorts of breakages (slashes in posts, SQL vulnerabilities in old plugins,
and new plugins even, etc) and just isn't possible.
As mentioned in a previous reply, the solution going forward is a new API
and helper functions, it's a issue that's being actively worked upon in
other words.

You probably don't realise it, but, magic_quotes are not the only thing
that WordPress does for developers, just off the top of my head we also
standardise Error reporting levels, register_globals (We force it off by
undoing it's work), various $_SERVER paths and uri's (so many different PHP
configs and server environments cause those indexes to be unset, set
incorrectly, or unreliable), and I'm sure there's even more things I'm
missing..

tl;dr: WordPress isn't totally insane :)