2

I'm trying to build a site (or define site a building configuration), which allows editors to create their own layouts using the Paragraphs module. Powerful options for editors, reuseability across different projects and full control over the generated HTML are important.

There will be grid paragraphs to create the layout/structure containing content paragraphs for image, text, sliders, videos, accordions, etc. Most paragraphs will have "non-content" data like column width, background color, slider autoplay on/off, etc. So far I've found two ways the to handle the non-content part, but I'm unsure which is the better way to do it:

A) Use normal fields for non-content settings and Field Group to create finetune the editor interface. Use template preprocessing and/or Twig logic to create the desired frontend output. (Do frontend coding in a base theme to allow reuseability across different projects.)

B) Use the Plugin-system from Paragraphs Collection to create "behavior" plugins (code and YAML configuration) for non-content settings. Get the frontend stuff done with preprocessing in the module's code.

The collection plugin was created by the maintainers of the paragraphs plugin themselves, so B) is obviously the way it should be done. It also more clearly separates content from design/other stuff. However, I'm usually doing frontend coding, and while I'm used to PHP, I'm fairly new to Drupal, so A) would be the path I'm used to. Also the paragraphs behavior plugin is explicitly labelled as experimental and not ready for production use.

I'm looking for some hints from experienced Drupalers on which route to take, also concerning long term maintenance for many small sites (at least 4-5 years) and reuseability across different client projects.

1 Answer 1

1

As you stated, the Paragraphs Collection module should be considered Experimental, and not used in Production environments:

THIS PROJECT IS EXPERIMENTAL. DO NOT USE IT IN PRODUCTION PROJECTS. THERE IS NO UPGRADE PATH UNTIL A BETA RELEASE.

This is especially true if your plan is to use this on multiple sites, with the life expectancy of 5 years.

The common method in Drupal 7, and currently in Drupal 8 is your first point, to use fields for settings and use preprocesses and/or twig templates to turn those fields into classes/markup you want.

For re-usability, you will either want to use the Features module and a base theme, or create your own module that will handle the config, templates and styling. I took that route with the Bootstrap Paragraphs module.

3
  • Thanks for your feedback, I've been looking at the source of your module, it's quite similar to what we want to achieve, except we want to get rid of the fat bootstrap dependency. For me as a newbie drupaler it seems to me that there is not really that much of a difference if I'm creating a module or a theme, it's just a different hook for almost the same code and a different position for templates.
    – Hudri
    Commented May 11, 2017 at 7:49
  • 1
    A set of custom Paragraphs types w/ fields, settings, and custom template overrides is the route I decided to take when architecting IU Paragraphs a solution for Indiana University's Pattern Library. The main drawback to this route (aside from reusability of paragraphs) is that drag-and-drop between nested paragraph types doesn't work (checkout bootstrap_kit for an alternate approach based on Bricks module). Commented Jan 30, 2018 at 23:35
  • 1
    Cool stuff @JamesWilson! Both of the drawbacks you mention about Paragraph usability are being addressed in the Paragraphs issue queue. Reuse paragraphs / Library: drupal.org/project/paragraphs/issues/2414865 Introduce a Drag & Drop Mode: drupal.org/project/paragraphs/issues/2825575 Commented Feb 2, 2018 at 11:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.