Simpler pages and blocks

I'm against this patch - the workflow is *anything* but simple. Don't force me to load an FTP client. I thought Drupal was a content management system - if I'm forced to a) write my content in a text editor (and PHP code that tweaks existing data or otherwise generates data *is* content), b) upload it through an FTP program, c) THEN manage it in the CMS, Drupal just isn't useful to me anymore. That's too many steps, too many additional resources, and too much headache. Updates will be uber annoying (open up FTP, find the file, grab the file, modify the file, reupload the file), and so will bugfixing (the whole process over and over again).

Hey, I'm all for security. But this is security that is becoming a pain in the ass - it's as bad an idea as "whee, let's move a bunch of crap into non-public directories!". I, as an administrator, should be able to decide who I trust with uploading PHP, and if that means Just Me, or All of This User Role, then so be it. Don't force me, or my administrators (who may not have an FTP client or, more importantly, whom I DON'T WANT TO HAVE FTP ACCESS ON MY DAMN BOX), to go through this insanity.

I agree with Morbus. While I don't like php snippets particulary and agree with Ber that you should rather write a module, people who have chosen to ignore my opinion should be free to use this feature without too much interference.

And I agree with killes
if you really want to commit this to core then there should be a front end in the admin area which makes it easy to upload and edit such *.inc files

just one new concern
I know that this system makes it easy to write small code snippets, but i think it brings more inconsistency in drupal
because with this we have two different ways to write and provide some kind of modules....

I much prefer the solution here: http://drupal.org/node/46941

means you could remove the php filter module from the modules directory, and only allow certain sites to use it.

chx: bullshit. There is no semantic difference in content between:

 <p>this</p>
 <p>is</p>
 <p>a</p>
 <p>series</p>

and

<?php
 $terms = array('this', 'is', 'a', 'series');
 foreach($terms as $term) {
   print "<p>$term</p>";
 }
?>

They both produce the same content in differing ways, just using different languages and logic. Obviously, it's a really really really simple example, but I balk at the suggestions that a) I should use an FTP program each and every time I change a term or the surrounding data, or b) "well, that's a pisspoor example, and you shouldn't use PHP for that anyways", or c) "well, you should write a module for those four lines of code. Oh, and if you REALLY want to remove the FTP part, hook it into taxonomy, and ooh, ooh, hook_settings, and generally take 3 minutes of a regular node/PHP filter and turn it into an hour of work".

I can't stand this patch or the thinking behind it. Absolute idiocy.

"All points are moot" - ahahah. Man, that's some funny shit. "I am chx, the security genius. I will make your life more difficult, and you must accept it, because I am the security genius. Don't even bother trying to argue: I am the security genius. You are not. alt.morbus.die.die.die."

Ok, so Drupal provides a functionality that allows people to extend it's functionality with small snippets of PHP code inserted in a node or block. This catches on and drupal.org now includes snippets for both nodes and blocks. While there is alot to be said for writing a module it can be over kill for a lot of the tasks the snippets provide.

From the start though it has been know that PHP can lead to security problems and that there is potential risk to using them. Now some seem to be saying that the risk is too high and people must do it our way or tough luck, a really good approach in my opion to alienating people who have embraced drupal.

Personally I have no problem with a module that requires I turn something on (enable a module, set a global setting) but this talk of disallowing PHP in nodes and blocks is off putting. In doing so you would be either disallowing or making harder a feature that makes it easier for people to customize drupal to their liking. And that is one of Drupal's strenghts, the flexiablity to allow users of Drupal to build the web site they what, not the one some CMS constrains them to.

moving

-1.

We certainly can't have page, pages, blocks, and block in core.

I like this approach because it is more convenient to do some editing in a real editor rather than a textarea. But Morbus's point in #11 is valid (except for the ranting); editing via textarea is useful.

I think the best way to move this forward is
- Make it a single module in contrib, with 'php' somewhere in the module title
- Find someone who wants to code the textarea end
- Put some permissions on the textarea end so it can be locked out when necessary
- Bonus points: make the node type CCKable

moving

D7 is in alpha fase already.

I agree with drumm on a contrib module and making this a won't fix.

So, should this go to won't fix?