Whole node form is saved instead of widget form, possible data loss

+1. Same happening for me, whith the slight difference that if there are no mandatory fields it saves the node but keeps the form open. When I do complete all the fields and save, the node duplicates.

I'm using 7.x-3.x-dev.

Thanks

Found these other issues that may be related to this one (or may even be the same issue):

http://drupal.org/node/1312762
http://drupal.org/node/1312286
http://drupal.org/node/1267768
http://drupal.org/node/1270306

@clanet, I don’t see any module by that name in my system. It was created on and exported from Drupal Gardens.

Here’s a “prettified” version of the output of DRUSH pm-list, showing every module we have:

All are the absolute latest recommended (for most) or .dev (for Calendar, CTools, Date, and Views) versions except that Views has not yet been updated to the 31-Oct-2011 .dev yet, since the MD5 checksum on it mismatched (see my Issue there).

Edited only to “prettify” the Drush pm-list output above.

I have a theory on why this happens, just theory yet. So ajax is returning [...] correct form_id.

Update: Theory is that hierarchical_select_ajax() is inspired by file_ajax_upload() which says "As long as the form processing is properly encapsulated in the widget element...". And in case of file_ajax_upload(), it is well encapsuled in widget element and operates on sub-form for that widget. On the other hand hierarchical_select_ajax() is operating on full node form and when saving "Create new item form", submit button processes and submits whole node, not just widget. We need to investigate little more of how file.module does it :)

I'm also seeing this issue when creating new taxonomy terms on a new node. I do not have a file upload in the form in this case. Because of this it is creating duplicates of each node. Makes the module almost unusable.

If i understand correctly we just need to paste the above somewhere? if yes then where?

Thanks
Athos

Just a quick clarification to danielson317's comment above, the hook_node_validate method does not require that the node content type be defined in the module. I'm sure :-)

But, both of these solutions have the exact same effect and use the same strategy.

I'm also having this problem on 6.x-3.7.
It seems like #14 is suggesting that there's another module interfering? I don't have the admin language module on my site. Not sure what else to suspect, but I'll comb through and start disabling things to check.

EDIT - Looks like this was the Ajax module. Disabled, drush cc all, tested the node/add with multiple terms from HS, and works fine (got one node, not several).

@morningtime #14:

Yeah, this prevents me from saving nodes completely, because of
The content on this page has either been modified by another user, or you have already submitted modifications using this form. As a result, your changes cannot be saved.
...am using the admin language module.

-EDIT- that is the culprit: just don’t use the admin language module

No, that isn’t the culprit. I’ve never used that module (see my module list above), and I have the same issue.

I just figured it out.

The error is in "live preview". There is a javascript file called common_config.js. Part of it is designed to show your selections.

If you look at line #113 (.filter(':not(.create-new-item-input):not(.create-new-item-create):not(.create-new-item-cancel)')), you'll see that it will delay the input until node save.

If you write any javascript, you'll know that the quotes will prevent this from parsing.

Just delete the single quotes and it will work or paste this in its place:

.filter(:not(.create-new-item-input):not(.create-new-item-create):not(.create-new-item-cancel))

Note: If your field is required, you'll still see required field warnings but this won't effect anything. I am working on an if statement to add to fix this.

Please let me know if this works.

Philbert

Afraid you're right. I added existing terms. It also seems that this module has now been abandoned.
Wim Leers is now working for Facebook and has not posted anything on Drupal.org since September (as far as I can tell).

Unless someone (with a lot more expertise than I) can take over this module, it will not look good for Drupal and the open source community.

I really like Drupal but when things like this and the token problems et. al. happen, it makes me worry about the future of Drupal.

I agree and also wish him the best.

I believe that Facebook pays very well and also keeps their people very busy.

At one point, he was working on a re-write of this as a 4.x release. Maybe someone would like to contact him and see if he is making any progress?

here's a custom module that solves this issue (using #10) and other HS issues (see http://drupal.org/node/1389740):

http://drupal.org/sandbox/ahwebd/1389734

I spent some time debugging this issue and comparing how HS works compared with the File module.

The actual cause is not what @mansspams or @danielson317 theorized about there needing to be a sub-form. I checked and it doesn't look like file fields use any kind of sub-form to do processing; they're just vanilla form widgets / form elements.

Instead, it's actually the fact that FAPI can't determine what button was actually clicked when processing the form, so it assumes it was the "Save" button. You can see this behavior in includes/form.inc on line 1856.

The real hint here is that the other callbacks HS uses, such as the one that triggers the "add new item" form to be rendered in the first place or the callback once a user has chosen an item, do not cause the form to validate. Only the "Create" and "Cancel" buttons cause a problem. The process callback only places those buttons in the form array when the HS widget is in "creating new term" mode, and the process callback is fired BEFORE the FAPI evaluates what button was clicked, so they're not available for form processing.

The File module gets around this by always putting the upload controls / buttons in the form, even when the form is not in a state where uploads are accepted, and then enabling or disabling access to the controls in a "pre_render" callback. That didn't work here, so I used an "after_build" callback which seems to have done the trick.

I also noticed that the D7 AJAX API seems to handle some of these issues. Perhaps if HS was ported to use the built-in AJAX callbacks from D7, this problem might not need special handling. I'm not sure; I'm not up-to-speed yet on it. For now, I've just added a "TODO" comment inside _hs_process_render_create_new_item() to this effect. Hopefully, someone with more D7 AJAX callback experience can look at this.

The patch for this is attached. Please review.

Attachment	Size
hierarchical_select-callbacks_trigger_required_field_validation-1293166-27.patch	4.89 KB

Patch #27 works well when e.g. Title field is required but gives me the "field is required" error when the HS fields are required.

#10 works for me smoothly.

#10 did it for me. Thanks!

I ran into a bug with the above patch when used inside the Panels IPE (and specifically when used with the Ctools modal dialog). The issue is that the "Cancel" button added by Ctools inside the form wizard wasn't working correctly. After some debugging I found this was due to the form API getting confused between the form's main "Cancel" button and the one added here, and not knowing which was clicked.

Since "Cancel" is a pretty common button name, I think if this patch is going to add it to a whole bunch of forms like that it would make sense to give it a different machine name other than the standard 'op' which Drupal normally uses.

I don't have time right now to roll this into the above patch directly, but the code for it looks something like below (applied on top of the patch in #27):

Hi,

I have problem applying the patch #27... I've tried it on both 7.x-3.0-alpha5 and 7.x-3.x-dev version of hierarchical_select.

Thx

Rerolled patch @ #27 against DEV and added Davids recommendations @ #35.

Attachment	Size
hierarchical_select-callbacks_trigger_required_field_validation-1293166-39.patch	5.07 KB

The patch in #39 fixes the duplicate saving of the node when a new term is saved. However, if cancel is selected instead, the whole node is saved resulting in a duplicate when the node is saved.