For a project I am working on I need to (un)publish nodes using a field different from {node}.status. I have been able to manage almost everything I need through hook_nodeapi(), but I can't make Scheduler work as the query performed in scheduler_cron() cannot be altered and the node having status 1 but "custom status" 0 are not selected.
It would be really useful if scheduler_cron() were refactored so that its code were reusable.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | scheduler-988210-2.patch | 4.08 KB | plach |
| #1 | scheduler-988210-1.patch | 4.46 KB | plach |
Comments
Comment #1
plachHere is a patch that performs the refactoring. The logic should be unaltered.
(FWIW the custom module I'm working on aims to fix Book's inability to handle unpublished nodes without patching D6 core.)
Comment #2
plachThis is a patch for Scheduler 6.x-1.7, the patch to review is #1.
Comment #3
eric-alexander schaefer commentedThere are some problems with this approach: Although your module will call this functions there will be a log entry saying scheduler did that. There might even be a scheduler revision log. Also the
hook_scheduler_apiwill be invoked which might not be what either your module or the modules implementing that hook want to happen. Why don't you just fire the 'node_publish_action' and 'node_save_action' for your nodes?Comment #4
plach@Eric Schaefer:
Well, the idea is to execute a cron job exactly as if Scheduler was performing it, so the watchdog entries and API hook invocations are what we want. Otherwise we'll be forced to copy the code in
scheduler_cron()and just change the queries.Comment #5
eric-alexander schaefer commentedOK. Could you please explain why you want to that? I am trying to understand your motivation.
Comment #6
plachSure, and thanks for your time :)
We are trying to build a module working around #26552: Allow users with access to unpublished nodes to create unpublished books. After trying various approaches requiring to patch D6 core, we decided to go for a full-contrib solution: basically the idea is making book nodes always have status 1 (in order to make core queries to work as intended) and instead granting access to them using a custom status field, which does not interfere with core queries. We managed to make almost everything work as intended, but we are lacking Scheduler integration: as I was writing previously, one option we have is copying
scheduler_cron()code and changing its queries, the other one is what I proposed in #1.Comment #7
eric-alexander schaefer commentedWouldn't it be much more useful if scheduler provided a hook for custom queries. Something like
hook_scheduler_publish_query()andhook_scheduler_unpublish_query()which either return a query string or a list of nodes to operate on? Or maybe something likehook_scheduler_cron_query($op='publish'), which would support future scheduler operations.scheduler_cron()would do it's own query and then call all implemented hooks and work those nodes.How about that? I actually like that idea. I do not like the idea of exposing
scheduler_publish()because then it becomes a liability. Whenever I would try to change it, it could break another module. With my approach above scheduler would ask your module which nodes it wants published, but keeps the function private. The inner workings ofscheduler_publish()might change anytime, but a list of nodes always stays a list of nodes.Comment #8
plachYes, this could be a viable solution either. Do you want me to write down a patch or do you prefer to do it yourself?
Comment #9
eric-alexander schaefer commentedI'll do it myself. Sounds like fun... :-)
Comment #10
eric-alexander schaefer commentedHere you go:
http://drupal.org/cvs?commit=461908
http://drupal.org/cvs?commit=462060
Comment #11
plachThank you! Now I'm a little bit distracted, but I'll have a look to this ASAP.
Comment #12
eric-alexander schaefer commentedComment #13
plachYes, this is fixed. Sorry for the delay. If I'll find any drawback I'll open a new issue.
Thanks!