Deprecate and remove `status` and `info` settings from `block_content` blocks

Created on 7 March 2024, 11 months ago

Problem/Motivation

It was discovered in #3379725-5: Make Block config entities fully validatable β†’ that the config schema for Block config entities (type: block.block.*), and specifically the "base settings" for block plugins (type: block_settings) contains three key-value pairs (status, info and view) that actually are block_content block-specific. And … two of them are completely unused: status and info.

Ah, I finally found the explanation for why status, info and view_mode are part of the generic type: block_settings (and hence apply to ALL block plugins!).

The answer: it's simply an oversight that occurred in #2274175: Block plugin schema should be defined separately from the entity β†’ . πŸ˜„πŸ‘ (\Drupal\block_content\Plugin\Block\BlockContentBlock landed >1 year earlier, but the tight coupling only was removed ~6 months earlier, in #1927608: Remove the tight coupling between Block Plugins and Block Entities β†’ . Arguably at least there this should've been rectified, but that was at the height of the "we must get D8 done yesterday!" era, so it totally makes sense.)

So this issue has the potential to clean up some very old technical debt, that's caused confusion for every person who has ever looked at the exported YAML for blocks! πŸš€

Therefore null never makes sense, and it's only thanks to PHP's automatic typecasting that this has never been a problem πŸ˜…

Steps to reproduce

N/A

Proposed resolution

  1. Remove the status and info settings from \Drupal\block_content\Plugin\Block\BlockContentBlock blocks.
  2. Provide an update path that removes those two settings from existing blocks.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component
Block contentΒ  β†’

Last updated 4 days ago

Created by

πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

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

Merge Requests

Comments & Activities

  • Issue created by @wim leers
  • Pipeline finished with Failed
    11 months ago
    Total: 537s
    #113655
  • Status changed to Postponed 11 months ago
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    Even though we could easily land this before πŸ“Œ Make Block config entities fully validatable Fixed , I think it's better not to.

    Because #3379725 will bring much needed-clarity: that status and info belong in type: block.settings.block_content:*, instead of in type: block_settings (that's where they currently reside).

  • Pipeline finished with Failed
    11 months ago
    Total: 495s
    #113679
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    Because #3379725 will bring much needed-clarity: that status and info belong in type: block.settings.block_content:*, instead of in type: block_settings (that's where they currently reside).

    The changes in #3379725 will also cause most (I actually think all) test failures on the current MR to disappear. That's another important reason to postpone this issue: if we wait for that to land, then this issue's MR can stay as simple as it is today!

  • Status changed to Needs work 3 months ago
  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Parent issue landed, so we can fix this now.

  • First commit to issue fork.
  • Pipeline finished with Canceled
    6 days ago
    Total: 93s
    #396255
  • πŸ‡¦πŸ‡ΊAustralia acbramley

    Fixed merge conflicts and created a CR, still NW as we need an upgrade path

    https://www.drupal.org/node/3499836 β†’

  • Pipeline finished with Failed
    6 days ago
    Total: 471s
    #396257
  • Pipeline finished with Failed
    4 days ago
    Total: 507s
    #398200
  • πŸ‡¦πŸ‡ΊAustralia acbramley

    It looks like a lot of the test failures are now something like this:

        1) /builds/issue/drupal-3426302/core/lib/Drupal/Core/Config/Schema/SchemaCheckTrait.php:211
        The 'status' setting for content blocks is deprecated in drupal:11.2.0 and is removed from drupal 12.0.0. It was unused, so there is no replacement. See https://www.drupal.org/node/3499836.

    Which is coming from an update path test, I'm assuming because the db fixture has those keys set. Not entirely sure how we usually solve this kind of thing.

Production build 0.71.5 2024