Can we use layout_plugin module to provide different templates for paragraphs

You mention a limit of "up to 12 fields in the row". Where is this limit from?

If we have some default layout, how would you apply the layout to the paragraphs?
Is this issue about selecting a layout per paragraph type? You just mention "paragraphs" and omit the word type.
Then you would display groups per layout region to assign the fields?
Or is there some UI offered from layout module that is plugged into the paragraphs UI?

I need more elaboration on how the things work to understand the effect.
Related screenshots / links would help... or even a mockup if word based description is not accessible enough.

I've been wondering along the same lines as the IS. Paragraphs is the natural tool to turn to for allowing content editors to build out complex pages like landing pages. But I don't see an easy way right now for content editors to work with the layout of a page.

One could in theory panelize a page, and place an empty paragraphs field in each region, allowing the editor to nest whatever paragraphs they want in each region. But this still predetermines the layout and gives no control over it to the editor.

What would be very nice (and relatively simple?) would be a built in paragraph type called "Layout". This would:

- build on layout_plugin, D8's new standard for layouts

- The Layout paragraph type would simply be a selector that enabled the editor to choose a layout from those defined according to layout_plugin

- the "fields" of the Layout paragraph type would be empty paragraph fields (i.e. entity reference revisions field pointing to the paragraphs entity), one for each region of the layout.

- the site builder would configure the Layout field to set what layouts where available to the editor (from amongst those known to layout plugin), and what paragraphs types could be used within its regions.

The result would be that site editors would to give content editors supervised control over layout as well as content.

What I'm describing can be achieved already manually, by defining paragraph types that contain other paragraph types (one for each possible layout to be offered) and positioning with custom css or using Classy paragraphs. But using the layouts of layout_plugin would tap into a layer of standardisation and code reuse: the paragraph types would be automatically created for you, and themes would already know how to position them.

I've just figured out that using display suite, we can already enjoy the benefits of layout_plugin with paragraphs.

Because paragraphs are entities with a "manage display" page, thanks to display suite you can choose a layout for a paragraph on that page, and decide what fields go in which regions.

Therefore, you can create in practice apply predetermined layouts in a paragraphs field by:
- installing display suite
- adding a paragraph type called e.g. "2 column section"
- add 2 fields to the paragraph type, "entity reference revisions: paragraph", with names "left" and "right"
- on the manage display page of the paragraph type, set the layout of that paragraph type to "2 column flexi" and place the "left" paragraph field in the left layout region, and right in right
- Go to your content item, and wherever you can normally insert a paragraph, choose to insert a "2 column section" paragraph, and bang!

You can now split any paragraphs field into 2 paragraphs fields, layed out side by side. Best of all, it's nestable so you can split either side again (and again ...) if you want to.

The only drawback I see is that I'd have to manually a paragraph type for each layout I want to allow editors to use, but it seems unlikely I'd want to offer a large number so it's not much of a problem.

@Pivica. I'm not very clear about the bigger picture of your thinking. Are you thinking about
1) how to use paragraphs module (as it is now) to do powerful non-obvious things? or
2) how to develop paragraphs to deliver functionality that can't be delivered now? or
3) how to improve the UI of paragraphs module when it's doing more complex tasks?

For example, when you talk about an "additional paragraph item called group which is used to group other paragraph items and it can also have subgroups.", this seems to be something that this module already allows site builders to create for themselves? We can already create our own paragraph type called "group" and inside it place just a single entity reference revisions paragraph field. This gives us nestable paragraphs. Have you overlooked this, or are you talking about improving the UI for it, or documenting it better?

More generally, one of the interesting things about paragraphs for me is how well it plays with fields, display modes, other modules, etc. I'm wondering if much of what you describe seems like it could already be achieved by adding editable fields to a paragraph type, hiding (disabling) those fields in the display mode, and using other modules to alter the rendering of the whole paragraph depending on the value of that hidden field. I'd love to learn more about how to do this, but it seems like the issues would be identical for any Drupal entity that supports fields and display modes. So a much more generic module (e.g. the Conditional fields module), not explicitly Paragraphs aware, could support this.

I look forward to discussing more and learning from you!
Jonathan

While discussing about paragraph reusability i discovered that our co-project Atoms is now Bricks and there was some interesting progress regarding the aspects mentioned above. We might want to investigate that to understand their moves and if they also apply to how we think about Layout.
https://www.drupal.org/project/bricks

