Dependency from core block plugin to block module

Created on 16 May 2025, 2 days ago

Problem/Motivation

Core makes use of a permission defined by an optional core module: block.module.

The broken block plugin references a permission defined by Block.

Steps to reproduce

Test Broken plugin message display, when Block.module is uninstalled. The message cannot be displayed.

Proposed resolution

  • The permission should be merged into core/system, or
  • A new or different permission should be introduced to replace the use of administer blocks, or
  • The display of Broken message should be tied to something other than permissions

Remaining tasks

Decide on resolution

User interface changes

None.

Introduced terminology

None.

API changes

Maybe/tbd

Data model changes

None

Release notes snippet

None

๐Ÿ› Bug report
Status

Active

Version

11.0 ๐Ÿ”ฅ

Component

block.module

Created by

๐Ÿ‡ฆ๐Ÿ‡บAustralia dpi Perth, Australia

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @dpi
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia annmarysruthy

    I had a look at the different options, and hereโ€™s what I think:

    • Moving the permission into core/system would fix the dependency issue, but it might be confusing to have a block-related permission show up even when the Block module is turned off. That could lead to some questions about what it actually does.
    • Adding a new permission, like view broken block messages, feels like the cleanest solution. It avoids relying on the Block module, keeps things clear, and makes it easy to control who can see these messages.
    • Checking something else instead of permissions, like if the user is an admin, could also work. But using a permission is more flexibleโ€”site builders can decide exactly who should see the message.

    So, Iโ€™m thinking of going with the second option: adding a new permission in system.module and updating the Broken block plugin to use it.

    Open to suggestions.

  • Pipeline finished with Failed
    2 days ago
    Total: 1175s
    #498963
  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia dpi Perth, Australia

    I personally would suggest against a new permission, especially with such a limited purpose.

    Its bloaty and too theoretical at this point.

    Another approach could be just like we have with twig debug service parameter. Then pass along that parameter as a part of plugin creation. That way it isnt tied to a specific user, and the broken message can never be displayed in a non development environment, and inversely is always present on a development environment.

    Contrib or future changes could easily tie multiple parameters together under a "development parameter", which turns on the above proposed parameter plus twig parameter plus others...

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    Should this be postponed on โœจ Add a Production/Development Toggle To Core Needs work ?

    Could also see triggering E_USER_WARNING maybe, then it comes down to error reporting settings and permissions without the dependency.

  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia dpi Perth, Australia

    @catch that issue looks like it could provide what we need.

    Marking as postponed but anyone feel free to add other opinions.

  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia dpi Perth, Australia

    Should this be under Base/Plugin systems instead of "Block.module" component?

Production build 0.71.5 2024