Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: Bèr Kessels Status: patch +1 for the idea. Untested, though. Chx, do yuo not need to default the node-settings? Bèr Kessels 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.

Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: nevets Status: patch 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. nevets 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.

Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: Junyor Status: patch 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 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.

Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: Junyor Status: patch As I figured. -1. Junyor 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).

Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: kbahey Status: patch -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. kbahey 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.

Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: Bèr Kessels Status: patch 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. Bèr Kessels 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 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. ------------------------------------------------------------------------ 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.

Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 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. Dries 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 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. ------------------------------------------------------------------------ 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

Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: Goba Status: patch 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. Goba 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 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. ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ Tue, 26 Jul 2005 10:09:50 +0000 : Dries +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. ------------------------------------------------------------------------ Wed, 27 Jul 2005 09:17:44 +0000 : kbahey 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?

Issue status update for http://drupal.org/node/27330 Post a follow up: http://drupal.org/project/comments/add/27330 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: drumm Status: patch (code needs review) Looks like the PHP code format is in HEAD and disabled by default. I think this is okay and this patch is not needed. drumm 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 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. ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ Tue, 26 Jul 2005 10:09:50 +0000 : Dries +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. ------------------------------------------------------------------------ Wed, 27 Jul 2005 09:17:44 +0000 : kbahey 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? ------------------------------------------------------------------------ Wed, 27 Jul 2005 09:29:39 +0000 : Goba 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. ------------------------------------------------------------------------ Wed, 27 Jul 2005 09:55:06 +0000 : kbahey 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?