Provide frontend editing experience for Layout Paragraphs.

+1

Im currently testing using our custom front end theme for content editing, and find it works pretty well. Uncheck "use admin theme for content editing" and try it.

I do need to add extra css to the node edit form to adjust the default layout_paragraphs color and spacing to suit our theme, and pull in the css libraries for all placeable paragraph types so they display correctly immediately when placed.

Can you give details, please?

Edit: double-post sorry, see below.

@thomas.wardin: At /admin/appearance, under "administration theme", uncheck "use the administration theme when editing or creating content".

Now your front-end theme will be used when editing content, with layout paragraphs enabled.

There will be some issues with increased spacing to accommodate the layout paragraphs interface, and your front-end theme will need to handle those, as well as override the assumptions layout paragraphs makes about things like background colours. You can attach css whenever layout paragraphs is active by using libraries-extend in your front-end theme's .info.yml file:

libraries-extend:
  layout_paragraphs/layout-paragraphs-widget:
    - mytheme/layout-paragraphs

And define the layout-paragraphs library and its css file(s) in your theme's .libraries.yml file.

It turns out you don't need to pull in all the css libraries for each possible type of paragraph, that happens automatically when one is added.

I'm in the same situation, we only want this for very custom pages. It's next on my list to investigate. I suspect I'll probably write a quick custom module if there's nothing small and simple already available.

How would you expect to edit non-paragraph fields if the other fields are not displayed? Would you have to edit those via a separate step?

In my case I change the sidebar to an expandable html5 details element, move it to the top (or maybe bottom), and put all non-paragraph fields in there (possibly including the title). For a new node, we expand it by default. We do try to put as many fields as possible in layout paragraphs however, for consistent experience.

To do things like this, your theme can:

• Override the node-edit-form.html.twig template
• Implement hook_form_node_form_alter()
• Implement hook_preprocess_node_edit_form() (possibly)
• etc

I think given the huge diversity and complexity of contrib and custom themes, and the richness of the Drupal field ecosystem, trying to do anything like this is always going to require theme-specific customisation and workarounds, and achieving a consistent experience will be difficult. Your theme would need to be built with layout paragraphs in mind at all times.

Have you seen the Aten article and its videos? That looks like a pretty nice implementation, and seems to be using their front-end theme. Or perhaps a custom admin/editing theme that uses their front-end theme as a base theme, to ring-fence the problems. I might try the latter, and switch that in for node-edit only.

I dont want my editors needing to edit in 2 different places, with 2 different UIs, for the same page. They get confused enough about how it all fits together anyway...

I was looking to see if there were any issues discussing this and found another as well so relating it to this one.

This discussion could be the kernel of something that eventually makes it into Drupal core as "true wysiwyg editing" in a few years time. Don't hold your breath...

With regard to geysir - all that has to do is edit content paragraphs in isolation. What we need to deal with here is editing paragraphs that may be layout sections, paragraphs that may be layout content, and paragraphs that may be both (layout section paragraphs may have visible fields). Then there is the possibility of layouts nested within layouts.

That makes a simple interface like the one geysir provides rather more difficult within the context of a front-end theme, because in that theme, at the most basic level, there may be no margin or padding around the parent layout section and the child layout content. If so, the content control/edit widgets can overlap or obscure the section control/edit/widgets, depending on backgrounds, z-indexing and other factors. I'm having trouble with this in my current implementation for content that should bleed to the section edges. It's hard to provide true wysiwyg tools in that situation. There's a good reason the default styling for layout paragraphs adds some margin/padding, even in the admin theme.

There is no way layout paragraphs can or should provide default styling to deal with this this for every front-end theme. If a theme wants to support layout paragraphs editing, it has to be the responsibility of that theme to handle the layout vs content distinction while editing.

Just providing some kind of toggle for "edit using front-end theme" sounds simple, but would result in a lot of confusion and support requests from site builders and themers using a contrib or custom theme, who do not (and need not) understand the interaction between the theme and layout paragraphs, and expect some kind of auto-magical wysiwyg overlay. We are not even close to that yet.

Let's switch this interesting and important discussion to 2.x as further development will happen there. Still very very good points and interesting discussion, while hard to implement ;)

+1 for this feature.

I tried but no luck

libraries-extend:
layout_paragraphs/builder:
- mytheme/global

+1 for this feature

I've created a Issue fork and made some changes to allow that the field displays the default theme templates and load a library.

