There are a lot of scenarios where trying to configure a webform at node/edit/x (or node/add/webform) is not the ideal situation. For example, take the following workflow:
- Create a new Webform node, giving it a title and body. You can't assign any components for e-mails yet since no components exist.
- Webform redirects you to node/x/edit/components, but marks the webform unpublished (forced) until you click the publish button.
- Add some components to the form.
- Then go BACK to node/x/edit, and select some components to receive e-mail.
- Publish the Webform manually.
Instead I'd like to work towards a workflow more like this:
- Create new webform node, giving it a title and body.
- Webform redirects you to node/x/webform/components (a separate tab), but doesn't force the unpublished state.
- After configuring components, you go to node/x/webform/email and configure e-mail templates (see #277581: Send emails with a custom/templated body (and subject, to addresses and from addresses))
- After configuring e-mail, you configure submission settings at node/x/webform/settings
- Publish the Webform if necessary.
The workflow isn't any shorter but it's more linear. This approach of making a separate "Webform" tab (not under "Edit" any more) opens the possibility of "Webform-enabling" any other content type, so you could potentially have multiple types that have webforms attached to them (and thus different CCK fields).
This patch separates Webform's configuration from the edit tab and introduces a "webform.pages.inc" file to store the separate menu callback and form. We can move more configuration pages into this file to save on memory and parsing as we continue the 3.x branch.
| Comment | File | Size | Author |
|---|---|---|---|
| webform_separate_node_configuration.patch | 46.92 KB | quicksketch |
Comments
Comment #1
quicksketchCommitted so we can move on to #277581: Send emails with a custom/templated body (and subject, to addresses and from addresses) and #468176: Webform/Form-builder integration.