Do not install a PHP code format by default

+1 for the idea. Untested, though.
Chx, do yuo not need to default the node-settings?

This is one of Drupal's best features. Why should we hide it and/or make things more difficult for so-called "advanced users?" I feel that the ability to create PHP pages and PHP blocks should be part of the out-of-box experience. (available without any "extra steps" on a fresh install) A first-time user looking for this ability might get discouraged and give up before finding the "input formats" screen and realizing that they must create a new item.

Also, this might be a problem resulting in support requests if people get confused and combine other filters with the PHP parser filter.

Interesting, I thought it was general disabled by default (but installed). I think it should be part of the default install because it very useful in creating custom blocks and nodes.

I'm going to +1 this.

php input format is deadly.

Just because something is powerful, doesn't mean it should be hidden away. How can you make custom PHP blocks without this input format?

Junyor: No you can't. Which is why I'm -1'ing this.

I think the opposing argument is that people who really need to make custom PHP blocks and/or nodes could create the input format themselves. However, I think this is an insult to the intelligence of someone who knows PHP well but may not necessarily be familiar with Drupal (yet).

As I figured. -1.

I'd prefer the filter to be defined but disabled.

-1 from me.

PHP input is needed in many blocks and pages I use, for example adsense module.

There has to be a better way of handling the security side effects of PHP input, for example, making sure that it really is restricted for anon users and access control really works the way it should.

-1: I imagine this will lead to improper set ups, where people place the filter in the HTML format instead of creating a new format with the filter in it. When told they need to enable PHP support on their site, people will look for a checkbox that says "PHP Filter" and check it. And it will not cause any visible problems, because PHP only kicks in between <?php ?> tags.

Steven, you are right. As are the others that say 'it is too hard to turn it on'. But as Steven also said " the filter admin is pretty bad, but the problem is that it is quite complicated;.. none of the mockups made before had all the necessary functionality in them"
I agree with this. Steven is right when he points out the filter UI is bad. I would like to go as far to say it is horrible. But I too have no clue as how to fix it. So this is not a rant on that UI; Just to point out that the part that is broken is the UI.

Thus, I think we should keep security tight and switch off PHP. And then, as next step, fix he system and UI. Let s not leave security "holes" open, because we cannot get our interfaces right.

Allright. Talk is silver, code is gold, and mockups ar egold-withsilver :) Please comment on http://drupal.org/node/27364

+1 (I suggested to disable the php code format) Better safe than sorry, whether you like it or not. Many sites got hacked because we messed up. We can't allow that to happen again. Security is more important than ease of use. Given the PHP code filter is for power users only, we'll be good.

The issue is not the presence of PHP as a valid input format.

The issue is that this is exposed in situations that it should not be exposed, or to users who

It is not ease of use, but features. Many features will be broken by the lack of this filter. Examples are Google Adsense, Banner module, all the PHP code snippets, ...etc.

If this is temporary, while we secure it, I have no problem with it.

a better approach is to include the filter by default, but not make it enabled by default. In this case, the site admin makes a concious decision to enable it.

In all cases, can we document why we did this, and how to enable it (at one's own risk), so we do not get swamped with support requests with 4.7?

Kbahey, I don't know what you mean by "until we secure it". PHP has no security model, if you allow people to run arbitrary PHP code typed in by themselfs, they can do anything unsecure. Nothing will prevent them from this. Creating another layer of security (ie. inventing another scripting language on top of PHP) might help, but I doubt anyone is going to do it.

That was not what I meant.

What I meant was to prevent the PHP filter programmatically from being exposed where it should not (e.g. nodes, comments), while allowing it where it should (e.g. blocks).

The problem so far is that it is exposed in places (or for users) where it should not be.

Exploits are caused by bugs that humans do while they program. That is a fact of life, and will not change as long as humans write code.

Whatever these bugs are caused by Drupal (not PHP), is within our control, and we should fix them.

I realize this will not work in all cases, but in most, that should work.

Clearer now?

Looks like the PHP code format is in HEAD and disabled by default. I think this is okay and this patch is not needed.