First off, 3.x version is awesome, good work! However it has made my life a bit more difficult, now that the php validation / submit code is to be done via FAPI in a custom module. That's a great change, but the form ids contain the node id. This is fine when you just have one site, but we have multiple dev sandboxes, an internal QA site, a staging site and a live site. It's very difficult to keep the node ids in sync, so we end up having multiple hook_form_alters just so we can test the custom submit processing function on the different servers. In addition we've no way of knowing until new webforms are pushed live what node id they will get - which means we end up modifying code during the release process :(

It'd be great if it were possible to set a unique 'webform id' which would be used in the FAPI form_id if present, otherwise fall back to using the nid. Then we could have one submit function which could be used across all sandboxes, and wouldn't have to modify code during deployment.

Thoughts?

Cheers,
Stella

CommentFileSizeAuthor
#26 webform_uuid.patch6.2 KBtimaholt
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

I see where you're coming from with this request, but I'm not sure it will be added. The same problem exists with theming e-mails, headers, or forms, since all of these match patterns like webform-form-[nid].tpl.php. Though on the other hand most forms don't have any theming (or custom PHP code). I'd probably suggest a simple approach of creating an unpublished webform node on your live site, add your custom module that uses that unique NID, then publish the node when you want to deploy it.

stella’s picture

It's not theming I'm concerned about - I have a general theme for all webforms. It's the custom hooks for validating and submitting the forms. For each webform on the site, I have to do some extra processing to submit the form data with a 3rd party system. The code is slightly different for each webform. So I've put the custom hook validate and submit functions in a custom module.

All updates to the live site are currently done using hook_updates() (though switching to features soon), this includes the creation of webforms. So creating the webforms beforehand isn't ideal for our workflow, but then neither is editing the module code on the live server to update it with the new node id.

quicksketch’s picture

I was just pointing out that custom theming shares the same problem as custom form_altering(), since both are dependent on the NID. If using Features, perhaps http://drupal.org/project/uuid_features would help with the deployment of Webforms.

jcarnett’s picture

+1 for the option to set a custom ID

It's really rare to theme anything based on node ID (frankly, it's bad practice), so I don't think that's a good parallel here. To me this is much like giving views a machine name, and I think that's more similar to what's being requested here.

My current workaround involves adding a hidden form element to every webform just to give myself something other than the NID to identify webforms in form_alter() and other hooks and I suspect that's a fairly common practice among developers dealing with multiple environments. When it comes to theming webforms I end up doing extra work to wrap the form in a container with a custom ID or class. All that would be unnecessary if it were possible to give the webform a custom ID/name.

quicksketch’s picture

Title: Set a unique webform id to use instead of node id » Set a unique webform ID to use instead of node ID (and use it for theming, exports, features, form IDs, etc.)

Updating title. I'm still not 100% on-board with the idea but I can see how it would be valuable in a lot of applications. Marked #1053864: Is possible to make a Webform as an exportabe object? duplicate.

robertom’s picture

sorry for noise message, but I would subscribe this issue.

fuerst’s picture

Just a note: I found http://drupal.org/project/uuid_features to be a good way to have Webforms exported in a Feature (using the Features module). If not using Features at all you may use http://drupal.org/project/uuid by itself to create UUIDs for Webforms.

ronlg’s picture

I'm on board with Stella. We are setup with multiple dev/sandbox environments that use their own databases. It becomes a big problem when node id's are out of sync.

The approach I took with Webforms 2.9 was to use the path alias in the class. It strips the "/" and replaces it with a "-" just incase there are multiple levels. This works great and keeps us from having to deal with the pesky node id's.

Stella, if you need help with this, please let me know.

kenorb’s picture

+1

rayasa’s picture

+1

lsolesen’s picture

+1

DuaelFr’s picture

I think this is an huge improvement and I totally agree with Stella. Drupal development is going more and more professional so staging concerns become really important.
It may be the time to think about a 4.x version using Entities and CTools.

