Content Editing XP

In our company, we often work with clients who are not used to working with this type of dashboard. We’ve found that, especially in some less visible places, the field name alone is not enough to clearly explain what they are editing on their website. On top of that, the limitation of field names (for example, not being able to use spaces) reduces readability. As a result, we frequently need to manually explain to our clients what each field does. That’s why we see great value in having the option to add a description to every field, so we can provide precise guidance on how that field works.

None of the popup menus have any visual indication that overflow menu items are hidden. For example, the rich text (blocks) editor in the attached screenshot. But its is not limited to that menu, all menus are affected. I've seen lots of users open menus, not seeing the menu entry that they are looking for, and closing the menu again. Had they scrolled up/down then they would have found the desired option, but there is no visual indication that one can scroll. Yes, if you move the mouse over the menu then the vertical scrollbar appears. But users tend to close the menu if they don't see the option they are looking for, they don't hover over it. I'm using Chrome on Fedora Linux.

In an early Strapi v4 version (might have been v4.0), components inside dynamic zones were all expanded. A little later (might have been v4.4), components were displayed collapsed and content managers had to expand each component in order to see/edit the component. Now (v4.10), they are automatically expanded again. For content type structures that feature a lot of components, this makes the page very very long. It would be great if there was a setting which allows developers or content managers to configure if they want to display components automatically collapsed or expanded. Ideally there would be a system wide setting as well as a per-user setting.

I have translated my column names and they appear correctly in the conent manager table view. But in the view settings, the original, un-translated names appear. Relevant code line: strapi/packages/core/content-manager/admin/src/pages/ListView/components/ViewSettingsMenu.tsx Line 165 in 6d1dbc9 <Typography fontSize={1}>{header.label}</Typography> My thoughts on this, shouldn't it be implemented like it is here? strapi/packages/core/content-manager/admin/src/pages/ListView/ListViewPage.tsx Lines 158 to 171 in 6d1dbc9 const translation = typeof header.label === 'string' ? { id: content-manager.content-types.${model}.${header.name} , defaultMessage: header.label, } : header.label; return { ...header, label: formatMessage(translation), name: ${header.name}${header.mainField?.name ? .${ header.mainField.name } : ''} , }; }); This issue was first posted to Github but apparently never moved here https://github.com/strapi/strapi/issues/23041

For both marketers and developers, it could be very useful to have the ability to contribute content from their tablet and mobile. To do that, the user interface needs to be responsive and adaptive to every device sizes.

Add option to create copies for uploaded images in webp and avif. By default the plugin should keep it's behaviour and not convert uploads. But if its configuration is enabled to convert, it should save an additional copy for each breakpoint in every enabled image type. This two image type formats are very useful to improve web loading time. See: https://github.com/strapi/strapi/issues/10420

I feel like Strapi would benefit for more customisation of editing views for each content type and component. Things missing include fieldsets to group fields together, accordions, tabs, helper elements like descriptions that aren't attached to fields.

Add native support for JSON-LD (JavaScript Object Notation for Linked Data) in Strapi content types and APIs. JSON-LD is a widely adopted format for structuring linked data and improving content discoverability across web platforms. Official support would enable developers and content teams to easily expose semantic relationships and metadata from Strapi-based sites. Example Use Case A “Blog Post” content type could automatically output structured data such as: { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Understanding Headless CMS", "author": { "@type": "Person", "name": "Jane Doe" }, "datePublished": "2025-12-18" } This would improve search visibility and simplify content syndication.

I would need a way to set alternativeTexts per language on files in the upload plugin. For now I just built a custom collection, which contains a file and localized alt text. However, I think this is a very common use case and related to i18n plugin, so I just opened as an issue. See: https://github.com/strapi/strapi/issues/10220

Add i18n options for content manager view settings (eg label, description, placeholder) See: https://github.com/strapi/strapi/issues/10110