Create a layout builder variant

I decided to start working on this. Still plenty of work to be done, but this is a start at least. Setting to NW to see if i broke something.

Link is not displayed in sidebar https://git.drupalcode.org/project/page_manager/tree/2960739

Ref https://www.drupal.org/node/2749491

Hey everyone, we are doing some work on this as part of #3051071: Switch to using Layout Builder rather than Panels/Panelizer. Here's a patch that fixes:

Main Todos:
* ✅ Saving doesn't work.
* Refactoring the storage classes so we don't hardcode it into the page variant.
* Profit?

Note: this patch is from the 2960739 branch.

PS: Can we rename the branch to 2305199-layout-builder so that is shows up in sidebar. See #5.

Let's display some output.

Here's a full patch against 8.x-4.x for easier review. The actual content should be the same as #7 - I basically just applied that patch in a local git clone of the feature branch, and then made the diff.

I haven't tested yet, but here's some review just from skimming the code:

1. +++ b/page_manager_ui/src/Form/PageVariantConfigureForm.php
   @@ -42,7 +42,8 @@ class PageVariantConfigureForm extends FormBase {
   +    // @todo
   

   What's this @todo for? Can it be removed?

2. +++ b/src/Annotation/LayoutBuilderStorage.php
   @@ -0,0 +1,17 @@
   +class PanelsStorage extends PluginID {
   

   The file is called LayoutBuilderStorage and the class is PanelsStorage, so probably this isn't even used?

3. +++ b/src/Plugin/SectionStorage/PageManager.php
   @@ -0,0 +1,189 @@
   +  public function access($operation, AccountInterface $account = NULL, $return_as_object = FALSE) {
   +    // @todo
   +    return AccessResult::allowed();
   +  }
   

   Always allowing access seems like it could be a problem :-)

4. +++ b/src/Plugin/SectionStorage/PageManager.php
   @@ -0,0 +1,189 @@
   +  public function isApplicable(RefinableCacheableDependencyInterface $cacheability) {
   +    // @todo
   +    return TRUE;
   +  }
   +
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function getSectionListFromId($id) {
   +    // @todo
   +  }
   +
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function extractIdFromRoute($value, $definition, $name, array $defaults) {
   +    // @todo
   +  }
   

   A bunch of @todo's at the end

I just did some manual testing and found a couple of things:

1. When first creating a new page and going through the sequential wizard, I was unable to add any sections. I would click "Add section" and the AJAX spinner would go, but the tray wouldn't open. However, once I finished that wizard, and got to the one where you can access any part of any variant, then adding a section and block would work
2. The sections and blocks I added got saved, and were still there when I edited the page again!
3. When I went to view the page I made, the content block that I created and added didn't appear. However, the "Powered by Drupal" block (a block plugin) did appear

This is certainly starting to get there!

I looked at the block issue today ( 2 and 3 from previous comment). I don't have a solution for it yet but layout builder is using \Drupal\layout_builder\InlineBlockEntityOperations::handlePreSave to handle inline_block entities.

I'll see if we can make this work with the page variant entity or try and come up with a custom solution.

\Drupal\layout_builder\InlineBlockEntityOperations::handlePreSave to handle inline_block entities.

Yeah, maybe parts of that can be moved to a public service in core, to enable easier integration for contribs. to handle inline blocks.

OK a few more updates:

1. I got inline_blocks to work with \Drupal\layout_builder\InlineBlockEntityOperations
2. Implemented a bunch of todos.
3. Rename PageManager to PageManagerLayoutBuilderStorage. This matches the other LayoutBuilderStorage plugins and I think is a better name.
4. Removed the unused LayoutBuilderStorage annotation.

Ready for some feedback.

I'll re-roll this.

Re-rolled.

Thanks so much, @arshadcn!

I just did some testing, and inline blocks are now working, which is super awesome! This fixes #10.3, but I still experienced #10.1. I wonder if we need to attached some library somewhere in the add wizard so that the settings tray will work?

Looking at the patch code: it looks like #9.1, .2 and .3 are resolved! #9.4 which points out some // @todo in the section storage plugin still applies to the latest patch, though. Do those methods need to be implemented? They're both deprecated, so maybe not? Although, they both make reference to storage initialization, so I wonder if maybe this is why the UI doesn't work when first creating variant in the add wizard?

I think #10.1 and allowing adding sections and blocks during the initial "add" part of the wizard, is probably the biggest functional piece that needs to get fixed here.

Thank you so much, this is a very promising feature request! Great work especially to @arshadcn & @dsnopek! THANKS!

I've just tried #15 and the selection "Layout Builder" in the "Type" select appears! Also the layout can be assigned and blocks can be put into regions. We LOVE it!

We found the following bugs (using Drupal 8.7.3 and Adminimal Theme (if that may have any impact)) with page_manager 4.x-dev:

• When aborting without saving the variant before (clicked abort) and afterwards try to add a new variant, the old layout and blocks appear on the last step. No chance to "reset" cleanly. I had to delete the row from table "key_value_expire" to make it work again. So I'd guess on "Abort" the temporary value should be deleted, furthermore it shouldn't be loaded in completely differently named variants? In this case the last step of the wizard didn't save at all anymore. On clicking "Finish" or submit() via JS console didn't save it. No error message appeared.
• Blocks can not be moved (drag / drop) once added. The drag cursor appears but the element doesn't move.
• Blocks can not be edited once added, because no Icon is visible.
• Blocks can not be removed once added, because no Icon is visible.
• UI doesn't work when first creating variant in the add wizard (#confirming)

BTW: You should perhaps have a look at #3035174: Rename SectionStorageTrait to SectionListTrait regarding SectionStorageTrait for the future which may have impact on this.

Thank yo so much, great work!

OK new patch is ready for review. Here's a list of fixes.

1. You can now build layouts in the wizard. It works when you add a new page and when you add a new variant. (This fixes #10.1).
2. Renamed Layout Builder (in the wizard tree on the left) to Layout to match what we see when we edit layout for other entities.
3. Fixed a bug where the tempstore is not cleared when you save or abort a variant.
4. Fixed an issue where contextual links are not rendered.
5. Added content preview.

When aborting without saving the variant before (clicked abort) and afterwards try to add a new variant, the old layout and blocks appear on the last step. No chance to "reset" cleanly. I had to delete the row from table "key_value_expire" to make it work again. So I'd guess on "Abort" the temporary value should be deleted, furthermore it shouldn't be loaded in completely differently named variants? In this case the last step of the wizard didn't save at all anymore. On clicking "Finish" or submit() via JS console didn't save it. No error message appeared.

❌I've been able to reproduce same with Block variants. So maybe a bug in page manager and not necessarily with layout builder?

Blocks can not be moved (drag / drop) once added. The drag cursor appears but the element doesn't move.
Blocks can not be edited once added, because no Icon is visible.
Blocks can not be removed once added, because no Icon is visible.

✅This is all fixed now. Turns out that seven removes all contextual links for blocks. This affects adminimal as well since it uses seven as base theme. See #2487025: Remove contextual links in Seven. I added a fix to keep contextual links for layout builder blocks.

UI doesn't work when first creating variant in the add wizard (#confirming)

✅This is same as #10.1 and is now fixed.

Ready for another round of reviews @dsnopek @Anybody 👍

When I apply the patch, clear caches and then just visit the site front page, I get a fatal exception:

Error: Call to undefined function seven_preprocess_block() in page_manager_ui_preprocess_block() (line 171 of sites/default/modules/contrib/page_manager/page_manager_ui/page_manager_ui.module).
page_manager_ui_preprocess_block(Array, 'block', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('block', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 450)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 501)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 87)
__TwigTemplate_40a6292315b477a803ee4e2674bb313be00f336f9f83f99750d2e9aca3aff5c1->doDisplay(Array, Array) (Line: 443)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 414)
Twig\Template->display(Array) (Line: 422)
Twig\Template->render(Array) (Line: 64)
twig_render_template('modules/contrib/radix_layouts/plugins/layouts/radix_burr_flipped/radix-burr-flipped.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('radix_burr_flipped', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
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: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I think the call to seven_preprocess_block() needs to make sure we're actually in the seven theme (or a child theme of it) before making that call.

If I access an admin page, then I don't get the fatal error, so I'll see if I can test the rest of the patch despite this first issue...

Yeah just noticed this as well. Fix incoming.

I was able to test despite the seven_preprocess_block() thing, and everything works as expected per #18! The main issue (#10.1) was fixed, along with all the issues pointed out in #17 except for the about aborting the variant, but since that's also present with "Block page" variants, I think that's fine for the scope of this issue.

I skimmed the code, nothing new jumped out at me.

I think once the fatal error is handled, this will be ready for RTBC and maintainer review :-)

