Remove PHP filter by default
Hi! A good read is http://www.webschuur.com/node/409 . Some points I do not care of, but: 1) As Drupal moves forward, upgrading PHP nodes is cumbersome at best. (blocks are easier to be found) 2) The security aspect. PHP filter is just too powerful. I can debate to death that it's safe now, no matter what -- the mere presence of PHP filter will make baby Rasmus cry :D However, it's true that defining a whole module is more complicated than a php node. Is it? I submitted a patch http://drupal.org/node/46857 which adds an 587 bytes module to core which lets you save a PHP into something.inc and then view it at the path pages/something. It just can't be simpler. Also, defining a block is more difficult than just using a snippet. Is it? No. The necessary module is a lot complicated this time, 690 bytes :) . Kind regards Karoly Negyesi
On Sun, 29 Jan 2006 10:15:38 +0100, John Handelaar <john@userfrenzy.com> wrote:
Karoly Negyesi wrote:
Also, defining a block is more difficult than just using a snippet. Is it? No.
Yes.
Unless there's a TTW way to add modules.
Well, not through the web, but the point here is that I would like to tighten security and not allow PHP entered in the browser. If you want to enter PHP code, you save the snippet into an inc and upload it. For a page, you do not need to even enable anything. That's the closest I can get to TTW. Regards NK
Karoly Negyesi wrote:
On Sun, 29 Jan 2006 10:15:38 +0100, John Handelaar <john@userfrenzy.com> wrote:
Karoly Negyesi wrote:
Also, defining a block is more difficult than just using a snippet. Is it? No.
Yes.
Unless there's a TTW way to add modules.
Well, not through the web, but the point here is that I would like to tighten security and not allow PHP entered in the browser.
I know. But making out that it's not harder is what I'm calling you out for :)
If you want to enter PHP code, you save the snippet into an inc and upload it. For a page, you do not need to even enable anything. That's the closest I can get to TTW.
I was going to ask how you execute a .inc without a PHP filter, but then realised you're planning some sort of user-defined include dir. jh
If you want to enter PHP code, you save the snippet into an inc and upload it. For a page, you do not need to even enable anything. That's the closest I can get to TTW.
I was going to ask how you execute a .inc without a PHP filter, but then realised you're planning some sort of user-defined include dir.
Exactly. See the patch. The modules are now around .5K. Can't be simpler :) Regards NK
Well, not through the web, but the point here is that I would like to tighten security and not allow PHP entered in the browser. If you want to enter PHP code, you save the snippet into an inc and upload it. For a page, you do not need to even enable anything. That's the closest I can
Ugh, holy crap, please no. Let me shoot myself in the foot, but don't force me to fucking load an FTP client. I thought this was a content management system - if I'm forced to a) write my content in a text editor, b) upload it through an FTP program, c) THEN manage it in the CMS, Drupal just isn't useful to me anymore. -- Morbus Iff ( i've eaten fruity pebbles with p-diddy ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 29 Jan 2006, at 4:22 PM, Morbus Iff wrote:
Ugh, holy crap, please no. Let me shoot myself in the foot, but don't force me to fucking load an FTP client. I thought this was a content management system - if I'm forced to a) write my content in a text editor, b) upload it through an FTP program, c) THEN manage it in the CMS, Drupal just isn't useful to me anymore.
I completely agree with that. I do also however agree with making the php filter a separate filter and not including/installing it by default. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Sunday 29 January 2006 10:31, Adrian Rossouw wrote:
Ugh, holy crap, please no. Let me shoot myself in the foot, but don't force me to fucking load an FTP client. I thought this was a content management system - if I'm forced to a) write my content in a text editor, b) upload it through an FTP program, c) THEN manage it in the CMS, Drupal just isn't useful to me anymore.
I completely agree with that.
+1 from here (that is, +1 for keeping PHP pages integral to core). I know how to write modules, but there are times when a PHP page gets the job done faster. Remember that a "PHP page" doesn't have to be all PHP, and it doesn't even have to access Drupal functionality. Maybe the PHP page is mostly HTML code with just a couple of print() statements to echo out system variables -- like a page that lets the user behind a firewall find out their external IP address, for instance. Also, what if the PHP page is temporary? Who wants to write a module to support some special feature that's only needed for a week, say during a server migration? As long as, by default, normal users can't create PHP pages (that is, all roles' access for this content type is turned off, so only user #1 can create or edit PHP), I don't see a problem with security. Novices aren't going to know how to create PHP code in the first place, and advanced users should operate under the principle of "your gun, your bullet, your foot, your choice." Open Source is not about protecting me from myself. If user #1 is dumb enough to grant PHP page permissions to "anonymous user" then they deserve what they get. (Should we document this on the settings page? Yes. Should we block it from happening? Maybe. I could _potentially_ even support a proposal to hardwire the PHP filter so that it is always "user #1 only" access, but I'd want to think about it first.)
I do also however agree with making the php filter a separate filter and not including/installing it by default.
This won't help security, IMO. Again, novices won't be creating PHP no matter how easy or how hard you make it. Advanced users know what they are doing and will create _good_ PHP. The intermediate user who knows how to create PHP but not how to create good PHP won't be deterred by merely having to put it into a separate file instead of typing it into the CMS -- these users know how to use FTP. IMO, all this proposal does is to make it less convenient for those who want to use PHP pages, while doing nothing to actually improve the quality of the code found on such pages. We should document known security risks and publish "best practices" as part of the Drupal handbooks, but we should not limit the flexibility of the system. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Op zondag 29 januari 2006 17:12, schreef Syscrusher:
This won't help security, IMO. Again, novices won't be creating PHP no matter how easy or how hard you make it. Advanced users know what they are doing and will create _good_ PHP. The intermediate user who knows how to create PHP but not how to create good PHP won't be deterred by merely having to put it into a separate file instead of typing it into the CMS -- these users know how to use FTP.
This is only one single case of security. 'Till now we have neglected the network of sites. The cascaded administration rights. And even the fact that people can gain PHP input rigths trough some backdoors, when they were given too many rights. But the network (aka Drupal hosting) needs this most. Let us please not forget that there are loads of other cases then that One Site with Server You Administer. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Syscrusher wrote:
IMO, all this proposal does is to make it less convenient for those who want to use PHP pages, while doing nothing to actually improve the quality of the code found on such pages. We should document known security risks and publish "best practices" as part of the Drupal handbooks, but we should not limit the flexibility of the system.
Scott
Agreed. As the site administrator and creator, I can create customized views into the data easily using PHP pages. It would take 10 times as long to write a custom module to do the same work -- and then I have the overhead of yet another module. Usually I just need to insert 3 to 10 lines of PHP code into my page to accomplish what I needed. Why write an entire module for that? ..chrisxj
Op zondag 29 januari 2006 16:31, schreef Adrian Rossouw:
I completely agree with that.
I do also however agree with making the php filter a separate filter and not including/installing it by default.
Money mouth and stuff: http://drupal.org/node/46941 Bèr
I do also however agree with making the php filter a separate filter and not including/installing it by default.
I, too, agree with this, and have stated as such on http://drupal.org/node/46941. Didn't see that one before. -- Morbus Iff ( *splutch* ... /me respawns ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Op zondag 29 januari 2006 15:22, schreef Morbus Iff:
Ugh, holy crap, please no. Let me shoot myself in the foot, but don't force me to fucking load an FTP client. I thought this was a content management system - if I'm forced to a) write my content in a text editor, b) upload it through an FTP program, c) THEN manage it in the CMS, Drupal just isn't useful to me anymore.
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. 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. Bèr
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
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.
No need to write a custom module with my pages and blocks module.
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.
With great power you can cause lots of good -- and lots of harms.
We need to recognize that for MANY sites, this will be a crippling downgrade.
No way. I can write you an upgrade (and even volunteered to do so) which will convert all blocks & php nodes to inc.
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.
The problem is in restriction. Folks, understand this: as long as PHP filter is there, all you need is one broken contrib module and your site is dust. Also, I know that many shops won't even consider Drupal for this filter because it's too risky. If you need to say "no it's not because" then you have lost the argument because if you need to reason then it's not secure enough. (And yes, input filtering is also needed but let's leave something for the spring, too :) ). Regards NK
No way. I can write you an upgrade (and even volunteered to do so) which will convert all blocks & php nodes to inc.
"Ooh, it's February. Time to update my latest financial reports. Let's see, what page was that again? Oh, right, node/34. Hey, where'd the edit tab go? Oh shit. My financial reports are gone? They were supposed to be visualized yesterday! Fuck, fuck, fuck. Quick, someone find me six hours to hunt down and discover what the hell happened to my edit tab!" ... chx responds with the inevitable ... "Ah, there's the edit tab. *click*. What's this? My code has been moved into pages/34.inc? I have no access to that! I'm just a lowly financial manager who knows how to plug numbers into a function call! I have no FTP access! These were supposed to be visualized yesterday! Fuck, fuck, fuck. Quick, someone find me six hours to hunt down and discover the IT person so he can create me an FTP account, install FTP software on my machine, teach me how to use it, and abuse me for trying to edit the PHP in Microsoft Word!"
The problem is in restriction. Folks, understand this: as long as PHP filter is there, all you need is one broken contrib module and your site is dust. Also, I know that many shops won't even consider Drupal for this filter because it's too risky. If you need to say "no it's not because" then you have lost the argument because if you need to reason
Fair enough - I'll agree with that. -- Morbus Iff ( *splutch* ... /me respawns ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Op zondag 29 januari 2006 18:18, schreef Karoly Negyesi:
The problem is in restriction. Folks, understand this: as long as PHP filter is there, all you need is one broken contrib module and your site is dust. Also, I know that many shops won't even consider Drupal for this filter because it's too risky. If you need to say "no it's not because" then you have lost the argument because if you need to reason then it's not secure enough. (And yes, input filtering is also needed but let's leave something for the spring, too :) ).
The very fact that the input filter is there, is what bothers me most. Yes, it can be restricted. It can be turned off. But you need to know about all the ways to get there. We have investigated the ways to become SU. in drupal 4.7 there are at least 7 totally different ways of rooting (for becoming SU is that, exactly) a drupal site. Nearly all are related to gaining PHP rights, then using that to change the PW of SU. So in order to be completely secure, you have to: * turn off "administer user" rigths (unreated to PHP filters) * give no-one administer permissions. resulting in not allowing half of the modules to be switched on-off, rendering flexinode (for example) unusable and more. (we really need to find some way to cascade this, so that a users can never give anyone more rights then he has) * give no-one "administer input filters" rights (very unhandy if you want ppl to control wiki syntax or so) Or, in other words: to maintain a secure network of sites, you must configure them to be hardly unusable, because you need to turn off a lot of crucial features. PHP input is the biggest contributor of all this. So, if we want Drupal to be the hosting tool, developers tool and JoeSchmoe tool, we really need to chop out a lot of functionality and stick that into modules that can be removed. Because a non-existing module is nothing to worry about. Developers should (IMO) not even consider using php input, they should deliver it with acme_inc_custom_code.module (or so).hosting providers will want to be 500% sure that no-one can run arbitrary code. Never. And Joe User wants to copy-paste. Only for the latter the PHP input is really needed. Also note (unrealted, but certainly worth thinking abuot) that Rasmus pointed uot that eval'd code performs worse and uses more memory. And that did not even get me started about the upgrade hell when you have a lot of b0rken PHP input (no longer existing API calls) making your site inaccesible. All in all, it boils down to: Drupal is fine to ship with all the PHP input stuff, but it must be able to get rid off it. Completely. We need to work on that. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
We have investigated the ways to become SU. in drupal 4.7 there are at least 7 totally different ways of rooting (for becoming SU is that, exactly) a drupal site. Nearly all are related to gaining PHP rights, then using that to change
I'm confused - how can a PHP input filter cause a user to become root, when PHP execs itself in the user space of the Apache process? -- Morbus Iff ( god less america ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On Sun, 29 Jan 2006 22:33:37 +0100, Morbus Iff <morbus@disobey.com> wrote:
We have investigated the ways to become SU. in drupal 4.7 there are at least 7 totally different ways of rooting (for becoming SU is that, exactly) a drupal site. Nearly all are related to gaining PHP rights, then using that to change
I'm confused - how can a PHP input filter cause a user to become root, when PHP execs itself in the user space of the Apache process?
Berkes means "Drupal root" obviously.
On Sunday 29 January 2006 15:33, Morbus Iff wrote:
We have investigated the ways to become SU. in drupal 4.7 there are at least 7 totally different ways of rooting (for becoming SU is that, exactly) a drupal site. Nearly all are related to gaining PHP rights, then using that to change
I'm confused - how can a PHP input filter cause a user to become root, when PHP execs itself in the user space of the Apache process?
Not Unix root, but Drupal root. <?php db_query("Update {users} set name='me', pass=md5('ownzed') where uid=1"); ?> View that page. Then log in as me/ownzed and you've just taken over UID 1. (Above code may only work on MySQL, but I'm sure a postgres version is no more difficult.) I think that's the kind of thing people are worried about, and now that I think about it so am I. I think the simplest solution is just to move the PHP filter to a contrib module. Those that want it can drop it in and enable it, while those that don't need it don't have to worry about it. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
I think the simplest solution is just to move the PHP filter to a contrib module. Those that want it can drop it in and enable it, while those that don't need it don't have to worry about it.
On 30 Jan 2006, at 12:00 AM, Larry Garfield wrote:
<?php db_query("Update {users} set name='me', pass=md5('ownzed') where uid=1"); ?>
It's not just that site either. A php page can open up all the settings.php files in sites/* and change the passwords for ANY of your sites. So a single person on large multisite install could compromise ALL the sites. FYI: i set db credentials in the virtual host entry using setenv, so that it is only defined for that session. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
On 30 Jan 2006, at 12:00 AM, Larry Garfield wrote:
<?php db_query("Update {users} set name='me', pass=md5('ownzed') where uid=1"); ?>
It's not just that site either.
A php page can open up all the settings.php files in sites/* and change the passwords for ANY of your sites.
If your site is running unmodified mod_php you are in for a few more surprises. =:) Cheers, Gerhard
I am now convinced that making the PHP filter functionality a separate module is the best way to go. This way, those who need PHP filtering can turn it on explicitly. Help or documentation or disclaimers will state the drawbacks of that. If people want it, it is their choice. So, it is off by default, and has to be turned on manually by the site admin. It has to stay in core, and not be a contrib module. The reason is that this raises its quality, and is under constant scrutiny that is often not the case with contrib. chx pages module is worth exploring two, but Ber's approach addresses the security aspect of the filter.
got a formula for that... Thats a hot one. On Mon, 2006-01-30 at 02:18 +0200, Adrian Rossouw wrote:
On 30 Jan 2006, at 12:00 AM, Larry Garfield wrote:
<?php db_query("Update {users} set name='me', pass=md5('ownzed') where uid=1"); ?>
It's not just that site either.
A php page can open up all the settings.php files in sites/* and change the passwords for ANY of your sites.
So a single person on large multisite install could compromise ALL the sites.
FYI: i set db credentials in the virtual host entry using setenv, so that it is only defined for that session.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op zondag 29 januari 2006 22:33, schreef Morbus Iff:
I'm confused - how can a PHP input filter cause a user to become root, when PHP execs itself in the user space of the Apache process? Root as in SuperUser == root. root of Drupal.
Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Bèr Kessels wrote:
Op zondag 29 januari 2006 18:18, schreef Karoly Negyesi:
The problem is in restriction. Folks, understand this: as long as PHP filter is there, all you need is one broken contrib module and your site is dust. Also, I know that many shops won't even consider Drupal for this filter because it's too risky. If you need to say "no it's not because" then you have lost the argument because if you need to reason then it's not secure enough. (And yes, input filtering is also needed but let's leave something for the spring, too :) ).
The very fact that the input filter is there, is what bothers me most. Yes, it can be restricted. It can be turned off. But you need to know about all the ways to get there.
We've had that input filter for at least since Drupal 3.0 and probably even before that. All of a sudden you are worried about it?
We have investigated the ways to become SU. in drupal 4.7 there are at least 7 totally different ways of rooting
Please don't use unrelated terms to describe this problem.
(for becoming SU is that, exactly) a drupal site. Nearly all are related to gaining PHP rights, then using that to change the PW of SU.
So what? I could probably delete Dries' account on drupal.org. I've never done it and probably won't do it.
So in order to be completely secure, you have to: * turn off "administer user" rigths (unreated to PHP filters) * give no-one administer permissions. resulting in not allowing half of the modules to be switched on-off, rendering flexinode (for example) unusable and more. (we really need to find some way to cascade this, so that a users can never give anyone more rights then he has) * give no-one "administer input filters" rights (very unhandy if you want ppl to control wiki syntax or so)
Or trust the people you give administration rights...
Or, in other words: to maintain a secure network of sites, you must configure them to be hardly unusable, because you need to turn off a lot of crucial features. PHP input is the biggest contributor of all this.
So, if we want Drupal to be the hosting tool, developers tool and JoeSchmoe tool, we really need to chop out a lot of functionality and stick that into modules that can be removed.
It really amuses me that you bring up this discussion /after/ you've started a hosting service. :p I am fine with putting this in a module, btw. But this is mainly because I believe in modularity. Today I've written three og contrib modules. Each of them provides some small functionality I need. I could have merged them into one big thing, but I think that the modular approach is better suited to Drupal and will also other people use these modules independendly.
Because a non-existing module is nothing to worry about. Developers should (IMO) not even consider using php input, they should deliver it with acme_inc_custom_code.module (or so).hosting providers will want to be 500% sure that no-one can run arbitrary code. Never.
They just need to figure out how to secure their apache setup. Not that a big deal.
And Joe User wants to copy-paste. Only for the latter the PHP input is really needed.
Well, these are the people who'd probably want to become your clients. So I think it is not the correct approach to take this away from them.
Also note (unrealted, but certainly worth thinking abuot) that Rasmus pointed uot that eval'd code performs worse and uses more memory.
He also said that unserializing stuff would eat a lot of memory...
And that did not even get me started about the upgrade hell when you have a lot of b0rken PHP input (no longer existing API calls) making your site inaccesible.
Right, that is the main reason why I think that using php input is a bad idea after all. That and the fact that browser windows aren't made for editing code.
All in all, it boils down to: Drupal is fine to ship with all the PHP input stuff, but it must be able to get rid off it. Completely. We need to work on that.
Since this fits in with my modularity mantra I support this. Cheers, Gerhard
Op zondag 29 januari 2006 22:45, schreef Gerhard Killesreiter:
It really amuses me that you bring up this discussion /after/ you've started a hosting service.
Yes. this summarises all your concerns: ists a scratch your itch thing! It has never itched me, so I never bothered. Now that it itches I come up with solutions? is that not what OSS is about? Bèr -- [ End user Drupal services and hosting | Sympal.nl ]
All in all, it boils down to: Drupal is fine to ship with all the PHP input stuff, but it must be able to get rid off it. Completely. We need to work on that.
Agreed. We don't need to throw everything over board; we just have to refactor bits and pieces so it becomes easy to turn PHP filters off. I bet that this is a critical toggle for virtually any hosting company. -- Dries Buytaert :: http://www.buytaert.net/
Content is not PHP. Code is not content. Content is text; PHP is logic.
I disagree. A Top 10 table is content. It requires code to generate that content. That content exists nowhere else but as a *result* of the code being generated. Code, logic, and content are entwined in this example. -- Morbus Iff ( *splutch* ... /me respawns ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Op zondag 29 januari 2006 10:15, schreef John Handelaar:
Unless there's a TTW way to add modules.
What is TTW? -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
I have a patch ready that makes a phpinput.module and removes all that code from core filter module. I need to reroll it against a more recent HEAD, for it has some conflicts. And since it will be post 4.7 I want to wait a bit more with it, because I will have to maintain it all along. Bèr Op zaterdag 28 januari 2006 22:57, schreef Karoly Negyesi:
Hi!
A good read is http://www.webschuur.com/node/409 . Some points I do not care of, but:
1) As Drupal moves forward, upgrading PHP nodes is cumbersome at best. (blocks are easier to be found) 2) The security aspect. PHP filter is just too powerful. I can debate to death that it's safe now, no matter what -- the mere presence of PHP filter will make baby Rasmus cry :D
However, it's true that defining a whole module is more complicated than a php node. Is it? I submitted a patch http://drupal.org/node/46857 which adds an 587 bytes module to core which lets you save a PHP into something.inc and then view it at the path pages/something. It just can't be simpler.
Also, defining a block is more difficult than just using a snippet. Is it? No. The necessary module is a lot complicated this time, 690 bytes :) .
Kind regards
Karoly Negyesi
-- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Op zaterdag 28 januari 2006 22:57, schreef Karoly Negyesi:
Also, defining a block is more difficult than just using a snippet. Is it? No. The necessary module is a lot complicated this time, 690 bytes :) .
FWIW, I have added two modules to sympal (FKA drupalCOM): custom_blocks.module custom_views.module That is IMO the place where people can copy-paste any custom blocks code. As well as that views.module is flexible enough to allow for for agile creation of blocks. (for testing etc) Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
participants (13)
-
Adrian Rossouw -
Bèr Kessels -
Chris Johnson -
Darrel O'Pry -
Dries Buytaert -
Gerhard Killesreiter -
Jeff Eaton -
John Handelaar -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Morbus Iff -
Syscrusher