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.

There are three migration types being executed in this specific order: Internal migrations User migrations Schema update The order should be: Internal migrations Schema update User migrations Reason behind this is that when the developer is working on something, it is done in this order: A new field is added in the CMS and the migration is written at the same time to work with that field. In our scenarios, all the user migrations are somehow connected to the schema change and require schema to be updated first.

It might happens that you're going to develop a website which includes a blog. It could be interesting to split the APIs into two different projets. However, it can be annoyed to deploy on two different servers for such a little API. That's why the multi-tenancy is interesting! The multi-tenancy (or multi-projects) changes the architecture of an application to allow multiple projects in a single Strapi application. Each project is fully independent, you can use different databases, configurations, plugins, etc. More details https://github.com/strapi/strapi/issues/1465

When using i18n, it seems like relationships are dropped. When using translations, this can be a bit annoying.

Currently we do not validate any size for image but its available for strapi logo customisation, it would be useful if its provided for all image uploads if required we can use it.

I'm migrating from Strapi 4 to Strapi 5 and need to override the default login page in production. In Strapi 4, I successfully replaced the default login component by using webpack’s NormalModuleReplacementPlugin to redirect users to my custom login component. In Strapi 5, however, despite providing my custom login component (which I placed in the expected directory), users are always redirected to the default login screen. (To be clear, I’m not referring to just modifying the welcome page or the login logo—I want the entire login component to be replaced with my custom one.) Has anyone managed to override the default login page in production in Strapi 5? What steps or configurations are needed to ensure that my custom login component is used instead of the default one? Any insights or updated approaches (especially with Vite now being used for the admin build) would be greatly appreciated! StrapiProject/src/admin/webpack.config.js: "use strict"; const path = require("path"); const webpack = require('webpack'); const strapiCacheSrcPath = path.resolve(__dirname, "../../.cache/admin/src/pages/AuthPage/components/Login"); /* eslint-disable no-unused-vars */ module.exports = (config) => { if (process.env.NODE_ENV === "production") { config.plugins.push( new webpack.NormalModuleReplacementPlugin( /admin\/src\/pages\/AuthPage\/components\/Login\/(.*).js/, (resource) => { if (resource.createData.resource){ const replacedFilePath = resource.createData.resource.replace(strapiCacheSrcPath,path.resolve(__dirname,'ui/pages/AuthPage/components/Login')); if (replacedFilePath.endsWith('.js')) { resource.createData.resource = replacedFilePath; } } } ) ); } return config; };

Right know strapi doesn't handle this type of sorting and that would be very handy for use experience because if They can do this with fields, why not with relations? Right know strapi already allow populate:{field:{count:true}}, but there isn't a straight forward way to add this very common functionality of ordering by count or sum.

It's a very common practice for content editors to press ⌘+S or strg+S to save a document. This shortcut should have the same behaviour as clicking the 'Save'-Button.

With the upcoming release of Strapi v4.3.0 and Media folders, the content API will not be able to utilize them. For those that believe it would be a good addition to also have folders at the content API level please leave a vote and comment what your use case would be.

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.