Right, this is a bit crazy, there are now three four five modules in the niche to mimic webform cloning / templating. None stand out in relation to functionality, all appear maintained, all have about the same small user base, with exception of the newest module Webform defaults created February 12, 2013.

In case we get issue queue ping-pong, these are:

Webform Template
Created: October 28, 2011
Supports: 6.x-dev, 7.x
Usage: 2,963 / 14,603 (Jan 16, 2016)
Bugs: 0 (Jan 16, 2016)
Other issues: 10 (Jan 16, 2016)

Tags an existing webform to use as a template that is selected during node creation.

Webform Share
Created: November 2, 2010
Supports: 6.x, 7.x
Usage: 7,443 / 20,444 (Jan 16, 2016)
Bugs: 5 (Jan 16, 2016)
Other issues: 5 (Jan 16, 2016)

Exports an existing webform and allows administrators to save this against a content type, so that the webform is generated automatically on node creation.

Webform Default Fields
Created: July 20, 2011
Supports: 6.x, 7.x
Usage: 2,276 / 15,795 (Jan 16, 2016)
Bugs: 1 (Jan 16, 2016)
Other issues: 3 (Jan 16, 2016)

As per Webform Share, but uses an existing node to define as the template for the automated creation

Webform defaults
Created: January 30, 2013
Supports: 6.x-dev, 7.x-dev
Usage: 52 / 1,350 (Jan 16, 2016)
Bugs: 0 (Jan 16, 2016)
Other issues: 2 (Jan 16, 2016)

Sounds identical in functionality to Webform Template (without reviewing the code).

Node Export Webforms
Created: March 23, 2015
Supports: 7.x-rc
Usage: 314 / 1,614 (Jan 16, 2016)
Bugs: 0 (Jan 16, 2016)
Other issues: 0 (Jan 16, 2016)

Extends Node Export, adds support for Webform Validation and apparently helps resolve some exporting issues.

Note

And similar functionality can be gained using Node Export, Node Clone, or any of the other modules that can handle exporting and importing of entities

In relation to the name space, I prefer "Template" and this appears to be more customizable; internally maybe "Default Fields" is cleanest, and "Share" has the most users (3,385 means nothing in the grand scheme though, approximately 0.3% of sites) & is the oldest and can export / import between compatible versions of webform on different sites.

I'm happy to retire mine, if either one of the alternatives can provide an internal storage solution that doesn't depend on having nodes lying around, which is the main reason why we don't want to use node clone.

i.e. a blank node that has the webform attached can be easily cloned / altered slightly to get the templating functionality of both Template and Default Fields.

All I know is that I can not take lead nor spend too much time on this, but I hate to be personally invoked doing duplicate work and cluttering up the already overcrowded module landscape.

And dangling the carrot...

If one of you pick this up and get the other two to reason to drop theirs, then the additional users will just scape the module into the top 1000 725 500 400 :)

I'll cross link this thread from my project page and append Webform Template to the list of modules that provide this functionality on the project page. (I picked this module as I love the name most)

Thoughts?

Comments

rv0’s picture

Thanks for summing things up.

Have not tried the other modules (yet)
I personally don't really have an issue with webform_template being "node" based for the following reasons:
- webform being node based.
- although some usecases involve an internal content type primarily used for "template" purposes, other usecases would just require cloning existing (public) webforms, In fact I have implemented both scenario's on multiple occasions.
- it's still a big difference with node_clone as we're cloning webforms, not nodes. It's a much more logical thing to do and better in terms of UX

But if there are alternatives I'm willing to examine / give feedback.

