Support UUIDs for Feature Exporting

Here is the patch for adding a webform_uuid submodule to provide support for deploy and features uuid.

Unless I'm missing something the patch in #1 didn't work as hook_uuid_entities_features_export_entity_alter() uses the Features component as the hook rather than the module and webforms are exported to Features through the node component.

Attached is a patch that uses hook_uuid_node_features_export_render_alter() instead (with changes to account for use of $node instead of $entity. The rest of the code is the same with minor coding standards changes.

I haven't looked at the changes in 7.x-4.x so I'm not sure how applicable the patch will be there.

This patch fixes an issue with #2 and doesn't take into account the comments in #3.

The above patch only seemed to work along with the patch from comment 1 of #2117453: uuid_node doesn't use entity_uuid_load/save to load/save node. I believe this is because webform_entity_uuid_load() and webform_uuid_node_features_export_render_alter() have some overlap in functionality (replacing nids with uuids).

Without the additional patch webform_entity_uuid_load() isn't called, which exposed the issues with webform_uuid_node_features_export_render_alter() which are fixed in this patch.

As with Webform components, we need to map webform email NIDs also. Here's a updated patch that does just that.

@paulihuhtiniemi from the code exported by Feature I still see NID used npt UUID.

After reading #4 carefully again, I patched UUID_features with the patch from first comment on #2117453-1: uuid_node doesn't use entity_uuid_load/save to load/save node

Seems to working great!

For six months we've been successfully using patches
webform_uuid-2076483-4.patch
along with
uuid_features-doesnt-use-entity-uuid-load-save-to-load-save-node-2117453-2.patch

Also had a look at webform_uuid-2076483-5.patch and it looks great.

Seems to working great! x2

+RTBC recommend webform_uuid-2076483-5.patch

we've been using patch on 4.x dev branch

Using #5 I'm getting a problem when moving between local, dev, and stage.

It seems that the webform export is exporting a serial and nid which may already exist on the new environment. Then, when you go to submit a new webform, webform tries to store it by an already used nid and serial, causing this error:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '3-7' for key 'nid_serial': INSERT INTO {webform_submissions} (nid, serial, uid, is_draft, submitted, remote_addr) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 3 [:db_insert_placeholder_1] => 7 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => 1404422047 [:db_insert_placeholder_5] => 50.201.154.94 ) in drupal_write_record() (line 7207 of /mnt/www/html/sunpowerstg/docroot/includes/common.inc).

Thanks for your work on this. I suggest that you create your own webform-related module. I'm going to close this since there is no issue or patch for webform core.

What this module does its create a new submodule under webform that allows UUID related functionality to work.

According to #2074599: Remove all Contrib module functions from uuid.core.inc, plus reference where UUID support is for contrib modules the process like a few other contribs (migrate, features, etc) is to provide that support in the contrib module itself.

I appreciate that this is more of a feature request and shouldn't hold up any official releases but can a discussion happen first before this issue is closed since it seems to be the recommended approach that was done by a lot of other contrib modules?

I am going to reopen this issue but feel free to close again if inappropriate to do so.

I wasn't suggesting that webform support be put into the uuid module (although this would be appropriate-- see below), but rather that someone -- maybe you -- create a distinct webform/uuid integration module -- not part of webform. There are dozens and dozens of such add-on webform-related modules.

When there is code that integrates two modules, there are always choices about where to put support. Build it into one module, the other module, or put it into a third module? In my opinion, the popularity of the modules drives this somewhat. For example, the usermerge module supports profile2. There is no way that profile2 is going to add support a tiny, unpopular module like usermerge.

I would suggest that uuid adopt a philosophy similar to usermerge. The module itself provides integration with the most popular modules, leaving the rest up to custom developers, the other modules' maintainers, or 3rd modules. This way usermerge is useful out-of-the-box and can be extended.

So, let's see, uuid has about 10% of the popularity of webform. I would suggest that building support into uuid as add-on or some other mechanism would be appropriate.

Leaving this open for discussion, at least for a while. :)

There's nothing wrong with having a submodule that isn't used by everybody using the parent module. For example, we're all using ctools, but very few of us are using Bulk Export, one of its submodules. I don't see the value-add of splitting this out into its own module if it needs to be used with it.

Keeping these around does not add operational bloat because users can simply keep the module disabled if they don't want to use it. However, splitting them off into separate modules does cause bloat in the module space because it increases the number of modules to keep around instead of keeping them combined.

Let's get that module in here. Setting to "Needs work" based on #10.

@colan -- I open-minded about the conclusion, but I'm not sure I agree with your arguments. Assuming for the moment that you have the webform_uuid module enabled, you have the same runtime bloat whether it is a submodule or separate module. The only difference is what folder it lives in. It is still an extra time through the module loop for every drupal_alter and so forth in either scenario.

If it is a separate module, then it doesn't live on the servers of the roughly 500K-1M webform installations, where it takes up disc space. If it is a submodule, it does.

I can see the logic of submodules if there were a manageable number of them. But there are probably 100 or so webform-related modules (maybe more -- it would be hard to count them).

Another issue is maintenance. A submodule is the responsibility of the main modules maintainers, at least in terms of d.o permissions. A separate module can be maintained by anyone.

OTOH, there is something to be said for not having to go to the trouble of creating a whole new module "space" on d.o, including getting the module approved.

I am also a little unsure how this relates to human-readable machine names for webforms (and maybe components). It is probably orthogonal, but I sure would like to be able to write something like HOOK_form_webform_client_form_MYWEBFORMID_alter, rather than HOOK_form_webform_client_form_NODEID_alter. And similarly for theming. Is there a role for uuid's here? I think not, but I thought I'd mention it since quicksketch mentioned it in the OP.

I suppose it comes down to different philosophies, neither one better than the other. But as you're a maintainer, it's ultimately your decision. ;)

I'll admit I don't have much of a stake in this; I'm here because a distro I'm using for a client has it included. Unless other folks have more convincing arguments, maybe those that are actively using the submodule could spin off another project for it?

Setting to active to keep the discussion going, but if there are no more thoughts in the next little bit, let's close this one.

Actually, scratch that.

What is the status of this as far as becoming it's own module? Did anyone have plans to make this happen?

@drystaldawn - Tag. You're it. I'm closing this issue because it won't be included in webform itself. That doesn't mean that it wouldn't make a nice add-on module.

Heh, ok well here it is then: https://www.drupal.org/project/webform_uuid

The initial release is the patch from this thread without any modifications at all. If anyone wants to be added as a contributor they can open a ticket in the new project's issue queue.

@crystaldawn -- be sure to add your module to the list of webform-related modules that is referred to on the webform page. Thank you for your contribution.