Add abilitaty for admins to bypass the Form Builder interface to access advanced Webform component settings

It also loks like it's stopping the Salesforce list picker showing if you use this with the Salesforce Webform Data Integration module. So it would be great if you could switch between the form builder and default webform.

Besides, form builder occasionally caused some problems, either not able to show the latest fields entered (I am not sure why), or cannot integrate with other modules (e.g. Salesforce list picker mentioned above, the "Select or Others" module...).

Also, there is no "clone" feature for individual field as in the original interface. Sometimes users need to clone a field (or fieldset), especially for complicated selection option list.

So it would be nice if there is a checkbox above the webform design form to turn the Form Builder UI on and off.

The complication here is that Form Builder operates on a cached version of the form, which only gets written to Webform's storage when you click the Save button.

Currently if you were to expose the old UI, it would be easy for the Form Builder cache and the Webform component storage to get out of sync: new Form Builder components would not appear on the Webform UI until you've clicked Save, and new/changed Webform components would be liable to get clobbered by the Form Builder save process.

Or could it be solved with a save operation before switching UIs? I think that's the easiest option, and don't see any problems with that. Perhaps it should be made clear, that switching the UI saves the node.

What about resetting the form_builder_cache every time the form_builder_webform_components_page() is loaded? I think originally it was only intended to handle the AJAX requests during editing the components. Having the form_builder_cache live longer than that is rather strange behavior in the first place.

+1 for this feature request. I would desperately need this right now.

Being able to switch to the normal view instead of Form Builder would be very helpful. There are apparently too many things that Form Builder currently does not take account of.

From my own uses, it fails for:

• Select or Other
• Pre-built select option lists
• Webform Add More
• Webform Layout

Or, it'd be even better if the Webform UI for Form Builder could some how dynamically ascertain and implement other added functionality like normal webform does on its own. If select or other or any of these other modules can add themselves to show up in webform's options, I think Form Builder should notice that and grab the same options being fed into webform.

But great module otherwise. Has lots of potential!

+1

+2

Any update on this ?

Is there any way to disable form builder UI for custom nodes ? forms ?

Many thanks

Gabriel

Just ran into this limitation.

I'm using webform_views_select to dynamically load options into a select list. I had to disable form_builder in order to add & configure this field - which is not so bad although a bit convoluted.

My issue is that when I re-enable form_builder, the select field becomes invisible. If I edit the form and save, my custom select is forgotten and destroyed.

Hm... not fun.

Would be nice if form_builder was able to at least save/preserve the fields it cannot create/edit.

Related issue: https://www.drupal.org/node/1532264

Subscribe. Anyone has started implementing a solution for this feature? Please share your ideas. Thanks

I've posted a patch on #2034543: Form cache delete on node save should remove all cache entries for that form that reduces the form_builder_cache side-effects a lot. If this patch is accepted there is an easy solution to this feature request:

1. Change the current menu_callback() to optionally show the original webform interface (ie. if $_GET['form_builder'] == 'off'
2. Display the link somewhere on the form_builder page.

+3

Yes,I'd like to see more features could be added to form builder. For example ,May the form builder module can clone the fieldset component and his child componets,see this issues :Add ability to clone entire fieldsets in Form builder

Here is a patch that makes the original webform interface accessible in additon to the form_builder interface.

We still need to deal with #2034543: Form cache delete on node save should remove all cache entries for that form to really make both interfaces coexist. But I guess this patch may help some of you.

Been using the patch from #17 for a while now, could use some maintainer review.

EDIT: oops, didn't realize torotil is a maintainer.. So uhm.. what's stopping this from being committed?

Patch from #17 does provide access to the original webform components interface, but saving a new webform then takes the node author to that original interface, instead of to the Form Builder interface. You need to click the Form Builder tab added by the patch to get to the drag-and-drop interface.

I believe this is because of the following redirect in Webform's webform.module (around line 1871):

function webform_form_submit($form, &$form_state) {
  drupal_set_message(t('The new webform %title has been created. Add new fields to your webform with the form below.', array('%title' => $form_state['values']['title'])));
  $form_state['redirect'] = 'node/' . $form_state['nid'] . '/webform/components';
}

@rv0: That's an easy one: I'm maintainer now.

@brianbrarian: Good point. Seems like we need to implement our own #form_submit-handler to override the redirect.

I've added the form_submit-handler and committed the patch to 7.x-1.x. Thanks for the review. It's always good to have another pair of eyes looking over changes - even though I'm maintainer.

The new dev of 7.x-1.x does appear to fix this issue. Saving a new webform goes directly to the Form Builder interface, with the regular webform components interface available by clicking the tab.

Updating to the new dev wiped out the Webform Default Fields that I had configured for one webform-enabled content type, though, so I had to rebuild those default fields. Not really a problem for me, but anyone who's using Webform Default Fields ought to be prepared for that to happen.