Problem/Motivation
(I came across this when porting Login History to D8.)
In D7 hook_block_info() had a 'properties' key and the only documented key of properties was 'administrative', a boolean. #1535868: Convert all blocks into plugins removed these docs and moved at least some of the administrative = TRUE properties to blockSettings() methods on the block plugins.
It looks like blockSettings() is now defaultConfiguration() on a block plugin, at least for the case of ForumBlockBase. It seems like all of the other block plugins that were using 'administrative' have now been converted to views.
This 'properties' information ends up in active config but I'm not sure if or how it's used in D8. Most or all of the other data in the defaultConfiguration() methods of other block plugins in core seems to be related to things that a user can configure on the block instance form.
Proposed resolution
Remove the 'properties' from \Drupal\forum\Plugin\Block\ForumBlockBase::defaultConfiguration() or document somewhere what this does and how to use it.
If this is just a simple removal, the component can be changed to forum.module.
Remaining tasks
Figure out what to do.
User interface changes
n/a
API changes
n/a
Comment | File | Size | Author |
---|---|---|---|
#32 | 2251789-32.patch | 2.27 KB | Ankit.Gupta |
|
Issue fork drupal-2251789
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
Comment #1
star-szrThis might be a more accurate title.
Comment #2
star-szrAnd making the title less unruly while I'm at it.
Comment #5
tim.plunkettIt's in forum.schema.yml ¯\_(ツ)_/¯
Comment #12
larowlanComment #13
dhirendra.mishra CreditAttribution: dhirendra.mishra at Valuebound for Valuebound commentedHere is the patch below..Kindly review it
Comment #15
imalabyaUpdated patch to fix the tests.
Comment #16
longwaveI think the "properties" sections also need removing from forum.schema.yml.
Comment #17
imalabyaUpdated patch to remove the properties from schema.yml
Comment #18
longwaveLooks good. The only remaining instances of "properties" in forum module are in RDF mappings, which are unrelated to this issue.
Comment #19
alexpottWe need to target 9.3.x. 8.9.x only gets security fixes.
Also this is not this simple. We need to deprecate the schema and update any existing block config because they'll have...
Comment #20
alexpottFwiw this administrative property thing was removed by #1535868: Convert all blocks into plugins
Not really sure what replaced it or even if it was replaced.
Comment #21
longwaveAddressed #19 and opened an MR.
I am guessing the next tag will be "Needs upgrade path tests", which will be tricky because while forum module is installed in drupal-9.0.0.filled.standard.php.gz, neither of the blocks are placed.
Comment #23
alexpott@longwave your crystal ball is working :)
It's not too bad - you can add a small php file to install the blocks into the config - look in 8.9.x for inspiration in old upgrade tests. 9.x doesn't have so many of them.
Comment #24
longwaveAh yeah, I forgot we can do that.
Comment #25
longwaveFixed CSpell issue. I wish testbot would bump issues to NW when they fail like this.
Comment #26
daffie CreditAttribution: daffie commentedThe added upgrade path looks good.
The fixture adds 2 block with the old properties key set.
The basic filled drupal 9 fixture does not have those block included.
The upgrade test that the properties key gets removed for both blocks.
Back to RTBC.
Comment #27
catchQuestion on the MR.
Comment #31
longwaveThis came up again in #bugsmash triage. First of all the MR needs bringing up to date as this will have to go into 10.1.x, then @catch's comment still needs addressing.
Comment #32
Ankit.Gupta CreditAttribution: Ankit.Gupta at Dotsquares Ltd. commentedReroll the patch #17 with Drupal 10.1.x
Comment #33
quietone CreditAttribution: quietone at PreviousNext commentedForum is approved for removal. See #1898812: [policy] Deprecate forum module for removal in Drupal 11
This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
It will be moved to the contributed extension once the Drupal 11 branch is open.