Simplifying page status: published/hidden etc

[apeisa]

There are some weak points on how processwire currently handles page status (I'm talking about 2.1, not sure how things work in 2.0).

After you give page name, you are taken to edit view, but page is not published yet (means it is not visible to site visitors). But after you click "save" first time then page gets published. There are couple of weak points here:

1) You cannot add images before publishing, because image uploads require page saving

2) If you want keep page as a draft, you have to set status: hidden, which is (if I'm right?) little bit different from unpublished. It is also clumsy and hidden behind settings tab.

3) This is really unclear and actually difficult to explain why it works this way (other than "you don't want to publish empty page")

How it should work (this came from our client, but I liked this flow):

1) First step just like it is now, just name and continue

2) Now you have same notice "page is not published yet", but now there is two buttons:

  => "save as draft" (this keeps page unpublished)

  => "save and publish" (works similar to old save)

3) After page is published, there is only one save button like there is now.

And there should also be setting to unpublish page. Difference between unpublished & hidden is that hidden is just hidden from search & navigation etc, but unpublished is actually only available for users who have edit access to that page.

What to you guys think? Also, I'm not sure if I got all points right or I have misunderstood reasoning for current flow, but this would make more sense I think.

[ryan]

The main reason for the "unpublished" status is to accommodate that state that a page has after it's been created, but before any real content has been added to it. It's a temporary status. You wouldn't want it showing up in lists, or to be accessible at it's URL, until you'd populated it with content. But I agree the current implementation could use improvement in the areas you've described.

The "hidden" status is unrelated... that's just a way to designate a page not to show up in find() and children() calls. It's a way to take a page out of the general flow of the site, but still have it accessible at it's URL. So you can still $pages->get() a hidden page, but you can't $pages->find() it (unless you override the setting in your selector).  The hidden status isn't intended to be used as a workflow status. Instead, it's just meant to be something to hide specific purpose pages from showing up in navigation and searches...

I like what you've suggested here, it sounds like a great solution. I will proceed with the changes as you've described. I think this will be possible to implement fairly easily.

[Adam Kiss]

I actually think it's horrible idea; at least, the part with two buttons.

• 'unpublished' status it's a good idea; There is much more then one usecase for this setting
  
• Having two buttons just during the first content input, I think it'll just confuse users
  
• If add the two buttons during the first 'real save', we now have:
  • 
     
• One 'save' button, which creates unpublished page
   
• then two buttons, which either do or don't change page status (save as draft and save as published)
   
• then we have one again, which either also publishes the page (if saved as draft previously) or doesn't
  

All in all, I don't think it's good idea to introduce more buttons, that do basically the same thing (save), but with slightly different flavors.

But, dedicated place of page edit setting the page published/drafted only, it's a good idea.

[apeisa]

Nope, it is not a horrible idea

You actually understood it little wrong. If you save as draft, then it will stay "unpublished" so there will be two buttons also next time you edit a page.

UI is something that need to be crafted carefully. Probably something like green button for default action (save & publish), but only light text link for save as draft function.

[apeisa]

The "hidden" status is unrelated...

Yep, it should be unrelated, but since there is now way to keep page as unpublished, but still add content & save, then this is currently only way to prevent the page being 100% published. And the fact that you need to save page once before you can embed images to rte-fields makes this painful.

I like what you've suggested here, it sounds like a great solution. I will proceed with the changes as you've described. I think this will be possible to implement fairly easily.

Good to hear this. I think that "two buttons" is very much needed here. Of course there should be clear default & alternative action, so that this won't be too hard decision.

