Text like "You have already submitted this form." and "View your previous submissions" should be configurable per form (not globally). Some forms may not desire to have the former message printed because it looks like an error message (when in fact it's OK to submit multiple entries).

Comments

mgenovese’s picture

mgenovese commented

I should clarify: at the moment, all the text is hard coded into the module. I'm asking for it to be (a) configurable, and (b) configurable on a per form basis, versus configurable for all forms. Some forms can only have one submission per user, and thus necessitate certain response text, and forms with multiple submissions allowed may use other text that is more appropriate.

Same goes for "Go back to the form" - this should be configurable. For each form, we may have a name for it (e.g. "Submit another request.", etc.)

quicksketch’s picture

quicksketch
he/him
commented

Most of these things are handled in the theme layer. I'm not sure duplicating all the functionality of the theme system in Webform is a wise decision.

Confirmation message: theme_webform_confirmation() (Drupal 5) or webform-confirmation.tpl.php (Drupal 6).
Submission status message: theme_webform_view_messages (Both D5 and D6).

Both could be made to support per-webform by appending the NID, similar to the way e-mail headers and e-mails can be themed per-node.

mgenovese’s picture

mgenovese commented

Perhaps I'm a bit of a newbie in this area. My understanding was that the theme system was generally manipulating the layout the website, and sets of nodes (including just a single node). I wouldn't have imagined that the modification of a module's message output (non-layout, non-CSS, non-markup) text should be relegated to the theme system. In my humble opinion, being forced to create a theme page (per node) for every form I create isn't an elegant solution to the problem....just to change the message text output from the module. For sites with multiple forms, and multiple themes possible, this seems to be significant logistical overhead.

Because each webform can be quite different, but the default messages you're using are uniform, this almost necessitates theming each form (potentially).

Let me know if I'm wrong here about the use of theming. It just seems like custom messages per webform is a cleaner way to go from the admin-experience perspective, and not duplicating the real reason that the theme system exists.

willdashwood’s picture

willdashwood commented

I second mgenovese. I wanted to be able to completely hide "You have already submitted this form. View your previous submissions" so I had to open up the module and comment out that bit of code.

quicksketch’s picture

quicksketch
he/him
commented

Once again, you need to take into consideration the flexibility Drupal offers you directly. There's no need to edit (hack) the module.

- Copy the "theme_webform_view_messages()" function from webform.module to your template.php
- Rename to "[name of your theme]_webform_view_messages"
- Change or comment out any messages as necessary.

willdashwood’s picture

willdashwood commented

Yep I would normally do that but if there are any changes to those functions I'll probably miss them as I'll no doubt forget I've overwritten the function in template.php. Neither method is good which is why I think the feature is worth adding.

budda’s picture

budda
Primary language English
Location Cheshire
commented

Using the theme function it great for true flexibility. But like @willdashwood says, as a module version updates I often forget i've overridden theme functions in template.php and overlooked them during a module update.

This bit my bum recently when updating webform module and the email template function was sending out empty emails.

vannus’s picture

vannus commented

site editors might want to create their own webforms - and thus email responses.

having them dip into php which they dont know anything about isnt a popular option.
(designers like us know php, but often others dont)

#329069: Outgoing emails should be editable using "Mail Editor" sounds like a good way to achieve this.

quicksketch’s picture

quicksketch
he/him
commented

You can already edit all e-mail responses in 2.x through the template layer (yes, PHP), and in the 3.x version through a UI (no PHP).

vannus’s picture

vannus commented

ooh :) and 3.x is meant to have views integration too, isnt it?

any idea when 3.x will be stable enough for production use?

quicksketch’s picture

quicksketch
he/him
commented

Considering Webform is just barely staying afloat (see #604930: Webform Needs Another Maintainer), probably not for a while. :-(

vannus’s picture

vannus commented

version 3.x has only 5 critical issues, and only 2 of them are 'release preventing'.

it may be a bit of a cheat - but if the 2 issues are sorted & tested for a bit, you could release 3...

then posting on all the 6.2 issue to upgrade to 3.x (in a test environment of course!) to check if they're issue is resolved - as you have done here. if the issue also exists in 3.x, they should update the issue to reflect that.

after a quick look around, i think doing this would clear some issues (like this one).

ill go up to 3.x - let me know if you want to go ahead with above suggestion, if you are, ill have a look at some of the existing issues and post 'fixed in 3.x' for issues that look ok in 3.x

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Closed (won't fix)

You can either theme your responses or use String Overrides. Customizing all response text is outside the scope of any module.