Content Editing XP

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

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.

Strapi version: v5 --- What I'm asking for Public, stable injection zones in the media library admin interface so that developers can register their own custom tools — for example a custom image editor, a watermarking tool, a CDN purge button, or an AI background remover — without patching Strapi internals. Current behaviour The Upload plugin admin UI has no documented public surface for customisation. Adding a custom action button or panel to the asset detail view requires overriding internal Strapi source files. There is no equivalent of the Content Manager injection zones ( listView.actions , editView.informations , etc.) for the media library. Expected behaviour The media library exposes named injection zones a developer can target from a custom plugin: upload.asset.detail.actions — toolbar slot next to the built-in Download/Copy URL buttons on the asset detail panel upload.asset.detail.sidebar — a collapsible sidebar panel below asset metadata (good for custom editors or external service panels) upload.asset.list.bulk-actions — additional items in the bulk-action toolbar when multiple assets are selected upload.header.actions — slot next to the Upload button in the library header Each zone receives the current asset (or selected assets) as props so custom tools have full context. Example use case A custom plugin registers a "Compress & Replace" button in upload.asset.detail.actions . When clicked it opens a modal, runs the asset through a custom Sharp pipeline with tighter settings, and replaces the file — all without touching Strapi core code. Why this matters Different projects need different image workflows. Injection zones let the Strapi team ship and maintain a clean default media library while the community builds specialised tools on top of it — the same model that makes the Content Manager extensible today.

Strapi version: v5 --- What I'm asking for A set of image editing tools built directly into the media library admin UI, so content editors can manipulate and re-optimize images without leaving Strapi. Current behaviour The media library is view-only (except crop) after upload. Editing an image requires leaving the admin, using an external tool (Photoshop, Squoosh, GIMP), re-uploading, and re-linking the asset everywhere it is used. Re-optimization (reducing file size after the fact) is not possible at all from the admin. Expected behaviour An "Edit" button on any image asset opens an editing panel inside the admin Editing tools: crop (with aspect-ratio presets), resize, rotate, flip, basic adjustments (brightness, contrast) Re-optimization tool: re-run Strapi's image processing pipeline on an already-uploaded asset to regenerate formats at a different quality level or dimensions without re-uploading the original Saving a non-destructive edit creates a new derivative asset; the original file is always preserved Generated thumbnails and responsive formats are regenerated automatically after any edit Why this matters Content editors working in production — property managers, marketing teams — regularly need to adjust images post-upload. Today every adjustment is a multi-step round-trip outside the admin. Built-in tools keep the entire editorial workflow inside Strapi and remove the dependency on external software for routine tasks.

Strapi is almost fully responsive, but the Homepage and Settings pages of the admin panel don't adapt well to smaller screens yet.

Strapi version: v5 --- What I'm asking for Two related improvements to how upload providers work: Multiple simultaneous providers — configure more than one storage backend and route uploads to the appropriate one based on content type, folder, or an explicit choice at upload time. Provider configuration in admin settings — store provider credentials and options in the Strapi config store (editable in the Settings UI) instead of requiring them to be hardcoded in config/plugins.js or environment variables. Current behaviour Strapi supports exactly one upload provider at a time. It is configured statically via config/plugins.js or environment variables, which means: Changing provider or rotating credentials requires a code change and redeployment There is no way to route different uploads to different storage backends Non-developer admins cannot change storage settings without touching code Expected behaviour Multiple providers: Register N providers, each with a unique key (e.g. s3-private , cloudinary-public , local ) A default provider is used when none is specified The active provider can be specified per-folder in the media library, per media field in a content type, or passed explicitly in the Upload API call Admin-managed configuration: A dedicated Upload section appears under Settings in the admin panel Each registered provider displays its configurable options (bucket, region, API key, etc.) as editable fields Values are stored encrypted in the Strapi config store; no restart required for credential changes Environment variables remain supported and take precedence over admin-stored values (for CI/CD pipelines and secrets managers) Why this matters Applications that handle both private documents (contracts, invoices, guest IDs) and public media (listing photos, logos) need different storage destinations with different access rules. Today this requires a custom middleware. Admin-managed config also makes Strapi viable for self-hosted setups where the operator deploying the instance is not the developer who built it — they can rotate an S3 key themselves without opening a code repository.

Strapi version: v5 --- What I'm asking for Decouple the Upload plugin from Strapi core so that it becomes an optional, community-replaceable plugin — the same way users-permissions is a plugin that can be disabled or swapped. Teams that need a fundamentally different media management experience could then replace it entirely with their own plugin, or opt out of it for projects that manage files outside of Strapi. Current behaviour The Upload plugin is bundled into Strapi core and cannot be disabled or replaced. Any project that uses Strapi ships with the media library, regardless of whether it is needed. There is no supported path to swap the entire media library for a custom implementation. Expected behaviour The Upload plugin is extracted into a standalone, versioned package (e.g. @strapi/plugin-upload ) that ships as the default but is not a hard core dependency It can be disabled in config/plugins.js for projects that manage media externally A third-party or custom plugin can declare itself as an upload provider replacement by implementing a documented interface contract (routes, services, content types) Strapi's own field pickers and relation widgets that reference media assets work against that interface, not against a hardcoded internal dependency Why this matters Some projects use Strapi purely as a data API and manage assets in a dedicated DAM (Cloudinary, Bynder, Imagekit). Others need a fundamentally different upload UI — a multi-step ingestion flow, folder-enforced taxonomy, or a restricted upload interface per role. None of these are possible today without forking core. Making Upload a proper optional plugin gives the community the same power over the media layer that it already has over the auth layer.

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.

Currently there is no content editing lock. This can result in issues when 2 editors are working on the same content. In example editor 1 has saved some changes, while editor 2 has the same (old) content already opened. Editor 2 saves his changes after editor 1, and the changes from editor 1 are lost. Realtime editing with multiple editors would of course be the future, but in the meantime I would suggest a lock on the content, similar like in the WordPress CMS.