Is scheduled publish feature in the roadmap now?

[Stupidism]

What I found is this: https://payloadcms.com/blog/version-0-15-0

[DanRibbens]

This could use a detailed example or made as a plugin, but what you can do is add your own fields with versions with drafts, and manage it through access control to create your own workflows for publishing content.

Say you have a collection for posts that includes a field for publishAt for scheduling later, you could set it up this way:

const Post: CollectionConfig = {
  slug: 'posts',
  labels: {
    singular: 'Post',
    plural: 'Posts',
  },
  versions: {
    drafts: true,
  },
  access: {
    read: ({ req: { user } }) => {

      // a logged in user will be able to read all posts
      if (user) {
        return true;
      }

      // a guest will see only posts that have been published for  published at a time before the current time for the request
      return {
        and: [
          {
            publishAt: {
              less_than: new Date().toJSON(),
            },
            _status: {
              equals: 'published',
            },
          },
        ],
      };
    },
    readVersions: ({ req: { user } }) => Boolean(user),
  },
  fields: [
    {
      name: 'publishAt',
      type: 'date',
      admin: {
        position: 'sidebar',
    },
    // ... other fields for the content
  ],
};

There are situations that can add complexity to your workflows to plan around:

1. When using a static site generator, posts will only appear after a rebuild so you will need to do some dynamic querying or filtering.
2. If you need to maintain current and future versions of content. For example, you want changes for the home page set to occur at a future date, but your site still needs a published version to be shown before that change and only fetch the newest published version be displayed on the site.

Does that help?

[Stupidism]

@DanRibbens I created a repro repo here. Can u help me check what's wrong? #702

[DanRibbens]

@Stupidism, Thanks for the reproduction steps, that made it easy to see what was going on.

See response: #702 (comment)

[Stupidism]

I know I understood it wrongly now. What I want is exactly like you said here

Do u have any suggestions on how to achieve this?

What I can imagine is that:

1. Trigger a webhook every time an article is published
2. Add another SchedulePublish Button near the publishDate. Setup a corn job server to automatically trigger publish when the time comes.

[DanRibbens]

1. Trigger a webhook every time an article is published

It is not usually recommended to do this. Consider if you have a content change that is being made on multiple pages to or models. In that scenario you need to be able to make a few different edits and then publish the changes all at once. This can be done with a custom UI control for publishing lots of changes in one push. It also cuts down on build if that is a concern from a hosting perspective. If these are non-issue than it can be done this way.

2. Add another SchedulePublish Button near the publishDate. Setup a corn job server to automatically trigger publish when the time comes.

You can do this for sure!
Add an or condition to your query to accomodate the extra publishedDate docs to serve different versions of the document at the correct time. Remember this is separate from the access control since we're talking about staticly served pages and that will be different from the user access.

Does that make sense?

[Stupidism]

@DanRibbens Yes, I know we need a strategy to group the publish events of articles.

Thanks for your response!

[Stupidism]

Yes, it helps.

I’m currently using Contentful and investigating alternatives to that(Just too expensive and hard to customize).
Our editors like the publish feature they provide very much. It meets both the two situations you mentioned above.

How to solve them with payloadcms then?

[Stupidism]

I think I might need to @DanRibbens to send a notification to you.

[denolfe]

Hey @Stupidism , did you take a look at the PR linked in Dan's comment? #567 (reply in thread)

[Stupidism]

@denolfe Yes, it solves the basic requirements of not showing the draft before publishDate for the first time.

But for the second situation @DanRibbens mentioned, I think this cannot solve it.

[Stupidism]

@denolfe @DanRibbens Thanks, I see the new feature in the demo project now:

[ssyberg]

👍🏼 bumping this feature, we've implemented 50+ CMS solutions for clients over the years and this almost always a requirement (fwiw this is a core feature in most CMS solutions I've worked with), would strongly support this to be considered for core and not plugin/roll your own

[denolfe]

Tagging this as 'Planned', so we can prioritize accordingly.

[SalahAdDin]

Is it now available? @denolfe

[prineshaz]

This is extremely important to our customers if we take on Payload.

[danielmlr]

any updates on this feature or have i missed the functionality?

[cbratschi]

How does it work in contentful? For our projects I would need a start and end date i.e. the document is only published in this date range. Both values are optional.

[wkentdag]

FYI I built a plug in to do this! https://github.com/wkentdag/payload-plugin-scheduler

Would love some feedback.

[cbratschi]

@wkentdag Thanks, looks fine but one has a publish date. An unpublish date is not available.

I need a more generic solution for cron jobs. Some fields have a certain lifetime and Next.js revalidation is needed for such cases. I will have a closer look how to implement this for Payload 2.x and with Payload 3.x running on a custom server.

[cbratschi]

Checked the Contentful specs:

https://www.contentful.com/help/scheduled-publishing/

It supports many additional features. Probably too much for most cases and therefore more complicated to use.

[SalahAdDin]

It would be nice if Contentful would be open-source :'-)