When a future publish date is set, manual publishing is impossible. The entity will stay unpublished as long as a future publish_on date is set. To me this is counterintuitive.
Perhaps, if this current behaviour keeps being preferred, the instant publishing could become a configurable option?
It currently can be done by removing the scheduled publish date first, but when this use case becomes a much used one on a busy website, it would be nice to just publish regardless of the scheduled date.
Extra hickup:
Because the entity status is set to 0 in the entity_presave hook as soon as there is a future publish_on date, it is impossible to alter this behaviour through any hook or subscriber because the original publish/unpublish action is gone at this point. We don't know if the entity was intended to be published or unpublished in the first place.
A simple use case could be: New content is being reviewed via the workflow method but also scheduled for publishing in case the review isn't done in time. When reviewed in time, the content should be able to be published without the necessity to remove the scheduled publish date first.
(Note that in my case I use moderation states, which makes it more messy because the state is successfully set to Published, but the node keeps the status "0").
When manually set to published, allow scheduled content to be published instantly regardless of the publish_on date. Also remove the publish date while manually publishing.
Another approach would be to rewrite this part of the logic and to dispatch the PRE_PUBLISH_IMMEDIATELY event as soon as $publication_allowed && $publish_immediately are true. Then make scheduler subscribe to its own event and add all logic (such as if $entity->publish_on->value <= $request_time then ...) there. At least this way the logic would be more alterable.
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
fernly commentedComment #3
fernly commentedComment #4
fernly commentedComment #5
sassafrass commentedI am encountering a related issue. Given the following scenario: A user creates a piece of content that gets reviewed and placed in an Approved State immediately prior to being Published. Content must be an Approved State in order to be Scheduled for Publishing. On the Node Edit page, if the user tries to directly publish while there is still a Scheduled Date/Time, an error is displayed as expected: "The scheduled publishing state of published is not a valid transition from the current moderation state of published for this content." However, if I go to the Latest Revision page, I am allowed to set the node to a Published state without an error, the node remains unpublished, and previous versions become inaccessible.
Suggested behaviors: Either allow instant Publishing in both use cases (preferred), or prevent saving and display an error in both cases indicating that the Schedule Date needs to be removed to Publish instantly.
Comment #6
sassafrass commentedI created a patch off of the 2.x branch that allows direct publishing that I am successfully using on my local. I've added an option to the entity form to "Allow direct publishing". If it is checked and the user Publishes content that has been scheduled for a date in the future, the content is directly published. If this is something that the module owners want to include, I'm happy to continue working on this as they see fit.
Comment #10
klimpCreated the issue fork.
However, I ended up not using this patch. Updating
scheduler_content_moderation_integrationto the latest2.xfixed the issue for me. See https://www.drupal.org/project/scheduler_content_moderation_integration/...There is a difference in the behaviour though:
- patch #6 removes the scheduled Publishing
- the solution from
scheduler_content_moderation_integrationleaves the Scheduled Publishing settings intact while preventing a node from being unpublishedComment #13
jonathan1055 commentedHi @sassafrass, This does sound like a reasonable Use Case, so thank you for the patch.
@klimp - I know you said you do not use this behavior, but can you confirm that the MR you created was directly from the patch in #6? If so then @sassafrass can continue and use that MR, because patch testing is no longer done. I have just updated the fork branch because it was 21 commits behind 2.x
Comment #14
klimp@jonathan1055 confirming. Yes that was the case. My original commit is identical to the patch in #6
Comment #15
fernly commentedThe patch in #6 is a good working solution for the described issue. Tested in version 3.0.3 of scheduler.
Comment #17
jmoreira commentedMR 199 works as expected for me. Updated the MR to (hopefully) make the CI pipeline pass.
Comment #18
bkosborneAgreed this is useful. At the very least, a validation error should be shown when someone tries to manually set the state of an entity to the same state that is already published. Right now it just seems to ignore it.
Comment #19
jonathan1055 commentedThere are some things still to do:
Ideally it would be nice to give the user a warning/ask for confimation before proceeding, but we don't currently have anything like that in this module. Maybe an extra checkbox to tick, with explanatory text so that we can make sure the user knows they are altering the workflow that had been set.