@macolo Interesting thoughts, here's my experience with our clients:

Copy/paste

Not really a big issue; I don't think any of our clients/editors have ever raised this.

Rows and Columns

The complexity is definitely an issue for our clients. When we template out articles/bios/services, etc., we remove the need for editors to get involved with rows and columns.

But on landing pages, we essentially have an empty template that leads to lots of questions/confusion for editors who don't use the system every week. We try to get around this by having an unpublished "/templates/" section in the sitemap where we have pre-built examples they can copy/paste/edit, but it's definitely fiddly.

We talked about building something that allowed you to create "Templates" in the plugin list when you click + to add a new element. Users could save existing row/column layouts as a "Template" and then re-use them later from the plugin list instead of using individual plugins. We never built it, but I'd happily outline our thoughts in more detail.

The other alternative as you say is to simplify it but my concern is that clients always manage to find a 5 column layout they need so how would that be built outside of the "standard" 2/3/4/6 column layouts?

In text plugins

I don't like these, so we discourage clients from embedding; they have link/button functionality in a separate plugin, so we encourage them to use that. When we switch over to tiptap we might hide it completely to stop them from doing it :)

With respect to an improved editor experience and overview on the structure of plugin trees I have had the following thoughts for a while now:

• Allow for some (not too strong) colour coding of wrapper elements, say, grid plugins, so it becomes easier to identify a grid structure. (Same for accordions etc.)
• Allow for plugins to mark them as not editable (i.e. double-clicking will not bring up a modal). They can be added/changed programmatically by a parent plugin. Example: A row plugin could manage its columns. A hero plugin could manage, say, three slots represented by three child plugins: an image, a header, and a body.

I for instance created a special mixin class which can be added to any component. It adds an extra checkbox to hide that component when rendered. In the structure editor, this component then is styled as shown here:

possible solutions
stop endorsing bootstrap-based website setups and come up with a css grid framework independent approach for columns / layouts. For example, in most layouts, 2-columns, 3-columns, 4-columns, 6-columns and a flexbox container is probably sufficient. What's a best practise to implement such a simplified column approach in django CMS?

@macolo Do you think we should move to something like Tailwind as that is mostly a de-facto standard now or do we go with a generic solution without endorsing a specific framework?