Override Publish changes button + Return all drafts

[adam-mrozik]

Hey,

I couldn't locate any info on this. Is there option to override Publish changes button functionality?

Second question: Can I query DB for all draft documents? I saw preview function that can send whole draft to the frontend, but I would like users to be able to save like ~10 different drafts and sort of preview all of them. Is that possible?

Third question: Is there a way to batch publish multiple documents together?

[jmikrut]

Hey @adam-mrozik — good question!

1. Overriding the Publish changes button is currently not possible, but it would be a great addition. We would accept a PR to add this functionality for sure. It would just function like how swapping in a custom component works now - except you'd swap in your own Publish button. Would be cool. Can I ask what you're looking to do with this?
2. Yes, you can, although I think there's a bit more that we should think through here. What are you trying to do? Finding all pages that have never been published is easy - just use where: { _status: { equals: 'draft' } }. But that will not send back pages that have been published, but have newer drafts available. To get both all pages that have never been published, as well as all pages that have newer drafts available, you would need to use the draft: true argument and then filter the results manually in your app(s).
3. To batch publish multiple documents together, you could write a script that fetches all draft documents and then loops over them to change each one's _status to 'published', but that would need to be a script. There is no endpoint operation available for this but it could be easily done with a custom endpoint or script.

How's that?

[adam-mrozik]

Wow, Thanks for very quick answers!

Just for the context:

1. I want internal employees be able to publish changes to prod with this button, so I wanted to add some safety checks (e.g. is appropriate version of PROD frontend deployed for the given payload cms version, or add some additional safety pop-up like are you sure you want to deploy document to PROD?.
2. I imagine internal employees might want to change multiple documents and see how it all looks together. I wanted to make it so that Save Draft saves the document and makes it visible on Staging website, while Publish Change would push data to to the PROD website. This way I can have only one Payload CMS and one place for internal employees to edit documents and also publish them to the default site.
3. Nice! So just a custom button would suffice here, thanks!

[DanRibbens]

Everything has changed since this thread was answered. I wanted to give an update.

Is there option to override Publish changes button functionality?

First of all, there is the ability to swap out the admin.components.edit.PublishButton or SaveDraftButton with your own custom components when drafts are enabled. Then we also have the ability to add custom endpoints if you wanted to customize the request on the server side instead.

For custom endpoints made with the same route and method as an existing Payload endpoint, your own handler will be called instead (or used like a middleware if you call next() from req, res, next). This is helpful if you are able to do your custom logic server side and also whatever you're adding is good for any rest calls to that endpoint (no way to distinguish a REST call from the admin UI apart from any other source).

The custom endpoints are changing a bit for v3 since we won't be on express. You'll still be able to do your own custom endpoints, but I believe you'll have to call the underlying method using the local API after your own logic instead of calling next()
You should have everything you need, let us know if there is something else you need here.

Third question: Is there a way to batch publish multiple documents together?

This is an possible now from the list view of a collection with drafts enabled by selecting multiple rows in the list, or all docs, or querying within the filters in the UI and selecting all that match.