Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.When going to node/{nid}/webform/emails, the $form structure contained an nid key in the 7-x.3-.x branch. All other forms (components, conditionals) still contain that.
This is handy when having todo form alters, although one could argue we should use the #node property as that's also available. However the 'nid' key comes in handy for the https://drupal.org/project/entitycache_flush and will make sure it works for both branches of webform without having to change the code.
Patch upcoming.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 2074909-1.patch | 1.92 KB | swentel |
Comments
Comment #1
swentel CreditAttribution: swentel commentedPatch.
Also fixes some tabs/spaces in the same file.
Comment #2
quicksketchI'd prefer to get rid of 'nid' rather than add it. Unfortunately 3.x and 4.x are not API compatible in many ways, we shouldn't attempt to make them compatible in this one instance. However it should be documentated in the change list: https://drupal.org/node/1609324.
Comment #3
quicksketchAlso, the 4.x version of the module should only be updating conditionals/emails/components via node_save() at this point. Any use of an add-on module to make it compatible with Entity Cache shouldn't be needed in the first place. If it is necessary, I'd like to get that fixed directly in the Webform module.
Comment #4
swentel CreditAttribution: swentel commentedre#3, using node_save() is great. Should I create a patch to remove every nid key then in the other forms ?
Comment #5
quicksketchThat would be great by me. I'd love to get consistent. However, please keep the $form['details']['nid'] in the main webform_client_form() form, that's one place where I'd like it to stay for the sake of flexibility. People do all kinds of crazy things with the main form and I'd like to keep the NID as part of POST for whatever reason people wish to use it.
Comment #6
deanflory CreditAttribution: deanflory commentedAnything on this since it's causing an issue with the entitycache_flusher module?
#2045967: Error on webform email settings page when used with Webform 4.0-alpha9
Webform 7.x-4.0-rc3
Entity cache flusher 7.x-1.1+6-dev
Comment #7
DanChadwick CreditAttribution: DanChadwick commentedAs I understand #5, the proposal to is remove nid from all the forms, relying on details/nid instead. How would that help Entity cache flusher?
Comment #8
deanflory CreditAttribution: deanflory commentedAs the linked issue pointed out in #6, this:
Comment #9
DanChadwick CreditAttribution: DanChadwick commented@deanflory -- I'm not trying to be dense, but I don't understand your reference. The change suggested by quicksketch in #5 would REMOVE the nid from all the forms, relying consistently on details/nid instead This would make entitycache_flush have to rely on that consistently which, if anything, would require more (but consistent) changes in entitycache_flush.
It would seem that entitycache_flush needs to change as per the issue you reference.
Comment #10
DanChadwick CreditAttribution: DanChadwick commentedAt this point, there may be form_alters that rely on what 7.x-4.0 shipped with. I think it is too late to move where the nid is stored. The related issue can resolve the error in entitycache_flush, which for 7.x-4.x I think does not need any special processing for the email form.
Please re-open if my understanding of this issue is not correct.