For some reason, the timestamp of the revision which is created by scheduler (publish or unpublish action) is set to the previous revision changed date instead of the current time.
I spotted these duplicated timestamps because I use some custom code to add the possibility to clone node revisions in the backoffice, and it uses the timestamps to make a mapping between revision number and timestamp (needed to clone fields revisions tables). Anyway I added a check for doubles so it's really not a blocking issue for me anymore but still it is odd that scheduler adds duplicate timestamps (new revisions are created from previous changed date instead of current time, as stated above).
So here is a patch to correct this behavior.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3007266-5.scheduler-revisions-timestamp-update.patch | 6.6 KB | jonathan1055 |
| #5 | unpublished.png | 61.91 KB | jonathan1055 |
| #5 | published with touch option.png | 70.22 KB | jonathan1055 |
| #5 | published without touch option.png | 72.67 KB | jonathan1055 |
Comments
Comment #2
jonathan1055 commentedThat's interesting. So is it right that it is our responsibility and we have to set the timestamp in Scheduler's code?
Comment #3
b2f commentedWell as I said it is not a blocking issue, but I was mislead by it while debugging some code.
So I suggest it would be best for clarity sake.
Comment #4
jonathan1055 commentedThanks, yes I agree that revision timestamps should not be duplicated. I was just wondering the proper way to correct it.
Comment #5
jonathan1055 commentedI have improved the log message to give more information. Now that we have the proper revision timestamp we don't need to give the current time in the message, but instead can give the scheduled time. (this is useful if there is a long delay after the scheduled time before cron is run). Also it was confusing to give the previous creation date if the 'update creation date' optoin was not set. The date has not changed, so why would you say "previous date". This info is added as an extra only if that option is set.
For unpublishing, the 'old change date' is unnecessary and has been removed.
Comment #6
jonathan1055 commented@B2F let me know if you think the revision log messages are OK. See the screen grab in #5
Comment #8
jonathan1055 commentedActually I decided to commit the changes anyway. But tell me if you have suggestions on improving the log messages.