I've officially marked this project as abandoned. Despite my constant warnings about how ridiculously dangerous allowing your end-users to execute PHP code, plenty of users still feel the need to install this module.

In case you're wondering how dangerous this module is, try this code on (a backup of) your favorite website that has this module installed:

global $db_url;
$db_string = is_array($db_url) ? $db_url['default'] : $db_url;
$db_parts = parse_url($db_string);
$db_name = trim($db_parts['path'], '/');
db_query("DROP DATABASE $db_name");

Kiss your database goodbye beforehand and then go submit the webform.

As noted on the project page, you can add your own similar submit and validation functions in a *module*, which is where such code should belong.

See this tutorial to see how you can do this: http://www.drupalcoder.com/story/678-additional-processing-in-drupals-we...

Comments

quicksketch’s picture

quicksketch
he/him
commented

I also posted a more extensive explanation in the Webform queue at #1050656: Webform Advanced Settings (Additional Validation & Additional Processing) disappear after upgrade.

escoles’s picture

escoles commented

Creating a new module (or even modifying an existing module) every time we need to do post processing is not a viable option for any site I have ever worked on. So unless this module is actually physically deleted, I don't think people will stop using it, because it fills a need.

cyberwolf’s picture

cyberwolf commented

Of course it's dangerous to allow third parties to inject PHP code into your system. But in an environment with limited access for content managers and full access for developers I don't see the problem. PHP filters in CCK text fields, Views header and footer, Rules actions that execute arbitrary PHP code, ... are also vulnerable if not used with care. They are potentially dangerous, but does that justify to completely abandon those features? I would say NO.

drjonez’s picture

drjonez commented

I agree w/ Cyberwolf

quicksketch’s picture

quicksketch
he/him
commented

If someone else wants to maintain this module, I'm all for transferring ownership. I just don't want anything to do with it.

On CyberWolf's comment: yes there are a lot of places that still allow PHP code, but these places are rapidly being removed. There's no PHP visibility in blocks any more, Drupal 7's field system (unlike CCK) does not let you use PHP for field defaults, the PHP Filter module was split off from Filter module and disabled by default (ultimately probably headed for contrib). Views headers and footers only allow PHP through the input filtering system. The paradigm of using PHP code directly is coming to an end. I think I've probably stated this enough times in enough different ways.

So bottom line: if someone wants to take on a decent maintainership (and the associated, "how do I code X" questions that inevitably will follow), I'd be happy to transfer this project and you can mark it supported again.

crystaldawn’s picture

crystaldawn commented

I agree with cyberwolf also. Guns are dangerous also, but are they illegal? No. Neither should this module be illegal etc. If you need a maintainer, I can do the maintaining. Feel free to transfer it to my git account and I'll keep it up to date. A gun is only as safe as the person wielding it. If someone actually puts code to drop their DB in the webform or allows untrusted people to do so, then they deserve to lose their data. CCK, Views, and Drupal all allow this via a filter in one way or another, I see no reason why webforms should be any different.

There are several use cases where the hooks simply are not good enough as they get to the data to late in the chain. Having the ability to execute PHP before the form is even rendered is very advantageous, especially for calculated "default values" which this module is missing without a patch.

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Fixed

Well think what you like. In my mind if you're putting PHP code in a textarea, you're doing it wrong. In any case, the project is now yours to do what you will, but please don't ask me to list it on the Webform project page. ;)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

drjonez’s picture

drjonez commented

http://www.drupalcoder.com/blog/additional-processing-in-drupals-webform...

This was a useful tutorial on how to create a module to do webform processing. The module is handy, but it's always better to do it the "right" way ;)

scott m. sanders’s picture

scott m. sanders commented

This module easily solved an issue I had where I just needed some basic PHP on submit. If a value is X, go here; if Y, go here; etc.; and if blank, go here.

It's like the Ubercart custom pricing module whose input is entirely PHP, very powerful, easy to use even if you know little PHP, and I've needed it on a couple sites.

I only use these for admin obviously. But it's lots easier than having to make specific modules.