milky: The 'magic_quotes' in my opinion is the most stupid thing the Zend people added to PHP. Because it is a config setting, it is set differently on many servers, thus making it hard to get a PHP script run equal on many systems. The magic_quotes add backslashes to GET, POST and COOKIE variables to give novices a chance to write 'safe' PHP database usage code without having to learn programming...(!)
Yes, I'd really like to say the magic_quotes are for stupids.

Even if the magic_quotes are now off by default in recent PHP versions, they still are a problem, because many providers still have poorly written code (not managing to use addslashes() or similar before writing to database) and thus enforce people also to live with the antiquatic_quotes (there is the .htaccess workaround, ok, but it is not safe or always possible to use it).

This problem for example lead to constructs like "eventually_add_slashes()" functions in many projects (*PhpNuke has such one for example). This slows down everything and makes code unreadable - in ewiki such an eventually_add_slashes() function had to be deployed around 100 times to work around the antique_quotes 'feature'. So my approach was the "fragments/strip_wonderful_slashes.php" include, which redecodes any garbaged $_REQUEST variable.
This is a good thing, because ewiki's database code cares about adding backslashes before sending commands to the database - and in fact PHP's magic_quotes sense of adding quotes wasn't even capable of doing it correctly, because different databases (ADODB) use different escape chars!

For an bad example of problems with magic_quotes just see the sourceforge.net site - their software is also not aware enough of their own PHP interpreter having the trouble_quotes enabled, so you\\\\\'ll often see backslashes appear before quotes, often you\\\\\\\\\\'ll see a long line of \\\\\\\\\\\\\\\\\\\\\ backslashes, where you wouldn\\\\\\\\\\\'t expect (they also have problems with \newlines, but that\\\'s another story ;)

bottom corner