Change History (25)

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.

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.

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.

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

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

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

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?

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

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