Fixed.

This is great! Thank you, we'll also test this now!

I just applied the interdiff from #23 and tried again. The fatal error is fixed!

I'm going to mark this as RTBC to try and attract the maintainers over to do some review. :-)

@Anybody: I'm looking forward to hearing how your testing goes as well!

Thank you very much @arshadcn it works!!

The only thing that still doesn't work is the drag & drop for existing blocks, but perhaps it's because we're using adminimal theme? I'll have a closer look as soon as I find some time. I guess it might be a separate issue, but let's wait for further feedback. In the wizard it's working, but not on the final layout page.

Wonderful, I'm so happy about this, you are great!

The only thing that still doesn't work is the drag & drop for existing blocks, but perhaps it's because we're using adminimal theme?

Drag & drop of blocks is working fine for me (I'm using the Seven theme). The adminmal theme could be related because there is the hack in there to workaround Seven: what if adminimal is doing something similar? Maybe we need a more generic hack that'll work regardless of which theme is messing things up?

Really amazing work done here, thank you all!. In a fresh D8.8 installation it works fine. Here some appreciations.

1. +++ b/page_manager.info.yml
   +++ b/page_manager.info.yml
   @@ -6,4 +6,5 @@ core: 8.x
   
   @@ -6,4 +6,5 @@ core: 8.x
    dependencies:
      - drupal:system (>=8.5)
      - drupal:block
   +  - drupal:layout_builder
   

   We introduce the logical dependency on the layout_builder module. Despite it is in core, it forces existing and new installations to enable it, even if it is not going to be used at all.

   IMHO, this feature would be better to be provided by a submodule. It should not be hard to move into 'page_manager_layout_builder' or similar submodule name. It would be also convenient to isolate the layout builder related issues and its specific support that it requires, such as the builder storage.

2. I got an exception trying to view a page that contains custom blocks from an imported config. The steps to reproduce:
   1. In a fresh D8.7 or D8.8 installation with standard profile, enable page_manager_ui
   2. Create a page with one layout builder variant, add a 1 col section and a custom basic block with arbitrary content
   3. Update and save changes
   4. Export configuration to sync
   5. Uninstall the page_manager module, created page will be removed from the active config
   6. Import configuration from sync

   The following exception occurs trying to access the page:

   Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 150 of /var/www/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).
   

