Tests for: FATAL error when a view with a placed block is disabled or removed

This is indeed annoying and there are multiple problems here, but this at least fixes the UI and

This is green now.

+++ b/core/modules/block/lib/Drupal/block/Tests/Views/DisplayBlockTest.php
@@ -49,7 +49,7 @@ protected function setUp() {
-  protected function testDeleteBlockDisplay() {
+  protected function ptestDeleteBlockDisplay() {

Oops

I just tested the user story in the topic opener from damiankloip with the latest git pull of 8.x. after creating view of users, adding the Views:users block to sidebar right, deleting view and viewing page as noted, no WSOD and the log files are clear.

MAMP, php 5.4

There we go.

I applied patch #12 against a freshly installed current 8.x
- I created a view with displays newest five items in a block
- I created a view with displays newest users in a block
- I placed both blocks in header region and reloaded homepage. Both blocks were there.
- I deleted view with newest five items and reloaded homepage. No errors and only users-block was there.
- I deleted view with newest users and reloaded homepage. No errors and no block was there.
So everything is fine.
Thanks for the patch, @dawehner!

+++ b/core/modules/block/lib/Drupal/block/BlockPluginBag.phpundefined
@@ -57,12 +57,7 @@ protected function initializePlugin($instance_id) {
-      $module = $settings['module'];
-      // Ignore blocks belonging to disabled modules, but re-throw valid
-      // exceptions when the module is enabled and the plugin is misconfigured.
-      if (!$module || \Drupal::moduleHandler()->moduleExists($module)) {
-        throw $e;
-      }

That's completely hiding all errors now, at least watchdog_exception()?

@dawehner pointed me to this to make sure that it was kosher from a SCOTCH perspective. it actually kinda isn't, but the code that's already in isn't good either.

we don't ever want other systems acting on behalf blocks system and assuming something about its storage mechanism - this is (part of) why we're doing #2022897: Shift responsibility for creating unique config id/machine name off of (views) block plugins and onto BlockFormController. doing so precludes the possibility that block plugin instances might be placed & managed by any system other than core's block.module - and we're already doing exactly that in princess.

HOWEVER, that's no reason to block the fixing of this critical bug, especially because the code is no more broken in that respect by this patch than it was before. so, a followup is just fine. and here it is: #2031859: Invoke an event[s] when a plugin ID disappears.

This is the same patch as #12, but I want to know whether it fails. If it does not, I would vote to NOT do this change in this issue.

Rerolled.

+++ b/core/modules/views/lib/Drupal/views/Plugin/Core/Entity/View.phpundefined
@@ -374,4 +374,22 @@ public function mergeDefaultDisplaysOptions() {
+  /**
+   * {@inheritdoc}
+   *
+   * Allow display plugins to react on deleting the entity.
+   */
+  public static function postDelete(EntityStorageControllerInterface $storage_controller, array $entities) {
+    parent::postDelete($storage_controller, $entities);
+
+    foreach ($entities as $entity) {
+      $executable = Views::executableFactory()->get($entity);
+      $executable->initDisplay();
+      foreach ($executable->displayHandlers as $display_handler) {
+        $display_handler->postDeleteView();
+      }
+    }
+  }

There is a conflict from changes in #2031519: Deleting a view does not empty it's object cache with this function. This causes installation to fail. I am rerolling a patch to fix this and first test manually. The installation succeeds after my changes. I will just run the tests locally and see if I can make some progress.

Found the problem that caused all those warnings and exceptions. It was a very simple change, as shown in interdiff.

Now, lets see what testbots have to say.

I am fixing some of the errors with this patch. These errors were all due to incorrect usage of StorageController::load() method in the test. It was being used with the syntax of loadMultiple(), which threw all those errors.

The error I could not fix yet was:

Drupal\Component\Plugin\Exception\PluginException: The plugin (views_block:test_view_block3-block_2) did not specify an instance class. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 62 of /var/lib/drupaltestbot/sites/default/files/checkout/core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php).

I am not entirely sure how to go about fixing it. The error is due to DisplayBlockTest.php, line 118 (after patch):

    // Remove the third view and ensure that the
    $view = entity_load('view', 'test_view_block3');
    $view->delete();

I got a similar error during manual testing when I deleted the view, but it was "fixed" after earlier fixes. I could not repeat it during manual testing in any case. I will post again if I find something. Meanwhile, I hope this analysis is useful.

It seems to be basically a duplicate of #2031859: Invoke an event[s] when a plugin ID disappears

I just skimmed through the patch in #2031859: Invoke an event[s] when a plugin ID disappears and it looks like it might fix the problem in this issue. However, I think we could definitely use tests written in this issue. I will try out the patch there (which seems to be RTBC'd) and do a test for the problem in this issue.

I''ve bumped #2031859: Invoke an event[s] when a plugin ID disappears to critical. Moving this to major for tests. If this ends up not being a duplicate (apart from the tests), please bump it back to critical.

Mve issue link

23: vdc-2018493-23.patch queued for re-testing.

Triage Notes:

• Followed steps to reproduce the core issue and it is no longer an issue.
• I searched for the fixing issue but couldn't find it.
• The issue summary needs updating because I think what's being asked for is test coverage.
• Changed to task because we're just asking for tests
• Added Beta Evaluation assuming test coverage.

(Saving proposed issue credit for discussion and triage participants at LA.)

I tested on Drupal 11.x, standard install, using the steps in the issue summary. I was not able to reproduce the problem. Presumably because the block is deleted when the view is deleted.