Theming webforms

This patch includes a lot more than it should. I even see features, and changes that are in the current stable release of webform.

Please re-roll this patch against the latest CVS head for Webform, so that it only includes the changes required to include the template suggestions.

See http://drupal.org/handbook/cvs and http://drupal.org/patch for guides on doing this.

I can see merit in the idea, especially when copying a node from a testing site to a live site generally results in the node having a different nid. How do you go about merging the changes between your dev and live sites in the database? Or do you simply create the node again through the web interface? If so, then I do not think this idea would be useful, as you could simply create the webform on your live site, leave it unpublished, and create the template directly there.

The patch is a little rough, but the idea is sound.

This change doesn't improve the process of creating forms, but significantly enhances a developer's ability to associate CSS to extant forms. The idea specifically allows development teams using source code control to stage to a shared server and then publish to a production server where the form ids might be different. Even if you re-create the form in the database by hand, that doesn't obviate the need to have the associated CSS committed to source control and staged for client approval prior to deployment to production.

This addition allows webform to be a solution for professional Drupal development shops with change management procedures, which would be of great value to me personally.

I'm a little hesitant about this proposal, because it's putting additional burden on users that are least likely to understand what it's used for. If you're capable enough to be theming your Webforms, you won't have any problem understanding the purpose of such an option. But what about the majority of users that don't even know what theming is, let alone able to use it on a webform. Additionally, a minor issue compared with the usability problem: some form names would conflict with existing .tpl.php files, such as "webform-confirmation.tpl.php" or "webform-mail.tpl.php".

I tend to use the approach suggested by cdale, where the form is always created on the live site unpublished, then you can theme it by downsyncing your database locally and working there, commit the new .tpl.php file when you're done and publish the node.

I'm not sure what the burden is to people who aren't interested in theming a form. I see names for webforms as a logical parallel to names for views and content types.

Often times "site builders" or developers are setting up content types and views. Webform is much more the tool of the average user or content manager than either of the mentioned tools (though of course developers use Webform also). The point being, the only one that benefits or would ever use a machine name for each webform is a developer, the person most capable to understand its use. Burdening end-users for a developer setting seems unnecessary.

I noticed in this patch, that to achieve the themeing by name, it removed the ability to theme by nid. I think if this feature were to be added, it would have to be done in such a way that it still allowed themeing by nid. I can honestly say, I can not see how this can be done.

It would seem that it would have to be one or the other, unless the name was made optional (And hidden away under advanced settings). This would allow to check if the name was set, and use the name suggestion instead of the nid.

Of course, this could cause all sorts of other issues if a client accidentally added a name to a webform you set up for them, and themed with the nid. The form themeing would be lost, and you'd be stuck in support calls fixing it. (Not that it would be difficult, but definitely annoying). And I most definitely think that allowing theme template names to be changed by a field on a form that could potentially be updated quite frequently, by people who do not have a great understanding of drupal, is a very bad idea.

The parallels mentioned by Nathan Gasser to views and content types I think does not apply to webforms. Views and Content types are more of a 'setup and forget' kind of thing, and in general, a client would never have a need to go and edit those things. With webforms however, I feel it is very beneficial to be able to teach a client how to create and edit their own webforms, as it eases my burden on constantly having to make small changes, or making a simple form, when they can quite easily do it themselves and never have to bother me. They also save money because I do not have to charge them for my time. :)

I personally think for these reasons, that this is a won't fix. I have not marked this as such, but this is how I feel.

Having said all this, I would not be against having an admin section (Akin to Content types and views), where a site builder can associate a machine name to a webform. (Which will then allow this machine name to be passed through on updates, or re-added when re-creating the form on another site).

While this might solve the naive clients from breaking things, it does not solve the problem of what theme template pattern/suggestion to use.

If someone can show a way that this can be done to theme by name AND nid, (With some kind of precedence on whether a template exists) then I would support and help test this. But I can not see a way that this can be done with the current theme system in D6. Happy to be proven wrong though. :)

This change will not be added. If you want to implement this in your own site, you can do it through some fancy hook_preprocess_webform_form() function to create your own dynamic template names.

#7 could be combined with a CCK field which lets you define the "name" or "type" of the form, as required. The field could then be picked in in a preprocessor and appropriate template suggestions generated.