I hope this awesome module will go the right way.

mrmeech’s picture

I entirely agree with DuaelFr

quicksketch’s picture

Before I sign on to this idea, I'd have to see a proposal that actually makes it even remotely possible. This essentially is requesting that a node be given a machine name, which means all kinds of syncing/replace/overriding the database version of things. It sounds nice in theory but this is not an easy task. Webform benefits significantly from being a node (scheduling, permission, access control, moderation, workflow, etc.) and a lot of the benefit that people are envisioning is about managing through Features, which would throw all that functionality out the window.

DuaelFr’s picture

We may take inspiration from Drupal Commerce and Field Collection. They both use entities. For example, Commerce guys make difference between two concepts : product data and product display. First is an entity and second is a related node.

Webform configuration and submissions may be stored in entities which could be linked to nodes (or other entities) using Relation API. I think doing this way could open a lot of doors like using real Fields instead of Webform actual components for example.
If I had a lot of free time or a sponsor I would love to make it by myself but I have not ^^

quicksketch’s picture

@DuaelFr: I can't really see how that would help with the problem of exportability or machine names. Anything that is an entity will face the same problem as nodes, since nodes essentially are entities that make pages plus some other things like publishing options and access control. All entities no matter what their type are going to have the same challenges with exportability because they all have numeric, auto-increment IDs.

DuaelFr’s picture

Entities are really easy to plug with CTools but you are right, without machine names it will not be better than today.

I just had to play with an exportable webform. I was surprised to see that UUID and UUID Features worked well in spite of the nid living in export code. I had to use some hooks to suggest templates or behaviors based on this uuid but it works pretty well.

function pb_advisor_preprocess_webform_mail_message(&$variables) {
  if ($variables['node']->uuid == '2048d064-3333-41df-a5b4-8b5506e2dd8a') {
    $variables['theme_hook_suggestion'] = 'webform_mail_advisor';
    array_unshift($variables['theme_hook_suggestions'], 'webform_mail_advisor');
  }
}

function pb_advisor_mail_alter(&$message) {
  if ($message['id'] == 'webform_submission' && $message['params']['node']->uuid == '2048d064-3333-41df-a5b4-8b5506e2dd8a') {
    // Do sth
  }
}

Another problem is the submission's data mapping. Submission's data is an array indexed by components' ids instead of their form_key value. I writed a tiny function to help me with this too. Hope it could help.

function _pb_advisor_webform_get_submission_data($submission, $node = NULL) {
  if (NULL == $node) {
    $node = node_load($submission->nid);
  }
  
  $cmps = _pb_advisor_webform_get_components($node);
  $data = array();
  
  foreach ($cmps as $key => $cid) {
    $data[$key] = $submission->data[$cid];
  }
  return $data;
}

Regards,

queenvictoria’s picture

+1 for the tiered development workflow that Features assists with.

mstrelan’s picture

Version: 6.x-3.0-beta6 » 7.x-3.x-dev

Not sure why this is specifically tagged with 6.x-3.0-beta6.

It seems really simple to me, you just have a "webform_node" table which maps the unique webform id to the node id. It could be a many to one relationship so the same webform could be used on multiple nodes, if necessary. Submissions would probably have to have a foreign key to webform id AND node id in that case.

Webform id should be a machine name which is editable just like creating a View.

CarlHinton’s picture

Have you seen the module webform-classes http://drupal.org/project/webform-classes

DuaelFr’s picture

Is this something planned in the 4.x version ? I cannot find any roadmap :/

Summary :
- nodes are unexportable entities because a node is not configuration but content
- nodes' content types (bundles) are exportables because they define nodes' structure (thank to fields)
- webforms submissions does not need to be exportable because they are like nodes
- webforms defines submissions' structure and might be exportable like nodes' content types

The purpose is to split data and configuration and to provide a way for developpers to make their work versionable and deployable.

Webform entity and Forms (FSE) are in the good direction but they are showing a lack of usability and are forgetting some very useful functions.

