Webform Advanced Settings (Additional Validation & Additional Processing) disappear after upgrade

Hi Mike, I watched your descriptive video and I don't think my answer is really going to change too much here. I'll try to answer each part of your question in response to your video.

1. Where did the PHP fields go?

The PHP fields are no longer in the 3.x version of the module. It's a feature reduction from the 2.x version of the module. The *only* way to get these fields back in the same location as before is to install the unsupported Webform PHP module.

2. What happened to my existing PHP code?

Your existing PHP code is actually still there, saved in the "webform" database table in the additional_processing and additional_validate columns. However this code is not executed in the 3.x version of the module unless Webform PHP is installed.

3. Why were the additional validation and submission fields removed?

They were removed because of the wildly dangerous potential of executing PHP code in a textarea. See my explanation at #1043088: This project is abandoned, please stop using it.

4. Well if the fields are removed, how am I supposed to execute PHP code when the form is submitted?

You should do any custom coding in a module that will execute the PHP code from there. All code should always belong in a module, as it is easier to debug and much less likely to be exploited (intentionally or accidentally) by an end-user of your site.

An example for your particular use-case would look like the following:

- Make a new directory in sites/all/modules called "webform_extra".
- Make a new text file in sites/all/modules/webform_extra called webform_extra.info. Put this inside of it:

name = Webform Extra
description = Customizations for the Webform module.
core = 6.x
package = Webform
dependencies[] = webform

- Make a new text file in sites/all/modules/webform_extra called webform_extra.module. Put this inside of it:

<?php
/**
 * Implementation of hook_form_alter().
 */
function webform_extra_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'webform_client_form_44') {
    // Simply add the additional validate handler.
    $form['#validate'][] = 'webform_extra_validate_44';

    // Add the submit handler after the existing Webform submit handler,
    // but before the second Webform handler. Pop off the first one and add
    // ours second.
    $first = array_shift($form['#submit']);
    array_unshift($form['#submit'], $first, 'webform_extra_submit_44');
  }
}

/**
 * Validation handler for Webform ID #44.
 */
function webform_extra_validate_44($form, $form_state) {
  global $user;
  if (!isset($user->roles[4])) {
    form_set_error('', t('To delete a truck or load, the trunk/load must belong to your userid and you must be a permanent Member or on a trial basis. Please see the Home page.'));
  }
}

/**
 * Submit handler for Webform ID #44.
 */
function webform_extra_submit_44($form, $form_state) {
  global $user;
  include 'sites/default/files/posttrunkproc.php';
  posttrunkproc("", $user->name, $form_state);
}

- Turn on the new Webform Extra module you've just created.

5. Wow, that is so much extra work than just typing code into a textarea! Can't you just put those fields back in the interface so that I don't have to write a custom module like this?

At some point safety takes precedence over convenience. The removal of the PHP code fields from Webform is part of a broader trend in the Drupal community to make Drupal a safer and mature system. No respectable piece of desktop software would ever give you a textfield for "Enter C++ code here", the same applies to Web software. The ability to execute PHP code in a textfield has been removed from the Drupal 7 version of CCK for example. The "PHP Input Filter" was separated from Filter module and disabled by default in Drupal 6. There's a good chance it will be removed entirely and moved to contrib in D8. The removal of all PHP textareas is an eventuality that the Drupal community will need to adjust to, most likely by education on how to write simple custom modules, like the one I've described here.

I thank you for taking the time to document a potential new module, but I am disappointed that these fields have been removed.

Perhaps there is no place for PHP code in a web software. But respectfully, Drupal is also a web development software, and thus I feel PHP is acceptable if access can be restricted. Certainly you wouldn't allow end users to enter PHP. But isn't that why we have a permissions system? If someone is a trusted user and has the correct permissions, what is the risk?

A good example is the block system's visibility settings. I see that Drupal 7 has created a more robust GUI for filtering blocks. Very good. But I can still imagine a number of reasons why PHP evaluation would be useful, and thankfully is still allowed.

Speaking as a designer, such fields are a stepping stone toward descending into module development, hooks, field API, etc. I'm not sure how many of my ilk would attempt Drupal if knowledge of the aforementioned was needed for every snipped of PHP.

Anyway, I know this isn't a debate. What's done is done. I appreciate your work. Thanks for Webform!

