Skip to content

feat: Add category dropdown for Collection & Single types in admin UI #51

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Webbist-dev wants to merge 1 commit into
base: main
Choose a base branch
from
Open

feat: Add category dropdown for Collection & Single types in admin UI #51

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions rfcs/xxxx-template.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
- Start Date: (2023-04-18)
- RFC PR:

# Summary
Implement a category dropdown in the admin UI for both Collection & Single types.

# Motivation
The motivation behind this proposal is to simplify content organization and improve the user experience while managing content in the Strapi admin interface. Currently, users have to navigate through a long list of Collection and Single types, which can be time-consuming and cumbersome, especially when dealing with numerous content types. By introducing a category dropdown, users can easily group and filter their content types, making content management more efficient and user-friendly.

# Detailed design
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.
Copy link

@Boegie19 Boegie19 Apr 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

2. Automatically assign newly created content types to a default category (e.g., "Uncategorized") if no category is selected.
Copy link

@innerdvations innerdvations Apr 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@Boegie19 Boegie19 Apr 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ye I think this would work better also for the approach I had in my mind

2. Enable users to change a content type's category through the content type's settings.
2. Display the category alongside the content type in the main admin UI.

Edge Cases:

- Handling empty categories: If all content types within a category are deleted or moved to another category, the empty category should still be displayed in the dropdown to allow users to assign new content types to it.
- 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.
Copy link

@nathan-pichon nathan-pichon Apr 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

@Boegie19 Boegie19 Apr 21, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@MattieBelt MattieBelt May 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link

@Boegie19 Boegie19 May 1, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@MattieBelt MattieBelt May 3, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@Boegie19 Boegie19 May 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link

@MattieBelt MattieBelt May 3, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😉)


# Tradeoffs
Some tradeoffs to consider when implementing this proposal:

- Complexity: The addition of categories adds a new layer of complexity to the admin UI. However, the benefits of improved content organization and user experience outweigh this tradeoff.
- Workload of implementation: The implementation of this feature requires updates to the admin UI and possibly some backend changes. This might increase the workload for the Strapi team.
- Integration with current features: This proposal should not conflict with existing features and can be seamlessly integrated into the current admin UI.

The proposal does not require significant migration efforts, nor does it introduce breaking changes to existing Strapi applications. However, it might require updates to existing teaching resources, including videos, tutorials, and documentation to reflect the new category feature.

# Alternatives
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?
Copy link

@innerdvations innerdvations Apr 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following up my previous comment, I think "uncategorized" should be an unchangeable string in the translations file rather than an actual category entity.

- 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?
Copy link

@innerdvations innerdvations Apr 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My preference is for a sort order field in the category schema. Sort would happen first on sort order, then alphabetically.

Copy link

@Boegie19 Boegie19 Apr 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@andre2dash andre2dash May 8, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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