Under Community Review

Indeed some architectural improvement might be taken in this area

Would like to know how many customers are using so many RTF fields in one Component

Please vote if you are

A multi-value component that contains 400-500 items that contain RTF take longer to load, save

We have a component schema that has an embedded schema that's multivalue. Within the embedded schema the field is RTF enabled (only the term field). When the number increases to 400 the component takes long time to load and save and browser also crashes.

This enhancement request is for improvements around RTF field loading. 

Screenshot of Tridion Sites Ideas component content with multiple terms including '21st Century Act', 'American Express', and 'Americans with Disabilities Act' with creation and effective dates.

Parents
  • I agree with Neil, it must be a horrible user experience for the editors having to deal with so many fields at once. 
    I had a similar problem about 20 years ago during a content migration to Tridion with 150 fields. The issue then was that the browser had to render the RTF editor gui for a large number of rich text fields and would sometimes fail when the browser ran out of memory. We redesigned the implementation to simplify editor experience by breaking the design down to use several different content types rather than having one complicated "catch all" content type inherited from the legacy solution. This made it much easier for editors to manage and update the content.

Comment
  • I agree with Neil, it must be a horrible user experience for the editors having to deal with so many fields at once. 
    I had a similar problem about 20 years ago during a content migration to Tridion with 150 fields. The issue then was that the browser had to render the RTF editor gui for a large number of rich text fields and would sometimes fail when the browser ran out of memory. We redesigned the implementation to simplify editor experience by breaking the design down to use several different content types rather than having one complicated "catch all" content type inherited from the legacy solution. This made it much easier for editors to manage and update the content.

Children
No Data