It's still possible to have these fields through another module, but surely you can understand my hesitation around trying to offer any sort of support for such a dangerous and error-prone feature. You can still use Webform PHP (it works fine), it's just that such implementation is completely unsupported for all the reasons I have outlined.

is there really any risk for my site the 2.x way or using webform php?

I'd say the risks are greater sticking with Webform 2.x than using Webform PHP. There is no "inherent" security risk caused by using Webform PHP, it's just not a "best-practice" way to build out a site and is likely to expose your site to security problems if it were misconfigured. Webform 2.x is not receiving further updates so if new problems are found in the future, they likely will not be addressed.

I'm pretty sure I've already answered the question several times over.

There is no "inherent" security risk caused by using Webform PHP, it's just not a "best-practice" way to build out a site and is likely to expose your site to security problems if it were misconfigured.

MWease, Inconvenient as this feature reduction is, you have to admit the module is actually cleaner now. Those fields always seemed a little "dangerous and error-prone" to me. I can only image the tital wave of misuse and support requests they prompted. I suspect that is the driving force behind the decision to remove them.

Regarding PHP fields... I can't imagine Drupal without them, but I think I will never have to. If that day comes you and I can form an armed rebellion. :) To me, this move has more to do with the sustainability of the Webform project... which I am thankful for.

Why get rid of php fields? That's why Drupal has access control. A user with "administer content" access could destroy a site's content just as easily.

mwease, I hear you about permissions. Obviously, that was my point earlier. I don't think it is about that as much as it is about preventing user error.

I can't speak for quicksketch, but I interpret his response to mean that he has removed your favorite couch from the module because he is tired of people getting hurt on it and blaming him. While you and I may have used them with success, you have to admit those fields required a lot of explanation. I imagine it was pretty easy for well intentioned admins to screw up. So I think he is saying you are free to use it at your own risk with the new module, but he doesn't want to be bothered every time a new person tries to recline the couch and puts a hole in the floor. Anyway, that is my take.

I didn't mean to code is cleaner. No idea about that actually. I meant cleaner as in more easy to intuit. No more, 'what the hell do these do?' fields.

Thanks for providing the code examples quicksketch. Also, thanks for removing these fields, now we don't have to create a form alters to remove them :)

I have to say I find the arguments in favour of removing this functionality to be very weak. Content, blocks, and various other modules all allow the PHP input filter to perform PHP processing. For some reason you find the filter/permissions functionality that's been built into Drupal since probably forever (I started with Drupal 4) to no longer suit your needs and you call it insecure. If that is true you've made Drupal no more secure since this functionality continues to exist everywhere else. Claiming anyone can use the unsupported unmaintained Webform PHP module is a cop out. Why not at the very least put the functionality back in and make it a setting in settings.php where I imagine you could expect anyone placing a setting there to know what they are doing since you appear to be afraid of noobs hammering their own toes. Anyways, I feel the need to call bullshit on this change and the arguments in favour of it.

I was a bit hasty on that last comment... I didn't realize the Webform PHP module works in conjunction with Webform, That's at least a good alternative solution similar to my suggestion of a settings.php config entry. I still don't see the point in removing this functionality, since anyone with the PHP input permission can still wreak havoc with the site via the description confirmation page description box which is where I was about to move the post processing funcitonality. But hey, it is your module after all. I probably wouldn't care so much about this change if there had been a transition period... say Webform 3 indicating that it would be removed and then a year later Webform 4 having it removed. But I'm on a deadline right now, going back and changing all our webforms is not something I can do right away.

Cheers,
Rob.

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.

Changed title for better googleability.

I probably wouldn't care so much about this change if there had been a transition period... say Webform 3 indicating that it would be removed and then a year later Webform 4 having it removed.

Webform 3 was under development for over two years and went through dozens of pre-releases publicly available all with the PHP functionality removed. This wasn't exactly an "all at once" decision.

In any case, I won't be adding a PHP textarea back into Webform with any amount of lobbying. You can install Webform PHP if you want this functionality.

For what it's worth, I had never created a completely new module until adding webform_extra today. I added the validation and processing I needed for one form in this manner, and it took me about 20 minutes. The example outlined in #1 is pretty simple. Thanks for creating and maintaining this module!

Hi quicksketch

I am trying to set up such custom module for 7.x but without any success.

I have a web form with send copy to user Checkbox, if user do not tick checkbox , no email copy will be sent to sent to user. I am trying to achieve this functionality. Please give some pointer.

Thanks