The problem with this approach is that the editors needs to know how the css grid of the themes work to give structure to the content.
Most css grids are row based with different column widths. This makes content manipulation a case of creating rows with column content. The options I'm going to show in this article are all about this way of structuring content.
Paragraphs
The first Drupal specific solution is paragraphs. The paragraph as an html tag is in fact a row, so the name captures the intention.
The way it works is to create all the different types of paragraphs, or rows, the editor will need. Each paragraph type has a template to place the fields, or columns. These paragraph types can be added to a content type with the paragraph field.
The good
- The single block of html is cut up
- Editors don't need to know how the css grid works
- Simple to set up
The bad
- When there is a lot of content on a page it can be hard to find a specific piece as editor
- Paragraph type content can't be shared with other pages
- To provide as much choice as possible a lot of paragraph types are needed
Bricks
The second Drupal specific solution is bricks. This is the newest of the Drupal specific solutions. It is so new it depends on experimental modules from Dupal 8.3.
The idea is to define the content that can be placed in a column, this is called a brick. The rows are created with a *.layouts.yml file and template files in a module or theme. The easiest way to create the bricks is to install the eck module. This module adds forms to the backend to create an entity with different bundles. The entity is added to the content type with the bricks field.
The good
- Because the rows are split from the column content less configuration is needed
- The editors can create content structures developers didn't think of
- Brick content can be shared with other pages
- A specific piece of content can be found easy when there is a lot of content, because the form display is a tree like menu items.
The bad
- An experimental dependency which has the potential consequence to remove content by a future breaking change
- Harder to set up
- Naming bricks to be descriptive for the content can be hard
Ckeditor widget
The ckeditor widget is the only solution where the single body field stays. Widgets are predefined pieces of html that are added by buttons in the toolbar. I linked to the first part of the how to create a widget tutorial.
Like bricks you can define row types and column content types with widgets.
The good
- It is CMS independent
- Content looks as it would on the site
- Rows are not the only content structure that can be added, freedom is good
The bad
- Content can not be shared with other pages
- Rows are not the only content structure that can be added, too many possibilities can create problems
- A big toolbar to provide the editor as much choice as possible
- Toolbars per content type are harder to set up
Conclusion
If the editors are used to work with html I recommend the ckeditor widget solution because it is writing html with shortcuts like the emmet plugin for desktop editor en IDE applications.
if the editors are not used to work with html I recommend bricks because it provides the most flexibility while being easy to use.
The only case in which i recommend the paragraphs solution, is when the editors want a limited amount of choices and most of the content is short.
