Lets see if I stumbled on a bug or if this is the intended behaviour.
I’m setting up the blueprint for the homepage of a site and I’m trying to configure the status
If I use this
status:
draft : Draft
unlisted : Unlisted
listed : Published
You can’t disable the draft state. All pages are always created as drafts first. Are you using a hook to set a listed or unlisted state on page creation?
For all other pages, you wouldn’t be able to create pages if there was no draft state.
This is another issue and I think there could be a solution (for example allow the possibility of creating pages with the desired status as default) but it’s not that important right now
…or, if we had the ability to programatically override blueprint options, you could use a page.create:after hook to change the status of the page after creating it, even if in its blueprint you had set its changeStatus: false.
Yep, that’s a different story. However, it would just be a workaround while the issue that the draft option exists when you can’t make the home page a draft page, persists.
@texnixe Is there a way to set pages to prevent editors from turning published pages into drafts again?
We’re using the following hook to publish a page automatically as soon as it’s created:
'page.create:after' => function ($event, $page) {
$pagesToUnlist = [
'pages/news-category',
'pages/news-category-index',
];
if (in_array($page->blueprint()->name(), $pagesToUnlist)) {
$page->changeStatus('unlisted');
}
},
This works fine, any new page is set to unlisted as soon as it’s created. But editors still have the option to turn the page back into a draft, which we don’t want to allow in this case.
We tried to set changeStatus: false in the blueprint. But this disables not only the option in the panel, but also the API apparently, so with this we can’t create any new pages since the hook will cause an error.
Is there a simple way to set pages to be published automatically (skipping the draft stage) and not allow editors to change the status?
@texnixe Thanks for the suggestion! Using roles to limit access is a solid option. Though for small sites with only few editors, we won’t create any roles or permission checks, so it would still be nice if it was possible to achieve this behaviour for everyone.