#1573 closed task (blessed) (fixed)
Categories (née Tags)
Reported by: | obenland | Owned by: | obenland |
---|---|---|---|
Milestone: | Priority: | high | |
Component: | Plugin Directory | Keywords: | |
Cc: |
Description (last modified by )
Review the use of tags, see https://make.wordpress.org/plugins/2016/02/25/re-thinking-tags-in-the-plugin-directory/
Attachments (2)
Change History (48)
#3
@
9 years ago
Fwiw, I wouldn't consider comment 2 as part of tags, but perhaps a separate view/filter/whatever that we'd have to build.
#5
@
8 years ago
As mentioned and discussed, we're moving from tags to categories.
For this ticket, we have a few things we'll need to do:
- Create the categories, in a way that's localizable.
- Output the categories on the plugin detail page (already done?).
- Allow plugin authors to add categories to their plugins in the plugin admin (maximum of three).
- As part of the migration script, map current tags to categories.
I think comment:2 (and the Featured "category") should be a separate taxonomy that doesn't display on the plugin detail page. Thoughts?
The other two proposed taxonomies will be completed in other tickets.
This ticket was mentioned in Slack in #meta by obenland. View the logs.
8 years ago
This ticket was mentioned in Slack in #meta by netweb. View the logs.
8 years ago
This ticket was mentioned in Slack in #meta by obenland. View the logs.
8 years ago
This ticket was mentioned in Slack in #meta by obenland. View the logs.
8 years ago
#22
@
8 years ago
@dd32: I added a suggestion as to how to handle tag to category conversion on import: 1573.diff.
Should we convert the category slugs to IDs in the map directly or continue with slugs and getting IDs?
Is that spot in the importer a good point to do the conversion or should it be done somewhere else?
#23
follow-up:
↓ 24
@
8 years ago
@obenland currently the sync script uses the same importer.
I'm curious if you think we should be coverting tags on each import, or if we should instead just do it once as a one-time migration?
I'm kind of thinking the add plugin form should ask the submitter to choose the categories, and we should only assign categories automatically for existing plugins.
#24
in reply to:
↑ 23
;
follow-up:
↓ 25
@
8 years ago
Replying to dd32:
I'm curious if you think we should be coverting tags on each import, or if we should instead just do it once as a one-time migration?
Not sure how much this would hold up each sync, but it should be enough to do it once. Should I just add the class and not hook it up for now?
I'm kind of thinking the add plugin form should ask the submitter to choose the categories, and we should only assign categories automatically for existing plugins.
That sounds reasonable, I'll add it to the upload shortcode.
#25
in reply to:
↑ 24
@
8 years ago
Replying to obenland:
Replying to dd32:
I'm curious if you think we should be coverting tags on each import, or if we should instead just do it once as a one-time migration?
Not sure how much this would hold up each sync, but it should be enough to do it once. Should I just add the class and not hook it up for now?
It's not a performance issue to run it every time, it's more of that we don't want to be overriding their category selection in wp-admin
every time they commit a change :)
Perhaps we should only run it if the post doesn't have any categories assigned?
#32
in reply to:
↑ 30
@
8 years ago
Replying to obenland:
Can you think of more to do here?
Category pages should be sorted by Most Active Installs first I believe, in fact all archives should be (unless they've got another pre-selected order).
#33
follow-up:
↓ 34
@
8 years ago
Spacing is weird on mobile (see screenshot). Can we change to text to a sentence instead?
Showing plugins in the "Media" category:
Something like that?
#34
in reply to:
↑ 33
@
8 years ago
Replying to samuelsidler:
Spacing is weird on mobile (see screenshot). Can we change to text to a sentence instead?
Showing plugins in the "Media" category:
Something like that?
I find it a little wordy and I'm not sure how scalable it will be given the amount of taxonomies we're planning on using.
What about Category: Media
to make it less redundant?
@ipstenu mentioned an idea: