Subscribe: WordPress Trac: Ticket #5684: Tags should be able to edit names/slugs
Added By: Feedage Forager Feedage Grade C rated
Language: English
attachment set  attachment  bulk delete  categories  delete  form  manage screen  manage  patch  posts  screen  search  set  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: WordPress Trac: Ticket #5684: Tags should be able to edit names/slugs

WordPress Trac: Ticket #5684: Tags should be able to edit names/slugs

As of 2.5-bleeding [6627], there is no way in the default, core WordPress admin screens to edit tag names or slugs. It might also be helpful to delete tags. So, a "Manage Tags" screen, similar to "Manage Categories", would be a useful addition to the cor


keywords changed

Fri, 18 Jan 2008 13:47:11 GMT

  • keywords needs-patch 2nd-opinion added

+1, although it sounds like a lot of work will have to go into this.

Sat, 19 Jan 2008 20:25:51 GMT

I believe an elegant way to integrate this would be by creating a "tags" option under the management panel, preferably next to categories. So far the Advanced Tag Entry plugin ( seems to do a fairly good job of wrangling up existing tags, except it feels a bit clunky and misplaced sitting within the posts editor if you just want to edit your tags.

Here's a quick outline of how it might fit in better:

write/manage -> edit/create new post

A1) (rough) When creating or editing post entries, the most a user should see is a small collection of the tags they use most often. Just as links to populate the form field, along with a field of tags currently in use for the post.

A2) (a little more elegant) Using auto-completion to save from displaying dozens or hundreds of tags used most often. This could then be moved to the editor sidebar area allowing a user to add more tags like he or she would with categories. Either one at a time or multiple and upon submitting would populate the list below. To remove, simply untick the check box. Upon saving with a refresh unticked tags remain, ticked boxes remove but the tags are still stored.

manage -> tags

This is pretty straight forward to just display it like the categories list. Displaying the tag name, slug, a link with number of posts it's attached to and an optional description. Sort this alphabetically with two divisions, tags in use, and orphans which have been removed or unused. For users with several dozen or hundreds of tags, an option to sort by header would be a comfort.

Tue, 22 Jan 2008 15:43:42 GMT

I am working up the Manage Tags screen; will submit a patch in the next couple of days, time permitting. It is mostly working, but has a few more details to work out.

attachment set

Tue, 22 Jan 2008 18:50:47 GMT

  • attachment set to tags-patch.diff

Patch to add Manage Tags to the admin menu system

keywords, summary changed

Tue, 22 Jan 2008 18:59:39 GMT

  • keywords has-patch added; needs-patch 2nd-opinion removed
  • summary changed from There is no way to edit tag names/slugs in WordPress to Tags should be able to edit names/slugs

Tue, 22 Jan 2008 19:00:31 GMT

OK, I've added a patch.

This adds a Manage / Tags screen to the admin, next to Manage / Categories.

It pretty much works like Manage / Categories, except that because users can have tons of tags, it uses a paging system (currently set to 10 tags displayed at a time) to display the tags on the manage screen. Maybe it should be set to 20 tags at a time? I wasn't sure. That variable is inside the new wp-admin/tags.php file, just before where it generates the list of tags.

Only one thing I didn't yet get working: if you click on the link that shows how many posts there are for a given tag, it should take you to the Manage / Posts screen, with only those posts displayed (just like it does for categories). But this doesn't work. The reason is that post querying is not currently set up for tag IDs as it is for category IDs. There is some provision for tag_id as a query variable, but it isn't completed enough to work.

Maybe someone else can make that part working? It looks like it would require some changes to the WP->parse_request function in wp-includes/classes.php (to make tag_id be an acceptable query variable), and then to WP_Query->get_posts (in wp-includes/query.php) to take that variable and do the right thing with it.

Wed, 23 Jan 2008 01:22:36 GMT

Maybe it's worthy as a new bug; But a global to specify how many tags/categories/post items a user wished to display on the admin pages could prove useful. But for now, showing 20 or 25 at a time seems reasonable versus managing 10 (out of 100) at a time might seem annoying to manage.

Wed, 23 Jan 2008 13:51:26 GMT

I thought of a better alternative to the tag_id issue: just use the slugs in the URL. So I'm about to attach a second patch that is fully working.

Regarding the number of tags to display, the post screen is hard-wired at 15 per page, and changing it looks like a pain. Categories are not paged -- the Manage screen always lists all your categories, which is probably OK for most users.

So, in this patch (which I'll submit shortly), I decided to hard-wire the tags at 20 per page, but it's done with a global variable called $tagsperpage. If that variable is set (by a plugin or whatever) before the tag list is printed out, then that many tags are shown instead. (I tested that and it works fine.)

attachment set

Wed, 23 Jan 2008 13:53:04 GMT

  • attachment set to tags-patch-better.diff

Better patch: links in the tags list to the number of posts now work

Fri, 25 Jan 2008 19:29:02 GMT

(In [6660]) First cut at Manage->Tags. Props jhodgdon. see #5684

Fri, 25 Jan 2008 19:29:56 GMT

I reorganized some things. Hopefully I didn't butcher anything.

Todo: Add search, use paginate_links().

Fri, 25 Jan 2008 20:26:14 GMT

Works for me! I just tested it in [6662] bleeding edge trunk. I agree, a search function would be useful, especially for those who have zillions of tags.

Thanks for putting this in! Now I will be able to hopefully get rid of my Advanced Tag Entry plugin, or at worst case, just keep the tag entry part of it and drop the tag management sections.


attachment set

Fri, 25 Jan 2008 20:52:43 GMT

  • attachment set to tagsearch.diff

Patch that adds search to the tag screen

Fri, 25 Jan 2008 20:54:52 GMT

The patch I just added can be applied to [6662] to add a quick search/filter function to the tag screen.

I did it with "Tag contains..." rather than "Tag starts with", because otherwise it doesn't work well for multilingual users.


Mon, 28 Jan 2008 17:21:14 GMT

(In [6670]) Tag searching from jhodgdon. see #5684

Mon, 28 Jan 2008 17:22:29 GMT

Changed search box a bit in prep for the new design coming to the manage pages. It's gonna look ugly until then.

Mon, 28 Jan 2008 23:04:47 GMT

I don't think your patch will find tags containing the search terms, only tags that start with the search terms. Correct? If so, can you put that back in? I don't have time to test this today and verify, but a quick look at your patch makes me think you left that part out.

Mon, 28 Jan 2008 23:25:47 GMT

(In [6677]) Fix tag search. Props jhodgdon. see #5684

Tue, 29 Jan 2008 10:02:55 GMT

If strings, included in LIKE patterns include % or _ more results than we want will be returned. For example if we search for % we will get all rows, instead of just those containing %.

Here is a patch, which adds like_escape function and passes $searchterms through it. There are lots of other places in the code, where the same problem exists. If you like the idea of like_escape I will find and patch them.

attachment set

Tue, 29 Jan 2008 10:03:09 GMT

  • attachment set to like-escaping-for-tags-search.diff

Tue, 29 Jan 2008 14:36:18 GMT

+1 on nbachiyisi's idea. I especially like having a separate function that can be used elsewhere (or possibly called from a plugin).

Tue, 29 Jan 2008 17:20:27 GMT

(In [6680]) like_escape() from nbachiyski. see #5684

Tue, 05 Feb 2008 03:09:43 GMT

(In [6721]) Use siteurl, not home, for constructing paging links. see #5684

Tue, 05 Feb 2008 03:18:46 GMT

(In [6723]) Use wpurl, not home, for constructing paging links. see #5684

Tue, 05 Feb 2008 07:45:41 GMT

(In [6727]) Add beginnings of bulk tag delete. see #5684

Tue, 05 Feb 2008 16:43:51 GMT

Anyone want to finish up bulk tag delete?

Fri, 08 Feb 2008 16:04:32 GMT

I'll take a shot at it...

attachment set

Fri, 08 Feb 2008 16:26:22 GMT

  • attachment set to tagbulk.diff

Add bulk delete to tag management page

Fri, 08 Feb 2008 16:29:26 GMT

I just added a patch to do the bulk delete. It could be slow if a lot of tags were deleted at once, I guess (uses a for loop and calls delete_term repeatedly), but I think that's fairly unlikely (since the screen only displays 20 I think?). If you think it's an issue, I could create a delete_terms or delete_tags function that would delete a bunch at once, but I thought it would be OK (and a bit safer, since all the actions get run for each delete).

Fri, 08 Feb 2008 19:38:53 GMT

(In [6759]) Bulk tag delete from jhodgdon. see #5684

Fri, 08 Feb 2008 21:37:59 GMT

Also todo, making the paging and styling look like what was recently introduced on the Manage->Posts page. That styling is still not quite done, but it's getting closer.

Thu, 14 Feb 2008 23:54:39 GMT

Something happened when someone reorganized the styling: when you try "Search Tags", you get a message saying "Tags Deleted", and no searching (or deleting) is done.

Fri, 15 Feb 2008 00:02:58 GMT

(In [6855]) Fix manage tags wrong message display. see #5684

Fri, 15 Feb 2008 00:06:10 GMT

I don't think that will do it.

It looks to me as though it was in [6848] - someone removed the ending form tag for the search form, as well as the starting form tag for the bulk delete form. (see line 144 and 148-9 in the left column on that changeset page)

I think a previous change had inserted some other code above that first ending form tag, so it wasn't with the search form and it didn't look like part of the search form.

Fri, 15 Feb 2008 00:21:20 GMT

My mistake: just did SVN update and it is working, as of [6855]

Is it time to close this bug now? I'm very happy with the result. :)

status changed; resolution set

Fri, 15 Feb 2008 02:26:30 GMT

  • status changed from new to closed
  • resolution set to fixed

If you're happy, I'm happy. :-)