3. As usual, performed changes and new features need test coverage.

Agreed on no dependency, but I don't think a submodule is necessary. PM can just provide extra code when LB is installed

1. +++ b/config/schema/page_manager.schema.yml
   @@ -142,3 +142,12 @@ display_variant.plugin.http_status_code:
   +display_variant.plugin.layout_builder:
   

   The schema can stay even if LB doesn't exist, not harming anything

2. +++ b/page_manager.info.yml
   @@ -6,4 +6,5 @@ core: 8.x
   +  - drupal:layout_builder
   

   Agreed that this should be removed

3. +++ b/page_manager_ui/page_manager_ui.module
   @@ -139,3 +139,36 @@ function page_manager_ui_local_tasks_alter(&$local_tasks) {
   +function page_manager_ui_theme_registry_alter(&$theme_registry) {
   ...
   +function page_manager_ui_preprocess_block(&$variables) {
   

   These should have @todos pointing to #3005403: Cannot delete or edit a block that is placed in a section of the layout_builder in case that gets resolved

4. +++ b/src/Entity/PageVariant.php
   @@ -23,8 +23,12 @@ use Drupal\page_manager\PageVariantInterface;
   + *     "storage" = "Drupal\page_manager\Entity\LayoutBuilderStorage",
   ...
   + *     "form" = {
   + *       "layout_builder" = "Drupal\page_manager\Form\LayoutBuilderForm",
   + *     },
   

   These could be added to a hook_entity_type_build() that checks for LB (instead of a separate submodule)

5. +++ b/src/Plugin/DisplayVariant/LayoutBuilderDisplayVariant.php
   @@ -0,0 +1,92 @@
   + * @DisplayVariant(
   + *   id = "layout_builder",
   + *   admin_label = @Translation("Layout Builder")
   + * )
   + */
   +class LayoutBuilderDisplayVariant extends VariantBase implements PluginWizardInterface {
   

   This plugin could be added via hook_display_variant_plugin_alter() behind a moduleExists check

6. +++ b/src/Plugin/LayoutBuilderStorage/PageManagerLayoutBuilderStorage.php
   @@ -0,0 +1,123 @@
   + * @LayoutBuilderStorage("page_manager")
   ...
   +class PageManagerLayoutBuilderStorage extends PluginBase implements ContainerFactoryPluginInterface {
   

   What's this annotation? Not coming from LB...

7. +++ b/src/Plugin/SectionStorage/PageManagerSectionStorage.php
   @@ -0,0 +1,233 @@
   + * @SectionStorage(
   + *   id = "page_manager",
   + *   context_definitions = {
   + *     "entity" = @ContextDefinition("entity:page_variant"),
   + *   },
   + * )
   + */
   +class PageManagerSectionStorage extends SectionStorageBase implements ContainerFactoryPluginInterface {
   

   This can stay as-is since it won't be discovered unless LB is installed

Thanks everyone for testing and reviewing.

@tim.plunkett I've implemented the suggestions and removed the hard dependency on layout_builder. Thank you.

@Anybody Thanks. I installed adminimal but could not reproduce the drag and drop issue (see gif below).

@manuel.adan I'll add the tests now.

Re-rolled.

Added JS tests.

The labels are different between 8.7.x and 8.8.x. I think we should use CSS selectors, or ensure compatibility with 8.7.x as it is the stable and target branch currently.

Great progress here, lovely too see! Here's a first review.

1. +++ b/page_manager.module
   @@ -0,0 +1,41 @@
   +      ->setHandlerClass('storage', LayoutBuilderStorage::class)
   

   We are overriding all page variants to use the LayoutBuilderStorage which feels wrong. I think this is something was mentioned previously in the issue.

2. +++ b/page_manager.module
   @@ -0,0 +1,41 @@
   + *   TRUE is layout_builder is enabled.
   

   Maybe change to: Returns TRUE if Layout Builder module is enabled, otherwise FALSE.

3. +++ b/page_manager_ui/page_manager_ui.module
   @@ -139,3 +139,40 @@ function page_manager_ui_local_tasks_alter(&$local_tasks) {
   +function page_manager_ui_theme_registry_alter(&$theme_registry) {
   

   We should have test coverage for this as well.

4. +++ b/page_manager_ui/src/Form/PageVariantConfigureForm.php
   @@ -38,7 +38,7 @@ class PageVariantConfigureForm extends FormBase {
   +    $form['variant_settings'] = $variant_plugin->buildConfigurationForm([], (new FormState())->setValues($form_state->getValue('variant_settings', []) + ['page_variant' => $page_variant]));
   

   Maybe split this into multiple lines for better readability

5. +++ b/src/Form/LayoutBuilderForm.php
   @@ -0,0 +1,140 @@
   + * Provides a form containing the Layout Builder UI for Layout Library.
   

   for Layout Library => for Page Manager.

6. +++ b/src/Form/LayoutBuilderForm.php
   @@ -0,0 +1,140 @@
   +   * The Section Storage Manager
   

   Missing a ending punctation

7. +++ b/src/Form/LayoutBuilderForm.php
   @@ -0,0 +1,140 @@
   +   * Constructs a new DefaultsEntityForm.
   

   DefaultsEntityForm => LayoutBuilderForm

8. +++ b/src/Plugin/DisplayVariant/LayoutBuilderDisplayVariant.php
   @@ -0,0 +1,92 @@
   +        'sections' => [],
   

   This indentation is not correct.

Fixed the tests and implemented suggestions from #35.

after apply the patch #36, I don't see there is a layout-builder variant in the variant-type drop-down selection ? or am I doing the wrong way ?

@freelylw Do you have the layout_builder module enabled? This patch only adds a soft dependency, so it won't do anything if the layout_builder module isn't enabled. You may also need to clear caches

@dsnopek I enabled the layout_builder module already, and clear the caches as well, its a fresh drupal 8.7.2 installation. still no layout-builder variant showing.

Still failing on 8.8.x. Let's try this again.

#41 works in my drupal8.7.2

I can see we still missing 2 things then we will have something the same like when we were in drupal7 panel_page

1: there is no auto-drag for left/right of the section width, its a fix percentage at the moment, in reality, it doesn't work in this way.
2: why we don't have "Disable Drupal blocks/regions" on the page that we had in D7 version. at the moment, after you create a page, the default system block still showing .

@freelylw: I'm glad it's working for you now! Please open new issues for those other things in #43 - this issue is just to allow Layout Builder to be used for Page Manager variants. Those would require changes in a bunch of other places that are outside the scope of this issue (ex. a new layout plugin for fully flexible column widths, a setting to swap in a DisplayVariant to hide the global blocks, etc).

#41 Failing test here is tricky, since it passes locally for me. Tried re-running to see if was random, but seemed to fail again :( Is anyone able to reproduce the failing test locally?

#35.1 Still needs to be addressed.

The patch seems to be working for me, although I haven't tried anything really complicated yet.

The tests are also passing for me locally, so I kicked off some new test runs just to see what happens.

I'm running PHP 7.2.16 in a docker container, tested using the run-tests.sh script.

And now it looks like PHP 7 worked but has coding standards errors, whereas PHP 7.1 and 7.2 failed.

My bad for accidentally setting off the PHP 5.5 test, it's one of the defaults and I wasn't paying enough attention.

Checking what fixing the new coding standards errors does to the PHP 7 test.

Testing if waiting for the selectors to exist fixes the tests.

Okay, trying waitForElementVisible.

Well, after some further testing, it would also seem that contexts are not being passed into layout builder. For example, creating a layout builder variant of the default node view page does not allow you to place any node-related blocks on the page.

Even global contexts, such as the current user, don't seem to work - you can add and even preview them in the layout builder:

But when you try to view the page, you get an exception:

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\ContextException</em>: The &#039;entity:user&#039; context is required and not present. in <em class="placeholder">Drupal\Core\Plugin\Context\Context-&gt;getContextValue()</em> (line <em class="placeholder">73</em> of <em class="placeholder">core/lib/Drupal/Core/Plugin/Context/Context.php</em>).

This is so nice :) Thank you for the Patch

Seems that the patch is not applying for the latest stable version of Page manager.
Waiting for Drupal 8.8.0 to be out with the stable Layout Builder.

#52, Layout Builder was stable in 8.7.0 (released in May 2019).

Thank you Tim, Noted about that.
already working on
#3082049: Initialize [Varbase Layout Builder] with starter set of layouts and styling options for sections

But I have noticed that Drupal 8.8.0-beta1 do have an administration title for Section Configuration

It would be nice to have the layout builder variant with the page manager module out of the box. not sure about the administration title. or all will be synchronized in a blob in the database.

Hi all,

Summarizing remaining todos from previous comments : 

• Fix #35.1
  

  We are overriding all page variants to use the LayoutBuilderStorage which feels wrong. I think this is something was mentioned previously in the issue.

• Fix #51.1
  

  Well, after some further testing, it would also seem that contexts are not being passed into layout builder. For example, creating a layout builder variant of the default node view page does not allow you to place any node-related blocks on the page.

  • Reproduced : Entity view (Content) from CHAOS TOOLS section and all blocks from the CONTENT section are missing
     
• Fix #51.2
  

  Even global contexts, such as the current user, don't seem to work - you can add and even preview them in the layout builder But when you try to view the page, you get an exception.

  • Reproduced too, see detailed error
     
• Fix tests

Some additional issues I found in testing patch #50 : 

1. User has the ability to add block Entity view (Page Variant) but clicking on Add block doesn't work and log an error. Any other block user tries to add next will fail in the same way (ajax throbber displaying but nothing happening)
   • This block doesn't seem useful anyways, maybe it should be filtered out of the list
   • Gif here
      
2. wsod + same error in dblog appear when trying to add a Layout Builder variant to a page where a Panel variant already exists. Could not reproduce on newly created page though : 
   • Gif here
      
3. Core block Page title is missing from available blocks
   • That's a shame, it's a useful block
     Screenshot here
      
4. User has the ability to add block Main page content to Site template page (created by the Panels Everywhere module) but clicking on Add block doesn't work and log an error. Any other block user tries to add next will fail in the same way (ajax throbber displaying but nothing happening)
   • Gif here

Good news, selection criterias based on url path seem to work fine)

Made some changes to the patch #50. In this new version, contexts should be passed to this new variant. Attached are some screenshots of contexts working.

+++ b/page_manager_ui/src/Form/PageVariantConfigureForm.php
--- /dev/null
+++ b/patch.patch

+++ b/patch.patch
+++ b/patch.patch
@@ -0,0 +1,904 @@

@@ -0,0 +1,904 @@
+diff --git a/config/schema/page_manager.schema.yml b/config/schema/page_manager.schema.yml
+index 49e5cfc..95b1483 100644
+--- a/config/schema/page_manager.schema.yml

I bet this patch should not be included in this patch, please also provide interdiff of changes from previous patch to simplify review

Sorry I didn't provide interdiff before. The only thing I did was to implement the ContextAwareVariantInterface in the variant and to create sample values for context during the preview.

One thing I noticed while using this new variant is that it doesn't allow changing the page title, but that's something I did't include in the patch.

I found that layout_builder uses `context.repository` service to provide context. Still can not understand why/how node provides its context. This module does it always, even it can not :)

For some reason (localy at least) i found that apache doesn't process /exampleroute well, changed this.

We should probably update the issue summary, based on #55. It is quite unclear what remains to do here :)

I've rolled back changes i made during patch attached in comment #60, and now i found a reason of wrong context provided during editing of layout builder context. I've realized also, that it is impossible to add entity config context to context list via UI since this issue https://www.drupal.org/project/ctools/issues/2696819

Reproduced tests non-working drag-and-drop but have not found a solution to fix it

Realized that layout builder form (for adding new block) puts contexts taken from context.repository service. Replaced name of current_user context (not sure if it is good decision) but covered case when user can select wrong context for User entity view block

Looks the patch hit a wall on contexts which are not fixed in related #2511568: Create "context stack" service where available contexts can be registered

big interdiff because i've removed "patch.patch" (i think it was a mistake). @andypost problem is not in ctools context but in layoutbuilder creation form. As i mentioned in previous comment - it takes context list from context.repository, but there is another machine name, so, i changed context name provided by page_manager also to don't duplicate it. Need to discuss this point.
About panels_everywhere: i suggest to do it in issue opened under panels_everywhere project

Rerolled version

Some fixes after re-rolling of patch

Hope it is last fix for current state. Next thing is to think about do we really need update of context name? If yes, we need update of current configs (to replace context name) and tests for it :)

Thank you very much, YurkinPark, impressive work!

After updating to the latest .dev and applying patch #77 I get the following error:
TypeError: Argument 1 passed to Drupal\page_manager\EventSubscriber\CurrentUserContext::__construct() must be an instance of Drupal\Core\Plugin\Context\LazyContextRepository, instance of Drupal\Core\Session\AccountProxy given

Before we were working with beta4 + patch#31 successfully.

Additional note:
We had to use the module "layout_builder_st" (based on core issue #2946333: Allow synced Layout override Translations: translating labels and inline blocks) in a different project and it seems that it crashes with this implementation.

@anybody , problem you have described in comment 78 can be resolved by clearing cache, because service definition is changed

@YurkinPark, thank you - of course I did that prior to my comment but it didn't work... problem persists. But don't care too much about this, we've been using the early patches already and it's okay if in the worst case we have to recreate the pages when this is committed. I just wanted to leave the information here for you.

Ok, news! :) I finally found out why a cache clear did not help for me. After applying the patch from #77 I had to update the page_manager page access condition the following way in

page_manager.page.my_page_xyz.yml:
New (working):

access_conditions:
  -
    id: user_permission
    permission: 'my permission XYZ'
    negate: false
    context_mapping:
      user: '@user.current_user_context:current_user'

Before it was:

access_conditions:
  -
    id: user_permission
    permission: 'access drowl admin dashboard'
    negate: false
    context_mapping:
      user: current_user

(See last line!)

which was generated by an older version of Drupal Core or Page Manager module.
We're using user_permission_condition module, but that wasn't changed in the meantime.

So maybe this is unrelated to the patch and simply appeared because with the patch I switched from 4.0-beta4 stable to 4.x-dev. After updating the yml (or re-saving the access conditions for that page in page manager -which was unaccessable due to that exception), everything works fine now.

Any ideas where to open that issue?
The ugly side-effect was, that every page showing a menu link to that page manager page also broke due to the missing context.

Your notice is related to current patch for sure. I noticed in comment 77 that context name is changed because of layout builder (it provides exactly this context) thats why i decided to ask community for this change

After using #77 in many many projects successfully I can confirm RTBC. Of course I'd be happy about more feedback. Anyway its a great and large first step to this important feature.

This can not be released because there is no prepared updates. @Anybody you have case when you applied patch and your instance was down. hook_update will update existing instances to don't have WSOD.

Well but wasn't the reason here that I applied older patches on that sites before? Or did I get that wrong?
In that case I think an update path from patch to patch would be nice but optional?

Module should not provide upgrades between patches but at least post update hook should be added to cause cache clear and rebuilding of plugins

1. +++ b/page_manager.module
   @@ -0,0 +1,41 @@
   +function page_manager_entity_type_build(array &$entity_types) {
   +  if (_page_manager_is_layout_builder_enabled()) {
   +    /* @var $entity_types \Drupal\Core\Entity\EntityTypeInterface[] */
   +    $entity_types['page_variant']
   +      ->setHandlerClass('storage', LayoutBuilderStorage::class)
   +      ->setFormClass('layout_builder', LayoutBuilderForm::class);
   

   would be great to add comment why that fires in this hook instead of alter

2. +++ b/page_manager.module
   @@ -0,0 +1,41 @@
   +function page_manager_display_variant_plugin_alter(array &$definitions) {
   +  // Disable the layout builder plugin if layout builder is not enabled.
   +  if (!_page_manager_is_layout_builder_enabled()) {
   +    unset($definitions['layout_builder']);
   

   Sadly no way to exclude plugin other way

3. +++ b/page_manager_ui/src/Form/AddVariantContextsForm.php
   @@ -35,7 +35,7 @@ class AddVariantContextsForm extends ManageContext {
   -    );
   +    )->toString();
   
   +++ b/page_manager_ui/src/Form/PageVariantContextsForm.php
   @@ -36,7 +36,7 @@ class PageVariantContextsForm extends ManageContext {
   -    );
   +    )->toString();
   
   +++ b/src/Entity/PageVariant.php
   @@ -7,6 +7,7 @@ use Drupal\Core\Condition\ConditionPluginCollection;
   +use Drupal\Core\Plugin\Context\ContextInterface;
   

   this changes looks unrelated

4. +++ b/page_manager_ui/src/Form/PageVariantConfigureForm.php
   @@ -38,7 +38,7 @@ class PageVariantConfigureForm extends FormBase {
   -    $form['variant_settings'] = $variant_plugin->buildConfigurationForm([], (new FormState())->setValues($form_state->getValue('variant_settings', [])));
   +    $form['variant_settings'] = $variant_plugin->buildConfigurationForm([], (new FormState())->setValues($form_state->getValue('variant_settings', []) + ['page_variant' => $page_variant]));
   

   Why formstate needs to store whole entity?
   I think form object already has page variant entity

5. +++ b/src/Plugin/DisplayVariant/LayoutBuilderDisplayVariant.php
   @@ -0,0 +1,121 @@
   +  public function getWizardOperations($cached_values) {
   +    $operations = [];
   +    $operations['layout_builder'] = [
   

   empty array init is useless

6. +++ b/tests/src/Unit/CurrentUserContextTest.php
   @@ -25,32 +23,20 @@ class CurrentUserContextTest extends PageContextTestBase {
   -    $account = $this->prophesize(AccountInterface::class);
   -    $account->id()->willReturn(1);
   -    $user = $this->prophesize(UserInterface::class);
   ...
   +    $currentUser = $this->getMockBuilder(AccountProxyInterface::class)
   +      ->disableOriginalConstructor()
   +      ->getMock();
   ...
   +    $contextRepository = $this->getMockBuilder(LazyContextRepository::class)
   +      ->disableOriginalConstructor()
   +      ->getMock();
   

   Any reason getMock() used instead of prophecy?

Does this patch correctly with beta 5 or is my system being stupid as I am getting errors when I try to patch manually and with composer it just fails.

Thanks,

@christopher-riley patch attached in comment #77 can be applied correctly. May be you have another patches in your list?

That is what I was afraid of I am using the patch https://www.drupal.org/project/page_manager/issues/3124470 to correct the issue with selection criteria. Hopefully these will both get committed soon so I can avoid having to patch anything.

New version of patch contains all previous changes and post_update which allow you update all page_variants with new current_user context name and tests for post_update

This is so GREAT news, thank you very very much @japerry! I'm really excited!

Just wanted to let you know that running the update leads to

> [notice] Update started: page_manager_post_update_replace_current_user_context
> [warning] Invalid argument supplied for foreach() page_manager.post_update.php:32
> [notice] Update completed: page_manager_post_update_replace_current_user_context

on all our pages, but it works.

While this patch (now merged into dev) integrates Layout Builder into the Page Manager UI, it doesn't appear to provide for in-place editing (on the page itself) and there is no Layout tab (as found if a content type has Layout Builder enabled).
Am I missing some way for a user to edit the page content and layout without having access to the administration side of the UI?

Hey japerry thanks for responding.
I've added a "Layout Builder" variant and while that provides the layout UI, it's only on the administration side.
If I visit the created page there is no "Layout" tab as can be found when a regular node page is created with Layout Builder enabled for it.

My use case would be user 1 creates a site homepage via Page Manager with the Layout Builder variant.
Lower admin users should be able to add content to this page in the sections but not have access to the Page Manager administration UI.

Awesome work everyone! Just for reference though, using the Layout Builder variant still doesn't work with Panels Everywhere as discussed here: #3143487: Not compatible with "Layout Builder" variant as site template (Workaround found)