The current date/time picker does not allow keyboard input or copy and paste of the date/time (even when properly formatted) https://design-system-git-main-strapijs.vercel.app/?path=/story/design-system-components-v2-simplemenu--with-iconbutton It would be handy to have a date range, however this feature is perhaps more related to type suggestions for custom fields

Display a field only if some conditions are met.

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.

For both marketers and developers, it could be very useful to have the ability to contribute content from their tablet and mobile. To do that, the user interface needs to be responsive and adaptive to every device sizes.

In Strapi v3 we used to automatically regenerate the UID when the linked field changed. In Strapi v4 we no longer do this and you have to manually regenerate. This should be an optional and not set by default

Allow users to manage content by having a published and draft content at the same time.

Note: This feature request was passed in through an EE ticket. I'm posting it on their behalf. Currently, filtering collection types allows using case-sensitive versions of operators (see https://github.com/strapi/strapi/blob/main/packages/core/helper-plugin/lib/src/components/FilterPopoverURLQuery/utils/getFilterList.js#L14 ): equality ($eq) contains ($contains) not contain ($notContains) $startsWith $endsWith Could you add possibility to use case-insensitive version of these operators? $eqi $containsi $notContainsi $startsWithi $endsWithi It should be quite easy as it's already available in the API. So it's just about adding the possibility in React component. https://docs.strapi.io/dev-docs/api/rest/filters-locale-publication#filtering Currently, I overrided the node_modules with patch-package, but it's not a maintainable solution.

While you edit a blog post, you might associate it to a brand new category. Unfortunately, if the category doesn't exist, you have to save the post. Create the category. Then go back to the post to attach it the category. Until we release this functionality to create new entry on-the-fly on top of the relation fields. https://github.com/strapi/strapi/pull/5125

The easiest example to explain is laid out like this, we have the following models: Make Model Sales In this context we are talking about cars, so the make would contain a list of car manufacturers (Subaru, Toyota, Ford, Chevy, ect). Thus the model would contain some options like WRX, GT86, Mustang, Corvette. The way we would setup the sales model would be a oneWay relation to each make/model, and in the context of this request when we create a new "sale" we would select the make (say subaru) now when I go to select the model I should only be able to see/select the "WRX" model since it's made by Subaru. I should not be able to select "Toyota" "Mustang" as that car doesn't exist. See for more information: https://github.com/strapi/strapi/issues/8708

Summary The current and previous (v3) WYSIWYG editor are more so basic markdown editors and while markdown is awesome (since I'm writing this feature request in markdown smile ) I believe there is room for improvement and we could swap the default editor shipped with Strapi for something more feature rich and complete. There is already community options in both v3 and v4 such as CKEditor 5, React MD, Toast UI, and Editor.js I do think we should ship something more feature complete then forcing everyone to install one of the community options. If anything we could also make it easier to swap out our editor by standardizing methods to build new editors into the Strapi interface. Why is it needed? Our current editor only supports the bare minimums in terms of markdown support (eg no tables, ect) and support for things like inline youtube video previews, ect are a bit more complex to handle properly. Likewise not all non-technical content editors are familiar or like markdown. Likewise in many frontend frameworks a library is required to convert markdown to html. I believe it could be possible to handle this type of conversion server side and maybe caching those outputs (or pregenerating them). see: https://github.com/strapi/strapi/issues/12440