I tried to install Bricks but hit various problems - I filed an issue.

Looking at his screenshots, it seems like he's hitting what seems to me to be the biggest issue for us: UX problems.
When you start nesting editable content chunks on an content edit form, the UX starts falling apart.

At the moment I'm inclined to think that Paragraphs has all the necessary mechanics for building rich layouts, the challenge is to find a UI that works.

I'll start an new issue about UI improvements for nested paragraphs.

About nesting: In File Entity we offer an edit widget that opens editing the referenced item in an overlay. That's clearly by design to allow us keep the parent edit form uncluttered. This might be a problem though with multiple levels of nesting... The overlay however is more complex in implementation because it needs separate routes / callbacks and understand the context... ;-)
Others might prefer inline editing for "all" cases.

Note that paragraphs already offers various edit modes, with collapsed preview and only inline editing on click..

IMHO we need to carefully craft something that works nicely by default, and provide a few options that make sense and support special cases... Yet still stay limited in clear boundaries of cases we want to support because they represent our major cases and mindsets.

It makes sense to keep the module focused on its prime use cases.

Overlay is an interest possibility. It doesn't reliably solve the problem, as if you're heavily nested then the content of the overlaid form itself can then be too complex.

To discuss what can be done for UX of nested within the current paradigm I opened #2642810: UX improvements for nested paragraphs, complete with screenshot of a tidier UI.

I was on the Drualcon Vienna session about The Layout Initiative in core:
https://youtu.be/56tu6x-Em1o?t=4m50s

It would be awesome to have this for paragraph also.
I ask the presenter about it:
https://www.youtube.com/watch?v=56tu6x-Em1o&t=10m30s

In short it should be doable. There is a patch for core do be able to support itemes by thier delta. After that it just need a UX/glue code to get it to work.

IN D8 I have been using display suite (ds) to control the paragraphs layouts and it seems to work reasonably well. However the paragraph preprocess hook does not fire because ds_entity_view becomes the theme hook instead.

This means that for example the following "content" variable is needed to fish out a field value, not "paragraph".

set imgurl =  file_url(content.field_para_bkgnd_img[0]['#item'].entity.uri.value)
....
<div {{ attributes.setAttribute('id', settings.wrapper_id).addClass(my-para-class', settings.wrapper_classes) }} style="background-image: url('{{ imgurl }}')">

This works and I've been using it. Not a responsive background image here tho!
see also #2678104: Get image URI from paragraph and #2831903: Improve Paragraphs preprocess, THEME_preprocess_paragraph, field + twig documentation

Promoting for some more attention. There's more popularity of the topic and we need to research and decide for Paragraphs if we can help people to easily benefit from this.

I described this method at the Drupal meetup in Boston last night to several people and they were interested!

My main issue remains working with background images particularly since this method doesn't make it easy for me to attach the unique ID to the class of the paragraph, which would be the best way for this to work with https://www.drupal.org/project/bg_image_formatter

I added note here #2824884: Drupal 8 Port for attaching ID . this method does work to attach ID if you are NOT doing the display suite approach, and instead you are just making regular paragraph templates. I copied it from a bootstrap paragraphs patch.

@EclipseGc is working on making the layout builder that is in core now compatible with paragraphs as well: https://github.com/timplunkett/d8-layouts/tree/fix-paragraphs. I would recommend you talk to him how you can help.

Now the initiative is on D8 Core as experimental module. Anyone has an update?

The link you posted @Berdir is not working anymore.

Does this module tackle the issue? https://www.drupal.org/project/entity_reference_layout

Here is an article about it: https://atendesigngroup.com/blog/drupal-8-paragraphs-layout-discovery

Does this module tackle the issue? https://www.drupal.org/project/entity_reference_layout

I have tried the module. It looks very promissing.

Here is an article about it: https://atendesigngroup.com/blog/drupal-8-paragraphs-layout-discovery

I have implemented the structure a bit differently. Instead of creating a new layout field on a content type, I have created a new Paragraph "Layout".
I have added the layout field to this "Layout" paragraph using an additional "Section" paragraph as mentioned in the article.

I think with https://www.drupal.org/project/layout_paragraphs and https://www.drupal.org/project/mercury_editor we can finally close this years old issue?
Please reopen, if someone disagrees.