This is a followup to #1535868: Convert all blocks into plugins.

Block visibility settings need to be revisited in the context of the Display model.

With respect to determining whether or not a particular user sees a block, the plan is to have two independent considerations:

  1. Visibility, which is attached to the Display containing a block instance, but the block instance itself knows nothing about.
  2. Access, which is inseparably implemented on the Block class itself as a method.

Most, if not all, of what's currently done with block visibility should fall into the former category.

Comments

sdboyer’s picture

Status: Active » Postponed
xjm’s picture

Status: Postponed » Active
Issue tags: +Blocks-Layouts
webchick’s picture

Priority: Normal » Major

This is not "normal" :)

gábor hojtsy’s picture

Testing blocks as plugins now, visibility settings do work (at least for paths), so I assume this would be implementing them in some new context where they are displayed, but is not yet applicable as-is. What else is this postponed on?

gábor hojtsy’s picture

Also there are currently JS bugs related to visibility, see #1882252: Regression: Block visibility summaries are broken (quick fix proposal posted there).

xjm’s picture

Issue tags: +Block plugins
jibran’s picture

Can we add per entity type + bundle visibility and remove node type visibility?

xjm’s picture

Can we add per entity type + bundle visibility and remove node type visibility?

That sounds like a brand new feature to me, so I don't think so at this point. It's also out of scope for this issue I think.

tim.plunkett’s picture

Status: Active » Postponed

I would think this is still blocked on #1896076: Contextual Plugins and supporting code and whatever Display SCOTCH code @sdboyer is working on.
Because right now, we still have working visibility, the same as D7.

jibran’s picture

Status: Postponed » Active
jibran’s picture

xjm’s picture

Issue tags: +API change

I'm thinking this might be D9 material now, unless there is a compelling reason to break APIs by refactoring here?

I thought there was some feature regression from D7 related to block visibility, but #9 seems to indicate otherwise.

xjm’s picture

Version: 8.x-dev » 9.x-dev

#1871854: Decide whether to restore per-user block visibility or provide it in contrib was the feature regression I was thinking of, so moving this to 9.x.

catch’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.