quicksketch’s picture

I'm currently not planning on it because of the difficulty of reconciling database versions with "in code" versions. This is still an extremely messy operation. As I think I've stated above, Webform's being nodes still provide quite a few advantages also, including being schedulable, access control compatible (such as when combined with OG), moderation, etc. Unless we make Webforms something else besides nodes (or anything with an auto-increment ID), we're going to be facing the exportability problem. So this issue doesn't have any way forward because there isn't any good solution to the problem that I can see.

richsky’s picture

I tried the feature uuid path (with node export), and I could export webforms quite easely, but as soon as you export more than one, then you dive in features conflicts (I could not sort out at the moment).

xpasi’s picture

Having the same issue, but not with multiple sites, but multiple transltions....

We're making the site with 3 languages initially and it will be translated to about 10 more languages after deployment.... I need to make a few changes to a "contact us" form with form_alter. I can of course make these to the 3 language nodes we currently have, but we'd have to remember to make the changes imidiately after every new language in the future ... and on top of that, the translators are doing their job semi randomly, so they'd have to inform us when the translation is done!

For now, I'll go with the hidden field route, but a custom machine name for webform would be much appriciated!

stella’s picture

For that one you could use the entity translation module instead (https://drupal.org/project/entity_translation)? With that you just have the one node, and have the fields translated.

timaholt’s picture

FileSize
6.2 KB

So it makes sense to me that this unique ID should be a UUID. This patch adds a webform_uuid module that provides support for using uuid_features or deploy with webform nodes, their components and webform validation rules (if they exist).

This patch does not turn components or rules into revisionable entities, but that could happen down the road if someone wanted to run with that.

timaholt’s picture

Status: Active » Needs review
quicksketch’s picture

Hi @timaholt. I really don't think a randomly generated UUID is what anyone wants when it comes to form_alter, theming or CSS identifiers. I think it *does* make sense for exporting, but I don't think the current patch of setting "nid" to something other than the NID is a good idea. If we're going to support UUIDs, the support should explicitly supported, not hacked in. This probably means adding a new database column for UUID in the Webform table, similar to Drupal 8. If I understand it correctly, that's actually the only place we need to add it. Everything else still keys off the NID.

So far, I think this issue has focused on the machine-name aspect. I think it would make sense to make UUID support a separate request and keep this issue for a user-entered value.

timaholt’s picture

@quicksketch, so you're right this patch doesn't support the theming stuff. But the idea of turning the nid into the UUID on load is for Deploy or UUID Features, since you'd export with that value. Then on pre-save you convert it back so that you have the new nid of the parent node. Essentially the webform components (and validation rules) are exported as a part of the node entity and aren't entities on their own. If we wanted to add proper UUID support to make webform it's own entity, that would work too. But this is for the short term, since that seems like a far off goal. I can always move this to a separate thread, since it does meet a real need at the moment.

quicksketch’s picture

@timaholt: I made a new issue at #2076483: Support UUIDs for Feature Exporting for UUIDs. Could you re-post your patch over there?

quicksketch’s picture

Issue summary: View changes
Status: Needs review » Active

Setting this issue back to active. This issue is for machine names, but the patch is for UUIDs, which should continue in #2076483: Support UUIDs for Feature Exporting.

quicksketch’s picture

Version: 7.x-3.x-dev » 7.x-4.x-dev
gagarine’s picture

Title: Set a unique webform ID to use instead of node ID (and use it for theming, exports, features, form IDs, etc.) » Give a machine name to webform and use it for theming, exports, features, form IDs, etc.

Update the title accordingly to the comment #31

DanChadwick’s picture

This sounds like a compatibility mess, given that node ids are used the theming, form alters, etc.

DanChadwick’s picture

Status: Active » Closed (won't fix)

Given that 7.x-4.0 is imminent, and the 8.x branch will likely be a complete redesign, I'm closing this. I cannot imagine trying to get dozens of webform add-on maintainers to support a 7.x-5.x branch.