strapi
π Question: What are the main pain points you have using Strapi? (Episode 7)
Many years ago, the Strapi Chief Product Officer @Aurelsicoko asked the community what their main pain points were and how critical these issues were to the rest of the community.
Since then, every year (2024, 2023, 2022, 2021, 2020, 2019) we have asked the same question.
Once again, the Strapi team wishes to get the broad community feedback, so the question again this year is: what are the main pain points you have using Strapi?
Some Rules for this issue:
- Please try to be short and to the point, and describe your use case and why you feel this is an important issue.
- Only one pain point per comment (you can add as many comments as you want, but only one per comment, please)
- Be sure to construct pain points respectfully and constructively, following our Code of Conduct
Instructions
- Please only post one pain point at a time.
- If your pain point has already been listed, make sure to upvote it instead of posting a similar message. A simple :+1: will suffice.
Template
- Issue: Please describe your issue.
- Context: Give more details about the use case.
Copy-paste the following markdown template:
**Issue:**
Please describe your issue in a single sentence.
**Context:**
Give more details about the use case, background, or your detailed thoughts.
**Which version are you on:**
- [ ] Strapi 3
- [ ] Strapi 4
- [ ] Strapi 5
We look forward to reading all your comments. All contributions are welcome, don't be shy π
Issue: Strapi's Data Transfer doesn't work reliably.
Context: Most clients using Strapi require multiple environments. Moving content from to the other is troublesome β whether we're talking about getting developers up-to-date with the latest set of filled out pages, or moving the pages from UAT to staging, etc.
We usually encounter that this tool starts failing once once media library grows to a certain size. it's been brought up by multiple of our clients who do not want to (or cannot in some cases) hassle with hacky scripts or dump & replace the database.
Which version are you on:
- [ ] Strapi 3
- [X] Strapi 4
- [X] Strapi 5
Issue: Improve typing generated by Strapi that can be reused in other packages.
Context:
We have a monorepo with multiple applications, one of which is a Next.JS app. We export Strapi's autogenerated types into the workspace, utilizing them in the frontend. These types do not seem to respect modifies such as Required, and they always include | null | undefined.
Having an endpoint that hosts an OpenAPI spec (with custom endpoints as long as they use proper notation) would be awesome!
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [X] Strapi 5
That it doesn't even work:
|> npm run develop
> [email protected] develop
> strapi develop
β Cleaning dist dir (8ms)
β Ό Loading Strapi[ERROR] There seems to be an unexpected error, try again with --debug for more information
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ ββ Error: The module '\\?\C:\Users\Babak\Documents\my-strapi-project\node_modules\bette ββ r-sqlite3\build\Release\better_sqlite3.node' ββ was compiled against a different Node.js version using ββ NODE_MODULE_VERSION 137. This version of Node.js requires ββ NODE_MODULE_VERSION 127. Please try re-compiling or re-installing ββ the module (for instance, using `npm rebuild` or `npm install`). ββ at Object..node (node:internal/modules/cjs/loader:1734:18) ββ at Module.load (node:internal/modules/cjs/loader:1318:32) ββ at Function._load (node:internal/modules/cjs/loader:1128:12) ββ at TracingChannel.traceSync (node:diagnostics_channel:322:14) ββ at wrapModuleLoad (node:internal/modules/cjs/loader:219:24) ββ at Module.require (node:internal/modules/cjs/loader:1340:12) ββ at require (node:internal/modules/helpers:138:16) ββ at bindings (C:\Users\Babak\Documents\my-strapi-project\node_modules\bindings\bindin ββ gs.js:112:48) ββ at new Database (C:\Users\Babak\Documents\my-strapi-project\node_modules\better-sqli ββ te3\lib\database.js:48:64) ββ at Client_BetterSQLite3.acquireRawConnection (C:\Users\Babak\Documents\my-strapi-pro ββ ject\node_modules\knex\lib\dialects\better-sqlite3\index.js:14:12) ββ βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
scroll horizontally.
i simply tried creating a stripi project and this is the result of it. i don't feel like opening an issue. tried it with both npm and pnpm.
Issue: Unable to set relations as required by default
Context: It surely was mentioned before, but it still exists: relations cannot be set to be required, which results in bad user experience and errors
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Cannot read properties of undefined (reading 'attributes')
Context: 'Cannot read properties of undefined (reading 'attributes')'
Regardless of what you do, this error in Strapi Cloud haunts you, whether in a collection, in the view editor, when creating a relationship... and another thing you need to improve is the Cloud's logging terminal; it's terrible, with all due respect.
I posted a thread on Reddit the other day and saw that some people related to Strapi are participating. π https://www.reddit.com/r/nextjs/comments/1p6ewci/comment/nrr0eo1/?context=1
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Users & Permissions plugin missing features.
- A users email can be updated right away, regardless whether the email has been confirmed or not.
- Only one authentication provider per user.
Context:
- Currently you have to write custom a custom endpoint if you want to let an already registered user update their e-mail address with confirmation.
- Let's you want to provide user with multiple login options, this currently not possible.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: I can't nest dynamic-zones, I can only nest predefined components.
Context: Nesting dynamic zones would open up a lot of possibilities regarding page building. One could for example create 'columns' component containing a dynamic-zone field in which it could nest various other components (e.g. text, image, list, FAQ, form).
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Can't make required fields, conditionally hidden. (See #24541, #24431)
Context: When configuring fields that are required, but also conditionally hidden, I can't save the entry as it gives me error for the hidden required field.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Reliability: upgrading Strapi between minor and patch versions is unreliable and often introduces unexpected regressions.
Context: We run many Strapi instances in production. Even minor and patch upgrades often introduce random bugs, making every upgrade a high-risk operation that requires extensive testing.
For example, latest problem we just hit, upgrading from 5.31.2 to 5.31.3 caused a severe GraphQL performance regression.
And this kind of issue arise multiple times a month
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Lack of an $every operator.
Context:
Imagine you have a product collection and each product has a tags collection (One to many). Each tag has a status enumeration property with 2 possible values: 'NotApproved' and 'Approved'. I want to be able to say: Give me all the products that have all tags in status = 'Approved'. I don't think you can do that today. At least not with the Rest API current set of operators. If I implement my own endpoint and use the low level API via knex I could. I bet someone already requested this feature before but I haven't had the chance to look in the history of issues/discussions.
So here the example, the following payload assumes at least one tag in Approved status but that's not what I want.
{
"filters": {
"tags" {
"status": {
"$eq" "Approved"
}
}
}
It would be nice if we could do something like this:
{
"filters": {
"tags" {
"$every": {
"status": {
"$eq" "Approved"
}
}
}
}
Or something along those lines. Also, maybe having a $some operator to remove the implicit meaning to make it more clear? The workarounds I can think of, require adding an extra property at the product level, and everytime a tag changes the status, you need to check and decide to update the property at the product levle to approved/not approved manually, which is very annoying. We should be able to filter them directly via the rest api with those operators.
What about a custom plugin that allows me to add a new operator? Could this be possible at least?
Which version are you on:
- [ ] Strapi 3
- [X] Strapi 4
- [ ] Strapi 5
Copy & Paste of Blocks
Issue: Lack of support for copying and pasting components or sections (dynamic zones, repeatable components) within or across entries.
Context: Content creators often need to reuse similar page sections. Not being able to copy/paste blocks slows down page building and introduces manual error. Ideally, Strapi would support options like βCopy block JSONβ and βPaste block,β even across projects that share the same content types.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Thanks @dominik-juriga for calling me out! ππ»
Migration Between Environments (Data + Media)
Issue: Strapi lacks a reliable built-in tool for migrating both data and media across environments.
Context: Teams frequently move content between dev, staging, UAT, and production. A migration system that includes media files, handles relations, and optionally shows diffs before applying changes would solve a major operational pain point.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Focus Point on Image Resize
Issue: Strapi does not allow defining a persistent focus point to control image cropping and resizing.
Context: For responsive, CMS driven layouts, editors need control over which part of the image remains centered. A focus point that applies to all generated formats (thumbnail, small, medium, large) would greatly improve image handling.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
βοΈ Yarn / npm / Monorepo Workspaces Support
Issue: Strapi Cloud lacks native support for Yarn Workspaces or npm workspaces. This is a complication for our Template everyone can use. Here is also related ticket to Feedback Strapi page .
Context: Modern teams frequently use monorepos to manage multiple apps and shared packages. Without workspace support, deployment workflows become complex or impossible on Strapi Cloud.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
βοΈ One-click Version Rollback
Issue: Strapi Cloud does not support rolling back to the previous deployment with a single click.
Context: When a release introduces a breaking bug, teams need fast recovery. A rollback option that restores the previous working version including environment variables and configs reduces downtime and operational risk.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Clients delete media because of the conflicting usage of the trash icon.
Context: Since 2022 (and still in 2024) my clients have been deleting media because they use the trash icon wrong. On a relation field it is for unlinking media. When you click it, the media edit opens, and the trash icon fully deleted the media. Please use something else than a trash icon for unlinking.
Which version are you on:
- [x] Strapi 3
- [x] Strapi 4
- [x] Strapi 5
Issue: You cannot create components from plugins.
Context:
I create a component object and add them like strapi.components[Component.uid] = Component;, but that feels very shaky. I would love for proper support for adding components from code. Like in 2022 and 2024
Which version are you on:
- [x] Strapi 3
- [x] Strapi 4
- [x] Strapi 5
Issue: Working with the new documentId system is very complex.
Context:
I fully understand why Strapi has moved to documentId, but ids are still used so much... All relations are saved by id (one for draft and one for published). The REST api uses id when you filters on relations (so you have to do relation[documentId][$eq]=. Same with the documentService.find etc. filters. The UP plugin hasn't even been updated to use documentId's, it still requires you to use id's. I see so many questions pop up on discord/github from users not understanding how to use documentId's/id's.
And it gets even worse when relations just don't act the way you expect them too or show up different then you'd expect in the API because relations are ids.
If instead of creating a new id for every publish, and new entry was created for every old version, and the id of the document was persisted, the database would be way more readable (numbers don't change as much), relations could be sorted up front, relations could be persisted after an unpublish/republish action. Relations won't disappear on a discard changes. And no need for all the syncing code that happens after a save to update number across the entire db.
I understand that the documentId behaviour is now core and can't be changed easily, but I would really appreciate if you could have a fresh long look at how all of this is currently working.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Your pricing for Self-Hosted is absolutely bonkers. How can you charge per month AND per seat in a selfhosted environment? This technique is used in the SaaS context to prevent unlimited usage on your cloud servers, etc, but in a selfhosting context it doesn't make any sense.
- We can understand a monthly cost when you manage the servers (aka Strapi Cloud), but when we manage the servers, we expect a smaller fee.
- We can undestand a per seat cost when more users = more server cost to you, but not when we manage the servers.
- The only thing in the Growth plan that makes sense as monthly cost is the Basic support which you should separate in a smaller optional monthly cost. The rest are fixed cost.
We would be willing to pay a small monthly fee per self-hosted Strapi instance which we would consider ongoing support for Strapi development. Since we don't have that option, we will be setting up a recurring donation on https://opencollective.com/strapi for each of our selfhosted instances. The downside is that we will not be getting any of the "paid features".
Please think about this since we really want to support Strapi financially, but not with the current pricing scheme. Thank you!
Issue: The dashboard becomes sluggish when handling a large number of collections.
Context: Certain areas of the admin panel lag noticeably. For example, opening a relational field and loading its edit modal can cause heavy slowdowns or temporary freezes. The permissions screen also struggles when many collections are present β interacting with the checkboxes can freeze the UI. This could be improved by using collapsible sections or only rendering expanded groups to reduce the render load.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue
Major Strapi version upgrades introduce extremely large design and architectural changes, creating disproportionate migration overhead.
Context
While major versions naturally include breaking changes, Strapiβs major releases have consistently required significantly more effort than is typical for similar OSS frameworks. Iβve used Strapi since v2, alongside many other long-lived tools in the ecosystem, and Strapi remains one of the most difficult platforms to upgrade between major versions.
A few concrete examples:
v3 β v4
- Introduced the
data { attributes }wrapper throughout the GraphQL plugin. - Required substantial refactoring across several of my UIs.
- Created a large, high-risk migration surface.
v4 β v5
- Removed that same wrapper causing another sweeping change (though I appreciated the incremental approach of keeping the old API temporarily).
- Changed the stable ID field to a value that updates more frequently, replacing it with a new
documentId. - While I understand the roadmap motivation (as @laurenskling noted above), the change landed too quickly for many real-world use cases.
On my side, this single ID change impacted:
- Page URLs built on the v4 ID
- Custom CRON jobs
- External services and integrations
- Third-party consumers of our API
The migration has taken months, involved multiple teams (technical and non), and cost tens of thousands of dollarsβwith very little direct payoff on our side.
Request
Please consider adopting a more incremental, predictable, and longer-horizon approach to major breaking changes. Breaking changes are expected, but Strapiβs scale and frequency of breaking changes between major versions feel unusually high. Even modest stability improvements would have a major positive impact for teams relying on Strapi in production.
Which version are you on?
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue:
Strapi lacks support for subpaths (i.e., https://example.com/cms instead of https://cms.example.com).
Context:
We use Strapi as an authoring tool for content associated with a platform. By convention, users of the platform log in at https://platform.mydomain.com , but content authors would log in at https://platform.mydomain.com/cms/admin .
Strapi doesn't support this natively. You're required to put a reverse proxy in front of it. Worse yet, if you host Strapi as a Docker image, you need to include the full reverse proxy path (https://platform.mydomain.com/cms) as a build argument when building the Docker image. This prevents me from being able to deploy a single Docker image to any environment (e.g., Dev, Test, Stage); the image has to be built for a specific environment before it can be deployed there.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Greater user controls (for Strapi editors)
Context: Being able to add user restrictions to access certain content types and entries. Our Strapi instance handles around 40 sites - if we wanted to allow a user access to Strapi (for example: an external SEO agency) we are unable to prevent them from seeing all the other content available in the instance. It would be good if we could assign users access to content types and then also by entries available in those types.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Can't make required fields, conditionally hidden. (See #24541, #24431)
Context: When configuring fields that are required, but also conditionally hidden, I can't save the entry as it gives me error for the hidden required field.
Which version are you on:
- [ ] Strapi 3[ ] Strapi 4[x] Strapi 5
- https://github.com/strapi/strapi/issues/24463
Issue: Conditionals lack on types and can't add more than one variable.
Context: When configuring attributes, only one condition can be set for visibility. Furthermore, it's only available for enums and booleans. It would be great to be able to add every JSON Logic conditions. This is very handful when developing REST APIs.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Pick either id or documentid, not both
Context: I've not upgraded to v5 because of documentid. Pick one, not both. I don't even mind if old project can't migrate to newer version, but for new projects I don't want to deal with two tier id system. It's madness. Go back to id or make documentid work properly.
Which version are you on:
- [ ] Strapi 3
- [x] Strapi 4
- [ ] Strapi 5
Issue: Cannot have custom / additional fields for media uploads / assets.
Context: The assets uploaded via media library can have predefined set of fields and modifying this is a non-trivial override of Strapi Admin. There needs to be a simpler approach to allow having additional fields for media uploads.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue:
Make Content Manager collection entry edit UI form overridable / extendable via React code.
Context: The form to edit a record for any collection / single-type should be overridable in-code. Some amount of this is possible via custom fields but any change that needs to deal with multiple fields (eg - conditional fields) needs to be a major feature. This change would enable computed fields, sections with pre-filled data, etc easy to achieve.
This would be a huge change but it would complement how the server-side aspects are easy to extend via additional routes/ controllers / services because the Admin UI side aspects aren't as easy to extend / override.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: Copy from locale (fill from locale) doesnt show relations at first.
Context: more info here also with a video https://github.com/strapi/strapi/issues/21322 , very core feature for content management systems i'd say
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5
Issue: New code goes live with bugs because testing is not done with real life databases.
Context: I agree fully with @vanwalj on his issue. Big new features go live in a patch version (https://github.com/strapi/strapi/pull/24798 in 5.31.1), they are tested by multiple people, but still contain data losing issues on real projects. Or 5.24.1 that got deprecated because https://github.com/strapi/strapi/pull/24316 resulted in heavy data loss for everyone who booted this version. Working with DP/non-DP locale components in CT's has become so complex, so much code is being written again and again to handle all of these cases. And edge cases keep slipping thru, failed to get spotted by testing because they are not tested against a database with 5 years of artifacts. The result is me reading every single PR that hit every release, to check if I need to do some extra testing on my real databases. Upgrading is a fear, instead of a joy.
Which version are you on:
- [ ] Strapi 3
- [ ] Strapi 4
- [x] Strapi 5