UI for publishing/unpublishing block_content blocks

Might be worth noting, at the moment it is not possible to create a View of blocks and filter it by 'Enabled'. E.g. if a have a number of Custom Blocks which I have added to my Block Layout and some of them are Enabled and some are Disabled. If I create a View of Custom Blocks and filter them by Published, all the blocks appear in the list as all are considered Published by Views. There is no filter option to filter by Enabled.

Even if I remove a Custom Block from the Block Layout - it will still appear in my Views list.

If this issue is fixed, will it solve this problem too? Or is that a separate problem that I need to create a new issue?

Hi @frankdesign I think you're conflating two different concepts there

We have Block placements - these are config entities that you see at Admin > Structure > Block. These are configured block plugins that include the block-type, the region it is placed in and the theme. They can be blocks made from content (more on that below) but they can also be system blocks like menus, views etc

We also have Block content entities, these are what you see at Admin > Structure > Block > Block Library on 10.0 and below and Admin > Content > Blocks for 10.1 and above.

Block placements can be disabled and enabled

Block content entities can be published and unpublished (and even have drafts).

This is about adding a UI for publishing and unpublishing the block content entities.

They are two different concepts and unfortunately views has no visibility of the block placements which is where the enabled/disabled state comes from. It can only track the content entities.

1. Add additional test coverage for the UI implications of what happens if a block content entity is unpublished (see #87)
TODO - dependent on answer to 2-4

2. Confirm how this impacts translations (see #87)
Not sure how to verify this. But translation appears to be working

3. Confirm what occurs if a block config entity (placement) references an unpublished block
Updated getEntity() to check status before returning. So unpublished content won't appear.

4. Consider if we need to add a 'view unpublished' permission per #13
Not sure the use case.

Updated issue summary.

With the changes to the tests I wonder if that covers the change of the block not appearing when status is unpublished.

Putting to review for general feedback.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Moved logic to blockAccess ready for review again.

I have rerolled the last version of MR !4213 to D10.1.3 !THIS PATCH DOESN'T CONTAIN TESTS!

The last submitted patch, 153: 2834546-153.patch, failed testing. View results →

Hiding patch

Left a review on the MR, thanks for picking this up again 🥰

Addressed some feedback. Leaving NW for the open questions and other open threads.

All threads I believe have been resolved.

Posted a few nitpicks to the MR, I think @larowlan's questsions have all been answered?

Added a few nits. Setting to NW for the possible valid todo.

Addressed feedback and cleanup CR.

I'm not sure if this needs product manager or ux team feedback, but if it doesn't this looks good to go.

Based on the number of followers and participants, this seems like a feature that several folks would like to have. I'm not sure I understand when is this feature used and I didn't find any discussion about this from the thread. It would be helpful if folks could comment here / update the issue summary to explain what are the use cases for this feature. 😊

@lauriii

I have a number of blocks on a website that are click button links for membership renewal. The links are to an external third party website, who are handling the actual renewals and payments etc... As a result, I don't have access to publishing/unpublishing those pages/products.

The membership renewal window is only open for a few months each year. So I need to be able to allow content editors to show/hide the blocks with the button links. I don't want the same content editors to have access to the Block Layout page as there are loads of other blocks that I don't want them interfering with. So the only solution that I can see is to be able to publish/unpublish the block as the window open/closes.

At the moment, as site admin, I am managing the visibility of the blocks for them, not ideal but it works. I'd rather that they manage it themselves.

F

Re #163
We use this feature for a kind of "breaking news" block that is displayed on each page on our site.
When the news is outdated, we're unpublishing the block.

Thank you @frankdesign and @mrshowerman! Based on #164 and #165 +1 on the feature from me. I haven't looked at the actual code though.

Just fyi if there's an issue with the view updates for adding the filters I'm going to just remove those. Based on how I've seen tickets for content view where the view ships with the changes but no update hook for it.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased and removed the update hook for adding filters/columns to existing views. Based on how I've seen issues committed for main content view without update hook believe that's one hurdle we can just remove here.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased with 11.x and resolved conflicts.

Reverted back to before rebase to commit 53e960c6f5e42c0e42cbb24aa727811b817e3236 and rebased from there. Seems there was previous rebase errors even before that so fixed that too

Left some comments on the MR

I think we also need to check if we need a views wizard plugin change here, we probably want to add a status = 1 filter by default to any new view of block content entities. But we might not even have a views wizard plugin for block content, so if that's the case, nothing to do

The MR seems to cover a huge amount more than what is described in the IS (seeing action plugins, views filter changes, bulk operations, etc)

From the IS

If a block is unpublished it does not appear.

Are we not doing the access/rendering changes here? Also saw a comment on the MR about access handler changes but I'm not seeing them?

That was already done in #2820848: Make BlockContent entities publishable →

Rebased MR for latest 11.x
Added patch of MR for use in composer.
Applies to 11.x and 10.3.x.

Update of MR patch reflecting last fix (remove double status key in config).

I did my best to update the issue summary, tried to split the remaining tasks.
IMHO this should include an upgrade path for views block_content that is on route /admin/content/block.

This needs work for translations: Block content has translation, but translation unpublished, the source language is rendered. Something like this fixed the issue, but probably would better to be done at BlockContentBlock::getEntity()

--- a/core/modules/block_content/src/Plugin/Block/BlockContentBlock.php
+++ b/core/modules/block_content/src/Plugin/Block/BlockContentBlock.php
@@ -185,7 +185,9 @@ protected function blockAccess(AccountInterface $account) {
    * {@inheritdoc}
    */
   public function build() {
-    if ($block = $this->getEntity()) {
+    $currentLangcode = \Drupal::languageManager()->getCurrentLanguage()->getId();
+    $block = $this->getEntity();
+    if ($block && $block->language()->getId() === $currentLangcode) {