feat: Add category dropdown for Collection & Single types in admin UI #51
Conversation
This commit introduces a category dropdown in the admin UI for both Collection & Single types, improving content organization and user experience. Users can now create, edit, and delete categories, as well as filter content types based on the selected category. Additionally, content types can be assigned to categories through their settings, and the category is displayed alongside the content type in the main admin UI.
|
|
There was a problem hiding this comment.
Hello
Thanks for this proposal.
I have a little concern about the fact that it would be "only admin UI changes", but overall looks like a good idea to me.
Although, I'm not sure we want to add another layer of complexity to the admin UI at the moment.
Do not hesitate to rename the template file 😉
| - Handling category deletion: If a category is deleted, all associated content types should be moved to the default category. | ||
|
|
||
| # Example | ||
| No changes to the current API are required for this proposal. The proposed changes are only related to the admin UI. |
There was a problem hiding this comment.
There will likely be an impact on the server side, at least in the data that is being saved for content-types schemas.
Where would you like to store this category information?
There was a problem hiding this comment.
saving it in the file is the best option this will mean that the server would have to be restarted every time someone changes that
I would do 1 stap back with the proposal since we can't change the folder stucture for this I think it will be better to not save the categories groups in the file system but add a hook inside the content-type/single-type loading system and do that part in memory or not at all
tldr; save the categories in the schema files and generate what categories exist on startup or not at all
There was a problem hiding this comment.
Where would you like to store this category information?
As these categories improve the user experience in the Admin panel, saving it in the database is a better solution. A category as proposed now has no effect on the model structure or other backend implications. This way you also allow an easier way to customize the behavior of categories with their order & translations.
(And maybe if you have a good config structure this could also allow an option to save a user-personalized order, which could be saved in session for example.)
There was a problem hiding this comment.
I think first version should be file based and then later we can add db on top since now for every new strapi instance with a fresh db you now to redo all your categories since they are all only saved in the db
There was a problem hiding this comment.
Well, I don't like to see the schema file 'polluted' with Admin panel labels.
with a fresh db you now to redo all your categories since they are all only saved in the db
That's why we have config-sync and hopefully soon a selective data transfer system.
Don't get me wrong, I love to configure settings in file/git, but I see a better fit for these categories/labels in the database, which will also allow for order & translations.
There was a problem hiding this comment.
@MattieBelt Only thing it would add is ordering since internationalization would not be possible on the db layer without i18n installed and we can't assume it is. Also this would be a core strapi feature so if posible no plugins should be needed to make it work properly.
There was a problem hiding this comment.
Yes, it is possible to add translations this way, you would build it upon the translation/language system that exists in the core admin panel.
The database saved config could follow a similar naming system as the translation files, with useLocalesProvider and maybe even formatMessage it can be realized in core.
(I'm sorry translations would have been a better word choice, I edited my comment above. I also deliberately didn't use the term 'i18n' as that would point to the plugin, but that isn't the case 😉)
|
|
||
| 1. Add a category dropdown in the admin UI for both Collection & Single types, enabling users to filter content types based on the selected category. | ||
| 2. Allow users to create, edit, and delete categories from the admin UI. | ||
| 2. Automatically assign newly created content types to a default category (e.g., "Uncategorized") if no category is selected. |
There was a problem hiding this comment.
Instead of needing to create a category to default to, a content type's category could be nullable and those without a category would fall under "uncategorized". That way we don't have to worry about treating that category as a special case that can't be deleted, it can't be renamed (potentially a benefit to prevent confusion), we don't have to do a migration to initially create it and set all content-type categories to the default.
There was a problem hiding this comment.
Ye I think this would work better also for the approach I had in my mind
| An alternative solution could be to allow users to create custom views and filters in the admin UI, enabling them to organize their content types in a more personalized way. However, this solution might add more complexity than a simple category dropdown and require more significant changes to the admin UI. | ||
|
|
||
| # Unresolved questions | ||
| - How will the default category be handled in different languages? Will there be a translation mechanism for the default category name? |
There was a problem hiding this comment.
Following up my previous comment, I think "uncategorized" should be an unchangeable string in the translations file rather than an actual category entity.
| # Unresolved questions | ||
| - How will the default category be handled in different languages? Will there be a translation mechanism for the default category name? | ||
| - What will be the maximum number of categories allowed? Is there a need for a limit? | ||
| - How will category sorting be managed in the dropdown menu? Will users be able to sort categories manually or will they be sorted alphabetically by default? |
There was a problem hiding this comment.
My preference is for a sort order field in the category schema. Sort would happen first on sort order, then alphabetically.
There was a problem hiding this comment.
1 if we want manual sorting of the user would be a nightmare since or we need to add them to the db or we need to go over all schema files every time a order changes and update them all
2 if we just do alphabetically for both categories and content-types then we can do it fully in the file schema without having to look at the other schemas
so 2 would be better I think since it adds a lot less complexity
There was a problem hiding this comment.
remember when we talked about this? we talked about just adding a parent (nullable) reference to each collection type or single type, this should not affect current implementations and its basically meta to be visually sorted in the admin panel, it does not need to be more complicated than that, alphabetically sorted is fine. this way you can parent it to a "folder" or another collection/single_type
| The proposed solution includes the following design changes: | ||
|
|
||
| 1. Add a category dropdown in the admin UI for both Collection & Single types, enabling users to filter content types based on the selected category. | ||
| 2. Allow users to create, edit, and delete categories from the admin UI. |
There was a problem hiding this comment.
if we want to make it less complex we would could just use a string in the content-type for this
create: you create type in the new name or select from dropdown from all existing categories or leave it empty for uncategorized.
delete: after you delete or change the last item in the category the category will be auto deleted since there are no content-types left with it in info.Category
aka we add to the parser of the content-types on startup to create the categories and save them in memory
this means that this paser does all the heavy lifting since on restart it re generates all the categories
This commit introduces a category dropdown in the admin UI for both Collection & Single types, improving content organization and user experience. Users can now create, edit, and delete categories, as well as filter content types based on the selected category. Additionally, content types can be assigned to categories through their settings, and the category is displayed alongside the content type in the main admin UI.