[drupal-devel] [feature] Do not install a PHP code format by default

Dries drupal-devel at drupal.org
Tue Jul 26 10:09:54 UTC 2005

Issue status update for 
Post a follow up: 

 Project:      Drupal
 Version:      cvs
 Component:    database system
 Category:     feature requests
 Priority:     normal
 Assigned to:  chx
 Reported by:  chx
 Updated by:   Dries
 Status:       patch

+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.


Previous comments:

Sat, 23 Jul 2005 18:03:58 +0000 : chx

Attachment: http://drupal.org/files/issues/dbinit.patch (2.04 KB)

Those users that are advanced enough that they need PHP pages, will be
able to create a custom input format.


Sat, 23 Jul 2005 18:08:42 +0000 : Bèr Kessels

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


Sat, 23 Jul 2005 18:19:31 +0000 : TDobes

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.


Sat, 23 Jul 2005 18:45:41 +0000 : nevets

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.


Sat, 23 Jul 2005 18:53:02 +0000 : adrian

I'm going to +1 this. 

php input format is deadly.


Sat, 23 Jul 2005 19:25:40 +0000 : Junyor

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


Sat, 23 Jul 2005 19:57:27 +0000 : TDobes

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).


Sat, 23 Jul 2005 19:58:47 +0000 : Junyor

As I figured.  -1.


Sat, 23 Jul 2005 20:05:25 +0000 : Gerhard Killesreiter

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


Sat, 23 Jul 2005 20:21:44 +0000 : kbahey

-1 from me. 

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

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.


Sat, 23 Jul 2005 21:03:34 +0000 : Steven

-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.


Sun, 24 Jul 2005 08:39:15 +0000 : Bèr Kessels

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.


Sun, 24 Jul 2005 09:45:34 +0000 : Bèr Kessels

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

More information about the drupal-devel mailing list