The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.First of all - great module! But I have some ideas on how we could make it even better for the 6.x-2.x and 7.x branches.
Right now if we schedule hundreds of nodes on a given time, that won't perform well during cron with node_load() on every node. The risk of time out etc. will be big. But if we can choose to rely on Job Scheduler that would solve a lot of scaling problems. This would allow us to use the Queue API which is an optional dependency for the Job Scheduler. That way one could set up multiple server workers working of the queue without any performance or scaling problems. The queue workers can also work on the queue with a much higher frequency than would be practically possible with hook_cron() (taking into account that hook_cron clears the cache every time it runs etc.). This would allow for (un)publishing with almost no time delay. The downside of this is that it adds a dependency on the Job Scheduler, but could be optional which would allow for better scaling when needed.
I'd gladly join as a co-maintainer starting this work in the 6.x-2.x branch doing parallel development in the 7.x branch.
The reason for me bringing this up is because I love the module and we have an upcoming client that would suffer from scaling problems scheduling hundreds of nodes at one given time.
[-- other idea in original post, which is not currently being considered --]
I think it would be great to simplify things a bit. If we made the Scheduler module depend on the Date module that would allow us to strip out the storage part to one common place (CCK field storage) also taking advantage of the great Views integration that CCK and Date module already provides. Less code to maintain and we rely on already widely used modules. Another great benefit from this is that we get more flexibility on how we can build the node form and display the publishing dates etc.
Comments
Comment #1
bartezz commentedNice ideas! I myself haven't had problems with scalability but understand there could be a prob. So optional dependencies are nice to fix that part.
Don't have any problems with cck and date dependencies at all. Never ran a site without those modules.
Would be cool to see al this in a 2.x branche!
Cheers
Comment #2
dixon_Yeah, and we already have an optional dependency on the Date module for the Date Popup thing. So why not go all the way? :)
Comment #3
eric-alexander schaefer commentedThere is a reason why the dependency on date is optional.
Check out #550548: Date/Time example text does not respect the time zone. This really simple fix was posted a year ago. I has since been verified by lots of people (see the followups). It still is not incorporated into the module. I do not like the idea of depending on such a module. There are also other issues with date, which can not be resolved easily (#601814: Incompatible with Multistep, which prevents the simultaneous use of scheduler, date_popup and multistep). If it wasn't for this problems I would happily use date and remove all the date/time handling code from scheduler.
I actually believe that date should be a core module and should receive all the love core module enjoy. Date handling is far too important in a CMS to leave it to individual modules.
Did you know that job scheduler is still beta?
Comment #4
dixon_Ok. I can see the reasoning behind choosing not to depend on Date. Makes sense!
Yeah, I know job scheduler is in beta. But I still think an optional dependency on that module would bring us functionality that we otherwise have to duplicate in order to solve the scaling/performance issues I talked about.
Comment #5
eric-alexander schaefer commentedThe should be a date field in D7 core as I was informed. So that clears out some of the mentioned ideas. Also with D7 php5 is required which will make some of the date handling functions obsolete. I want to get the next 6er release out of the door after the holidays (like maybe on monday). After that I want to take on the D7 support. All new featured will then be implemented in D7. There will be backports of all new D7 featured to D6 (maybe in a 2.x branch).
Right now I will set a new title for this issue to reflect a worthwhile feature request, but I will also postpone it until we get some other stuff sorted out...
Comment #6
jonathan1055 commentedAre there any users who would like it if we had Scheduler more scalable as suggested, so that hundreds of nodes can be published simultaneously? I would say that if you have that many nodes, you would be using Schedulers Lightweight cron to allow lots of runs, and also you can use Views Bulk Operations to schedule many nodes in one operation.
This issue has been sitting here for over three years, so either we decide to work on it now, or I will close it.
Jonathan
Comment #7
jonathan1055 commentedJob Scheduler has a large customer base - 90,000 installs at 7.x and 10,000 at 6.x even though they are still at alpha/beta versions and not full releases. Queue API module only has a D6 version and under 2,000 installs. In D7 the queue functionality is in core
Moving this issue from Scheduler 6.x to 8.x as the discussions should happen there first. The changes certainly wont be implemented for 6.x
Comment #8
pfrenssenI don't think we need this. We don't need Job Scheduler since our scheduling is very simple. Queue API is in core since D7 but queuing items to be processed later goes against the primary purpose of this module: (un)publishing at a certain time. If we queue, it might be delayed to a later time, that wouldn't be good.
Reading back through the comments, this seems more like this issue was created to brainstorm a few ideas out of a desire to play with shiny new stuff. Nobody is mentioning an actual problem that needs to be solved. The use case from the summary was hypothetical.
I'll close this for now, if an actual need arises we can still reopen.
Comment #9
jonathan1055 commentedI agree, and thanks for looking at it though, via your work on 8.x. Good to close this.