...very surprised not to find the word "repeat" or "rotate" in any of the issues for this module. The prospect of having certain content published on a repeating or rotating schedule just seems so natural...

  • You want some reminder up throughout the day on Mondays (every Monday but only on Mondays).
  • Put up the notice about the monthly meeting for the 1st week of every month.
  • Put up the holiday banners every fall.

Trying to do this with Rules or some type of trigger is very complicated. Some Views contrib can rotate content but it's really only for slide shows and the like...

Since Scheduler is already picking dates in a standard way, how hard would it be to support repeating dates?

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


jonathan1055’s picture

A simple version of this could be done in scheduler, but whether it gets added depends on how well it fits with the rest of the scheduler code and whether we view it as an essential part of scheduling or just another 'great to have' option (there are lots of them already :-)

I could visualise how it could be done using a simple repeating pattern eg set the usual 'publish on' date & time and specify a number of hours or days for the repeated publication. You would likewise set an 'unpublish on' date & time but the same 'repeat duration' would be used. The repeat value could be added into the scheduler table as a simple number. Then during the cron run which does the publication, if a repeating value was given then a new row would be inserted into the scheduler table (or the existsing row could be updated) calculating the new date from the date just used. Likewise on unpublication. The difficulty would be in allowing things like 'every 1st of the month' because this requires more information to be stored in the scheduler table to allow the next publishing date to be calculated.

An alternative would be to allow multiple rows in the scheduler table, which would be inserted at the node editting time as is done currently. This has the benefit that the 'until' date could be specified and then all the events would be added to the table at one time. There would probably have to be a few tweaks to the logic in the cron function but that should not be too difficult.

So it comes down to whether other users, and more specifically the maintainer Eric, think that this is a useful addition to scheduler. This functionality is common in other calenders and mail programs, so it may well be good to include it.


videographics’s picture

Issue tags: +date API, +Date Repeat API

