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.

Making the theme accessible as CSS variables would help developers use more native CSS like syntax when writing their styles. It wouldn't be too hard to implement we could add a style tag to App.tsx and set its HTML to the theme object transformed. Here's a super quick demo I threw together https://codepen.io/Link2Twenty/pen/dPPXXQv?editors=0110

I'm using Strapi to create scientific documentation website with deeply nested, interlinked section content structures. Multiple editors with no coding background work on the website's content, making the Rich Text editor ideal for their needs. Currently, there's no straightforward way for users to set internal links to open in the same tab. I propose adding an option in the Rich Text editor to allow users to choose whether a link should open in a new tab or the same tab when creating or editing links.

At the moment, if someone add the color-picker custom field to a collection/component, the picked color is shown in the collection list only as a Hexadecimal string. It would be really nice if it could also show the actual color, like in the edit/create view.

It would be amazing if the image editor in the Media Library allowed for the selection of a focal point of the image so devs can crop responsive images accordingly. See for instance: https://docs.imgix.com/tutorials/focal-point-cropping

Currently, the “Media” field type is predefined so that Media documents only have a few associated information fields: File Name, Alt Text, Caption, and Location to define folders. It is not possible to add fields that would make it possible to classify or filter these Media documents, to find them or display them in a structured way. It would seem logical, however, to be able to freely add fields allowing these elements to be “qualified” (tags or list of choices or an additional free field that is neither a legend nor an alt). This customization, at a minimum, should be able to be done at the global level, but even more logically, it should be able to be done at the level of the field itself, as defined in the collection where it is integrated. The current experience is as follows: When I have a Media field in a collection, when using Strapi as a CMS, I can upload a media, but I only have the 4 fields mentioned above to associate information with it. Experience required: In such a specific collection, I would like to be able to upload documents via a Media field, but I would like to be able to add other types of information, which will allow me to find them in the media library later or allow me, when I display the information in my document, to present the associated media elements in a structured way, using this or these fields.

I have problem when using the populate deep plugin with localizations. When I populate deep, it will give me nested localization list, and the response is pretty large if we have multiple locales. I'd suggest that is it possible when get a content, we can have something like http://strapi/content-type/id?exclude=localizations

Consider adding the ability to specify additional attributes on model relations especially many-to-many. An example would be a course with many students and student has many courses and we want to specify the score of the student in that specific course. This would translate in SQL as a new relation table with student id and course id and we can add an additional column named score.

It would be great if we can version of our apis. v1/posts v2/posts

Hi team, I noticed that Strapi uses a fixed version of Vite ( https://github.com/strapi/strapi/blob/f93d6eabe52aa7681655cfa08eedbc3708dbb90d/packages/core/strapi/package.json#L168 ), which means that once a new vulnerability is discovered, we can't patch it until you guys patch and release a new Strapi version, or we override the package's version on our end. Could the ^ prefix be added to the Vite version? This would allow package managers to use the latest compatible version, so we can patch the vulnerabilities without depending on a new Strapi release. Thanks in advance.