Tags should be able to edit names/slugs

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

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 (http://poplarware.com/tagplugin.html) 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.

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.

Patch to add Manage Tags to the admin menu system

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.

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.

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

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

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

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

Todo: Add search, use paginate_links().

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.

--Jennifer

Patch that adds search to the tag screen

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.

--Jennifer

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

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

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.

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

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.

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

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

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

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

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

Anyone want to finish up bulk tag delete?

I'll take a shot at it...

Add bulk delete to tag management page

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

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

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.

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.

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

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.

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

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