Scheduler Content Moderation Defaults

Scheduler lets an editor say "publish this on Friday". Content Moderation gives content a workflow, such as Draft, In Review and Published. On their own they disagree: Scheduler ticks the published checkbox, while Content Moderation works out whether content is published from its workflow state. The checkbox gets overruled, the content never appears, and the date is silently used up.

This module settles that. Configure a content type once:

Publish on    →  move to Published
Unpublish on  →  move to Archived

From then on an editor only enters a date. When that date arrives the content moves through its workflow properly, so a new revision is created and anything else reacting to a workflow state change still behaves as expected.

Features

Two extra selects on the Scheduler tab of each content type, one for the publish date and one for the unpublish date. That is the whole configuration interface.

• Configured once, by the site builder. Editors never have to think about workflow states, they only set a date.
• Nothing is added to the content form. No new fields, no new database tables, no new database columns, and no change to how authors work.
• Travels in exported configuration. The setting is stored on the content type, so it moves between environments with the rest of your config.
• Works for imported and API created content. Content arriving by feed, migration or REST needs no extra data, since the content type already knows the answer.
• Only offers states that can work. The publish select lists published states, the unpublish select lists unpublished ones, and both are limited to states that become the visible version of the content.
• Explains itself when a workflow cannot do what you asked. The form tells you which states a date actually works from, and the status report lists any content type whose setting has stopped being valid, usually after a workflow was edited.
• Fails loudly rather than silently. A schedule that cannot run is written to the log. A date blocked only by a missing transition is kept and retried on the next cron run instead of being discarded.
• Adopt it gradually. A content type with no state selected behaves exactly as it would without this module installed, so you can configure only the ones you care about.

Typical use cases: a news site where articles always go from In Review to Published on their embargo date, a campaign site where landing pages are always Archived rather than deleted when they expire, or any site importing content that must enter a workflow rather than bypass it.

Post-Installation

There is no central configuration page. Everything is on the content type, next to Scheduler's own settings.

1. Apply a workflow to the content type at Administration » Configuration » Workflow » Workflows.
2. Enable Scheduler for that same content type at Administration » Structure » Content types » Edit, on the Scheduler tab.
3. On that same tab, two new selects appear, one under Publish and one under Unpublish. Choose a state for each and save.

The same settings appear for media types, taxonomy vocabularies and commerce product types, wherever Scheduler is enabled.

Two things to know.

First, a moderated content type needs a state chosen before its dates do anything. Leaving the selects empty is safe, but it does not make scheduling work on its own, because Scheduler's published checkbox is still overruled by the workflow. The module writes a warning to the log when it meets this case.

Second, choosing a state here does not override the workflow. When a date is reached, the content still needs a transition from the state it is currently in to the state you configured. This is by far the most common reason a schedule appears not to fire.

For example, if the only route to Published is an "approve and publish" transition out of In Review, then content sitting in Draft will not publish on its date, because nothing goes straight from Draft to Published. The date is kept and retried on the next cron run, so moving the item to In Review lets it go out. The content type form warns about exactly this, naming the states the date does work from.

If something does not behave, start at Administration » Reports » Status report. It flags a conflicting module and lists any content type whose configured state can no longer be applied.

Additional Requirements

• Scheduler 2.x
• Content Moderation, in Drupal core
• Workflows, in Drupal core

Drupal 10.3 or 11. No external libraries.

Recommended modules/libraries

None. This module needs nothing beyond the requirements above.

Note that Scheduler Content Moderation Integration should not be enabled alongside this module. See below.

Similar projects

Scheduler Content Moderation Integration solves the same problem, but stores the answer in a different place, and that decides who chooses it. Below, "Integration" is that module and "Defaults" is this one.

  Integration (per entity) Defaults (per bundle) State is stored on Two base fields, added to every entity of a supported type even where the bundle is not moderated The bundle, as third party settings State is chosen by The editor, on every item The site builder, once Entity form Gains two select widgets Unchanged Database changes Two extra columns on the data and revision table of each supported entity type None Different state per item Yes No Imports and API created content Must set the state fields, or the schedule is skipped Needs no extra data Travels in exported config No, the state lives on content Yes, with the bundle Offered states come from Transitions open to the current user, from the state the item is in The workflow attached to the bundle

Choose Defaults when the target state for a content type is always the same, when editors should not have to think about workflow states, when content arrives by feed, migration or API, or when you want the behaviour to travel in exported configuration.

Choose Integration when editors genuinely need a different state on individual items.

Do not enable both. They implement the same Scheduler hooks, and Scheduler skips an entity when either one reports a problem. The date is then never cleared, so every cron run reprocesses the same content and creates fresh revisions indefinitely. The content may still look correctly published, which makes this easy to miss. This module warns about the conflict on the content type form and on the status report.

There is one further practical difference. Where publishing requires review, so the only route to Published starts from In Review, Integration finds no usable state for a newly created draft. It then asks Scheduler to hide the publish and unpublish date fields, and editors cannot enter a date at all. This module reads the workflow attached to the content type rather than the transitions open at that moment, so the dates stay available.

Supporting this Module

Issue reports, reviews and merge requests are welcome in the issue queue. There is no funding link.

Community Documentation

The README in the repository covers the same ground in more detail, including how failures are handled, why a state might not be offered, the permissions involved, and the known limitations.