The steps to reproduce this are admittedly rare, but I see the value in reporting this in case if affects other versions. It's also best explained with a scenario:

  • Server cron scheduled for 30 minutes past every hour
  • Create a node and set "Publish on" for "4/5/2012 12:00pm"
  • At 12:05pm, user notices that the node is not published. Try to edit on the node edit page (node/1234/edit) and check the "Published" box and Scheduler correctly will not let you publish because "4/5/2012 12:00pm" is now in the past
  • Go to the content list (/admin/content/node/overview), check the node, and choose "Publish" from "Update options"
  • Node is now published, and Scheduler still has the "Publish on" date set for "4/5/2012 12:00pm" which is now in the past
  • Try and edit any part of the node at "/node/1234/edit" and Scheduler will tell you that the date/time is in the past
  • Cron runs at 12:30pm, but because the article was manually published, no action is performed and "4/5/2012 12:00pm" is still the "Publish on" value

I understand how this happens, because publishing from "/admin/content/node/overview" likely just edits a simple value in the database, bypassing the error-checking that Scheduler has in the node edit page. The only workaround that I can think of (other than asking the user not to publish stories this particular way) is to add an operation to the cron hook for Scheduler to check that if a node is published and the "Publish on" date/time is in the past to clear the "Publish on" value so future node editing is not greeted by an error.

Comments

Hi,
I've just been looking at this scenario to see if we need to address any problem. In your third bullet point "Scheduler correctly will not let you publish because '4/5/2012 12:00pm' is now in the past" all you need to do if you are publishing the node manually is go to the scheduler tab/fieldset and delete the scheduled 'publish on' date and time. Then the node can be saved without any error.

If however you proceed to publish via content admin, then the 'publish on' date does remain in the scheduler table and hence will be added to the form and displayed during node edit. I've just checked in 7.x-1.1 and when the cron run is processed the scheduler function works as expected (even though the node is already published) and the scheduled date is removed from the table and hence removed from the node. So this problem does not occur in 7.x

Maybe the D6 version behaves differently (I will test this), but my initial thought is that this is not a major bug (unless you convince me otherwise) and we probably will not be altering the D6 functionality.

Jonathan
[edit to make clear that this is not a problem in 7.x, only 6.x]

Issue summary:View changes

Clarification

Status:Active» Postponed (maintainer needs more info)

Just tested this on D6 and there is a difference. It is as you described - the publish_on date is not removed during the cron run because the node is not selected for processing due the 'where status = 0' in the SQL query. This condition has been removed in the D7 version, that's why the table gets tidied up.

To remove the publish_on date, you would need to edit the (now published) node and erase the date from the scheduler field as described above. I suppose there is a minor risk that if this not done, then the node gets manually unpublished at some later using the content admin form (not node edit), then it would get republished on the next cron run. However, I'm not sure this is a big-enough problem to warrant changing the cron sql processing of the 6.x version, as that could open up new unanticipated faults.

The scheduler table could be kept consistent with the node during the content-admin publishing process, using hook_nodeapi() but this would be a change in functionality. It might be useful for the 7.x version so would have to be discussed and changed there first.

If you have any thoughts on this, let us know.

Jonathan

Issue summary:View changes
Status:Postponed (maintainer needs more info)» Closed (won't fix)

I do not think we will be altering the processing for D6 at this stage. As this is not a problem in D7 I'm going to close this as 'wont fix'. But please re-open if you want to persuade us otherwise.

Thanks for your interest in Scheduler.

Jonathan