Updated: Comment #0
Problem/Motivation
\Drupal\custom_block\Plugin\Block\CustomBlockBlock depends on the module hanlder to check whether block.module is enabled. But custom_block.module depends on block.module so this is pointless.
This was changed a few times, most recently in #2003058: Replace drupal_container() with Drupal::service() in the block module, but was originally introduced in #1871772: Convert custom blocks to content entities.
Proposed resolution
Remove the dependency on the module handler.
Remaining tasks
Write patch.
Review patch.
Related Issues
#2003058: Replace drupal_container() with Drupal::service() in the block module
#1871772: Convert custom blocks to content entities
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 2069619-8.patch | 2.82 KB | rpayanm |
| #8 | 2069619-interdiff.txt | 700 bytes | rpayanm |
| #5 | 2069619-5.patch | 2.75 KB | rpayanm |
| #1 | 2069619-1-custom-block-block-module-handler.patch | 2.21 KB | tstoeckler |
Comments
Comment #1
tstoecklerHere we go. At least CustomBlockCreationTest passes on my machine, let's see what the bot says.
Comment #4
tstoecklerThis is still a valid issue. The module was renamed in the meantime, though, so the class is now
BlockContentBlock. Marking Novice, as the previous patch already outlines what needs to be done, the equivalent code just needs to be identified inBlockContentBlocknow.Comment #5
rpayanmTrying...
Comment #6
tstoecklerAwesome, looks perfect already. Just one thing:
This should be kept as well.
Comment #7
tstoecklerComment #8
rpayanmUps...sorry :)
Comment #9
tstoecklerPerfect. I worked on the original version of the patch, but since this had to be recreated from scratch I think it's OK for me to RTBC this.
Comment #10
alexpottUnneeded dependencies is a bug not a task. This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?. Committed f0a7c35 and pushed to 8.0.x. Thanks!