- Issue created by @wim leers
- Status changed to Postponed
10 months ago 11:09am 7 March 2024 - Status changed to Active
about 2 months ago 12:42pm 1 November 2024 - 🇬🇧United Kingdom longwave UK
Parent issue landed, so we can fix this now.
It was discovered in
📌
Make Block config entities fully validatable
Fixed
that the provider exported property is unused.
This explains why all blocks have
provider: null
at the root, but then have another provider key that is not empty, under settings (so settings.provider).
For example, block.block.olivero_account_menu.yml:
langcode: en
status: true
dependencies:
config:
- system.menu.account
module:
- system
theme:
- olivero
id: olivero_account_menu
theme: olivero
region: secondary_menu
weight: -4
provider: null
plugin: 'system_menu_block:account'
settings:
id: 'system_menu_block:account'
label: 'User account menu'
label_display: '0'
provider: system
level: 1
depth: 1
expand_all_items: false
visibility: { }
Top-level null provider, but the "settings" provider is system, which makes sense: this is a block plugin provided by the System module.
This was introduced in #2432791: Skip Config::save schema validation of config data for trusted data → and appears to have been an accident.
Note: the Block class has never had a $provider property 😅 Which is why we see provider: null in all block.block.*.yml files 😄
N/A
block.block.*:provider as deprecated — this will trigger deprecation warnings for any code producing provider from the config_export annotation for the Block config entity typeprovider from EVERY block. That will ensure no deprecation warning is triggered anymore, unless the site owner restores old/invalid config.None.
None.
None.
None.
Active
11.0 🔥
Parent issue landed, so we can fix this now.