Add Components to Rich Text Elements (or collection items)

@Bradford_Huber recently posted a brilliant idea on Twitter, the ability to add Webflow components in Rich Text Elements. This could be a light feature(?) that would solve an annoying limitation in Webflow; the lack of functionalities for the editor to add more advanced components e.g. galleries, fact boxes, ingress text, CTA’s, and much more to articles.

Vote in the wishlist here.

Hey Christoffer, just in case you’re not aware there is already a similar functionality offered in Finsweet’s Powerful Rich Text lib.

I think that while the idea sounds nice on the surface, it wouldn’t really be useful unless you could solve the CSS isolation issue. Without that, the component placed inside the RTB would look completely different from the same component outside of the RTB.

One way to do that would be to redesign RTB’s. :thinking: If every native RTB element ( paragraphs, headings, lists, etc ) had the RTE’s custom class affixed, they could be exclusively targeted by the CSS so that the RTB’s styling wouldn’t break the embedded components.

I rather like that actually.

@memetican Yes, the @Finsweet Powerful Rich Text is handy in many cases, but not very user-friendly for clients that are not developers. A third-party hack is not the best starting point for good UX!

Suppose the real problem that should be addressed, is that Webflow lacks features for clients/editors to easily add (and rearrange) components with predefined layouts in the CMS-system. A Webflow collection is VERY rigid in its structure. You can only set up predefined data fields and use those (or not). If a collection sometimes needs elements like CTA’s, galleries, fact boxes, contact cards, and tables (don’t get me started on tables!), they have to be predefined in the limited number of collection item fields, even though they will be seldom used. This clogs up the UI and consumes from the limited number of fields, unnecessarily. You can’t even decide in what order the elements should be displayed, only if they should be shown or not.

Agree, this is a separate frustration for my team, different from the problems with CSS isolation and component embeds, but I have a few techniques that might work for you.

The main approach we’ll use is to store those “intricate, sparse items” in a separate collection. That costs a collection and a ref field but it generally solves the “rarely used fields” issue which is much more expensive in our project designs.

Also it makes item-reuse a possibility, CTA’s being a good example of this.

The rest, we bridge with script- e.g. the component embeds, and conversion tracking links that identify the click source.

Overall it scores decently well on our metrics for client-ease-of-admin, efficient-CMS-use, flexibility, future-proofing, and of course it maxxes out on performance because there is no data fetch() required.

For extremely complex situations we actually store JSON directly in the CMS, and then use that in our Typescript libs to generate whatever is needed. Scores very low on client-ease-of-admin, but it offers a fairly unlimited solution for complex, accessible data retrieval.

A good example of where we use this might be in a real-estate site where the advanced part of the data structures aren’t CMS-friendly. That data is administered in another system anyway, so we just push it into a CMS field via the API, and then extract and use it via our client side scripts.

Not perfect, of course, but given that Webflow is primarily targeted at designers and not devs or database architects, these work pretty well. If you needed more, you probably need querying and security too, and then a solution like Xano becomes a better path.