I'm using Webform icw Form Builder on D7 and after I installed the modules I created a webform without any problems.
Today I tried creating another webform.
Everything seems to be working fine, until you save the form.
I get the message that all changes have been saved, but in reality, nothing is saved.
What could be the issue?

I saw posts about a similar issue but they were all D6-issues... so I decided to create e new one.

Comments

pluginguin’s picture

Status: Active » Needs review

I found a way around my problem.
It seems as if when I start the form by adding an emailadres in the form settings section, the fields I create in the form elements section reman visible after saving.

The problem is still there though... but no longer an issue for me.

pluginguin’s picture

Status: Needs review » Active
quicksketch’s picture

Project: Webform » Form Builder
Version: 7.x-3.15 » 7.x-0.9

Could you try using the latest dev releases of both Form Builder and Webform? I've done some pretty major overhauling in both versions that should correct this problem.

pluginguin’s picture

Ehm...
two questions:
1. I don't see a dev version of webform...?
2. How do I update from a released version to a dev version without first deinstalling everything?

Regards,

Pluginguin

pluginguin’s picture

Updated to formbuilder dev version... no change in behavior of forms.

quicksketch’s picture

It seems as if when I start the form by adding an emailadres in the form settings section, the fields I create in the form elements section reman visible after saving.

So could you recap how you're getting this problem? I think I might not be understanding the problem.

To reproduce(?):
- Create a new webform node.
- Rather than adding fields to the form, click on the Webform -> Emails tab and add an e-mail configuration.
- Then what?

pluginguin’s picture

When I create a new form and start by adding elements to the form and then save the form, nothing gets saved.
When I create a new form and start by setting up things in the form settings-page first, save those and then add elements to the form. The elements remain after saving.

BoogieBug’s picture

Confirm the reproduction as procedure described in #7 and subscribe for update.

Note that I'm using version 7.x-1.0 (8 Mar)

quicksketch’s picture

Category: support » bug
Priority: Major » Normal

I couldn't reproduce this form on the "webform" content type, but found that I have the described problem when creating content types that are webform-enabled (such as a "page" content type). Are you experiencing this on the "webform" type also, or did I find a different problem?

pluginguin’s picture

No, it is on webform enabled pages. Did not mention that. Thanks Quicksketch!

jeremymcminn’s picture

Im still getting this issue on content types with webform enabled - is there a fix for it?

emptyvoid’s picture

Version: 7.x-0.9 » 7.x-1.x-dev

I'm getting the following error with with a fresh install of form builder dev and webform dev (3.x)

Notice: Undefined property: stdClass::$webform in webform_component_edit_form() (line 477 of /path/code/sites/all/modules/contrib/webform/includes/webform.components.inc).

Should I be using a different branch for D7? Maybe 4-alpha (shutters in chair).

emptyvoid’s picture

Running xdebug on the code in question and I have determined that the $node object is totally empty. This of course causes the whole function to fail horribly.

Because the function is called via ajax the end user doesn't see a response. I do get the error back via ajax and it is visible when I run firebug.

I'll trace the method and see what is causing the $node object to not be referenced correctly.

emptyvoid’s picture

The following is the trace stack of methods in each files that is called to render the form elements in the form builder. In my case none of the form element types renders the edit form to modify properties.

code/sites/all/modules/contrib/webform/includes/webform.components.inc.webform_component_edit_form:510]	
code/sites/all/modules/contrib/form_builder/modules/webform/form_builder_webform.components.inc._form_builder_webform_build_edit_form:1056]	
code/sites/all/modules/contrib/form_builder/modules/webform/form_builder_webform.components.inc._form_builder_webform_mapped_form:931]	
code/sites/all/modules/contrib/form_builder/includes/form_builder.admin.inc.form_builder_field_configure:605]	
code/includes/form.inc.call_user_func_array:795]	
code/includes/form.inc.drupal_retrieve_form:795]	
code/includes/form.inc.drupal_build_form:339]	
code/includes/form.inc.drupal_get_form:131]	
code/sites/all/modules/contrib/form_builder/includes/form_builder.admin.inc.form_builder_configure_page:93]	
code/includes/menu.inc.call_user_func_array:516]	
code/includes/menu.inc.menu_execute_active_handler:516]	
code/index.php.{main}:21]
emptyvoid’s picture

Bingo!

/modules/form_builder/modules/webform/form_builder_webform.components.inc
Line: 1056

// Build the entire _webform_edit_file() form based on the current state of
  // the component, and obtain the slice of it that we want.
  $empty_form = array();
  $empty_form_state = form_state_defaults();
  $node = (object) array('nid' => NULL);
  $form = webform_component_edit_form($empty_form, $empty_form_state, $node, $component);
  $form = drupal_array_get_nested_value($form, $form_nested_keys);

Instead of creating a empty object with no definition why not load the target parent node object?

From reviewing the descriptor for the function I can't see any reference to the parent node nor the webform instance. So how can you bind the component to the target webform or parent node?

emptyvoid’s picture

Further tracing the issue I determined that the core webform components method does not load the referenced node.

Should I post this as an issue to webform too?

/webform/includes/webform.components.inc
line: 346 (current code)

/**
 * Form to configure a webform component.
 */
function webform_component_edit_form($form, $form_state, $node, $component, $clone = FALSE) {
  drupal_set_title(t('Edit component: @name', array('@name' => $component['name'])), PASS_THROUGH);
  $form['#attached']['library'][] = array('webform', 'admin');
  $form['#tree'] = TRUE;

  // Print the correct field type specification.
  // We always need: name and description.
  $form['type'] = array(
    '#type' => 'value',
    '#value' => $component['type'],
  );

Added a validation routine to check for the existence of a valid node object, if not load it from the component reference.


/**
 * Form to configure a webform component.
 */
function webform_component_edit_form($form, $form_state, $node, $component, $clone = FALSE) {
  drupal_set_title(t('Edit component: @name', array('@name' => $component['name'])), PASS_THROUGH);
  if (is_object($node) && (count(get_object_vars($node)) > 0)) {
      $node = isset($component['nid']) ? node_load($component['nid']) : NULL;
  }
  $form['#attached']['library'][] = array('webform', 'admin');
  $form['#tree'] = TRUE;

  // Print the correct field type specification.
  // We always need: name and description.
  $form['type'] = array(
    '#type' => 'value',
    '#value' => $component['type'],
  );

BOOM now it works.

emptyvoid’s picture

Component: Miscellaneous » Webform Itegration
Status: Active » Needs review

Changing to be more accurate.

emptyvoid’s picture

Status: Needs review » Needs work

Umm, yeah the code above only enables the first component added to the webform to actually work.. Add any others and.. (pffffttttt) no workie. :(

quicksketch’s picture

@emptyvoid: I can't reproduce the problem at all. The latest versions of both Webform 3.x and 4.x seem to work with Form Builder for me.

guictx’s picture

I'm on Webforms 7.x-3.x-dev and Form Builder 7.x-1.1 and although everything seems to be working fine - I can save changes to the form - I get the error message in #12 a lot.

torotil’s picture

Issue summary: View changes
Status: Needs work » Fixed

The notice has been fixed with the commit http://cgit.drupalcode.org/form_builder/commit/?id=3d904dfd6e36862f76710... about two years ago.

Status: Fixed » Closed (fixed)

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