Is there a solution to limit the number of submissions for a webform, in total not per user.

I'm using the webform as a volunteer sign-up sheet. And only can accept x number of people.
I want to be able to set on the form to only accept 10, 20, 100, etc. submissions and then lock.

Any ideas? If not I would like to kindly ask for a feature request.



Members fund testing for the Drupal project. Drupal Association Learn more


aichfeldjugend’s picture

are the volunteers all registered users?
or can anonymus users also sign up for whatever you use the webform?
in case 1: we need a developer
in case 2: enter the number of Submissions per User and set the access of the webform to "Anonymus User"

in hope that this will be useful

gintass’s picture

case 2 doesn't work (at least with the 6.2.9 version of the webform). I tested from my computer and it seemed to work, but when I opened registration to real users they were all coming from different computers with different IP addresses and they were still able register above the limit. Registrations didn't close automatically when the limit was reached. Only if everyone would use the same computer, above suggested "case 2" would work.

I found a better solution (php snippet) which does work:

quicksketch’s picture

Version: 6.x-2.7 »

Moving this to the 3.x version. This might be a good long-term feature to add, even though it's already possible to emulate this functionality with the Additional Processing code. See also #260989: Limiting the max number on a per form basis, not per user basis.

quicksketch’s picture

Title: Limit the number of submissions » Limit the total number of submissions
freakalis’s picture

Priority: Minor » Normal
Status: Active » Needs review
8.65 KB

I also need this feature because im using webform as a way of signing upp for an event. And the event has a limited number of seats.

I made this patch that adds a setting to webform settings if it should limit submissions per user or per total submissions.

I also has a new field (also at webform settings) where you can enter a custom messge if the the submission limit has been exceeded.

It needs two extra columns in the database to store this new info so I also made an update function to add these.

quicksketch’s picture

Status: Needs review » Needs work

Thanks for the patch freakalis. Adding the total limit is great but the addition of a custom message when the limit is exceeded should probably be split out into a different issue. We don't provide any other customization of messages, and I'm not sure we should purely because of the number of messages that Webform outputs. If you'd like to customize the message, you can use String Overrides module or you can override the theme_webform_messages() function.

If you want to tackle customized messages, let's handle it in #279703: All response text should be configurable and keep this one focused on just adding the options to limit the total.

freakalis’s picture

Version: » 6.x-3.0-beta2

I agree with you quicksketch. They are two separate issues. I have attached a new patch that just deals with the total submissions.

The reason i added the customizable limit text was because the default text says: You have submitted this form the maximum number.....
This is no longer true when it's the total submissions that counts. Better to say that the Form as been submitted this form the maximum number of.... etc

But also so you could have different limit texts for every form. Im using webform as a registration for events. If it become overbooked i would like to say something like, Please contact XXX to be on the reserve list or More slots will be available at XXX.

freakalis’s picture

And the patch :)

quicksketch’s picture

Looks pretty good, though just because there isn't a customizable message, it does make sense to create a new message that makes more sense. Rather than "You have submitted the maximum number of entries", something like "This form has received the maximum number of entries.", since it's entirely likely that a user would get the message even if they'd not submitted anything at all.

This change will also cause problems:

