Developer Experience

In order to make a put request in V5, you need to know the entire schema of the nested object. This is bad. Here's my use case. I have a course. The course has Modules (collection type). It also has Lessons (collection type). Each lesson has some data about the lesson overall (time to complete, thumbnail, etc.) and each lesson also has a list of "screens" (component) containing the lesson information, which have their own nesting of components and data. I have a list of 200 images, each of which corresponds to a screen, and I want to update the screens in strapi with the corresponding images. I understand that you can't just send the one key/value pair you need updated with a PUT request: frankly, this is annoying but fine. One might think, instead, you could query the API for the object, copy the response, and send it back with the updated K/V pair, but you can't do that either, because all of the other metadata (documentID, etc.) in the response will give a 400 error. You need to either know the schema of the object or know which fields are metadata and strip them out to update the item. This is really just a very bad system that makes it incredibly hard to update things with the API. Clicking through hundreds of lessons on strapi to add the images would be a complete waste of my day and probably take 8 clicks or more per lesson. I spoke with Paul and Beogie on Strapi Office Hour discord and they advised me to make a post here with this issue.

There isn't a good way to seed the database for local development. Ideally, we could seed any kind of content type as well as api keys, that way a developer could quickly get started with a monorepo strapi setup.

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.