Webform 7.x-4.0-alpha6 not compatible with Drupal-7.20

I was not able to replicate this on 2 different sites running Drupal 7.20 and Webform 7.x-4.0-alpha6. I was able to add and edit fields on both new and existing webforms.

I can't confirm this problem either.

albert9000,

do you have the 'Webform Conditional' module installed?

I had the same problem after installing Webform 7.x-4.0-alpha6 (in Drupal 7.21). After uninstalling Webform Conditional all works fine.
Is because Webform supports conditions of its own now, without additional modules.

Gregory

Hi guys! This is an update to lieb's post from March 20th.

We have a stand-alone production 7.19 site here at Oregon State, using 7.x-4.0-alpha6. When we attempted to update it a few weeks ago, the update failed and took the site down with it.

We rolled the production site back, then attempted to update a clone of it in development, which also failed. So we waited a few weeks.

We updated the sample site to 7.22 just recently to test it out and the update was successful. We're having issues with Webform conditionals, though. We're able to add components without a problem, but the conditionals panel is completely non-responsive. I'm wondering if there may be a problem with a js update that happened in core, perhaps?

We'll keep poking at this on our side as we have some reasonably critical webforms that are currently being used for our Information Systems division site. If we have any further information we'll pass it on.

We're able to add components without a problem, but the conditionals panel is completely non-responsive. I'm wondering if there may be a problem with a js update that happened in core, perhaps?

What do you mean by non-responsive? Does the page load, or do some buttons not work? Do you get any errors in your JavaScript console?

The "+" button on the conditional screen indicates a hover, but when clicked, it does nothing.

I'm not seeing any errors on my js console.

The "Save conditions" button is clickable. After it's clicked, I receive the "Conditionals for Test Webform Conditionals saved." message at the top of the screen.

I've got some additional testers looking into the issue and I'm getting some more results in.

• It appears that, for single page webforms that are left unmodified, the components and submissions continue to work correctly, but conditionals can not be added, edited, or removed.
• Multipage webforms are broken, even if they do not have conditionals.

Would you like separate tickets opened for these items or do you think it might all be part of the same problem?

Let's keep both issues here for now. Although neither issue really matches the original description of the problem from the original posting. In my testing, I can't reproduce these problems running Webform 7.x-4.0-alpha6 and Drupal core 7.22, so I don't think it's a direct incompatibility. Do you have any other modules installed on your site that affect Webforms (e.g. Webform Conditional, Webform Validation, etc) or all forms in general (CAPTCHA, Honeypot, AJAX Forms, etc.)? A conflict with another module or a bug in your theme are the most likely candidates I think.

Thanks @albert9000 for the followup. So far I haven't been able to reproduce any direct problems with newer versions of Drupal. @mercergirl and @fenns: If you guys can provide steps to reproduce these problems on clean installs of Drupal and Webform, I'll be happy to take another look.

I am having a similar problem. Form Components and Form Settings (under Webform tab) have extremely slow loading times. I'm running Drupal 7.22 w/ Webform 7.x-4.0-alpha6 and Webform Validation 7.x-1.2 also enabled.

Here are some performance figures:

1.) When trying to edit a Form Component (the page did not even fully load):

Page execution time was 30272.88 ms. Memory used at: devel_boot()=1.19 MB, devel_shutdown()=483.64 MB, PHP peak=619.25 MB.

2.) When trying to edit Form Settings (the page did not even fully load):

Page execution time was 19415.6 ms. Memory used at: devel_boot()=1.19 MB, devel_shutdown()=196.78 MB, PHP peak=487.25 MB.

Can provide more details if needed. Would really like to figure out what the problem is.

Hi @flywade, you should profile your site with XHProf to find which function is taking so much time.

I'm experiencing very similar symptoms as stated by the author. I had webforms working just fine, but I"m now at Drupal 7.22 and I've noticed that I can't edit the component field. When I try to edit the field, I don't get an error but I get the following screen:
http://postimg.org/image/9xxckto8d/

I have the following modules installed:
- Webform 7.x-4.0-Alpha6
- Webform Rules 7.x-1.6
- Webform Tokens 7.x-1.2

Component Types and results:
- Date (works)
- email (NOT work)
- fieldset (works)
- file (works)
- grid (NOT work)
- hidden (works)
- markup (works)
- number (NOT work)
- page break (works)
- select options (NOT work)
- textarea (NOT work)
- textfield (NOT work)
- time (works)

Hope this perhaps helps troubleshoot the issue a bit further.

Hi @ubun2Junky: The problem in you case may be that Drupal is using all the available memory to render the page. I've noticed this is a problem particularly when there are lot of tokens on the page, and if you have both Rules and Webform Tokens installed, you probably have tens of thousands of tokens that Drupal is rendering on the page several times. You might try the patch at #1801782: Use the new token dialog to enhance UX, which puts the tokens into a separate page-load by themselves, thus freeing up memory for the rest of the page load.

@quicksketch, I figured out the problem I was having. It is the combination of Tokens and too many Fields (we have at least 500 fields w/o counting).

Temporary fixed the issue by doing the following:

1.)

Added this function below (borrowed from token_tweaks module) to a custom_webforms module I already have for customizations to various web forms:

/**
* Implements hook_preprocess_token_tree().
*/
function custom_webforms_preprocess_token_tree(&$variables) {
$variables['recursion_limit'] = min(variable_get('token_tree_recursion_limit', 2), $variables['recursion_limit']);
}

2.)

Added '#dialog' => TRUE,' to function theme_webform_token_help in webform.module:

(starting at line# 3351)

$fieldset['token_tree'] = array(
'#theme' => 'token_tree',
'#token_types' => $groups,
'#dialog' => TRUE,
);

Will add this as a patch to my Drupal site in the coming days after testing it a bit more. However, I've noticed that the 7.x-3.19 version has a much different 'theme_webform_token_help' function. Will test soon if this issue with Tokens and far too many fields appears in Webform 7.x-3.19.

@ubun2Junky My issue doesn't seem related to Drupal 7.22 at all, but as the project I'm working on grew, and we added more content and fields, the slower webform's got.

Added '#dialog' => TRUE,' to function theme_webform_token_help in webform.module:

Yep, so sounds like the problem that would be solved by #1801782: Use the new token dialog to enhance UX (which essentially does just that). I'd like to get that patch cleaned up so that it looks good in the UI, then we'll be adding that to the main project. In the 3.x branch, the number of tokens wasn't a problem because we had a finite set of them. Using the D7 token system (especially if you have Rules installed), you can really have the number of tokens get out of control.

Closing after lack of activity.

I'm still having the problem.
When I create a new webform I get
Error
The website encountered an unexpected error. Please try again later.

Then if I check the webforms' list, I find it there despite the error message.

If I try to add a new field to the brand new webform, again:
Error
The website encountered an unexpected error. Please try again later.

This time no activity, no new field.

I've tried changing several different versions of webform.
At the moment I have webform 7.x-3.19+43-dev
Webform conditional is not installed.

I will take a look to #16
Thanks for the moment and I hope to find some help here!

Installed Webform 4.0 beta 1
Implemented #16 - only 2)
It works now.
Some more testing and I will let you know if there are problems.