I think a lot of the code needed to do this elegantly is already available. The Date module (http://drupal.org/project/date) has a Repeat API for creating a form element that will allow users to select repeat rules (any possibility imaginable) and store those selections in an iCal RRULE string. I imagine that this could be adapted to have the Scheduler module present the repeating form element and then store the rrule for its own purposes. Once the rrule is stored, Scheduler could then parse it to determine if the node should be published or not as an alternative to using the dates that are currently set manually.

The Date Repeat API also has a calculation function that will parse the RRULE and return an array of dates that match those rules. This could also be adapted for use in the Scheduler to help it determine if the node should be published or not.

Personally, I think this is a feature that would be accessible for non-technical users so it could end up seeing very wide adoption. I can imagine myriad applications for this but let me put it this way: Am I the only one that thinks that automatically publishing and un-publishing the "Happy Holidays" message on the site every winter is an edge case application? Have you actually tried setting that up that kind of thing using Rules?! Ugh.

My primary application for this right now is that I need to remind clients of upcoming annual events and holidays to promote seasonal purchases, so I want to set a schedule for each one and have the ones that are currently relevant appear on the home page. Currently there's no out of the box solution for doing anything like that.

I'm curious to hear others' thoughts on this...

klonos’s picture

I could also use this. For example publishing specific nodes only on certain dates (Xmas, New Year, Valentine's day etc.).

The Date Repeat API also has a calculation function that will parse the RRULE and return an array of dates that match those rules.

If this feature request is accepted & finally implemented in this specific way, there should also be a way to allow users to set a start date and an end date (so that the array isn't endless).

klonos’s picture

Version: 7.x-1.0-rc3 » 7.x-1.x-dev

...btw, feature requests go against the latest dev of the most recent branch.

videographics’s picture

#3: ...sounds good. I think that being able to publish and unpublish around the same holiday day(s) each year would be especially useful.

#4: sorry. of course...

cockers’s picture

I'd love this functionality, it's exactly what I'm looking for as I'd like to add an ubercart product to my drupal site that is only on sale at certain times of the day during the working week. Is it likely that this could happen?

cockers’s picture

I just realised that this is for Drupal 7... I use Drupal 6, not 7, but don't want to flood your issues table by making a new request for Drupal 6.

klonos’s picture

Hey Mark, don't be frustrated. New features are almost always filed against the latest branch (currently 7.x), but provided that a project's 6.x branch is still maintained these features have a chance of being back ported. If I were you though, I'd be looking to upgrade to D7 anyways ;)

cockers’s picture

That's good to know thanks :)

jdonson’s picture

Hello Fellow Drupal Folks,

Please update me as to the 6.x and 7.x progress of this 'repeating event' feature of Scheduler.

I can imagine a database column defined as an enum with varied date spans,

repeat ENUM('none', 'daily', 'weekly', 'monthly', 'quarterly', 'yearly'),

Where would this appear in the scheduler php code and where would the ui element code lie?

I would be willing to help. Thank you.

Anybody’s picture

Great feature request, keep me up to date :)

chefnelone’s picture

Issue summary: View changes

This is a very important feature to be added. I'll be tuned too!

alibama’s picture

i feel like this could probably be done cleverly with rules scheduler, but doing it in a general way with the repeat api would make more sense....

morsok’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev

Any plans to add this feature ?

sallakane’s picture

I created a recurrence system based on the days of the week.
Basically, if recurrence is enabled (check box just at the bottom of schedule screenshot1.png), I display the days of the week (screenshot2.png).
Then cron will test between the date of publication and unpublishment, and verify if one is in a day checked.

NB: I had to remove the date of publication from NULL after it is exceeded, in this system we keep the dates of publication and unpublishment in all cases. Then in the cron I include in the entityquery the status (example if I want to publish, I only retrieve nodes with status TRUE etc ..)


sallakane’s picture

woprrr’s picture

Status: Active » Needs work

Just a little regards into this patch :

  1. +++ b/scheduler.module
    @@ -201,6 +204,40 @@ function scheduler_entity_base_field_info(EntityTypeInterface $entity_type) {
    +      ->setLabel(t('Recurrence'))

    You should user $this->t() instead t() usages. @see StringTranslationTrait if you haven't $this->t() already here.

  2. +++ b/src/Plugin/Field/FieldWidget/SelectWithCheckboxesWidget.php
    @@ -0,0 +1,77 @@

    Unused white break.

  3. +++ b/src/Plugin/Field/FieldWidget/SelectWithCheckboxesWidget.php
    @@ -0,0 +1,77 @@
    +    if ($form_state->getValue('recurrence')['value'] == TRUE) {
    +      foreach ($form_state->getValue('days') as $day) {
    +        if ($day != FALSE) {
    +          $error = FALSE;
    +        }
    +      }
    +      if ($error == TRUE) {
    +        $form_state->setError($element, t('No day checked, or uncheck recurrence'));
    +      }
    +    }
    +    if (is_array($element['#value'])) {
    +      $values = array_values($element['#value']);
    +    }
    +    else {
    +      $values = [$element['#value']];
    +    }

    You can simply a lot the complexity of that.

  4. +++ b/src/SchedulerManager.php
    @@ -76,131 +76,149 @@ class SchedulerManager {
         $dispatcher = \Drupal::service('event_dispatcher');
    +    $lock = \Drupal::lock();

    You shouldn't use that directly for better mockability you need to use injected services instead of \Drupal::

  5. +++ b/src/SchedulerManager.php
    @@ -76,131 +76,149 @@ class SchedulerManager {
    +        $query = \Drupal::entityQuery('node')

    Similar problem use injection.

  6. +++ b/src/SchedulerManager.php
    @@ -216,131 +234,156 @@ class SchedulerManager {
    +    $lock = \Drupal::lock();


  7. +++ b/src/SchedulerManager.php
    @@ -216,131 +234,156 @@ class SchedulerManager {
    +        $query = \Drupal::entityQuery('node')


That would be better if we can purpose a Tests too. With lot changes we need to bu sure all is ok.

@sallakane you do switch issue to need review to play tests of module with your patch.

sallakane’s picture

Hi @woprrr, thank you for your review.
I'm looking at this, and I'm trying to fix it all.


jonathan1055’s picture

Status: Needs work » Active

Hi sallakane and woprrr,

Thanks for your input on this. The patch is big, 829 lines, so you definitely need to run our automated tests. When you upload a patch and set the issue status to 'needs review' the tests will be run automatically.

If we were to add the repeating functionality, however, I think it would need to be generic (see the discussion in #2, #3 and #10 above). Your work only covers days of the week and involves a lot of hard-coding. I don't think this is the direction we would go for Scheduler - we want be able to re-use a generic date-repeat rule somehow, rather than cater for each type of repeat via new long-hand code.

I don't want to put you off doing this coding work and having fun with enhancements for Scheduler, but I do want to warn you that with your current design it is unlikely to make it through and be committed. :-)