Feature Requests

I believe it would greatly improve the user experience if we can add a "folder-like" grouping function to content types (single type and collection type), so that if you have a lot of content types (for example if you have like 50 webpages, you will have like 50 single types), it really makes a lot more sense to have groups. For now users can only mitigate this by using some naming conventions, but I doubt if this is an elegant solution.

Summary Allow multiple related content-type schemas to be organized within a single API folder, enabling logical grouping of related entities and cleaner project structure. I spent a long time doing this and not understanding why it didnt work, before being told i could grouo the controllers etc but not the schemas. Motivation Current Problem In Strapi 5, each content-type requires its own API folder: src/api/ ├── forum/ ├── forum-thread/ ├── forum-reply/ ├── forum-moderator/ ├── forum-subscription/ ├── forum-thread-subscription/ ├── forum-notification/ └── forum-badge/ For projects with related entities (forums, e-commerce, multi-tenant systems), this creates: many folders for a single feature domain (forums) Cluttered admin menu with many similar entries Poor developer experience when navigating the codebase Difficult to understand relationships between entities Proposed Solution Allow multiple content-type schemas within one API folder: src/api/forum/ ├── content-types/ │ ├── forum/ │ │ └── schema.json → creates 'forums' table │ ├── thread/ │ │ └── schema.json → creates 'threads' table │ ├── reply/ │ │ └── schema.json → creates 'replies' table │ ├── moderator/ │ │ └── schema.json → creates 'moderators' table │ └── subscription/ │ └── schema.json → creates 'subscriptions' table ├── controllers/ │ ├── forum.js │ ├── thread.js │ ├── reply.js │ └── moderator.js ├── routes/ │ ├── forum.js → /api/forum │ ├── thread.js → /api/forum/threads │ ├── reply.js → /api/forum/replies │ └── moderator.js → /api/forum/moderators └── services/ Benefits Logical Grouping: Related entities organized together Cleaner Admin Menu: Hierarchical navigation (Forum → Threads, Moderators, etc.) Better DX: Easier to understand domain boundaries Scalability: Large projects can organize dozens of content-types Backward Compatible: Existing single content-type per folder still works Technical Implementation Each schema would still: Create its own database table Have independent CRUD operations Maintain separate permissions Generate its own API endpoints The change is purely organizational - the content-type loader would: Scan for multiple schema.json files within content-types/ subdirectories Register each as a separate content-type Optionally group them in the admin UI under a parent category Use Cases Forums: threads, replies, subscriptions, moderators, badges E-commerce: products, variants, reviews, inventory, shipping Multi-tenant: tenants, users, roles, permissions, settings CMS: pages, sections, blocks, menus, redirects LMS: courses, lessons, quizzes, enrollments, certificates Related Issues & History #12863 (Closed in v4 - revisit for v5?) #2548 "Group content type" (2018) #12674 Documentation issues with grouped APIs This feature was previously rejected for Strapi v4, but with Strapi 5's architectural changes maybe it's worth reconsidering. Why This Matters for Strapi 5 Strapi 5 represents a major evolution. Competitors like Contentful (spaces/environments) and Sanity (schema grouping) handle content organization better. As Strapi scales to larger projects, hierarchical organization becomes essential for: Enterprise adoption Developer productivity Maintainable codebases Alternative Considered Current workaround is hiding collections via pluginOptions.content-manager.visible: false, but this: Confuses other developers ("where's the schema?") Doesn't solve file structure clutter Loses admin UI benefits

I added the 'el' locale in app.js, but Greek does not appear as option in Interface Language dropdown. This is because the translation file is missing. Since I couldn't find a way to add it, would you mind adding it. If the problem is the translation file itself, I can provide you the whole file translated in Greek. Just let me know.

I have a hero component where I have an enumeration called versions, for some of the versions of this hero component I want to show conditional image field. Currently I can chose it show for only 1 version. If we have the ability to choose multiple enumeration values as condition or if we can add multiple if conditions, it will solve a lot of problems.

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.

It feels like this is a completely missing feature of the filter feature. Found it surprising that this feature didn't exist. You can filter by createdAt, updatedAt but not state (draft/published).

add option for disable this plsss

Currently typescript compilation is a bottleneck when the app is trying to start, taking upto 16seconds in my case. The bun runtime promises and seems to provide faster startup times. We can provide a way to ignore typescript compilation when the runtime is bun. The current implementation looks for the presence of tsconfig.json to identify if the project is a typescript project and dynamically changes the outdir.

The current Data Import/Export feature is NOT USABLE. This was reported in https://github.com/strapi/strapi/issues/20270 but closed as "not planned". This is a basic and crucial feature of a CMS, how can it not be intended/planned?!

Would it be possible to add a copy button on the repeatable components? The copy would duplicate the entry and insert the new one below it.