[development] Remove PHP filter by default

[Jeff Eaton]

> Content is not PHP. Code is not content. Content is text; PHP is
logic. 
> Hell, we could probably store the whole of Drupal in the database, and
add a 
> few small files to eval it.
> 
> Why is that not the case? Because we want to maintain a separation
between 
> logic and code. 

PHP is always *executable code* but it is not always *logic*. At least,
no more than HTML or XML. Many times in Drupal, it's just a shortcut to
printing the particular content that an admin wants/needs on a page. The
.inc file solution is fine for *completely custom* php driven pages, but
it doesn't help on other kinds of pages that currently have one-line php
calls to display dynamic information.

PHP snippets in key areas -- blocks, pages, and block visibility checks
-- have allowed sites to Get Things Done With Drupal without diving in
and writing custom modules for every niggling tweak. It's one of the
things that makes Drupal a lot more powerful and flexible. Until the
arrival of views.module, it was the only way for most users to get
customized listings of content. That's pretty basic.

We need to recognize that for MANY sites, this will be a crippling
downgrade.


> Besides these philosophical reasons, php input is just a real big
security 
> hole. It is not about shooting in your own foot. But about people like
bryght 
> etc handing out guns to let people shoot bryght in the foot. 
> Just for fun: try securing your site, by imagining an administrator
that you 
> do not trust. Its near impossible! that adminstrator can hardly
administer 
> anything, because you have to close so many backdoors, all related to
PHP 
> input that there is hardly anything left adminstrating.

That's understandable. I can see the case for turning PHP Filtering into
a separate module, leaving it disabled by default, and restricting it to
user 1. While the .inc file solution is technically cool, it is still a
blow to core functionality.

--Jeff