For the record, future plans for webform_template are:
- a plugin system (probably ctools based) for integration with other modules that extend webform to support cloning those settings (current approach in dev uses submodules, which is not really a good approach imo)
- better documentation for alter hooks
- more granular control of source/destination + defaults ( #1430752: Source type and default Template per content type

No ETA on these changes though. It will be done when we need the functionality.
I'm willing to incorporate the functionality from the other modules if it makes sense and patches are provided, because I don't have time to do this all by myself atm.

Alan D.’s picture

Sounds like you are in the same boat time wise. I've just spent 3 weeks working hard bringing Diff into the Entity world.

"dev uses submodules, which is not really a good approach", which you need a module to define the plugin... Comes down to personally preference I think. Although a 1/3 of Drupal 7 sites do not use CTools, and it is a beastly module to force on end users.

Caching isn't that hard, this is the guts of one I wrote for a sandbox project recently. It is about as bad as it gets, using drupal_static() and a i18n aware cache.

function file_attributes_component_definitions($type = NULL) {
  global $language;

  // Note that hook_file_attributes_component_info() has translated strings, so
  // each language is cached separately.
  $langcode = $language->language;

  $components = &drupal_static(__FUNCTION__);

  if (!isset($components)) {
    if ($cache = cache_get("file_attributes_components:$langcode") && !empty($cache->data)) {
      $components = $cache->data;
    }
    else {
      $components = array();
      foreach (module_implements('file_attributes_component_info') as $module) {
        foreach (module_invoke($module, 'file_attributes_component_info') as $name => $component) {
          $component['module'] = $module;
          // [edit - cut out some of the internal content]
          $components[$name] = $component;
        }
      }
      uasort($components, '_file_attributes_component_definitions_sort');
      drupal_alter('file_attributes_component_info', $components);
      cache_set("file_attributes_components:$langcode", $components);
    }
  }
  if (isset($type)) {
    return isset($components[$type]) ? $components[$type] : NULL;
  }
  return $components;
}

I think the main reason why I often avoid the node clone approach, is that we have had these deleted in the past by clients that don't know what they are doing, and one was even published and altered to do something completely unrelated.

Anyways, back to the issue at hand #1430752 looks like it will consumed Webform Default Fields (from a 5 min code review only).

rv0’s picture

"dev uses submodules, which is not really a good approach", which you need a module to define the plugin... Comes down to personally preference I think. Although a 1/3 of Drupal 7 sites do not use CTools, and it is a beastly module to force on end users."

Well.. I personally feel that using modules embedded inside the module to extend the functionality is kind of ugly. Imagine a list of 10 modules that integrate webform_template with webform_XYZ modules.. Drupal 8 will have a plugin system built-in to avoid this.

With well written documentation it should be very easy for others to integrate with it from within their own modules using the ctools plugin system (or to provide it as a patch and have it added to webform_template), plus there's no real need to enforce ctools (thats what module_exists is for..)
I haven't decided yet on the plugin system to use, that's why I just used a submodule for the webform_localization integration in dev.

As for reasons to avoid node_clone for cloning webforms, there's the problem of variable defaults on node fields (e.g. a start date field), translations, etc (i can go on because we used to work around a lot of these issues in the past)

Alan D.’s picture

As you say, it is one legitimate source of many :)

I would do 100% or 0% via plugin systems. Mixing code bases is messy. If a user needs functionality, then you kinda do by de facto, they installed it for functionality that depends on having the system. I'm not personally against this, I'm just saying. It is a nice DX, I've just written 4 basic plugins ones since my last post (3 were just panel layouts).

faqing’s picture

Project: Webform Template » Webform share
Version: 7.x-1.x-dev » 6.x-1.3

I have been using Webform Share, which is easy and powerful.
The only thing one needs to aware when importing: change the old nid (node ID number) to the new nid (use replace all).

For Webform Default Fields, if start from beginning (there is no webform created yet), you may try.

I have not tried Webform template.

In short, if you wish to create a webform based the old ones, use Webform Share or Webform Template.

Alan D.’s picture

Project: Webform share » Webform Template
Version: 6.x-1.3 » 7.x-1.x-dev

Moving back.

Personally, I think that Webform Template & Webform Default Fields could be easily merged. There are differences, but these are minor imho.

It would be nice if at least these modules mentioned the various options on the project page, particularity Node Clone at least....

peterx’s picture

I am looking at my requirements to move webforms around and comparing the options to other export/imports.

The Webform tables use a node id. Some of the other export/imports fail when they try to insert node 1000 into a Web site where the nodes are already past 1000. To move Webforms around, they need a machine id. If a machine id was attached to the webform table and used as the identifier, a form could be moved anywhere and replace the correct webform without having to artificially match up the node ids.

