Is possible to make a Webform as an exportabe object?

There are two approaches that you can use:

First of all thanks for your response.

1. You can install Node Export which will allow you to Export and Import nodes across sites using simple textareas. This is a proven, simple mechanism for moving a node across sites.

I tried this approach and is a good compromise. Unfortunately I don't have found how I can export also rules from "Webform Validation", but it's better than nothing.

I think that a good solution for this problem is using "Node export features" (is part of node_export), but I'm using Drupal7 and #1030678: Components missing from Drupal 7 version is a postponed task until #1005138: Port UUID to Drupal 7 isn't fixed

2. You can (try to) use UUID Features which integrates with features to export things like nodes into a Feature. This route is more experimental but more what people are looking for when it comes exporting Webforms into a Feature.

I've tried UUID (for drupal7) from github, but I don't have found a UUID Features for drupal7... for now I think this isn't a solution viable.

I saw that the Webform is a big module for my first approach to drupal internals and his modules, but in my spare time I would investigate if I can integrate ctools export capability in webform. You think that there is some incompatibility that I don't know now for this task?

Obviously if someone have some hints for this task I'm all ears ;)

The first and biggest task to exportability is this issue: #837594: Give a machine name to webform and use it for theming, exports, features, form IDs, etc.

Thanks for pointing me to this issue.

Any exportable object always has a non-changeable machine name by which it is used across environments. However since Webforms are nodes and almost by definition considered "content", we get into a sticky situation very quickly. All of the benefits that we get by being a node (such as combined use with CCK, path aliases, scheduled publishing, node access control systems) are dependent upon the Node ID. So just giving Webforms a machine ID doesn't actually help much at all, because the NID has to remain constant in order for all the systems that work with nodes to continue operating correctly.

Sorry if I do another question, but I'm wondering if this hackish might work:

1) export node with "node_export"
2) import this node into other environment
3) take note of this new NID
4) export "webform" and "webform validation" with CTools in code through Features (I know that this isn't possibile yet)
5) into exported code (#4) change NID value with NID of other environment (#3)
6) install the modified code (#5)

5) into exported code (#4) change NID value with NID of other environment (#3)

This would be quite a challenge to have this not negatively affect the exported node. The NID or the path of the node is stored in a dozen tables: blocks, comments, node_access, node_revisions, and lots of others (depends on what modules you have installed). There's a lot of information that relates to nodes that's not part of the exported $node object.

I would remember that I'm a n00b of drupal, but if I haven't misunderstood all those NID is related inside a single environment.

I would say what I intend in other words.

If i would add a webform to a Page content type with NID 5 without use GUI but utilizing raw SQL command directly in the database, I need to add

- 1 entry in webform table with "nid" field equal at 5 (Node Page already existent)
- N entry in webform_component table with "nid" field equal to 5 and "cid" field from 1 to N
- 1 entry in webform_emails with "nid" field equal to 5
- if I would I could fill also webform_roles (otherwise when I update roles in the GUI this table and his entries for NID 5 is regenerated).

obviously other fields of this entries is setted with good values

If I'm correct, discriminant between two environments is NID of Node Page already existent in which i would integrate webform

Another problem is that you'll run into all kinds of issues when you create a node on environment A that uses a NID that is used for something else in environment B. What happens when your Webform conflicts with a different piece of content with the same NID?

I hope that this don't happen :D

I would quote part of Exportable object tool (CTools help):

Typically, exportable objects have two identifiers. One identifier is a simple serial used for database identification. It is a primary key in the database and can be used locally. It also has a name which is an easy way to uniquely identify it. This makes it much less likely that importing and exporting these objects across systems will have collisions. They still can, of course, but with good name selection, these problems can be worked around.

In this case I could consider NID a primary key in the database (used locally). [1st identifier]
For the easy way to uniquely identify it I could use a name of "fantasy". [2nd identifier]

The webform exported now is (but I might be wrong) a packet where I could hardcode NID value (of Node Page already existent in the target environment) inside file.

Basically I would use this packet as a carrier transport instead of using a series of RAW SQL command.

I'm completely wrong? And yes, for hackish I intend "dirty hack" ;)

Another option which I didn't mention earlier is Deploy module, which attempts to solve the problem of moving content from one environment to another. It attempts to solve the problem purely from a brute force approach, solving every individual integration manually.

Not yet ready for drupal7, but thanks a lot also for this hint.