Why Is Turning Magic_Quotes_Gpc on Considered a Bad Practice

Slash appended to all my posts

special characters are escaped. you can remove the backslashes with http://php.net/manual/en/function.stripslashes.php

SQL-injection in PHP, how is it possible to send non-escaped quote to server?

You could have Magic Quotes on. What version of PHP are you running? Magic Quotes were deprecated in 5.3 and removed in 5.4 but they default to ON when present.

Magic Quotes will automatically escape quotes, but you really shouldn't rely on it. You should turn it off and use a different escaping method or even better look at using prepared statements.

Run get_magic_quotes_gpc() to see if you have them on. If so, turn them off by making the following changes to the php.ini file:

; Magic quotes
;

; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = Off

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = Off

; Use Sybase-style magic quotes (escape ' with '' instead of \').
magic_quotes_sybase = Off

PHP from quotation mark output

It is an old security feature from PHP called "Magic Quotes". All Quotes from GET- and POST varables are escaped with the backslash.

You can disable it by changing the value of magic_quotes_gpc to off in your servers php.ini or manually sanitize the strings using stripslashes($string).

Why does WordPress still use addslashes(), register_globals() and magic_quotes?

(Wordpress Open Tickets over Time)

Don't rely on the Wordpress codebase to do assumptions about good practice or current standards in PHP coding. I'm saying this as someone who has fiddled with wordpress development over a longer period of time.

Wordpress codebase is about 10 years old, it's full of legacy code^[1]. The program can not evolve on the code-level much because of that, so you find a lot of workarounds for problems that are already solved nowadays much better.

Just take this story: PHP had magic quotes. Wordpress developers thought it was useful. So for those hosts that did not have it configured, they added it. Ending up whith code that expects slashed input data often and at various places. The simple thing is, now they just can't change it to proper input processing and sanitization easily because of the usage of (super)globals introducing static global state nearly everywhere.

You can not easily refactor such code.

Same for the database class. It has a long history, originally based on an early version of ezSQL. At that time there was not mysql_real_escape_string and when it was introduced, the WP devs had the problem that not all installation bases support it.

So don't wonder about the coding practice you find inside the Wordpress code. You'll learn how things could have been done years ago and with more or less outdated PHP versions. It's not that long ago that Wordpress switched to PHP 5 for example.

• Backwards compatibility.
• Target a large amount of (technically more or less outdated) hosts.
• Don't break what works with defects.

This might not be your list of priorities (hopefully), projects differ here a lot. But having a legacy code-base alone is a burden regardless how project priorities are set. Wordpress is only one example.

---

^[1] see Milestones of WordPress: Early Project Timeline (ca. 2000 to 2005))

---

Related Topics