Developer Experience

For more information see: https://github.com/strapi/strapi/issues/784

When replacing an image with an image with different data the hash of the image doesn't change. See: https://github.com/strapi/strapi/issues/13882

It could be great to add context or let the users create their contents with little constraints. For example, a grid could have differents components inside like download cards or profile cards. Making a grid component for each variation is not optimal so it would make the UI clearer with fewer components. Lastly, the front-end developer could develop a component manager from front-end and it would manage all content to build the website like legos. The developer would maintain the content builder from strapi POV and the users can immediately use the news components or make change on already launched content.

Please extend the conditionals behavior. The idea of adding conditionals is great, but the way they are working now is really shit. Fields that are conditional and become hidden are not cleared so other fields relying on these fields are still shown. Then only 1 condition is not enough, we should be able to combine conditions as well.

Strapi's validation and typing setup has kind of evolved organically as the product grew, and it left traces. Right now, data structures get defined all over the place: frontend forms, backend APIs, Content API, Admin API, plus TypeScript types that often don't quite sync up with the actual runtime behavior. The result is several duplication, things drifting out of alignment, and a codebase that's trickier to work with than it needs to be. Bringing in Zod as Strapi go-to schema layer allows to have just one unified definition handling both validation and typing across the whole stack. One spot to define structure. One source of truth for what data should look like and what's valid. For contributors, this means way less time wrestling with overlapping systems and way more confidence in making changes. For devs building on Strapi, it would mean more consistency and reliability. What the Admin UI enforces actually matches what the API enforces. Plugin contracts are clear and stable. Plus, with Zod 4's built-in OpenAPI schema support, this sets us up for way better API docs and stronger guarantees for all the tools and integrations people build on Strapi.

The default height of the textarea for Long Text fields is not very narrow and it is not possible to resize it. This is a pain when editing the content.

Can the "Configure the view" page be enhanced with a grouping feature? This would be very useful for long forms

Currently, in Strapi 5, there is a significant architectural gap regarding programmatic data synchronization from external sources (APIs, Webhooks, Cron Jobs). Most developers implementing data ingestion follow a "Check-then-Act" pattern: Fetch data. Query for existence via documentService.findFirst({ where: { externalId } }). If exists, update(); otherwise, create(). This pattern introduces three critical failures: Race Conditions (Idempotency Gap): In a distributed or clustered environment, two concurrent ingestion processes can both "check" and find no record, then both attempt a "create," leading to duplicate records or database unique constraint violations. Partial Batch Failure: When processing 50+ records from an external API (e.g., Hacker News), a single malformed record (validation error) crashes the entire ingestion loop, leading to data loss for the remainder of the batch. Document Service Complexity: With Strapi 5's new Document Service (Draft/Publish, I18n), managing "Upserts" becomes significantly more complex for the developer to handle manually compared to the legacy Entity Service. Use Case: The "Hacker News" Integration Test Consider a "Job Board" plugin that syncs 100 stories from Hacker News every hour. If the network blips at record #10, the sync fails. If two cron jobs overlap, the database fills with duplicates. If record #45 has a title that is too long, records #46-100 are never processed.

We have enabled the Preview feature for content editors. At the moment, the Preview mode only provides two viewport options: Desktop Mobile We would like to support an additional Tablet viewport and have the ability to configure custom viewport sizes for each device type. Requested Enhancement We would like to: 1. Add a Tablet viewport option. 2. Configure custom viewport dimensions for each device type. example: • Desktop: 1440 × 900 • Tablet: 768 × 1024 • Mobile: 390 × 844

In my project there are many api's which have pretty much similar fields except one or two, it would be great if we have a feature to duplicate a content type fields in one click then add or remove the difference and finally create a new content type. see: https://github.com/strapi/strapi/issues/9429