Problem/Motivation

  • How do we unpublish a block? A radio button on the BlockContent entity form? a drop button on the BlockContent entity form?
  • Permissions? Who can unpublish BlockContent? Who can view unpublished BlockContent?
  • Views integration.
  • What happens when you unpublish an already placed block?
  • Can you place unpublished blocks in a region? But they just don't show up until published.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

timmillwood created an issue. See original summary.

timmillwood’s picture

Issue summary: View changes
timmillwood’s picture

Issue tags: +Workflow Initiative
larowlan’s picture

How do we unpublish a block? A radio button on the BlockContent entity form? a drop button on the BlockContent entity form?

A checkbox like node provides would be fine, then we could upcast to a dropbutton in the theme - like we do for node forms.

Permissions? Who can unpublish BlockContent? Who can view unpublished BlockContent?

Yeah this will be tricky, we would need to consider it alongside #1975064: Add more granular block content permissions - I think we should follow what node does though.

Views integration.

- should come for free in terms of the field, but we'd need to change the wizard to automatically include the filter.

What happens when you unpublish an already placed block?

- we should leave the block placement but the access plugin would return '#access' => FALSE on the render array, so it would be essentially hidden.

Can you place unpublished blocks in a region? But they just don't show up until published.

I think yes, that would be a good workflow for deployment/workspaces etc. Publishing the workspace would result in the block being published and the content showing up

timmillwood’s picture

Just updated the patch in #2820848: Make BlockContent entities publishable to not render block_content entities in the BlockContent block plugin if the block_content entity is unpublished.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

amateescu’s picture

Category: Task » Plan

#2834546: UI for publishing/unpublishing block_content blocks seems to be handling most of the UI parts, so we need a few other issue for handling permissions and views. I'm changing this into a Plan/discussion issue and marking all the others either as children or simply related.

amateescu’s picture

Bojhan’s picture

What happens when you unpublish an already placed block?

This should ideally behave the same to nodes, it should disappear from the front-end - but be available and in place in the backend.

Can you place unpublished blocks in a region? But they just don't show up until published.

I would say yes, this also strongly supports the workflow stages. The bigger question being, can we show items - that are not published, but in other states? Given that the whole point of workflow.

SKAUGHT’s picture

IMO: a block that is 'un-published' shouldn't just remain as a placed block. then, many unpublished blocks (even as forgotten todo's to re-publish them) could amount in the block UI (or any UI for ordering blocks in a region) with more noise..

In normal Workflow then, publishing a new revision would keep a block placed.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

szeidler’s picture

IMO: a block that is 'un-published' shouldn't just remain as a placed block. then, many unpublished blocks (even as forgotten todo's to re-publish them) could amount in the block UI (or any UI for ordering blocks in a region) with more noise..

I disagree. Publishing and unpublishing blocks could be a handy tool for users, without the "Administer blocks". So they simply enable/disable for example an promotion block, without the fear, that they will break the site. On the other hand. On the other hand: When sites will increasingly use Layout Builder, they would probably use that for placing/removing blocks on a landingpage. It really depends on the use-case, but I think a "Unpublishing the block, but keeping it place for republishing" is quite a valid one.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Closed (duplicate)

From reading the comments closing this as duplicate of https://www.drupal.org/project/drupal/issues/2834546 which I've been trying to breathe new life into.