I've seen use cases with customers where they'd want the option to schedule publishing of pages (and other content types as well). Any specific reason why we should not allow this by default for all content types?

Fair enough. Adding the "needs metrics" tag; not for the decision to implement this; just because it will be a good candidate to test #285

@stpaultim I would like to work on this issue.

Thank you for working on this @mmachinen 🙏🏼 ...there are test failures that need to be fixed, so I'm setting this back to "needs work". It seems to me that things should be fixed in the testPagePreview() function/method, since it seems to be using the page content type in order to test scheduling among other things. I haven't tested, but changing things like these should do it (there might be other additional bits here and there though):

• $this->backdropPost('admin/structure/types/manage/page', $edit, t('Save content type'));
• $this->backdropGet('node/add/page');
• $this->backdropPost('node/add/page', $edit, t('Preview'));

PS: Once #5236 is merged, you should rebase your PR branch (let us know if you need help with that), which should help to display these failures in a better format 😉

@jenlampton re this:

Because it's uncommon, and not hard to enable.

We're basically trying to remove one of the radio options from this UI here:

I'm not sure how much value this adds, as it doesn't declutter things much. Besides, I'm concerned about making an awesome feature (WordPress parity) less discoverable, plus working with government agencies I see that it is in fact used quite a lot (ministerial announcements that are not necessarily blog posts, new members of the department that need to be announced and added to the team members listing during a specific date/time after elections, new laws/regulations that come into effect after a specific date/time etc.). Perhaps we should reconsider this?

Well, the default when creating a new content type is to have the scheduling option shown. So I'm OK with this change here I guess.

Here's a new PR: backdrop/backdrop#5000 Based on the previous PR I assume tests will fail so I'll wait and see what needs fixing then attempt to do so.

Fixed failed test by removing scheduling parts. Confirmed removed parts were duplicated in other tests, so nothing should be lost here.

I certainly don't feel strongly about this. But, I can see where this is not a necessary default option (scheduling pages). In terms of discoverability, having it enabled on posts helps with this and posts are MUCH more likely to be scheduled.

It seems that "cards" are already off by default.

I support this change. We have a PR, so I will add this to the milestone and mark WFM.