Move block plugin code out of block.module

How would this unblock #2309715: Several views still say they depend on block module but not anymore?

+++ b/core/modules/aggregator/src/Plugin/Block/AggregatorFeedBlock.php
@@ -26,7 +26,7 @@
+class AggregatorFeedBlock extends \Drupal\Core\Block\BlockBase implements ContainerFactoryPluginInterface {

+++ b/core/modules/block_content/src/Plugin/Block/BlockContentBlock.php
@@ -27,12 +27,12 @@
+class BlockContentBlock extends \Drupal\Core\Block\BlockBase implements ContainerFactoryPluginInterface {

+++ b/core/modules/book/src/Plugin/Block/BookNavigationBlock.php
@@ -23,7 +23,7 @@
+class BookNavigationBlock extends \Drupal\Core\Block\BlockBase implements ContainerFactoryPluginInterface {

+++ b/core/modules/node/src/Plugin/Block/SyndicateBlock.php
@@ -20,7 +20,7 @@
+class SyndicateBlock extends \Drupal\Core\Block\BlockBase {

+++ b/core/modules/system/src/Plugin/Block/SystemBreadcrumbBlock.php
@@ -21,7 +21,7 @@
+class SystemBreadcrumbBlock extends \Drupal\Core\Block\BlockBase implements ContainerFactoryPluginInterface {

+++ b/core/modules/system/src/Plugin/Block/SystemPoweredByBlock.php
@@ -19,7 +19,7 @@
+class SystemPoweredByBlock extends \Drupal\Core\Block\BlockBase {

+++ b/core/modules/user/src/Plugin/Block/UserLoginBlock.php
@@ -20,7 +20,7 @@
+class UserLoginBlock extends \Drupal\Core\Block\BlockBase {

Other than the overzealous phpstorm driven refactor issue here, I'm quite ++ to this effort. Yes please!

+++ b/core/modules/block/tests/src/CategoryAutocompleteTest.php
@@ -26,7 +26,7 @@ class CategoryAutocompleteTest extends UnitTestCase {
diff --git a/core/modules/block/tests/src/Plugin/views/display/BlockTest.php b/core/modules/block/tests/src/Plugin/views/display/BlockTest.php

diff --git a/core/modules/block/tests/src/Plugin/views/display/BlockTest.php b/core/modules/block/tests/src/Plugin/views/display/BlockTest.php
index 7b83990..7a43656 100644

index 7b83990..7a43656 100644
--- a/core/modules/block/tests/src/Plugin/views/display/BlockTest.php

--- a/core/modules/block/tests/src/Plugin/views/display/BlockTest.php
+++ b/core/modules/block/tests/src/Plugin/views/display/BlockTest.php

+++ b/core/modules/block/tests/src/Plugin/views/display/BlockTest.php
+++ b/core/modules/block/tests/src/Plugin/views/display/BlockTest.php
@@ -10,7 +10,7 @@

@@ -10,7 +10,7 @@
 /**
- * @coversDefaultClass \Drupal\block\Plugin\views\display\Block
+ * @coversDefaultClass \Drupal\views\Plugin\views\display\Block
  * @group block
  */
 class BlockTest extends UnitTestCase {

Moving Block to views sounds sane! But this should move the test file as well.

While it's has moved away from the approach that prompted the comment, this would help resolve some of the stuff I brought up in #2031859-53: Invoke an event[s] when a plugin ID disappears.

We might want to document that modules providing plugins should do so via an API module and not lumped in with the UI, or is this mainly a case of block module being simultaneously required and often replaced?

We might want to document that modules providing plugins should do so via an API module and not lumped in with the UI, or is this mainly a case of block module being simultaneously required and often replaced?

I guess the question is when is there a reason to not want a UI-providing module installed. For example, image.module and filter.module (and many others in core) provide both plugins and a UI. If someone wants to disable the image style configuration UI or the text format configuration UI (or provide completely alternate ones), but still keep image effects and text filters at an API level, they can do so in various ways without needing the modules to be uninstalled. But, for that matter, I think the same is true of block.module. So maybe it comes down to a cost/benefit analysis of how common is the use case to not want the default UI vs. how much unwanted overhead is there in the unwanted UI's module being installed? Block UI, Views UI, and Field UI seem to be on the, yeah let's separate side of the line, but not sure about how many others in core and contrib need to be.

@tim.plunkett: well, yes, overly obtrusive hook implementations are a problem. But are you saying that once that issue is fixed that this one becomes unnecessary? Or is this one still justified on the grounds of block plugins being such a common dependency for so many core modules (whereas, e.g., image effects are not)?

Block UI, Views UI, and Field UI seem to be on the, yeah let's separate side of the line

For completeness, I'll point out that we actually have 3 layers:

• The plugin type(s) and corresponding concepts/interfaces
• The config entity type(s) that use the plugins and related interfaces
• The UI(s) for managing the config entities

And once this issue lands, each of the blocks, views, and fields use cases will use a different permutation of how these are split:

• Blocks will have the plugin stuff in \Drupal\Core\Block, and the config entity type and UI in the block module.
• Views has its plugin types and config entity type in views module, and the UI in views_ui module.
• Fields has its plugin types in \Drupal\Core\Field, config entity types (for non-base fields) in field module, and UI in field_ui module.
• While other use cases, like image module and filter module put all 3 layers into the module.

I don't think the above differences are necessarily a problem (each one, considered on its own, is pretty rational), just pointing them out.

Looks like the only thing outstanding here is #12?

I guess we have to bits of block.api.php as well?

+++ b/core/core.services.yml
@@ -264,6 +264,9 @@ services:
+    arguments: ['@container.namespaces', '@cache.discovery', '@module_handler', '@string_translation']

it is a pity that we cannot use the parent plugin manager here.

 * Contains \Drupal\views\Plugin\views\display\Block.
 */

namespace Drupal\views\Plugin\views\display;

use Drupal\Component\Utility\String;
use Drupal\Core\Form\FormStateInterface;
use Drupal\views\Plugin\Block\ViewsBlock;
use Drupal\views\Plugin\views\display\DisplayPluginBase;
use Drupal\views\Views;

use Drupal\views\Plugin\views\display\DisplayPluginBase;

This is not longer needed!

 * Contains \Drupal\Core\Block\BlockBase.

use Drupal\Core\Block\BlockPluginInterface;

Use statement not needed.

* Contains \Drupal\block\Tests\BlockBaseTest.

The test should be moved as well.

 * Contains \Drupal\Core\Block\BlockManager.

    parent::__construct('Plugin/Block', $namespaces, $module_handler, 'Drupal\block\Annotation\Block');

So the annotation has to be moved as well ...

 * Contains \Drupal\Language\Form\NegotiationConfigureForm.

use Drupal\Core\Entity\EntityManagerInterface;

This use statement is not needed.

    $theme = $this->config('system.theme')->get('default');
    $blocks = $this->blockStorage->loadByProperties(array('theme' => $theme));

This is NOT the proper way to get the default theme. \Drupal\Core\Extension\ThemeHandler->getDefaultTheme() is

 * Contains \Drupal\views\Tests\Plugin\Block\ViewsBlockTest.

use Drupal\views\Plugin\views\display\Block;

This use statement is not needed.

+++ b/core/lib/Drupal/Core/Extension/ThemeHandlerInterface.php
@@ -131,4 +131,12 @@ public function getBaseThemes(array $themes, $theme);
 
+  /**
+   * Returns the default theme.
+   *
+   * @return string
+   *   The default theme.
+   */
+  public function getDefault();

+1

Patch looks good, and that dead code removal hunk is great catch :)

Committed 7f2710b and pushed to 8.0.x. Thanks!

diff --git a/core/lib/Drupal/Core/Block/BlockManager.php b/core/lib/Drupal/Core/Block/BlockManager.php
index 86860dc..e65d2f6 100644
--- a/core/lib/Drupal/Core/Block/BlockManager.php
+++ b/core/lib/Drupal/Core/Block/BlockManager.php
@@ -18,7 +18,7 @@
  *
  * @todo Add documentation to this class.
  *
- * @see \Drupal\block\BlockPluginInterface
+ * @see \Drupal\Core\Block\BlockPluginInterface
  */
 class BlockManager extends DefaultPluginManager implements BlockManagerInterface {
 
diff --git a/core/lib/Drupal/Core/Block/BlockPluginInterface.php b/core/lib/Drupal/Core/Block/BlockPluginInterface.php
index 42290a0..200d10d 100644
--- a/core/lib/Drupal/Core/Block/BlockPluginInterface.php
+++ b/core/lib/Drupal/Core/Block/BlockPluginInterface.php
@@ -109,8 +109,8 @@ public function blockForm($form, FormStateInterface $form_state);
    * @param \Drupal\Core\Form\FormStateInterface $form_state
    *   The current state of the form.
    *
-   * @see \Drupal\block\BlockPluginInterface::blockForm()
-   * @see \Drupal\block\BlockPluginInterface::blockSubmit()
+   * @see \Drupal\Core\Block\BlockPluginInterface::blockForm()
+   * @see \Drupal\Core\Block\BlockPluginInterface::blockSubmit()
    */
   public function blockValidate($form, FormStateInterface $form_state);
 
@@ -126,8 +126,8 @@ public function blockValidate($form, FormStateInterface $form_state);
    * @param \Drupal\Core\Form\FormStateInterface $form_state
    *   The current state of the form.
    *
-   * @see \Drupal\block\BlockPluginInterface::blockForm()
-   * @see \Drupal\block\BlockPluginInterface::blockValidate()
+   * @see \Drupal\Core\Block\BlockPluginInterface::blockForm()
+   * @see \Drupal\Core\Block\BlockPluginInterface::blockValidate()
    */
   public function blockSubmit($form, FormStateInterface $form_state);
 

Fixed on commit.

Actually, core views should have been updated as well, but I already have a patch for that at #2309715: Several views still say they depend on block module but not anymore :)