Problem/Motivation

Our current demo is not yet a real representative example.

There are nice projects being developed.
An example is the Wondrous Paragraph Types
https://github.com/WondrousLLC/paragraph_types

Proposed resolution

This is not about a Demo and it's also not about a distribution.
This module purpose is for production use and it should be a building block like a feature that can be reused in upcoming distributions or custom install profiles.

It's about a collection of paragraph types that could make sense to anyone.

Due to the nature of Drupal 8, we can provide a collection of default configuration that leads to paragraph type creation.
We would reserve some names and add managed meaning to those.
If someone doesn't like a paragraph type, he can simply delete the unwanted types again.

The module could also assume special purpose for special paragraph types. A good example would be a layout aware paragraph type. The Admin UI could be altered / extended and the UX could be improved. Also we can establish recommendations about how to deal with layout.

The base module should possibly unwanted dependencies. Instead it could recommend modules and provide defaults with optional configuration.
For complex situations where multiple approaches could make sense, it could offer separate sub modules.

We would offer drush commands to maintain the default configurations.. Or some wizard like UI to pick from the defaults. Also the UI could display items with soft dependency like "There is a media / gallery / ... paragraph but you need 'media entity' first."

Remaining tasks

User interface changes

API changes

Data model changes

Comments

miro_dietiker created an issue. See original summary.

miro_dietiker’s picture

Title: Extend demo with paragraphs starter pack » [META] Build a best practices paragraph type collection
Issue summary: View changes

Retitling and rescoping the description.

See also this issue #2692051: [META] Alternative UI like divibuilder
It contains a reference to Divibuilder that provides nice ideas for default paragraphs that make sense.

miro_dietiker’s picture

jonathanshaw’s picture

Sounds like a great direction to move towards.

One idea I've hand in mind is that some of these more elaborate predefined paragraph types might want to distinguish between "content" and "settings" fields (settings fields being fields not displayed to site visitors that contain information used in the theme or widget to control the display or collection of content from the content fields).

The fieldgroup module could be used to distinguish between these 2 field types, i.e. a paragraph could have an optional field group called settings which would contain any settings fields. The settings field group could then be given a different treatment (e.g. perhaps displayed on a different tab) by the new Alternative UI.

There is some eventual relationship possible here with the components discussed by Wim Leers in #2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering).

Lukas von Blarer’s picture

Assigned: Unassigned » Lukas von Blarer

I am about to look into this next week at a paragraphs themed sprint in Zurich. Going to figure out how to approach this with @miro_dietiker.

jonathanshaw’s picture

Great. I realised that using field_groups was pointless for my settings idea in #4; Form Display Modes would be a much better approach.

miro_dietiker’s picture

Some loose notes from the Paragraphs workshop:

GOAL
- Not a Demo.
- Not a Distribution.
- Maintained best practices paragraph types set, that also could be shipped with altered admin UI.
- Including CSS / Layout + Design / OPTIONAL! (checkbox?)
- JS?! All OPTIONAL!
- Provide component definition for styleguides
-- Provide collection of sass / CSS markup to clone
-- Ship list of proposed sass / CSS includes
-- Lukas: Use the website as a living styleguide with example content?
- D8: Initially add all paragraph types, delete the unwanted
-- We can ship a wizard later to pick

The paragraph types do NOT depend on the module.
Uninstalling the module will degrade the UI to default.
Lukas: Ship CSS/JS with a different module?

LAYOUT MARKUP:
- Varying grids need different semantic markup!

LAYOUT TOOLS / PLUGINS:
- Display Suite?
- Panels? Panelizer?
-- Select a panel layout per paragraph?
For now the basic solution will not build on top of these.

APPEARANCE
- Layout (floating left / right)
- Background color / Set of styles
- Background image
-- Parallax effect?
- Grid column counts
-- Grid element width
-- Needs double wrapping
-- Do not spread the grid accross all content paragraph types

LAYOUT CONCEPTS:
- Multiple fields: Example: Limit the paragraph types in the left column differently to the right column.
-- Problem: Soon application specific!
- Single field + apearance setting: Equally distributed approch incl multicol grid, ...

FUNCTIONAL COMPONENTS:
- JS is connected with functionality!
- The default base will only ship data (field + markup)
- Ship paragraph types through optional config dependencies?
- Even with a specific media module, there are multiple ways
- Build flavor variants if multiple makes sense!
-- Configuration dependency
-- Group the paragraph types, and describe the implications
- Initially limit it to one case
- Later add a wizard when we have multiple cases / flavors

MEDIA
- Media Entity (VS File Entity?)

What's next?
We need to define the fundamental paragraph types and the separation to have an idea of the first milestone.

jonathanshaw’s picture

Great to hear this coming along. Two questions come to mind:

