Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Because there is not "never" option, user often try to put there something big enough like 1000, but in this case DB fails by error like this:
PDOException: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'field_datetime_value' at row 653: INSERT INTO {field_data_field_datetime} (entity_type, entity_id, revision_id, bundle, delta, language, field_datetime_value, field_datetime_rrule) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7), (:db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15), (:db_insert_placeholder_16, :db_insert_placeholder_17,
...Could you add some suitable validation rule? Something big enough, but something that works.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | date_repeat_form.inc_.patch | 1.59 KB | glnielsen |
Comments
Comment #1
glnielsen CreditAttribution: glnielsen commentedIt would be nice for the site administrator to be able to limit the number of repeat occurrences which can be entered and restrict how far into the future the repeat end date is.
This can be a major performance issue, possibly bringing a drupal site down, if someone with permission to create calendar events set either of these values to large.
Comment #2
glnielsen CreditAttribution: glnielsen commentedHere is a patch with hardcoded limits of max 50 occurrences or repeat date no later than 3 years from today.
This should help prevent any scaling problems from misuse of Stop Repeating.
It would be nice if someone could make those two values configurable in the admin interface.
Comment #3
klonos...or instead of hardcoding a specific limit we could only create the first few occurrences and let the rest be created over time during successive cron runs.
I mean, 50 (or 100 to be safe) repeats makes sense for annual things like birthdays, but what about monthly or weekly or even daily repeats?
Comment #4
glnielsen CreditAttribution: glnielsen commentedI totally agree. I just needed something that would work now to keep contributors from creating a recurring event that brings the server down.
Provided the patch so others could do the same until some more elegant solution is developed.
Comment #5
klonosThis could be classified as a feature request titled: "Create only a minimum amount (TBD) of repeats and set the rest to be created on successive cron runs"
Comment #6
Honza Pobořil CreditAttribution: Honza Pobořil commentedklonos: True, it sounds much better fot the feature.
For now we need to have some quick provisional fix: #2051033: Possible performance/security issue with repeating field if a large amount of values is defined.
Comment #7
vijaycs85guess [#2051033]trying to answer the same problem. One thing missing #2051033: Possible performance/security issue with repeating field if a large amount of values is defined. is the cron job to run/add further repeats. Again, I'm not very sure about how this implementation works for all scenarios(i.e. few sites might be running without cron). But we can update #2051033: Possible performance/security issue with repeating field if a large amount of values is defined. with cron change and close this issue as duplicate.
Comment #8
DamienMcKenna