1 - After update with the changes, go to /admin/config/content/layout_paragraphs/default-theme and check the checkbox option.
2 - Add your default theme library to load js and css. I created a separated styles file includind .lp-builder prepend each style so the styles will be applied on Layout Paragraphs Field only without conflicts.
Eg: mytheme/admin-library

I added the hook_theme_registry_alter to change paragraphs item and to add all your paragraphs--type templates too (if there is).
This modification search for template files inside your custom theme.

I hope it's useful and can set a path for this to be implemented.

An alternative that the module already has is to use the Layout Paragraph Builder field formatter on the 'manage display' and add or edit the paragraphs within the default theme.

Feel free to use, modify and even think it's bad :)

We're also working on improving the editorial experience here and tried out the MR in #22. It sorta worked for us, but we made a few changes:

1. In our case, we needed other templates added to the edit page, not just the Paragraph templates. For example, one of our Paragraph types displayed a list of node teasers, but those teasers were displayed using the default node template rather than the one defined in the default site theme. To solve this issue, we added a new "Additional templates to load" setting to the "Default theme" form. Any templates set there will also get added.

2. To support the new setting field above, we needed to load the theme registry for the default theme. We added a helper function to do this. Having that default theme registry array allowed us to set values like this:

$theme_registry[$template_name] = $default_theme_registry[$template_name];

This also allowed us to simplify the logic used to add Paragraph templates in the same way. Now, rather than looking at the file system to see what templates exist, we can look directly at the theme registry.

One caveat here is that we needed to call Drupal\Core\Theme\Registry directly because the default "theme.registry" service only returns data for the *active* theme. The core theme registry class called here is marked as @internal, but we could not figure out any other way to do this.

3. The MR in #22 will only add the Paragraph templates to the admin theme if you flush the cache while on the node add/edit page due to this code:

$route_name = \Drupal::routeMatch()->getRouteName();
$route_is_admin = \Drupal::service('router.admin_context')->isAdminRoute();

