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

Issue fork drupal-3524897

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

dpi created an issue. See original summary.

annmarysruthy’s picture

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.

dpi’s picture

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

catch’s picture

Should this be postponed on #1537198: Add a Production/Development toggle?

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

dpi’s picture

Title: Dependency from core block plugin to block module » [PP-1] Dependency from core block plugin to block module
Status: Active » Postponed

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

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

dpi’s picture

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

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.