Inconsistency in "changed" timestamp when publishing in the past

Hi gaele,

Is there a reason for this inconsistency?

Does "no one spotted this before" count as a reason?

We have the scheduler option to update the 'creation date' date on publishing, and this was added when we only had publishing via cron. But you are talking about the 'changed' date - just want to make sure that is correct.

At a later stage in 7.x development we introduced the concept of past dates and had to cater for what to do on node-save, and that is probably where the inconsistency originated. Maybe we need to look at both the 'created' and 'changed' dates and see if the immediate publishing should match the behavior of publishing via cron.

In scheduler_node_presave() when saving the node and the date is in the past, if past_date option = publish immediately and if 'touch' option is set i.e. to update the created time, then

      $node->setCreatedTime($node->publish_on->value);

but nothing is done with 'changed' date, so it defaults to the request time.

During cron, when a past date is processed, in schedulerManager::publish() we have

      $node->set('changed', $publish_on);

which is done in all cases, regardless of the 'touch' option. However if touch is set then we also have

      $node->setCreatedTime($publish_on)

So the questions are
(a) should the changed time be consistent when publishing manually and when publishing via cron
(b) If answer to (a) is yes, then which time should we use? Either we change the immediate manual publish code to set it to the publish_on date, or we change the cron processing to set it to the current time not publish_on time

Thanks gaele, yes that makes sence. To answer my question (b) I think it should be the immediate manual publishing process which gets fixed to use the publish_on time to match cron. The alternative, to change the cron processing to use 'request time' could be more disruptive for other sites, even though it is actually more accurate (the node was changed at the time that cron ran, not the publish_on time).

Here's a patch which sets the changed timestamp to match the publishing time when doing the 'publish immediately' processing.

As this also highlighted to me the (already-existing when doing it via cron) problem of producing content with a 'changed' date earlier than the 'created' date, and I have added an extra configuration opion in the node type settings form to cater for this. If the main 'alter content changed time to match publishing time' is not set, and past dates are allowed, then the new option will show up, and allow admins to chose whether to align the created date back in time to the publishing date. Giving an option here is the best solution, because some sites may want it, others may not. The default is 'off' to match the current behaviour.

If you have the means to try out patches, please give this a go. But I realise that you raised the issue more than two years ago, so if it is no longer applicable to your work, then don't worry.

Sorry this issue fell off my radar and it's taken so long to address it.

Jonathan

Added test coverage of the new option.

Change to how the message is built needs rtrim()

Fixed and committed.
Thanks gaele for spotting this and reporting it.