tl;dr: it's important for users to keep track of which documents are publicly accessible at any given time.
Problem
Right now, one can hit the Publish toggle button on any page, and that will automatically set the status to publish for it and any collections embedded therein. But:
- toggling the status back to
private will only reset the status of the page but not the collections; since a collection may be embedded in more than one page, we made no attempt at the time to determine which collections should be reset to private;
- there's no way in the UI to see the status of a collection, nor an explicit control to set them as private.
Possible solutions
The following are not necessarily mutually exclusive:
Automatically setting collections as private
With this approach, when toggling a page back to private, Cortext would determine which collections are embedded in the current page while not embedded in any other page, and set them as private.
Benefits: From a user's perspective, works acceptably well in simple scenarios where a collection is typically embedded in no more than one page.
Drawbacks: From a user's perspective, it gets very confusing very quickly to have to think that some collections may end up private and others public. From an developer's perspective, this seems like a nightmare, even if the underlying data model is changed. This is because the mapping from a page to its embedded collections (and vice versa) is not tracked in any sort of field or index: we currently have to parse-and-walk the block tree in a page's content in search of cortext/data-view blocks. So we would either have to analyse arbitrarily large numbers of pages upon setting a page as private (please no), or introduce server-side awareness of the collections embedded in a page and keep some kind of index up to date (e.g. two-way post meta).
Blindly setting collections as private
A variation of the above approach, where setting a page as private would set all collections therein as private too, as the risk of breaking some other page that happens to embed the same collection. This seems like a stupid idea, but I'm listing it here for the sake of completeness.
Benefits: Easy to implement and easy to explain to the user: "are you sure you want to set all of the following to private?"
Drawbacks: ... dumb?
Adding a Publish toggle button to Collection views, just like for Pages
This could be as simple as adding these two to Collections:
| Publish |
Unpublish |
 |
 |
Then, when a user tries to set a collection as private, a confirm dialog would explain that, if the collection is embedded in any public page, it will no longer be viewable to the public if the user proceeds.
Benefits: Easy to implement and easy to explain to the user.
Drawbacks: The user has to navigate to a collection to see its status. The user also has no way of knowing which pages may be affected by the status change.
Making public statuses more prominent in the sidebar
Something like the following, but which doesn't suck:
Benefits: Easy and understandable. Takes care of the visibility aspect. Could articulate well with some other enhancement (e.g. the previous one about adding a toggle button in the collection view).
Drawbacks: May make the sidebar look busy...?
tl;dr: it's important for users to keep track of which documents are publicly accessible at any given time.
Problem
Right now, one can hit the Publish toggle button on any page, and that will automatically set the status to
publishfor it and any collections embedded therein. But:privatewill only reset the status of the page but not the collections; since a collection may be embedded in more than one page, we made no attempt at the time to determine which collections should be reset to private;Possible solutions
The following are not necessarily mutually exclusive:
Automatically setting collections as private
With this approach, when toggling a page back to
private, Cortext would determine which collections are embedded in the current page while not embedded in any other page, and set them as private.Benefits: From a user's perspective, works acceptably well in simple scenarios where a collection is typically embedded in no more than one page.
Drawbacks: From a user's perspective, it gets very confusing very quickly to have to think that some collections may end up private and others public. From an developer's perspective, this seems like a nightmare, even if the underlying data model is changed. This is because the mapping from a page to its embedded collections (and vice versa) is not tracked in any sort of field or index: we currently have to parse-and-walk the block tree in a page's content in search of
cortext/data-viewblocks. So we would either have to analyse arbitrarily large numbers of pages upon setting a page as private (please no), or introduce server-side awareness of the collections embedded in a page and keep some kind of index up to date (e.g. two-way post meta).Blindly setting collections as private
A variation of the above approach, where setting a page as private would set all collections therein as private too, as the risk of breaking some other page that happens to embed the same collection. This seems like a stupid idea, but I'm listing it here for the sake of completeness.
Benefits: Easy to implement and easy to explain to the user: "are you sure you want to set all of the following to private?"
Drawbacks: ... dumb?
Adding a Publish toggle button to Collection views, just like for Pages
This could be as simple as adding these two to Collections:
Then, when a user tries to set a collection as private, a confirm dialog would explain that, if the collection is embedded in any public page, it will no longer be viewable to the public if the user proceeds.
Benefits: Easy to implement and easy to explain to the user.
Drawbacks: The user has to navigate to a collection to see its status. The user also has no way of knowing which pages may be affected by the status change.
Making public statuses more prominent in the sidebar
Something like the following, but which doesn't suck:
Benefits: Easy and understandable. Takes care of the visibility aspect. Could articulate well with some other enhancement (e.g. the previous one about adding a toggle button in the collection view).
Drawbacks: May make the sidebar look busy...?