Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist.

I am having this issue with a fresh installation of Drupal with the page manager installed with composer.

Breaks site, bump to major.

Did some fast debugging - the discovery's doGetDefinition() ends up receiving a list of LayoutDefinitions rather than plugin definitions.

Versions:
ctools: 8.x-3.0
page manager: 8.x-4.0-beta2
panels: 8.x-4.0
panelizer: 8.x-4.0

Backtrace:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('', Array) (Line: 84)
Drupal\Component\Plugin\PluginManagerBase->createInstance('', Array) (Line: 183)
Drupal\panels\Plugin\DisplayVariant\PanelsDisplayVariant->getLayout() (Line: 300)
Drupal\panels\Plugin\DisplayVariant\PanelsDisplayVariant->getRegionNames() (Line: 75)
Drupal\ctools\Plugin\DisplayVariant\BlockDisplayVariant->getRegionAssignments() (Line: 101)
Drupal\panels\Form\PanelsContentForm->buildForm(Array, Object) (Line: 256)
Drupal\ctools\Wizard\FormWizardBase->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 514)
Drupal\Core\Form\FormBuilder->retrieveForm('panels_block_page_content', Object) (Line: 271)
Drupal\Core\Form\FormBuilder->buildForm('panels_block_page_content', Object) (Line: 41)
Drupal\ctools\Wizard\WizardFactory->getWizardForm(Object, Array, ) (Line: 79)
Drupal\ctools\Controller\WizardFormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

The issue is in panels, moving the issue.

The plugin selector form does not apply the selected layout on form submit within the wizard, which created the issue. For me, the fast solution has been the attached patch. Please review.

Apologies! The correct patch attached.

I was reproducing this problem on Panels 4.0. I applied the patch in #7 and it instantly fixed the problem for me. It seems to me that this will need a regression test before commit, though. Thank you, @alexrayu!!

Welp, according to @tim.plunkett, the branch tests are failing without this fix. So I guess a regression test is not needed. In which case...I came, I saw, I tried the patch, it worked. That's an RTBC as far as I'm concerned.

Tests passed last time we rolled a release, 8.x-4.0-beta1. They are failing in 8.x-4.0.

I began with

git bisect start 8.x-4.0 8.x-4.0-beta1

(first is the most recent known bad commit, second is the most recent known good commit).

At each step of the way, bisect checks out a new hash, and you must tell it if the commit is good or bad.
To determine if the commit was good, I ran

php ../../core/scripts/run-tests.sh --non-html --verbose --url http://d8 --color --class "Drupal\panels\Tests\PanelsTest::testLayoutSettings"

And the first two times, the test failed, so I ran

git bisect bad

Because there were only a few commits, I only had to do this a couple times before git informed me of the breaking commit: #2873767: Tabledrag from change layouts doesn't work

The change to src/Form/LayoutPluginSelector.php in that patch seems to be exactly the problem.

However, I do not think the above fix is 100% right.
The correct fix would be
$variant_plugin->setLayout($form_state->getValue('layout'), $form_state->getValue('layout_settings') ?: []);
inside that new else{} block.
The above patch makes little sense to me, since $cached_values['plugin'] is immediately overwritten.
Furthermore, it does not take into account the 'layout_settings' portion.

Retagging for test coverage.

EDIT:
Just tested this with git bisect run, and it seems to work great!

git bisect start 8.x-4.0 8.x-4.0-beta1
git bisect run php ../../core/scripts/run-tests.sh --non-html --verbose --url http://d8 --color --class "Drupal\panels\Tests\PanelsTest::testLayoutSettings"

and that automatically found the right commit. Cool!

Uploading the updated patch with corrections requested by @tim.plunkett

I discussed this with @tim.plunkett on Slack and we realized that the test coverage is complete as-is, and does catch this. Furthermore, the $form_state->getValue('layout_settings') ?: [] bit of the patch in #11 is unnecessary. Why? Because the LayoutPluginSelector form doesn't mention layout_settings in its buildForm() method. The layout settings are configured in the next step of the wizard, which is a separate form. Indeed, the existing PanelsTest asserts for this.

I have confirmed that PanelsTest passes locally with this patch applied, and fails without it. I think we can safely say it's RTBC by this point.

Based on the major regression we're getting here, and the fact that adding the else around what was the old code seems to fix the 'change layout' functionality that was previously broken, it looks like we can commit this.

Rolling a 4.1 release as well.

I see that this problem is solved in the newest version of the module. Thanks