Opened 13 years ago
Last modified 9 months ago
#19859 reopened enhancement
"Bulk Edit" Missing The Ability To Edit Tags
Reported by: | ademos | Owned by: | oglekler |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Quick/Bulk Edit | Keywords: | needs-patch needs-design |
Focuses: | Cc: |
Description
Though I can add, remove and edit "categories," I cannot do such actions to "tags" inside of /wp-admin/edit.php
So basically, I'm interested in a "bulk tag editing" GUI for the WordPress admin.
===
I was hoping to find out the status of this feature (planned, not planned, etc) but it appears that no one has spoken about this feature on the WordPress Trac.
Is there any interest in adding this feature? And could the respondent please provide any details on why or why not?
Thank you for your time.
Attachments (7)
Change History (82)
#3
@
13 years ago
- Resolution worksforme deleted
- Status changed from closed to reopened
knutsp:
I apologize for my miscommunication.
===
I was requesting the following feature
1.) Click on a group of posts
2.) See the tags associated with that group of posts
3.) Rename, add or remove tags from that group of posts
===
If you look at how Gmail manages tagging, you can how their GUI works.
http://img192.imageshack.us/img192/7476/gmailbulktagediting4.png
Within the "Label as" box" you can see a check mark, indicating which tags are currently being used.
This is what I mean when I speak of "associated tags."
Such a feature is useful, because you can see which tags are used and which are unused.
In addition, you can individually add and remove tags from the group, by checking and unchecking them
===
From what I can see, this functionality is not available in current version of WordPress Core.
Tags can be overwritten, but it doesn't appear possible to see the tags associated with a group of posts.
===
So I was inquiring if there was any interest in adding this functionality to WordPress Core.
#5
@
13 years ago
@ademos: I see.
This situation is equal for both categories and tags. You can not see which categories that are already used on the posts.
Renaming tags or categories should not be included in this ticket, because that is a completely different thing. Adding or removing tags and categories on the basis of the existing terms in a set of posts could be a nice enhancement.
#6
@
13 years ago
knutsp:
I'm glad you agree that this feature could be useful.
I frequently find myself bulk editing posts, but not knowing which tags are already used.
---
I agree that renaming tags/categories is a separate GUI concept, but I didn't make multiple tickets for my inquiry, because I wasn't sure if my request had already been made or not. (since I am new to WordPress and the Trac software)
In other words, I didn't want to annoy the moderators with redundancy.
However, if this GUI concept has not been requested before, I would happy to separate my request into as many tickets as deemed necessary.
===
ocean90:
Thank you for adding the "ux-feedback" keyword.
It hadn't occurred to me, to label this ticket as part of the user-experience, but your addition makes sense.
#7
@
13 years ago
@ademos: This enhancement request is about editing tags (and categories) in the scope of posts. Renaming tags (and categories) should not be possible in this scope because this will affect every post that has this tag (or category). Such renaming should only be possible from the Tags (or Categories) screen.
This ticket should be about adding and removing categories and tags to a set of posts in bulk editing, based on the existing set of categories and tags already found in the actual set of posts. It could be enhanced to work on any taxonomy.
My advice is to change the description of this ticket to limit the task and to clarify. This will, in my view, increase the chance of getting someone to write such a patch in the first place, and getting it committed in the second phase.
#8
@
13 years ago
@ademos: I agree that this would be a useful enhancement, I've just had to move a bunch of posts from one category to another and not being able to see the categories in the bulk edit mode was not helpful.
I think it's simply a matter of displaying the categories or tags that are being used for the selected posts. However you would run in to complications if, you had selected multiple posts each with different categories. Which categories would be displayed? If you display all of them do you then when you update do you apply all of the categories or tags to all of the posts.
So what is on the face of it a simple problem, I think more though on this is needed. I'm wondering if the command "edit" is a little misleading for users, as the functionality is really add.
I'll think some more and post again if I think I have a solution.
#9
@
13 years ago
@Knutsp: Thank you for your advice, but I was unable to find a way to edit the description of my ticket. (I tried clicking the "Modify" link, but that only allowed me to change the summary and ticket attributes)
Would you suggest I create a new ticket to fix my mistake in description verbiage?
@gavinwye: You've made some good points about the complexity involved with implementing this feature, from a user-experience level. I agree that communicating which categories and tags are associated with each post, will be complicated. But with enough people involved, I think a solution can be found.
#10
@
13 years ago
- Owner set to gavinwye
- Status changed from reopened to assigned
@ademos: I'd leave the ticket the same as it has the history, I found it when I had the problem, so I don't think there is anything wrong with the description.
I'm going to try and mock up something this coming weekend as a solution to the problem, I'll post back on Sunday to let you know how I get on.
#12
@
13 years ago
@gavinwye: Okay, I'll take your advice and leave my ticket as it is.
I look forward to seeing your mockup!
#13
@
12 years ago
@gavinwye: I was curious if you had any update on your mock up of this GUI. You mentioned that you were planning to reply soon, but it's been awhile since our last discussion.
#14
@
12 years ago
@ademos, Thanks for nudge. It had completely fallen off my radar.
I've quickly sketched up something that I think would solve the problem. The biggest change is tags should be displayed for posts that are being edited in the tags field. At the moment the it is implied that the tags are not there. The same pattern should be used to remove tags as is used to remove the posts.
I've also take this opportunity to make some other changes to the architecture of this area. Currently the bulk edit component is displayed below the title bar which menas that the column headings are don't match up with the posts below. Pulling the bulk edit component out and placing it about the title bar would solve that. It then also seems sensible to rearrange the five drop down lists that are there as well.
My one question is, should you be able to bulk add tags here? I've added it, but all of the other functionality here is to do with editing existing values not adding. But I can't see a better place for this and it makes sense to me to be here.
Here's the sketch:
A few final points. This ticket has been open for a long time with little interest. So is that fact that this doesn't work really a big problem? Should this even be fixed? How many users would benefit?
It would be good to know your thoughts.
#15
@
12 years ago
@gavinwye: Thank you for sketching a mock up of this new area. This design looks very similar to what I was imagining. Specifically, I like how you compartmentalized each area, giving a separate space for "Categories" and "Tags."
In response to your concern about user engagement and interest, I think it would helpful to announce your mock up somewhere. Such an announcement would ensure that you got feedback from users and the core team. I don't know the correct place for such an announcement, but I sometimes see mock ups posted here: http://make.wordpress.org/ui/
Overall, I think this idea at least deserves some exposure before it is considered unwanted. The concept of having easier access to tags and categories during bulk editing, certainly seems like a feature that could be useful to many people.
#18
@
11 years ago
In Wordpress 3.8, adding a tag using the bulk interface doesn't work for me anymore - the new tag does not show up.
Did something break? Pretty sure this was working before.
#20
@
10 years ago
Has there been any update on this bug/feature?
I found a very old blog post from 2011 explaining how to bulk edit posts and in their screenshots the tags did appear when you clicked Bulk Edit. I created a stackexchange post here http://wordpress.stackexchange.com/questions/147656/bulk-edit-tags-in-wordpress which shows the screenshots.
#21
@
10 years ago
@zerodegreeburn There has been no interest in this for a very long time. I'm not pushing this forward as if there were interests someone would have solved the problem.
I'll contribute if someone want's to build this but there doesn't seem to be much interest.
#22
@
10 years ago
@gavinwye: Though two years have passed, I am still interested in solving this problem. While the WordPress Trac is publicly visible, it's possible that people who might be interested in solving this problem are not yet aware the problem is being discussed. (because they didn't notice this ticket on WordPress Trac) So at some point, (if no one else does so) I will find the preferred method of announcing this problem, so we can determine if people are truly uninterested in this problem or if they were simply unaware that the problem existed.
@zerodegreeburn: Thank you for your contribution. I had not realized that the "Bulk Edit" feature did display currently used tags, in a previous version of WordPress. This could be useful as a reference for fixing the feature in the current version of WordPress.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
7 years ago
#25
@
7 years ago
This ticket could benefit from a simple clickable prototype to better communicate how it'd work, if anyone's up for some additional design work.
This ticket was mentioned in Slack in #design by boemedia. View the logs.
6 years ago
#27
@
6 years ago
- Keywords needs-design added
With design contributors now having access to Invision, this ticket would be a good one to draft up a prototype to be able to click around. I’ve added a new keyword ‘needs-design’ and will note this down for contributor day at WordCamp Europe this Thursday in Belgrade. Hopefully we have people wanting to pick this up to move it forward.
This ticket was mentioned in Slack in #design by boemedia. View the logs.
6 years ago
#29
@
6 years ago
I agree with the comment 14 which says that perhaps it doesn't belong under "Edit". Edit for author, comments, status, pings, and sticky all have choices of "No change" or the actual different value for that field. Perhaps categories and tags don't belong together with this, and should have their own bulk action of "Add Term" in which the added terms are applied to all posts selected. I think that's what is happening already, but the interface is unclear what you will get when you type a tag or select a category.
There doesn't seem to be a good way to bulk remove a tag or category.
#30
@
5 years ago
- Keywords ui-feedback ux-feedback removed
As this needs a design, just removing the feedback label to get that focus.
This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.
3 years ago
This ticket was mentioned in Slack in #design by estelaris. View the logs.
3 years ago
#33
@
3 years ago
We can add the same X icon as seen to the left of the posts into the tags field as I did in the above mockup.
#34
@
3 years ago
- Keywords needs-testing added
Highlighted in component bug scrub 14 March 2022.
Copying over update written by Nalini who is unable to add comments on this ticket.
Summary:
- this ticket was last updated three years ago as needing design for a prototype design.
- Estelaris asked design channel for a review and design prototype. When update comes back from design, Mary advised core can produce a patch if still is a problem.
- webcommsat: could not replicate the issue and asked if anyone else could.
- MaryBaum and Meher to test async and add findings to the ticket.
#35
@
3 years ago
- Keywords needs-testing removed
- Owner changed from gavinwye to marybaum
- Status changed from accepted to assigned
This ticket was mentioned in Slack in #design by paaljoachim. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
3 years ago
#40
@
3 years ago
I went ahead and added a prototype.
The focus is on removing current tags in the Bulk Edit mode.
https://www.figma.com/proto/enUiWahhLPdHAe7VOTlUeU/Bulk-edit-remove-tags?node-id=1%3A2&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=1%3A2
Let me know if you would like me to extend the prototype.
#41
follow-up:
↓ 46
@
3 years ago
Have confirmed the behavior with tags, and I'll note here that the same thing is true of categories. You can add them in the Bulk Editor but not change them or remove any--the UI doesn't show which categories are checked.
The Quick Editor does show which categories are checked, and you can uncheck and recheck to your heart's content.
I took a look at @paaljoachim's Figma prototype--it's faithful to the tags UI in the post editors, both block and Classic, and therefore slightly different from the Categories UI. My question: should it be?
@paaljoachim, does it make sense for you to own this process, and the ticket, going forward?
Or, should we use a single pattern style for both categories and tags, and standardize that across Bulk, Quick, block and Classic editors?
This ticket was mentioned in Slack in #core-editor by paaljoachim. View the logs.
3 years ago
#43
@
3 years ago
Testing using WordPress 5.9.2
Let's say that I bulk edit three posts that all have a common category "Books".
These also uses the same tag "Fantasy" which are to be replaced.
Expectations based on quick editing one post.
I would expect when bulk editing these three posts to see the category "Books" checked and listed on the top of the categories list. I would also expect to see the tag "Fantasy" in the Tags list. So that I could replace the tag "Fantasy" with "Scifi" and click the Update button and see all three posts with the "Scifi" tag.
Currently bulk editing 2 or more posts does not show any checked categories or list any tags used. Both are blank. This breaks the consistency in comparison for quick editing a single post.
I would suggest to first make bulk edit for two or more posts work. To where it is similar to quick edit of one post. Keeping the current method in place.
- Common shared categories are checked and (should be) listed at the top of the Categories list. Unchecking and clicking Update will remove the unchecked categories from the bulk edited posts.
- Common shared tags are seen in the tags screen. Removing either by clicking into and manually removing as can be done in Quick Edit or clicking the x inside the circle as I mocked up further above will remove tags from the bulk edited posts.
I would say that consistency between Quick Edit and Bulk Edit is a very important aspect. As a user learns to use the Quick Edit there is the expectation that Bulk Edit would work the same way.
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
3 years ago
#45
follow-up:
↓ 48
@
3 years ago
Currently, bulk editing is done on a model where all values are empty by default, and submission of additional data is added to posts (if that data has multiple instances, e.g. categories/tags) or replaced (if it's unique, e.g. author/status).
Having any of the current data for the selected posts makes this considerably more complex, as the form would now need to fetch data for every selected post and compare the data for all tags & categories. That's trivial if we're comparing three posts, a couple taxonomies, and each taxonomy has a couple dozen elements, but I have some doubts about the scalability.
I do think it's a weakness that there's no option to remove terms in bulk editing, however. I think we should be looking at a context-insensitive interface for bulk removing terms.
The current interface is dedicated to adding new terms to selected posts. If we added an option to toggle the action those fields perform - e.g., a checkbox that switches the behavior to 'Remove Categories' or 'Remove Tags', then we could avoid needing to identify which terms were common between all the selected posts.
We still wouldn't be able to simultaneously remove and add terms in bulk edit, but it would be a significant improvement over what we have now.
#46
in reply to:
↑ 41
@
2 years ago
Replying to marybaum:
I think I misspoke earlier. The quick-edit behavior shows all the categories checked. But once you have two or more posts in the bulk editor, only the common categories are checked.
Have confirmed the behavior with tags, and I'll note here that the same thing is true of categories. You can add them in the Bulk Editor but not change them or remove any--the UI doesn't show which categories are checked.
The Quick Editor does show which categories are checked, and you can uncheck and recheck to your heart's content.
I took a look at @paaljoachim's Figma prototype--it's faithful to the tags UI in the post editors, both block and Classic, and therefore slightly different from the Categories UI. My question: should it be?
@paaljoachim, does it make sense for you to own this process, and the ticket, going forward?
Or, should we use a single pattern style for both categories and tags, and standardize that across Bulk, Quick, block and Classic editors?
This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.
2 years ago
#48
in reply to:
↑ 45
@
2 years ago
Thanks @joedolson . If it could be added to have an option to toggle the action those fields perform - e.g., a checkbox that switches the behavior to 'Remove Categories' or 'Remove Tags', would that be sufficient for an interim solution and one we could aim for 6.2 earlies?
Replying to joedolson:
Currently, bulk editing is done on a model where all values are empty by default, and submission of additional data is added to posts (if that data has multiple instances, e.g. categories/tags) or replaced (if it's unique, e.g. author/status).
Having any of the current data for the selected posts makes this considerably more complex, as the form would now need to fetch data for every selected post and compare the data for all tags & categories. That's trivial if we're comparing three posts, a couple taxonomies, and each taxonomy has a couple dozen elements, but I have some doubts about the scalability.
I do think it's a weakness that there's no option to remove terms in bulk editing, however. I think we should be looking at a context-insensitive interface for bulk removing terms.
The current interface is dedicated to adding new terms to selected posts. If we added an option to toggle the action those fields perform - e.g., a checkbox that switches the behavior to 'Remove Categories' or 'Remove Tags', then we could avoid needing to identify which terms were common between all the selected posts.
We still wouldn't be able to simultaneously remove and add terms in bulk edit, but it would be a significant improvement over what we have now.
This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.
2 years ago
#50
@
22 months ago
Component ticket scrub review January 30, 2023:
- patch would be needed for the option @joedolson has suggested what could be a better, interim solution. Further reviews on the .png Joe has suggested could be invited from Design Team.
- potential ticket to raise in dev chat, though not for 6.2.
- @oglekler offered to further review on a potential patch. She suggested the same things as apply to categories should apply to tags as well.
This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.
22 months ago
@
22 months ago
Mockup of tags (and categories) Bulk edit. I suggest previewing what tags are applied to all/part/none of the tags. I am not pretending that I like this mockup very mush, but my general idea is adding a bit more information and apply logic, which is widely used now to add new items to some lists. It can be implemented to the categories as well. Because categories and tags can be transferred to each other, they can be handled in a pretty similar way.
#52
@
22 months ago
Component review today
- @oglekler has suggested a first mock-up for a potential different solution. There are a couple of other mocks-ups on this ticket. Inviting comments to discover if we can find a solution, potentially combining some of the mock-ups posted.
@paaljoachim would you be able to share your thoughts? Would you also like to own this ticket?
This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.
22 months ago
#54
@
22 months ago
- Owner changed from marybaum to oglekler
- Status changed from assigned to reviewing
@
21 months ago
One can not see which category belongs to a specific post. Tags are just not seen and not possible to bulk edit.
#55
follow-up:
↓ 56
@
21 months ago
I am taking a step back.
I selected multiple posts which use various categories.
The blog posts are seen but it is not visible which categories belong to the posts.
(Looking at the mockup that @oglekler shared for tags and it can also be brought over to categories bringing a consistency between these.)
A checkmark = shows that these posts all have in common a category / categories.
A - (minus or dash) = shows that specific category / categories are used in some of the posts.
Empty checkbox = shows that a category / categories are not used.
@oglekler uses the above example for tags. It is a good way to use for categories and tags.
It makes the tags visible showing which are used, which are partly used and which are not used.
---
Based on @oglekler helpful mockup above I created my own mockup.
@
21 months ago
Here is an example using check, minus and empty checkbox. To show categories and tags included in all posts (checkmark), to show partly used, and not used.
#56
in reply to:
↑ 55
@
21 months ago
Replying to paaljoachim:
I selected multiple posts which use various categories.
The blog posts are seen but it is not visible which categories belong to the posts.
I believe there is another ticket for that: #11302, though it would be great to fix both :)
#58
@
21 months ago
@rutviksavsani starts to investigate how this can be done and will be back with the findings.
If you are also working on this ticket, please, write about your suggestions and progress for other not to repeat the already covered path.
#59
follow-up:
↓ 61
@
21 months ago
- Resolution set to invalid
- Status changed from reviewing to closed
@oglekler Here are my findings and suggestions for this component.
Considering that we may also support custom taxonomies other than Categories and Tags. I am taking few suggestions and approaches from discussions above and presenting this.
PS: The attached mock above is for reference of flow.
Suggested User flow:
- New option
Edit terms
in the dropdown for multiple/bulk edit. - Select posts to edit.
- When selecting the option we can ask for taxonomy selection. It can be Categories, Tags or any other custom taxonomy.
- The reason for selecting one kind of taxonomy is to reduce the complexity for the user as well as less heavy query.
- We can achieve more functionality in this case.
- Populate the terms of the taxonomies.
- The hierarchy would be we first show the terms that are already present in those posts and then provide a search box to find the others to add or modify to.
- We can allow users to select/deselect the posts per term as well by providing an option to do so alongside the terms. ( This will also accommodate the approach where a certain term is present only for some posts. )
- We can keep the same format/signs as suggested above for distinguishing between selected posts and partially selected posts.
- Provide a search bar to select new terms. This approach may come handy when there are a large number of terms and we cannot accommodate them in the taxonomy selection screen and also become difficult to search.
- Update.
Engineering assumptions/calculations :
- By providing limited number of terms, It may become easier to loop through them and update.
- By limiting one taxonomy at a time we can reduce the complexity of the query and also maintain good user experience for user by reducing clutter.
#60
@
21 months ago
- Resolution invalid deleted
- Status changed from closed to reopened
Ticket was closed accidentally.
🙏 Thanks @rutviksavsani,
Let's see what other participants are thinking.
#61
in reply to:
↑ 59
@
21 months ago
Replying to rutviksavsani:
Thanks, thinking this is a good start.
support custom taxonomies other than Categories and Tags
Yes, ideally the Bulk Edit would support custom taxonomies too. For that purpose it seems it will need one generic UI and method for hierarchical taxonomies (categories) and another for non-hierarchical (tags). Looks like this would be a major UI change and fairly major functionality change.
- When selecting the option we can ask for taxonomy selection. It can be Categories, Tags or any other custom taxonomy.
Do you mean that the Categories, Tags, etc. selection UI will be initially hidden like in tabs? Perhaps it would be better if they are all visible. Less confusing and a lot better for accessibility.
- The reason for selecting one kind of taxonomy is to reduce the complexity for the user as well as less heavy query.
It reduces the "area" of the UI, but increases the complexity for the user, and I think makes it harder for screen reader users.
- We can allow users to select/deselect the posts per term as well by providing an option to do so alongside the terms.
Not sure if this is a good idea. This is "Bulk Edit" of all selected posts. It would be easier for the users to select only the posts they want to change/edit. That's the main design principle in Bulk Edit.
- We can keep the same format/signs as suggested above for distinguishing between selected posts and partially selected posts.
The "three state checkbox" approach seems a bit confusing imho. A bigger difficulty there is how to convey the default state. I.e. once clicked the checkbox will have to go through the three states: all, default, none. Problem is, how to "tell" the users about that as it doesn't seem to be a common convention for checkboxes.
- Provide a search bar to select new terms.
Assuming that there will be some form of auto-complete on that field. That will work for Tags (non-hierarchical taxonomies) but not sire how it would work for Categories. Also the accessibility of this autocomplete was the main reason updating of Bulk Edit was postponed.
- By providing limited number of terms, It may become easier to loop through them and update.
- By limiting one taxonomy at a time we can reduce the complexity of the query and also maintain good user experience for user by reducing clutter.
I'm assuming the suggestion here is to do AJAX requests as soon as a user selects or deselects something? This was proposed before but was rejected as it would need to also "lock" the posts and taxonomies while a user is bulk-editing them. Such locking would need to be implemented first (currently only posts can be "locked", there's no lock for adding/removing categories and tags).
Frankly I'm not sure if this is worth doing. It will also be super confusing if a user changes a category or tag and then notices they have selected a wrong post and deselects it. If saved "on change" the wrong post would be changed anyway and the "Update" button at the bottom becomes somewhat pointless.
#62
follow-up:
↓ 64
@
21 months ago
Do you mean that the Categories, Tags, etc. selection UI will be initially hidden like in tabs? Perhaps it would be better if they are all visible. Less confusing and a lot better for accessibility.
I don't think this would be an accessibility concern. A well-constructed tabpanel is a good way of simplifying a complex user interface. I don't think it's a concern for most standard post types with just a couple of taxonomies, but for sites that make heavier use of taxonomies and a post type could have 6 or 7 taxonomies, I think this would be beneficial. It would be a significant benefit for keyboard users who aren't using a screen reader; screen readers have enough additional keyboard navigation mechanisms that they can work with it pretty easily either way, but navigating all those terms just from the keyboard would be very labor intensive.
Frankly I'm not sure if this is worth doing. It will also be super confusing if a user changes a category or tag and then notices they have selected a wrong post and deselects it. If saved "on change" the wrong post would be changed anyway and the "Update" button at the bottom becomes somewhat pointless.
Agree with @azaozz. Implementing any kind of autosave on bulk actions is pretty risky; I think bulk actions should only be handled when the user is ready.
#63
follow-up:
↓ 65
@
21 months ago
I'm assuming the suggestion here is to do AJAX requests as soon as a user selects or deselects something? This was proposed before but was rejected as it would need to also "lock" the posts and taxonomies while a user is bulk-editing them. Such locking would need to be implemented first (currently only posts can be "locked", there's no lock for adding/removing categories and tags).
No, I was leaning more towards the regular approach of updating the whole batch at once via a single query (No autosave). I agree with your point on un-necessary posts getting updated.
Assuming that there will be some form of auto-complete on that field. That will work for Tags (non-hierarchical taxonomies) but not sire how it would work for Categories. Also the accessibility of this autocomplete was the main reason updating of Bulk Edit was postponed.
Here I am not completely sure of the best approach, Will it be okay if we ignore the hierarchy and list them without the hierarchy?
Not sure if this is a good idea. This is "Bulk Edit" of all selected posts. It would be easier for the users to select only the posts they want to change/edit. That's the main design principle in Bulk Edit.
The only reason to extend this functionality was because, There may be posts that may not have a particular category while bulk editing but it will still need to be listed. So considering that we can go a bit further and allow users to individually select posts as well for a category if necessary.
#64
in reply to:
↑ 62
@
21 months ago
Replying to joedolson:
for sites that make heavier use of taxonomies and a post type could have 6 or 7 taxonomies, I think this would be beneficial
Yep, was thinking exactly about these cases. There's nothing worse than "wrapping up" tabs on a second row imho. Pretty confusing. Would probably happen if some taxonomies names/labels are long. Also on small screens/phones. Seems "accordion" type folding would solve that, but why not just unfold all? :)
So maybe the tabs "buttons" should be separate, not connected to the actual tabs? Worth exploring in mock-ups imho, especially on narrow screens.
#65
in reply to:
↑ 63
@
21 months ago
Replying to rutviksavsani:
Assuming that there will be some form of auto-complete on that field. That will work for Tags (non-hierarchical taxonomies) but not sire how it would work for Categories. Also the accessibility of this autocomplete was the main reason updating of Bulk Edit was postponed.
Here I am not completely sure of the best approach, Will it be okay if we ignore the hierarchy and list them without the hierarchy?
Don't think it would be possible to ignore the hierarchy. "Child" categories can have the same names as other categories that are not "siblings" (see the screenshot below). There are three different "My Category" with different parents.
Think this is one of the big UI/usability problems that needs to be solved first: "how to represent hierarchical taxonomies when autocompleting".
Not sure if this is a good idea. This is "Bulk Edit" of all selected posts. It would be easier for the users to select only the posts they want to change/edit. That's the main design principle in Bulk Edit.
The only reason to extend this functionality was because, There may be posts that may not have a particular category while bulk editing but it will still need to be listed.
Yes, I understand. But thinking the "three states checkbox" solves this. So users can select:
- Add this tag to all posts (checked state).
- No-change, default (dash state).
- Remove this tag from all posts (unchecked state).
The usual workflow for Bulk Edit is to select the posts and edit one thing, not multiple things. That keeps it simpler.
#66
@
20 months ago
The Indeterminate state checkboxes https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox#indeterminate_state_checkboxes may be used to add a third state (delete) to terms in the bulk edit with the native support of most modern browsers.
Since it's visual-only, we still need a way to send "removed" items to the server.
This ticket was mentioned in Slack in #core by oglekler. View the logs.
20 months ago
This ticket was mentioned in Slack in #core by oglekler. View the logs.
17 months ago
#69
@
16 months ago
- Milestone changed from Awaiting Review to 6.4
Moving it to 6.4 to try to tackle it in the next release
This ticket was mentioned in Slack in #core by oglekler. View the logs.
15 months ago
#71
@
14 months ago
- Milestone changed from 6.4 to 6.5
I didn't have time to work on this patch and no one picked up this so far, so I am moving this ticket into 6.5 in hope that we will make a progress there.
This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.
12 months ago
#73
@
12 months ago
This ticket was discussed during a bug scrub.
Because this ticket can be using the same logic is under work for #11302, I am suggesting to finish the work there previously and then tackle this one.
The feature is already there. When I open a bulk edit with the Use button, there is a textarea labelled tags. I put them in there, comma separated, and expect them all to be added to all posts tagged for editing.
If this doesn't show up or work for you I suggest the support forums.