Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
After sprinting fixing bugs in #1535868: Convert all blocks into plugins we (tim.plunkett, sdboyer and I) agreed that plugin.core.block was a horrible CMI prefix and that it really should just be block.
Proposed resolution
Rename and search/replace all instances of plugin.core.block -> block
Remaining tasks
None
User interface changes
None
API changes
None
Comment | File | Size | Author |
---|---|---|---|
#16 | block-1839904-15.patch | 7.98 KB | tim.plunkett |
#13 | block-1839904-13.patch | 7.11 KB | tim.plunkett |
#12 | block-1839904-12.patch | 7.99 KB | tim.plunkett |
#1 | drupal-rename_plugin_core_block-1839904-1-do-not-test.patch | 33.9 KB | disasm |
Comments
Comment #1
disasm CreditAttribution: disasm commentedAttached is a patch that renames all instances of plugin.core.block to block in all files. This can't be tested yet because it is not implemented in core yet. It's in patch #1535868: Convert all blocks into plugins.
Below are the commands to regenerate this patch after the other patch lands:
find ./ -type f|grep -v '.git'|xargs sed -i 's/plugin.core.block/block/g'
find ./ -type f|grep -v '.git'|xargs perl-rename 's/plugin.core.block/block/'
Comment #2
xjmYes please.
Comment #3
Dave ReidHow would this work if block module wanted to store extra settings? Wouldn't a config in block.settings be automatically loaded? I think having two levels for the plugin storage still might be good.
Comment #4
xjmViews does
views.view.*
andviews.settings
.Comment #5
xjmMarking this postponed on the main issue.
Comment #6
xjmComment #7
xjmRe-postponing on #1871696: Convert block instances to configuration entities to resolve architectural issues.
Comment #8
xjmComment #9
sunQuoting myself from #1826602-87: Allow all configuration entities to be enabled/disabled:
On the question of
block.plugin.$module.ID
vs.$module.plugin.block.block.ID
, the actual questions need to be:1) Who owns the config object? Block module or the $module? ("owns" means responsibility. Think of maintenance, update.php.)
2) Also: Are block plugins applicable to Block module only? Or can they be re-used by other services/modules? (What about SuperPanels³-NG 8.x-2.x in contrib? And also, wasn't the plan to blockify the entire system in the end...?)
Comment #10
tim.plunkettThis was postponed on the ConfigEntity issue for a reason, because it will mean we should follow the lead of every other ConfigEntity and make it
block.block.
Comment #11
xjmComment #12
tim.plunkettComment #13
tim.plunkett#1884758: Remove testing profile default blocks removed some of them.
Comment #14
tim.plunkettComment #15
EclipseGc CreditAttribution: EclipseGc commentedminimal profile's blocks need converting as well.
Comment #16
tim.plunkettMissed the ones from #1891324: Minimal lost its blocks
Comment #17
EclipseGc CreditAttribution: EclipseGc commentedThis looks completely sane if testbot is happy.
Eclipse
Comment #18
sunHm. What about #9 though?
My larger review in #1871696-43: Convert block instances to configuration entities to resolve architectural issues contained some more details:
Comment #19
tim.plunkettNone of that is this issue's problem to solve. This merely brings Block inline with everything else. There are other issues for that.
Comment #20
webchickCommitted and pushed to 8.x. Thanks! Don't think this needs a change notice, since it's D8 only.
Would you be able to cross-link those issues for where follow-up discussion is happening?