PublishLater may not work as intended regarding intended Publish Time

[johnrom]

Describe the bug

PublishLater may not display the intended date / time for a content item. Because the background task may run later than the intended publish date / time, the resulting publish will have a later than intended time. This is especially true if a user edits post around midnight, intending to publish for a specific date, but the publish doesn't run until after midnight. The Publish Later input uses the current time by default, so a user editing a content item around midnight might accidentally set a Publish Later to occur the day after it is intended. Then a content item intended to be published on 7/15 could display a published date of 7/16 for example. This can cause the publish date of content to become misaligned across communication channels and timezones.

While this is technically correct from a code perspective, there should be a way to choose the intended publish time versus the actual publish time as the PublishedUtc.

Before the following PR, it was possible to overwrite the PublishedUtc with the intended publish date, however the refactor moving the PublishLaterPart nullification from the PublishLaterPartHandler to the background task removed this capability.

#12276

Previously, it was possible to hook into PublishedAsync, with a handler ordered before the PublishLaterContentPartHandler, and overwrite the PublishedUtc with the ScheduledPublishUtc. I think this was a suitable workaround and that this was a more correct place to handle the content part removal, although I understand it probably caused a conflict with the background task.

I'm open to alternative solutions for this, but the current combination of behaviors can result in unexpected behavior when editing content.

Orchard Core version

2.1.6

To Reproduce

Schedule a publish for 11:59:59pm and see the published date reflect the following day.

Expected behavior

There should be a way to use 11:59:59pm as the publish datetime.

Logs and screenshots

N/A

[hishamco]

I'm open to alternative solutions for this, but the current combination of behaviors can result in unexpected behavior when editing content.

Please make a draft PR to see your proposal

[Piedone]

Do I understand correctly that the issue you're seeing is that, since background tasks run once every minute (by default), an item scheduled for 11:59 PM might slip past midnight? So, the problem is that the resolution of scheduled publishing is actually more than a minute.

BTW the date is stored in UTC, but what you set is in the UI time zone (which by default, is the site time zone).

[johnrom]

Timezone difference is understood, the issue is the difference between database publish time and intended publish time, which could span seconds, minutes, or with maintenance windows, the difference could be even greater if the website is down for an hour for example.

In my experience Publish Date is more of a matter of intent than a technical definition. If a post is scheduled to be published at a certain time, whether it happens at that exact time, the publish should still reflect the intended time. This would match the behavior of other CMSes as well, like WordPress, many of which allow you to actually specify the publish date whether it's in the past or the future.

https://wordpress.com/support/schedule-a-post-or-page/

If there is a technical reason that PublishedUtc must be the actual database publish time, maybe we need a separate module for specified publish date. I created a module for this that overrode the PublishedUtc using a content handler, but sometime in the past few years it stopped working with the publish system.

[Piedone]

So your main issue is not that the item may become public later than the scheduled publish time, but that the PublishedUtc timestamp will be later too, correct?

In this case simply setting PublishedUtc on the content item to ScheduledPublishDateTimeUtc before publishing here:

OrchardCore/src/OrchardCore.Modules/OrchardCore.PublishLater/Services/ScheduledPublishingBackgroundTask.cs

Line 54 in 96aa481

await contentManager.PublishAsync(contentItem);

should be enough to fix this.

Would you like to submit a PR for this?

[johnrom]

That fixes one of the issues I highlighted above. It would be a breaking change for current users who may not expect the implementation to change. Should there be a way to opt in to this change? Something like a setting "Preserve Scheduled Date/Time".

I highlighted two other concerns above that don't apply directly to Publish Later but could influence which is the best solution for this issue. I actually allow admins to specify a publish date, which doesn't appear to be possible anymore since the Content Manager resets the PublishedUtc after all the Handlers run. Updating the Content Item as you mention above would work for PublishLater since it has control over the whole process, but wouldn't allow additional modules to extend this functionality or intercept admin editing. To me, this doesn't conform to the open/closed principle and limits extensibility. I think a better solution is to go back to allowing Content Handlers to manage the PublishedUtc, and using that functionality within Publish Later. That way OC can support all three of the following, which it used to support:

• Allow PublishLater to set the PublishedUTC to ScheduledPublishDateUtc
• Allow PublishedUTC to be preserved across content item updates
  • Published: Original Date, Last Modified: New Date is common to display in blogs
• Allow admins to backdate content items

[Piedone]

Allow PublishLater to set the PublishedUTC to ScheduledPublishDateUtc

