silverstripe-elemental: Disable block-based publish by default
Publishing individual blocks is conceptually difficult. While we can implement the “least surprising” behaviour by default on the module level, as an author and project developer you still need to understand what’s happening. Some friction points:
- Any logic hanging off page publication events (
onAfterPublishetc) now need to be aware of this additional level of publication (e.g. updating a search index, regenerating a static view). - Block-based publication could be used to circumvent restrictions imposed on a page-level, e.g. where
canPublish()returns false because a workflow is enforced - Authors might misunderstand the “publish” action on a blocks edit view as publishing the whole page (where they’re not inline edited)
- Page history becomes more complex to follow, since not all publication events are tracked in page history. Note that we intend to fix this through versioned-snaphshots, but that’s not widely deployed yet (and probably shouldn’t be enforced by the blocks module)
Overall, I think block-based publication is a valueable power user feature, but it shouldn’t be enabled unless everyone understands the tradeoffs in their particular project context, like evaluating their permission models and used modules for technical or logical incompatibilities. Hence I’m proposing that we disable it by default.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 9
- Comments: 23 (15 by maintainers)
I think there’s a level of “this is what we’re used to” (both us as devs, and our particular clients), which I think you’re right to challenge, @clarkepaul.
I’m totally happy for these to be left enabled by default (and I fully intend to start using them in new projects in order to challenge my own preconceptions), but I still stand by the request to have the ability to disable them.
One reason I have for this is that: For large projects that use static publisher, we rely on having a single source of truth for when the author is “done” so that we can generate new cache records as few times as possible. For [these sites] it’s just not reasonable to perform this action every time a block is published.
Maybe there is a UX or programmatic fix for this that I haven’t considered though. One option might be providing “recaching” as a separate option, but then we risk an admin/author forgetting to do it.
I would be on board with this ticket being closed as long as https://github.com/dnadesign/silverstripe-elemental/issues/755 is still be progressed.
CC: @mfendeksilverstripe
That isn’t what this is about. This is about having the ability to disable the UI to publish blocks from the inline editor.
Interesting discussions happening here 😄 it’s really useful to read the different perspectives of CMS user requirements and how that might change depending on the size of the site.
My perspective on this is it’s a powerful piece of functionality and makes for a great UX, but as things currently stand we bump into a number of other issues in the CMS as a result of having this functionality available and the matrix of what this functionality requires us to support seems grow (or maybe that’s just IMO…).
Regardless, it seems like https://github.com/dnadesign/silverstripe-elemental/issues/755 is pretty much a pre-requisite to even having this conversation, so that should be the focus first before decisions are confirmed on default behaviour (it’s currently in the dev team’s backlog).
We have been user testing this with users so I stand by my points. I agree that for the most part people edit and use the main page actions, but there are still those who do want to retain the ability to individually control each block as per how it was when they weren’t inline.
I don’t follow your example @mfendeksilverstripe of shared content sorry, my example is much simpler. I might want to publish a carousel now but leave the rest of that page as modified because those edits shouldn’t go live yet, unfinished or need approving still.
I value hearing these comments from developers but I value more what I have heard directly from those using the blocks as CMS users. Seems we are hearing different things.
Seems your view of blocks might be more catered to larger sites, most Silverstripe projects are mid-sized and take around 3 months, we did some research on the number of blocks (in projects and per page) and 50 blocks per page is not the norm, it was an extreme. From memory, it was more like 7-15 per page on average.
I think what you might be wanting is composable blocks (fields can be added and removed like userforms) which is something we are considering for the future. Then you might only need one or two blocks and users can switch out or add as many fields as required. Blocks can be created and used as templates for repeated use. Experimental mockup here
Individual block publishing has been there from the start, it wasn’t my decision but through my research, I believe there are those who use it. If it was configurable by CMS users to turn it on/off I’d be happy with that.
We make all of our blocks “non-inline” and have never had any complaints about the publish button being confusing. We opted to “non-inline” everything because the inconsistent editing behaviour was confusing authors - clearly more so than publish buttons on blocks.
I agree with your ”Why this feature is needed:“ rationale above @clarkepaul, our clients definitely make use of the separate Save Draft/Publish actions on blocks.