An XML export is the logical choice with the option to include or exclude existing results. The file can then be stored in Git and safely edited for different sites. User modules could contribute extra sections to the XML file.

rv0’s picture

Status: Active » Postponed

Added the similar modules on front page.
I don't have time to invest in major changes in Webform Template.
If anyone wants to step up and do the required work, I'd be happy to help where I can, or perhaps carry over the project.

rv0’s picture

I think we may have another contestant

http://drupal.org/project/webform_defaults

Alan D.’s picture

Issue summary: View changes

Adding details about a fourth module :(

Alan D.’s picture

Title: Three overlapping modules » Four overlapping modules

Updating the title.

I think that D8 is probably a perfect time now to merge these if you are still going down the plugin path. I am just starting to consider a first port of some of my basic ones, probably the field based ones as these haven't changed too much (yet), but it could be a while before Webform is ported.

authentictech’s picture

I just used Node Export to transfer all my webforms perfectly and it would seem to the most standard Drupal-ly way of doing this, with the added advantage of working for all other node types.

What about building any additional Webform-related functionality on top of that module as a dependency?

bcreeves’s picture

Do any of these modules have an option for just copying part of a webform. Like just a fieldset and all fields contained in that fieldset?

My use case is I will be making a ton of different forms but they all have one or two fields or fieldset that should act basically the same.

bcreeves’s picture

Issue summary: View changes

Updating the stats within description to reflect current usage

LBiStockholm’s picture

From a users point I have found the major difference between these modules to be the 'default webform' behavior. Webform Template lacks this functionality, the others are built upon it.

Webform Template on the other hand gives the opportunity to reuse a template on many content types.

The difference between Webform Share and Webform Default Fields is - from an user perspective - the GUI.

A merge would be most appreciated. I am currently working with both Webform Share and Webform Default Fields since I need a default webform for my content types, and also would like to reuse (export...) the webform between the different content types.

Alan D.’s picture

Issue summary: View changes

Updated the stats.

Very approx only. analysis of the stats.

Usage stats suggest Webform template and Webform share approach as the most useful. At one download = one site, nearly 45% uptake, or at 2 or 3 downloads per site (i.e. updates), then near 100% uptake.

Only 22% for Webform Default Fields, but that has had at least 6 releases, so these stats would be unfairly weighted against that module. i.e. Each site had 5 downloads would correspond to 100% uptake.

Webform defaults is definitely not doing well in this area, under 10% with no releases. i.e. less than one in ten running with it after downloading it.

Very approx as it means that these are running incomplete statistics with unknowns like if Update Manager is running, the number of sites that have re-downloaded updated versions etc.

Alan D.’s picture

Issue summary: View changes
rosell.dk’s picture

rv0’s picture

Issue summary: View changes
rv0’s picture

Title: Four overlapping modules » Five overlapping modules
rosell.dk’s picture

I've had some problems with using Webform share to move a webform to another site
- Conditionals are not imported correctly (https://www.drupal.org/node/2556411)
- Importing in some circumstances causes website to be unavailable (https://www.drupal.org/node/2568693)

Node Export Webforms did not have these problems.

The problem with website crash was happening in a eval() statement. One advantage of Node Export Webforms is that it extends Node Export, which seems more mature than any of the modules listed here. And it can be configured to use JSON instead of eval()

It seems Node Export Webforms would be the recommended module for moving a webform from one site to another, or?

Alan D.’s picture

Issue summary: View changes
Alan D.’s picture

Issue summary: View changes

Adding info about Node Export Webforms too.

rv0’s picture

Title: Five overlapping modules » Six overlapping modules

And we have another: https://www.drupal.org/project/webform_component_bundles

This module provides a Webform-like interface for creating reusable bundles of components (fields). The component bundles can be easily added to new or existing Webforms.

Alan D.’s picture

hehe, albeit that does actually do a specific task, namely sharing groups of components between forms ;)

GiorgosK’s picture

These two module sound like they solve the same problem as webform component bundles
but have not have not tested them
https://www.drupal.org/project/webform_add_existing
https://www.drupal.org/project/webform_component_reuse