Disable block-based publish by default

[chillu]

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 (onAfterPublish etc) 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.

Related: Make core actions in ActionMenu more flexible

[chrispenny]

I'm a massive advocate for disabling the publish/unpublish button for Blocks (and all nested DataObjects).

I think you've raised all of the most important use cases for doing so - I just wanted to put my +1 on this decision.

[ScopeyNZ]

cc @silverstripeux

[chillu]

disabling publish button for all nested DataObjects

@chrispenny It's a bit trickier on other data objects, since we can't assume that they're embedded in an ownership structure which will implicitly publish them. So unfortunately it's a case-by-case decision by developers. It appears to be opt-in according to the docs, which seems appropriate.

[robbieaverill]

I think having the publish individual block feature would be incredibly valuable, but unfortunately the wider implications from the way SilverStripe works would (right now) result in a more confusing user experience. For that reason I agree that disabling it by default is a sensible move.

[chrispenny]

@chillu , sorry, I wasn't suggesting that you disable them by default as part of this work - I was just saying that we (in bespoke code) always disable them.

[clarkepaul]

I'm against this because it's a requested feature from users we tested with prior to making them inline. Are we avoiding to fix history (snapshots) and removing a really important feature in doing it?

For sites which use old-style blocks which aren't inline (like @chrispenny is using) a publish action doesn't make as much sense (they are unsure if they need to navigate back to publish the page as well). But when there are inline blocks most users will publish by the page actions. It would be wrong to use the case of it doesn't make sense for non-inline blocks as that is not the way blocks should be used going forward.

The publish action for blocks are hidden away so only advanced users that would require the feature would use it. I don't see there being much of a user issue here with the newer UI, the feedback we've had has been positive to have the extra control when needed at a block level.

Why this feature is needed:

• Multiple people can edit different parts of the page without conflicting with each other, publishing and approving independently
• You can publish content without affecting site tree page position changes, page name and URL changes
• Pages have evolved to be longer and more broken up meaning more control is required per block as opposed to at a page level
• It allows people to track progress in the content editing process
• It allows for workflows to be applied to blocks

We would be backtracking so far from what currently exists if we remove this functionality that I feel we're likely to not fix it later as its not "default" behaviour.

Page history really needs to be time-based and not version based, then some of the bigger issues with history would be solved. If a user wants to see how a site looked at 1 pm it's much easier to know which versions (page plus blocks) we need to show them.

As a side point, if the publish action is removed the block states would become redundant so they would have to be removed as well.

[chrispenny]

For sites which use old-style blocks which aren't inline

I'm in a project atm that has inline editing, but we still find the publish actions in the drop down to be confusing.

In any case, if we don't want to disable the buttons by default, that's totally fine, but we absolutely do need a way to reasonably disable them. At the moment, we do not.

[muskie9]

For sites which use old-style blocks which aren't inline

I think there's been discussion around relation management in blocks and inline editing, however in current state, I believe many relation management has to be handled as non-inline. I'm just noting this as we have a number of blocks that have relations that can't be managed inline at this time.

This is just a touch point to the overall discussion so as not to assume a block should be considered inline as it depends on the function of the block and the current allowance of management.

[clarkepaul]

@chrispenny out of interest is that CMS user feedback that publishing individual blocks confusing?

@muskie9 when editing a block which isn't inline, do you/your users find the publish button confusing? do you also remove it? I understand there are limitations in its current state, user forms is an example of that and we'd have to do some work to make it fit the inline experience. I think for most instances there could be a quick edit experience for the most important parts of a block (inline) and provide a full edit experience which would provide access to the complete block details. I see this acting more like a modal or panel which keeps you in the context of the page and preview so that the page actions are still visible/present.

I'd be supportive of making the block publish functionality disableable but not to make it default behaviour at this stage.

[kinglozzer]

when editing a block which isn't inline, do you/your users find the publish button confusing? do you also remove it?

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.

[muskie9]

when editing a block which isn't inline, do you/your users find the publish button confusing? do you also remove it?

I think we have a mix with our users so we leave the functionality as is. When we do our trainings we're just up front about overall functionality and let them know "this is how you need to use it". We do get some feedback from time to time that it's a little confusing at times with the varying editing behaviors, however a simple reminder and they're on their way editing again.

[chrispenny]

I'd be supportive of making the block publish functionality disableable but not to make it default behaviour at this stage.

That's honestly fine with me.

[mfendeksilverstripe]

I really like the idea of having the publish action not be present on blocks by default. With that said, I'm also happy to just keep it configurable.

Why this feature is needed:

• Multiple people can edit different parts of the page without conflicting with each other, publishing and approving independently

Speaking from experience on multiple projects, this is very marginal case. This would indicate shared content on a page which shouldn't be covered by blocks. As an example I could name a header block. This block renders header navigation links but the links are managed by models outside of the block globally (model admin or site settings). The block itself is not shared.

Multiple people working on a same page (or same page localisation if using Fluent) seems like a really marginal case which makes this a strange reason for a default setting.

• You can publish content without affecting site tree page position changes, page name and URL changes
• Pages have evolved to be longer and more broken up meaning more control is required per block as opposed to at a page level

Based on feedback from clients in vast majority of cases, blocks are considered integral part of the page which have little value in being published individually. The only example I can think of is shared content which should not be part of a block but rather a separate model.

• It allows people to track progress in the content editing process
• It allows for workflows to be applied to blocks

I think this indicates that there are multiple concepts on how large a block is. I worked on projects where blocks are quite small and you need many of them to build a page (up to 50 blocks). Publishing individual blocks makes more sense if the blocks contains much more content and thus much fewer blocks are used to build one page.

I recommend reviewing what is the average amount of blocks on a page from existing projects and match this to our expectation.

From experience keeping the blocks small provides better composition options compared to large blocks. Large blocks may end up suffering with the same issues as page types (complex rendering logic, many rendering options and sub cases) which was the reason why we ditched the page types in the first place. Of course, the downside is that you need to create many blocks but this can be remedied by a simple solution which is block template pages (new page is created from a template and is populated by default blocks).

There are also other considerations regarding individual block publish for example static cache. For should happen to static cache record if a block gets published but the page does not?

[clarkepaul]

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.

blocks are considered integral part of the page which have little value in being published individually

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.

From experience keeping the blocks small provides better composition

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.

[chrispenny]

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

[chrispenny]

Or, perhaps rather than closing this ticket, could it be repurposed for providing the configuration to disable/customise actions?

[brynwhyman]

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).

[clarkepaul]

We currently have a client who is making 100's of edits per day and are using block publishing for nearly every change as to not affect other blocks.

Kind of related, and out of interest they also required as custom functionality:

• page publishing without effecting the blocks on a page (idea already exists https://github.com/silverstripe/silverstripe-cms/issues/2490)
• ability to protect a block from being triggered to publish by the page it’s on e.g. locking it

[chrispenny]

Both of those sound like really useful additions to me.

I wonder if could have a future state where you get to pick and choose what to publish as part of some sort of "publish review" step?...

[chillu]

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.

Just to support this with some data: On our own platforms, 95% of stacks have an average of 4 blocks or less, and a max of 32 blocks or less (per elemental area, so roughly per page).

[clarkepaul]

Thanks for that, can image what people say (think they have) and what they actually have can be quite different. That stat of 4 blocks on average really helps things UX wise, while 32 gives me a headache :).

[RVXD]

Just put this in _config.php if you don't want automatic publishing of blocks.

Config::modify()->set(ElementalArea::class, 'owns', []);

[chrispenny]

That isn't what this is about. This is about having the ability to disable the UI to publish blocks from the inline editor.