-    // Disable the form if the limit is exceeded and page cache is not active.
-    if (($limit_exceeded = _webform_submission_limit_check($node)) && ($user->uid != 0 || variable_get('cache', CACHE_DISABLED) == CACHE_DISABLED)) {
+    // Disable the form if the limit is exceeded.
+    if (($limit_exceeded = _webform_submission_limit_check($node))) {

We MUST show the form to anonymous users if the cache is enabled to avoid the following situation:
- Anonymous user submits the form (limit of 1 per user).
- The anonymous user then gets the "You have submitted the max" message. The form is not shown.
- If the page cache is enabled, the page may get cached with the form not shown.
- Other anonymous users visit the page, but cannot see the form because some other anonymous user made a submission.

freakalis’s picture

Okey, in the normal limit submissions the cache check should stay. But when the limit is per webform it should not care about the cache. Because we don't wan't to show the form if they aren't able to submit it. Then we would like to show the "This form has received the maximum number of entries." even for cached/anonymous users.

If someone increase the submission limit in the webform the old cache would be cleared. Or am I still missing something :)

quicksketch’s picture

Yep, sounds perfect.

freakalis’s picture

New patch according to post 9-10.

New error message when using total submissions limit: This form has received the maximum number of entries.

malhadeff’s picture

We had a similar issue. Form users could select a particular time and date, but we could only allow 150 people to select each time and date. We dealt with it by using this in Validation (where "424" was the node id of the form and "18" was the cid of the form element and "150" was the maximum number of submissions for any particular value of the form). It gets the job done:

$sql_query = db_result(db_query("SELECT count(*) FROM webform_submitted_data WHERE nid= 424 and cid= 18 and data='%s'", $form_values['submitted'][18]));

if ($sql_query > 151) {
    $err_mess = " Sorry, no availability on " . $form_values['submitted'][18] . ". Please try another date/time.";
    form_set_error('a', $err_mess);
span’s picture

This looks very interesting indeed but the patch fails on the last beta version. Will this be implemented anytime soon? I'm afraid I can't contribute much due to lack of time.

quicksketch’s picture

Version: 6.x-3.0-beta2 » 6.x-3.0-beta6

This patch is pretty good but has some problems. The UI needs a bit of work too. Rather than using a checkbox for "Do not limit submissions per user. Limit by total submissions", it would make more sense to have this as a textfield. Since it's entirely common that there would be a limit of "1 submission per-user" AND "100 submissions total". With the current approach it's one or the other.

anon’s picture

Version: 6.x-3.0-beta6 » 6.x-3.6
6.24 KB

Almost the same as #12, but this one if for 6.x-3.6

redonwhite’s picture

Priority: Normal » Major

This patch seems to be working, but I have two remarks:

  • I agreee with #15 that there should not be a choice of limiting submissions either per form (total submissions by everyone) or per user. Instead, it should be done so that both options are available at the same time, since indeed it's a common scenario to have 1 submission per user AND a maximum of X submissions
  • it seems that right now the form is being closed upon first unsuccessful submission, instead of being closed on the last successful submission. this needs to change, since it frustrates the unlucky last user, who fills in the form but doesn't get the form submitted.

I think that many people here are using webforms for signups, so it's fair to move this to major priority, esp. given that it doesn't seem like a very big thing to implement?

redndahead’s picture

Version: 6.x-3.6 » 6.x-3.x-dev
Status: Needs work » Needs review
11.08 KB

Here is a version that will limit the total number of submissions the same way as it does by user. If a user is in a form while the limit has been reached after the user submits the form it will tell them the limit was reached while they were filling out the form.

reaneyk’s picture


goose2000’s picture

Title: Limit the total number of submissions » subscribe


Where is the dev version? I can't find it on the module page?

quicksketch’s picture

Title: subscribe » Limit the total number of submissions

@goose2000: Click "View all releases" on the project page. Note that the dev version doesn't have this feature either, you have to apply the patch in #18 if you'd like to try it out.

goose2000’s picture

Gotcha, thanks. I realize I need a different limit functionality though. I need a kind of select list where the options could have a limit set on them (sessions A,B,C). Each could be used up say 20 times. When 20 of A are submitted, that option is disabled or hidden. User would be forced to choose B or C.

Any thoughts on that? Probably should start a different issue ticket.

goose2000’s picture

I still can not find a version of 6.x-3.x-dev on the "view all releases page", MIA.

EDIT - found it here:

quicksketch’s picture

Any thoughts on that? Probably should start a different issue ticket.

Such complicated validation functionality sounds like it would be a better feature request for Webform validation than Webform itself, if they don't have a similar request already.

mdpenguin’s picture


span’s picture

There is now also a module that does this,

We migrated our old patched webform to use this module instead. It is still a bit rough in the edges (code?) but seems to work fine.

For anyone interested, this was how we made the migration.

  1. Install the module
  2. Move the data with the following statement:
    INSERT INTO webform_limit_submissions (nid, sid)
    SELECT webform.nid, webform.submit_limit
    FROM webform WHERE webform.submit_limit_total = 1
  3. Reset the limits on the forms with the following statement: UPDATE webform SET submit_limit = -1 WHERE webform.submit_limit_total = 1
  4. You can now remove the extra submit_limit_total and (submit_limit_text?) fields from the webform table
  5. Check to make sure migration was smooth with the following statement, count should not be higher then sid:
    SELECT wls.nid, wls.sid, submissions
    FROM webform_limit_submissions wls
    LEFT JOIN webform w
    ON w.nid = wls.nid
    LEFT JOIN (SELECT wss.nid, COUNT(*) as submissions FROM webform_submissions wss GROUP BY nid) ws
    ON wls.nid = ws.nid

In our migration we ran into a problem when updating webform from 6.x-3.6 to 6.x-3.11. For some reason the 'auto_save' field was never created in the webform table. This is another issue of course and I've seen it mentioned in the issue queue but do watch out if you are coming from an old version of Webform.

The symptoms of the problems where that when adding components to a webform they would be created in the DB but would not show up on screen. In turned out the form was never created in the webform table, probably due to missing the auto_save field. There was never any error messages though.

vernond’s picture

@span - I've done a bit of work with the webform_submission_limits module (see and would love it if you take a look and let me know what you think in that issue.

redndahead’s picture

11.24 KB

I still think this could/should go in the webform module itself. Here is a re-roll of the patch in 18.
@quicksketch you think that this has a chance of going into webform? or do you think it's better left up to contrib?

redndahead’s picture

11.3 KB

Fixes white space that I thought I had already fixed. grr.

Lion.creek’s picture

Hi, sorry for the stupid question. Where insert php code for validation? Thanks
Sorry I know

vernond’s picture

Please don't mix issues in one thread, rather open a new one. Better yet, first search to see if your question has been asked and answered before.

Webform no longer supports inserting php code as it used to. This is in line with a movement across all of Drupal to phase out such fields. You may either make use of the unsupported Webform PHP module (use at your own risk), Webform Validation module, or create your own custom module (see webform_hooks.php).

retiredpro’s picture

@redndahead. I applied your patch from #29 to the latest release of webform 6.x-3.14 from august 31 and I get the following error on the site.

Fatal error: Cannot redeclare webform_update_6329() (previously declared in /var/www/ in /var/www/ on line 1520

I used the latest stable release instead of the dev version because it was updated more recently. I also tried the latest dev version but I received the same error. Any ideas?

redndahead’s picture

You need to make it one higher than the last update number in install.php. So right now the last update number is 6329. So in my patch it should be 6330.

retiredpro’s picture

thanks for the quick reply, redndahead! that fixed it for me.

redndahead’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
11.53 KB
11.25 KB

Here is an updated patch for 6.x-3.x and also a patch for 7.x-3.x

redndahead’s picture

11.5 KB

Of course what patch of mine would be complete without whitespace fixes.

quicksketch’s picture

Status: Needs review » Needs work

This patch looks great! The only problem I see is that this segment is located in the wrong location:

+  // Check if the total number of entries was reached before the user submitted
+  // the form.
+  if (_webform_total_submission_limit_check($node)) {
+    // Show the user the limit has exceeded.
+    drupal_set_message('While you were filling out the form the maximum number of submissions has been reached.', 'error', FALSE);
+    return;
+  }

Right now it's in webform_client_form_submit(), when it should be in webform_client_form_validate() with the other validation of the per-user limit check. Other than that, these look good to go.

quicksketch’s picture

Oh I'm also concerned about this change (technically an API change):

-    theme('webform_view_messages', $node, $teaser, $page, $submission_count, $limit_exceeded, $allowed_roles, $closed, $cached);
+    theme('webform_view_messages', $node, $teaser, $page, $submission_count, $limit_exceeded, $total_limit_exceeded, $allowed_roles, $closed, $cached);

Really we shouldn't be making API changes like this mid-release-cycle. However it only affects Drupal 6 (D7 uses an array of arguments), and this function isn't often overridden afaik. I'd like to keep the change as-is for code-consistency, but I'm certain I'll get some flak from users in the future for it. So in advance of all the complaints: I'm sorry for breaking your theme overrides.

This change is an overall benefit that it is worth the change to me. Users will get an error upon upgrading when submitting a form that an argument is missing, so at least this won't be a silent problem.

redndahead’s picture

13.02 KB

Can we check this before I do the d6 patch?

redndahead’s picture

12.37 KB

Forgot to delete the old code.

quicksketch’s picture

Looks pretty good. In the existing code, we just let theme_webform_view_messages() print out the error message. Although your existing error message may be more descriptive, for consistency just reusing the same error message may be better. Also in the case of anonymous users, the limit may have been hit long before they even started filling out the form due to page caching.

We might also find a teeny performance gain by putting the "total" check before the "per-user" check, since it's more likely the the total limit will be hit before the per-user check (maybe... I'm just assuming here).

redndahead’s picture

12.62 KB
12.93 KB

Here are d7 and d6 patches with your suggestions.

redndahead’s picture

Status: Needs work » Needs review
quicksketch’s picture

Thanks @redndahead. I reviewed these and only found a few minor changes to be made:

- The total submission limit message wasn't working the D6 version of the patch (it was still using D7-syntax for calling theme functions with an array).
- There was a notice error when viewing forms of undefined variable $total_limit_exceeded.
- I moving the "total" limit above the "user" limit, as I think it makes more sense that way.
- I changed the text on the existing limit to differentiate it from the new limit. They now read:

Total submissions limit:
(•) Unlimited
( ) Limit to [     ] total submission(s)

Per user submission limit:
(•) Unlimited
( ) Limit each user to [    ] submission(s)

Now that we have two options, I think that checkboxes might be more appropriate than radio buttons. Previously I'd used radio buttons to line up with the other available options. Now however, the "Unlimited" option is confusing when combined, such as "Unlimited" per-user submissions combined with "3 ever" total submissions, obviously the per-user limit isn't really "unlimited" any more. I'm sure users will figure out easily enough, but the text is misleading.

We also have a bit of cleanup to do after this patch to make our variables and function names make sense. I don't like _webform_submission_limit_check() being per-user, it should be renamed for consistency with _webform_total_submission_limit_check().

Anyway, such cleanup tasks can be separate. This is good enough for inclusion.

quicksketch’s picture

Status: Needs review » Fixed

Committed to both 3.x branches.

redndahead’s picture

@quicksketch thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

nackie’s picture

Component: Miscellaneous » User interface
Category: feature » support
Priority: Major » Normal
Status: Closed (fixed) » Active


I was checking out the patch at #44 and was wondering if there is a possibility to limit the submissions based on the date? So, say you have a date component on the webform and there's already been a submission for that specific date, it should not allow any further submissions. The limit per day won't work in this case, as you could be filling in forms for different dates.



quicksketch’s picture

Category: support » feature
Priority: Normal » Major

@nackie Let's keep this feature request closed. I feel like your question may be a better request for than the core Webform module.

quicksketch’s picture

Status: Active » Closed (fixed)
nackie’s picture

Priority: Major » Normal

@quicksketch - no problem, I'll post it there then.