1) When you say you won't be building on top of DS & Panels, does that mean you won't be building on top of layout_plugin?

2) Are you thinking to have any configurable settings for each paragraph type coded, or were you thinking to have something that a sitebuilder could customise (and also have in their own custom paragraph types), along the lines of my #4 / #6 above?

miro_dietiker’s picture

You are right, we didn't cover all aspects of layout. Some more thoughts... ;-)

We have been talking of a paragraph type that establishes a grid (column count) with another nested paragraph type that represents a container with a specific width. This sounds like an overkill, but it allows full freedom in layout configuration. Also the container can introduce background image, stale and other aspects that are common over what content paragraph type is placed into the container... Still there are many possible variations of this concept.

We have been talking about general fundamental paragraph types (such as a button) and not complex combined ones, that are soon specific for an application with specific layout.

That said, we did not discuss about how we would offer layout variations of a specific complex component. It's clear though that on this level, we would want to offer a layout selector. If this will be bound to the layout plugin with configurability, or if we will do some preprocessing and have varying templates is unclear. It's also possible that we will try both. Note that we don't want to reinvent panels. A generic implementation that allows multiple layout variations per paragraph type is hard to implement. Most importantly because we learned that the content creator should not select a view mode. Instead view modes shouls stay consistent and we need layout variations per view mode. All this led us to the conclusion that we start with the easy part first, where a layout selector just switches the template suggestions and establishing of a layout would be done by shipping new template variation. By avoiding over engineering of configurability, this also allows fast implementation of custom solutions with easy total semantic control. We can always add layout plugin support later.

miro_dietiker’s picture

Priority: Normal » Major

Promoting as of our strategy.

Lukas von Blarer’s picture

Assigned: Lukas von Blarer » Unassigned

Unassigning from me since I currently don't have the time to work on this. I created a very rough first draft of what I think of. Please extend this:

https://docs.google.com/document/d/1vU845wGthKaX_YBUgTAN_My76FRt4K5F63ku...

miro_dietiker’s picture

Thank you for the document. I will need some time to check it.

I started working on a Paragraphs Types board where we collect cards and iterate on definition and discussion:
https://trello.com/b/LIu1prOi/paragraphs-types
It's almost empty for now, but will grow in the following days.

zmove’s picture

I worked on it (with a video demonstration), see my post here.

Don't hesitate to give me your opinion and feedback.

Lukas von Blarer’s picture

Looks great! Thank you!

yobottehg’s picture

Component: Demo » Code
Issue tags: +DevDaysMilan

changed from demo to code, tagged milan.

We are working on this here : https://github.com/WondrousLLC/paragraph_types

yobottehg’s picture

Issue summary: View changes
jeroen.b’s picture

Would it be cool if we are able to use H5P into this?
I might try to create a H5P field soon.

Lukas von Blarer’s picture

Sounds interesting. Maybe we could provide an optional paragraph type in case H5P is installed.

zmove’s picture

If the h5p module can provide a field, it would take 2 min to add an h5p paragraph type in the system.

jeroen.b’s picture

Yeah, but the H5P Drupal module is kinda weird and not for Drupal 8. I was thinking of making a h5p_field module.
Actually, after looking again, it's not that weird, I might do a direct port. Then it will just be an entity reference to the H5P entity.
Then we can make an optional submodule of the type collection module that contains the H5P paragraph.

miro_dietiker’s picture

Added H5P paragraph type to the trello board about paragraph types.

jonathanshaw’s picture

Layout plugin looks on track to be in core for 8.3: #2296423: Implement layout plugin type in core

miro_dietiker’s picture

When investigating this issue, we realised that for many cases, we don't need to have real content fields.
If we have paragraph types for functionality like slideshow or grid, we need to attach settings to paragraphs that could be easily serialised. We just need to find a way to offer them like fields when editing.

So we want to avoid building a collection with standard fields and then later change storage.

Preconditions architecturally for this issue are:
#2830016: Add a thumbnail/icon field to Paragraphs type
#2828506: Introduce a plugin system for paragraphs types

And to make the UI nice and reduce overload, we need perspectives.
#2825557: [META] Introduce edit perspectives

Still keeping the issue open as the process to identify feasible paragraph types and specify them should currently be if highest priority.

miro_dietiker’s picture

So, we started with plugins and realised that plugins completely shift how a best practice collection will look like
#2828506: Introduce a plugin system for paragraphs types

We will start experimenting with the conceptual goals at:
https://www.drupal.org/project/paragraphs_collection
And we already have issues for grid, slider, style selection.
#2834260: [META] Handle Grids
#2834266: [META] Handle Slider & Slides
#2834272: [META] Style selection
Experimenting, as in EXPERIMENTAL stage, not stable and (did i mention it already?) subject to change. ;-)

This will be awesome! :-)