I agree, and I still think a simple solution similar to what I elaborated above would suffice. I think the current behavior where the publish timestamp is not the timestamp what was scheduled but when the background task has run is technically correct, but doesn't match the user intent. (And thus I don't think it would be breaking.)

But I now found out where PublishedUtc is actually set and it prevents simply setting contentItem.PublishedUtc from taking effect:

OrchardCore/src/OrchardCore/OrchardCore.ContentManagement/Handlers/UpdateContentsHandler.cs

Line 75 in 7952356

context.ContentItem.PublishedUtc = utcNow;

This is also a handler. You can override it from a handler with a higher priority, or by setting the timestamp and updating the item with IContentManager.UpdateAsync().

Allow PublishedUTC to be preserved across content item updates
Published: Original Date, Last Modified: New Date is common to display in blogs
Allow admins to backdate content items

I think this is all available, but perhaps you expect a different terminology:

• PublishedUtc should not be preserved. That's the timestamp of when the most recently published version of the content item was published.
• For the original date what you're looking for is CreatedUtc. That is preserved, too.
• The last modified date is a third thing, which is available as ModifiedUtc. For published versions this is the same PublishedUtc.
• Admins can backdate content items, but only CreatedUtc. If you attach the Common Part to a content type and under its settings tick "Display date editor", you get an editor for it in the admin.
• What you'd display on the frontend, it usually only CreatedUtc, and if you want to indicate if the item has changed since it was originally created, PublishedUtc.

[johnrom]

The way I understood it, CreatedUtc is not actually the Publish Date, but the date when the Content Item was created (could be in draft, scheduled to be published in a week). Maybe I am misunderstanding.

Additionally, it looks like CreateContentItemVersion resets the PublishedUtc after all the handlers run. I could reading the wrong place as I haven't actually had a chance to do a deep debug as to why my handler that used to do what you describe above stopped working.

OrchardCore/src/OrchardCore/OrchardCore.ContentManagement/DefaultContentManager.cs

Lines 1030 to 1051 in 4760c28

	if (contentItem.Published)
	{
	// Invoke published handlers to add information to persistent stores
	var publishContext = new PublishContentContext(contentItem, null);
	await Handlers.InvokeAsync((handler, context) => handler.PublishingAsync(context), publishContext, _logger);
	await ReversedHandlers.InvokeAsync((handler, context) => handler.PublishedAsync(context), publishContext, _logger);
	}
	else
	{
	await SaveDraftAsync(contentItem);
	}
	// Restore values that may have been altered by handlers.
	if (modifiedUtc.HasValue)
	{
	contentItem.ModifiedUtc = modifiedUtc;
	}
	if (publishedUtc.HasValue)
	{
	contentItem.PublishedUtc = publishedUtc;
	}

[Piedone]

Yes, CreatedUtc when the item was first created. But then again, you can override this, including setting it for the future or creating a handler that sets it automatically. You can also retrieve previous versions of a content item via IContentManager if this is not sufficient and you definitely need the first PublishedUtc, what you can retrieve from the first version.

What I describe above about explicitly setting PublishedUtc works with the latest main since I tested it before writing my comment.

[johnrom]

Thanks for the explanation. It's a little bit odd, but what you're saying is that instead of using PublishedUtc as PublishedUtc, we can use CreatedUtc as PublishedUtc if we want to. The only concern is that we would lose the actual created date, which I'm okay with as I have never used a field like this. It's a suitable workaround.

Getting the first revision's PublishedUtc isn't a perfect solution as cleaning up old revisions is a common database task in long-lived blogs.

[Piedone]

Just to be clear, the value designed for this is the PulishedUtc of the first published version. Overriding CreatedUtc is just a different approach if you prefer.

As for the original issue: Fixing that an item published via Publish Later doesn't have PublishedUtc set as the schedule time can be done by setting PublishedUtc on the content item to ScheduledPublishDateTimeUtc after this line:

OrchardCore/src/OrchardCore.Modules/OrchardCore.PublishLater/Services/ScheduledPublishingBackgroundTask.cs

Line 54 in 96aa481

await contentManager.PublishAsync(contentItem);

This can be done by setting the property and updating the item with IContentManager.UpdateAsync().

Would you like to contribute a PR for this?

[johnrom]

I'm still not sure why we are blocked from updating the PublishedUtc via a handler, but I'll just use a custom part. I'll open a PR updating PublishedUtc as you describe above.