Content Editing XP

Hi Strapi team, We’re using Strapi 5.60.0 and would like to report a workflow regression in the redesigned Media Library. Previously, while editing an entry, we could complete the entire workflow from its media field: Open the media picker. Choose or create a destination folder. Upload files into that folder. Select the uploaded files and attach them to the field. In the new interface, uploads directly from a media field go to the library root without a destination-folder selector. Keeping files organized now requires extra navigation and separate upload or move operations. Please restore folder selection, uploading and attachment to the current field within the same dialog, without leaving the entry editor. We know about useLegacyMediaLibrary, but would like this workflow supported in the new interface too. Is this functionality planned, or is there a supported way to enable it already? Thank you!

When using brand names etc. in articles, problems such as blurred notation occur when translated into other languages with Strapi AI. I want them to be able to use custom prompts to address these issues.

For the "Rich text (Markdown)" type field, the Image button is right at the top editor bar. For "Rich text (Blocks)" type field, it is not on the editor bar, but hidden in the first, dropdown menu, at the bottom of the list. We would like to have this button on the editor bar for the blocks type field as well.

We cannot hide the Strapi or node version from the interface. We can't also hide the "Current plan". This information is available to all users, under "Settings > Global settings > Overview". However, in my case, except for me, all users are non-technical, so this information is just not necessary to them, and there should be an option to also hide this. Apparently, the code that displays this webpage is here: https://github.com/strapi/strapi/blob/762abbf7f8a8cae3cda9b6affcea50be8abc3ce9/packages/core/admin/admin/src/pages/Settings/pages/ApplicationInfo/ApplicationInfoPage.tsx . There should be an option to display or not this webpage, like there's an option to display many other pages. I can't believe this is so difficult to implement. Thanks.

We’re using Strapi’s AI translation feature, which automatically triggers translations whenever we save changes to the English version. Currently, this works well for text fields, but translated pages also contain images and dropdown selections (e.g. colors) that need to be added manually. The issue is that every time we update and save the English version, the translation process overwrites the translated pages and removes the manually added images and color selections. This means we have to rebuild these elements on every translation update. Could the translation logic be changed so that existing images and dropdown selections are preserved when translations are regenerated, while only the text fields are updated? This would allow us to make regular content updates without losing manually configured localized content. Alternatively, it would be ideal if the translation process could automatically copy the images and dropdown values from the English version to the translated pages. This would eliminate the manual work entirely, which is exactly why we’d like to make the AI-native Strapi functionality work seamlessly with our localization workflow.

Currently when a image is deleted with relations to a content collection. It just removes the relation without showing any information on where the images might be used on. It happens a lot of our customer, that they delete an image inside the media gallery without realizing they kill the relation for an required image.

I am making a custom rich text field for the front end of my site using Slate. I plan on adding support for @mentions and custom emoji. Since the Rich text (Blocks) editor in Strapi uses Slate, I need to be able to support my custom elements in Strapi. I plan to look into forking Strapi's editor, but being able to just extend the current one would be a lot nicer. I may look into writing a PR for making it extensible myself, but probably not anytime soon since my free time is all tied up with my personal Strapi project. I wanted to submit the idea in case anyone else wants to run with it.

Problem Rich text editor doesn't support custom elements. This can be achieved by extending the Rich Text editor or extending Markdown to suit your requirements. eg a link which opens login modal inside running rich text. While plain links are possible, these custom links are only possible if a custom entry can be embedded inside Rich text. Similarly, embedding links which open in a new tab inside a rich text snippet. Solution While creating a rich text field, a setting can be enabled to embed entries and which content types are allowed to embed. Embed can be inline or block level or both.

Strapi version: v5 --- What I'm asking for The ability to extend the plugin::upload.file collection type with custom fields through the Content-Type Builder — the same way the users-permissions plugin lets you add extra fields to the User collection type. Current behaviour The plugin::upload.file schema is fixed and cannot be extended. The Content-Type Builder does not expose it as an editable type. Workarounds require maintaining a separate shadow collection with a relation back to the file, which complicates queries and means asset metadata lives outside the media library. Expected behaviour The Content-Type Builder shows an "Upload" section alongside other plugin-owned types Developers can add fields to it: text, number, boolean, date, enumeration, relation — the same field types available on any collection type Custom fields appear and are editable in the asset detail panel inside the media library Custom fields are included in Upload API responses alongside the built-in fields Schema changes survive upgrades without manual migration Example custom fields copyright (text) — photo credit line for licensed imagery expiresAt (date) — flag assets that should no longer be used after a campaign ends approvedForMarketing (boolean) — editorial approval toggle for brand assets property (relation to a Property content type) — link listing photos directly to the property they belong to Why this matters The users-permissions User type extension is one of the most-used Strapi features precisely because real applications need more than the defaults. The same is true for media: in property management, e-commerce, and publishing, assets carry domain-specific metadata that belongs on the asset itself. The current workaround of a parallel shadow collection is fragile, harder to query, and invisible in the media library UI.