Opened 17 years ago
Closed 17 years ago
#5684 closed defect (bug) (fixed)
Tags should be able to edit names/slugs
Reported by: | jhodgdon | Owned by: | |
---|---|---|---|
Milestone: | 2.5 | Priority: | normal |
Severity: | normal | Version: | 2.5 |
Component: | Administration | Keywords: | tags has-patch |
Focuses: | Cc: |
Description
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 core.
As Ryan noted in a short email discussion about this, if someone creates this, it would need to take into consideration that some users have thousands of tags, and be able to handle this situation gracefully.
I might try to work up a patch, if no one else does before-hand.
Parts of this are handled by my (GPL) Advanced Tag Entry plugin on the post edit screen (http://poplarware.com/tagplugin.html), and Christine's Tag Managing Thing (http://www.neato.co.nz/wordpress-things/tag-managing-thing/) does much/all of this as well. I would personally rather see it in core than a plugin, though, and I think Christine has expressed the same opinion on the hackers list; could contact her to see about using her code.
Attachments (5)
Change History (36)
#2
@
17 years ago
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.
#3
@
17 years ago
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.
#4
@
17 years ago
- 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
#5
@
17 years ago
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.
#6
@
17 years ago
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.
#7
@
17 years ago
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.)
#9
@
17 years ago
I reorganized some things. Hopefully I didn't butcher anything.
Todo: Add search, use paginate_links().
#10
@
17 years ago
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
#11
@
17 years ago
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
#13
@
17 years ago
Changed search box a bit in prep for the new design coming to the manage pages. It's gonna look ugly until then.
#14
@
17 years ago
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.
#16
@
17 years ago
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.
#17
@
17 years ago
+1 on nbachiyisi's idea. I especially like having a separate function that can be used elsewhere (or possibly called from a plugin).
#24
@
17 years ago
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).
#26
@
17 years ago
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.
#27
@
17 years ago
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.
#29
@
17 years ago
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.
+1, although it sounds like a lot of work will have to go into this.