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
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:
- 3524897-dependency-from-core
changes, plain diff MR !12145
Comments
Comment #2
annmarysruthy commentedI had a look at the different options, and here’s what I think:
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.
Comment #4
dpiI 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...
Comment #6
catchShould 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.
Comment #7
dpi@catch that issue looks like it could provide what we need.
Marking as postponed but anyone feel free to add other opinions.
Comment #8
dpiShould this be under Base/Plugin systems instead of "Block.module" component?