I wanted to take a look how Wordpress handles this, and it is actually pretty messy (although it shows lot's of possibilities to user):

I also quickly sketched something how this could work in PW:

As we can see this is minor change in the UI, but will be super helpful in some cases. We also have to think carefully about what to say in notifications. I think one reason this happens is, that first notification is:  "Created page /new-page/ with template page". I think we shouldn't show that at all, only something like this:

"This page is not published. You will have to publish this page before it is visible on the site."

I also think that there should be possibility to preview the unpublished page if you have an edit access. It is otherwise very difficult to know how the page will look, if there is lot's of "freeform" content, like rte-fields with images etc.

And about terms used: I think we need to settle for "unpublished" or "draft", not to use both if we mean same thing. I vote for unpublished.

[ryan]

Thanks for taking the time to think this through. I agree with everything you've stated here, and also like the execution in the screenshots (and the link style for 'keep unpublished').

After seeing Benbyf's message today, I am thinking we might do one more thing to highlight that it's unpublished... perhaps strikethrough text for the page title in the editor, as well as in the page list, just so there's no way to miss that it's unpublished.

[almonk]

Isn't it easier to leave it up to the developer?

For example, for my clients I just add a checkbox called 'published' which they have to tick for the page to be included in listing pages.

I definitely don't think Wordpress should be held up as an idol for Processwire, it has one of the worst user interfaces in my opinion.

[apeisa]

Isn't it easier to leave it up to the developer?

For example, for my clients I just add a checkbox called 'published' which they have to tick for the page to be included in listing pages.

This is something that I thought also. And I do have "publish date" in news/blog post type, that is used. But this is actually more complicated issue. We do need some basic workflow baked in (nothing more complicated than published/unpublished), since this is how it actually works now (but is unclear). If there isn't any clear default (or the default is "always published unless developer does some special stuff in api") then you have to think this published/unpublished on every time you do your selectors. It would be clumsy on most sites. And this is so common need (I think that 80% sites needs some kind of draft/unpublished solution), so doing this in core is reasonable.

I definitely don't think Wordpress should be held up as an idol for Processwire, it has one of the worst user interfaces in my opinion.

I agree. I don't think it has worst interfaces, but it is complicated for average joe, and "blog roots" shows in many places (as a positive & negative). Processwire's strength is in totally different area than wordpress has.

I think most important thing is that person who creates page can be sure if his new creation is going live right away or can he test and play with content safely.

I added one more screenshot (vanilla Drupal 7.0). This is actually pretty good solution (if you strip down all the other stuff than published setting )

[ryan]

The latest commit of PW 2.1 now has the publish/unpublish as outlined by Apeisa. Take a look and let me know what you guys think. The main difference from how it was before is the following:

1. It now tells you in more obvious terms when a page isn't published (with a big headline at the top).

2. When editing a page that isn't published (only), there is a separate "Save + Keep Unpublished" button.

3. You can now unpublish a page. To do it, check the 'unpublished' status box on the settings tab.

4. Unpublished pages appear with a line-through in the PageList labels.

5. Unpublished pages are now viewable, but only if you have edit access to them. Previously, unpublished pages weren't viewable under any circumstance.

I'm thinking we should add new 'page-publish' and 'page-unpublish' permissions that can be definable with roles (?)

This version of PW 2.1 also includes several updates to the Setup > Templates section. You can now define roles that can add child pages for a given template, rather than having to maintain separate roles for page-edit and page-add access. Note that this also removes the need for a 'page-add' permission. This commit of the development version has had very little testing so please let me know when you come across bugs.

Thanks,

Ryan

[Lance O.]

I know this is an older thread, but I would like to make a suggestion. When I set the status of a page to "Unpublished: Not visible on site," the page was still viewable.

Until I found this thread, I didn't realize that an unpublished page remains viewable if I am logged into PW as an admin. My first thoughts were to think that this functionality did not work as expected.

It might be helpful to include an "Unpublished" label near the "Edit" label that appears at the top of a page when viewing it in the context of the site.

[diogo]

It's good to frequently test your site while not logged in. Use a different browser from the one that you use to develop, so you don't have to be always logging in and out. If you use Chrome, you can also open an incognito window for this.

Anyway, to make what you asked for on the default site, change these lines on foot.inc:

// If the page is editable, then output a link that takes us straight to the page edit screen:
if($page->editable()) {
echo "<a class='nav' id='editpage' href='{$config->urls->admin}page/edit/?id={$page->id}'>Edit</a>";
}

to:

// If the page is editable, then output a link that takes us straight to the page edit screen:
if($page->editable()) {
echo "<a class='nav' id='editpage' href='{$config->urls->admin}page/edit/?id={$page->id}'>Edit";
if($page->is(Page::statusUnpublished)) {
       echo "<br>Unpublished"; // this adds the unpublished status to the edit button
   }
echo "</a>";
}

[apeisa]

Ryan: just noticed that I have totally missed to to thank you about this. I think pw currently has pretty great middle ground on this area (visibility-toggle, published-toggle, locked-toggle).

One great idea that our marketing person said while updating our new site: it would be great to have simple "published" toggle on files/images too. What to do you guys think?

[ryan]

One great idea that our marketing person said while updating our new site: it would be great to have simple "published" toggle on files/images too. What to do you guys think?

I think there are situations where this is useful, and I even had one recently. I used a repeater with a 1-image field and a checkbox called 'published'. When I cycled through the repeater items to output the images on the front-end, I'd skip over any that didn't have $item->published.