// Just do that if the theme is 'admin' and the page is the add or edit node form.
if($route_is_admin && ($route_name == 'entity.node.edit_form' || $route_name == 'node.add')) {

The issue is that hook_theme_registry_alter() functions are run only when the cache is flushed, not on every page load. So, for this to work, the conditional above must be removed. That will mean that the Paragraph templates are always added to the admin theme which is probably OK. That is how the MR worked in the first place when the cache was flushed from the node add/edit page, but I don't think that will cause any problems.

I've updated the branch in Git and added a patch.

One caveat here is that we needed to call Drupal\Core\Theme\Registry directly because the default "theme.registry" service only returns data for the *active* theme. The core theme registry class called here is marked as @internal, but we could not figure out any other way to do this.

Well... The signature for that class' constructor changed in Drupal 10.3! I've updated the code in the issue fork and added a new patch that will make this work with 10.3 and prior versions.

Is this patch working in the direction of Layout paragraphs using the frontend CSS for the display of the Layout editing UI? That would be huge.
I last worked with this module in 2022 and it was my biggest gripe with it that the editing UI was completely unstyled because it did/could not call frontend CSS.
This was the one area where core Layout Builder was better than Layout Paragraphs.

Could the patch from #25 apply to 2.1.x ?

I will note that patch #25 does seem to work against 2.1.1 to load in a site's base theme for the paragraphs with just the checkbox enabled.

However, if you don't enter a value in the "Default theme library" field, the patch will throw warnings.

I might suggest updating the $enabled line in /src/Element/LayoutParagraphsBuilder.php to check for a non-empty config setting.

    // Loading default theme library configuration.
    $default_theme_config = \Drupal::config('layout_paragraphs.default_theme_settings');
    $enabled = $default_theme_config->get('display_default_theme');
    if($enabled == 1
      && !empty($default_theme_config->get('default_theme_library'))) {
      $element['#attached']['library'][] = $default_theme_config->get('default_theme_library');
    }

#25 return an error on D11.1:

PHP Fatal error: Type of Drupal\layout_paragraphs\Form\LayoutParagraphsDefaultThemeForm::$typedConfigManager must be Drupal\Core\Config\TypedConfigManagerInterface (as in class Drupal\Core\Form\ConfigFormBase) in /var/www/html/web/web/modules/contrib/layout_paragraphs/src/Form/LayoutParagraphsDefaultThemeForm.php on line 14

Fatal error: Type of Drupal\layout_paragraphs\Form\LayoutParagraphsDefaultThemeForm::$typedConfigManager must be Drupal\Core\Config\TypedConfigManagerInterface (as in class Drupal\Core\Form\ConfigFormBase) in /var/www/html/web/web/modules/contrib/layout_paragraphs/src/Form/LayoutParagraphsDefaultThemeForm.php on line 14

RE #31, if you made changes, please also apply them to the merge request. The patch workflow is deprecated. Also without interdiff, it's very hard to know what you changed.

I tested the merge request on 3.0.0-alpha3 (on D10.4.5) and it works (and applies) fine. There are some CSS issues but that's due to our custom theme and components integration which are depending too much on the global CSS styling. I managed to get the layout editor in the back-end to look like a 1-1 copy of what the front-end is showing! Very nice :-). Now just for us to ensure the front-end styling does't alter the back-end buttons/tabs/forms etc.

I will create a merge request with changes for 3.0.x

To fix #31 we need to solve this deprecation for D11 https://www.drupal.org/node/3404140 but that means bumping the min version requirement to D10.2 which I think is fine this day of age.

I created a 3.0.x branch and fixed the deprecation. The failing tests are not related to the changes here as the baseline for 3.0.x is also failing.

I accidentally borked the merge request for 2.0.x by merging 3.0.x onto that branch, I reverted that commit but GitLab is still showing more changes -.-.

In this case @bramdriesen, I recommend to create a new merge request with changes.

@sharique There is a new MR for 3.0.x

I don't think it makes sense to backport this to the 2.0.x branch as there are no fixes added to that branch anymore.

Thanks for all the work on this. A few thoughts:

- It looks like more work has happened since this was RTBC, so resetting to Needs Review.
- Ideally we'd flag as RTBC once multiple people have tested / provided feedback.
- @bramdriesen - you're 100% correct about tests failing for LP 3x - I added this issue and we're working on it.
- And finally... can someone (@bramdriesen maybe?) provide an overview of what this MR actually does? Does this impact the front-end editing experience, or rather bring frontend styles to the backend edit form? Screenshots might be helpful as well.

FWIW, my team has standardized on Mercury Editor as the way to bring Layout Paragraphs content editing more directly into the frontend (among other authoring enhancements). We worked on multiple other directions, each with their own pros / cons, before going that route.

Does this impact the front-end editing experience, or rather bring frontend styles to the backend edit form? Screenshots might be helpful as well.

Basically what this does is apply the front-end CSS to your back-end editing form. It provides a config form where you can specify the specific library (as in libraries.yml) from your theme to use. There is also an option to load additional twig templates, although I haven't found the need to use this. It doesn't change anything to the editing UI, nor the front-end.

The only minor annoyance (which to be honest is most likely because this is a very long running project since D8) with this is that if your CSS is too broad (e.g. you themed on button, or general form field styling) it gets applied to the back-end as well. To prevent that one could theme more specific or ensure that when working with SDC's for example all required CSS is present in the component for it to render properly, instead of relying on global styling.

Got it, thanks.

The only minor annoyance (which to be honest is most likely because this is a very long running project since D8) with this is that if your CSS is too broad (e.g. you themed on button, or general form field styling) it gets applied to the back-end as well.

This is exactly why we moved away from this direction. It is virtually impossible to both apply styles from the front-end to backend forms and prevent unwanted impact on the backend ui, at least in any way that is holistic and reasonably maintainable.

I would look at providing this functionality in a separate module or look at other modules (for example, Mercury Editor) that are already doing this kind of thing. I think the the overhead of maintaining this functionality, required test coverage, adequate handling of broad use cases, etc. is too difficult to justify adding it to layout paragraphs. All of that said, providing this as a separate module with a dependency on LP should be simple to do and to maintain for your specific purposes.

See comment #42.

Thank you @justin2pin, for the reply.
The Mercury Editor is a great module, but we are more used to a classic paragraph editing experience.
Ok. I will try to move this patch into a separate module.

We can easily isolate the custom theme CSS from the Drupal backend.

editor-layout-paragraphs-styles.scss

.lp-builder:not(.is-navigating) {
  @import '../../../../contrib/bootstrap5/scss/style.scss';

  @import "_variables";
  @import "_typography";
  @import "_mixins";
  @import "common";

  .lpb-layout {
    padding: 0;
  }

  .js-lpb-ui {
    font-size: 1rem;
  }

  .contextual {
    display: none;
  }

  .paragraph--type--layout {
    overflow: visible;
  }
}

Based on this issue created a separate module 'Layout Paragraphs Theme Extension'.
Thank you to everyone who contributed to resolving the issue.