In the admin, I'm not sure it's worthwhile to have different behavior whether you're merging more than one tag, or renaming a tag, especially since you may be renaming the tag to the same thing as a tag that already exists. This requires changes to the object_terms table, as you noted, but isn't done frequently enough to worry about from a performance point of view.
Term, from which Tag derives, also has an update method, so if you wanted to in a plugin you could rename a Term using it. For example, code similar to this will change a tag's display text: $tag = Tag::get( 'Asides'); // get a tag by the display name $tag->term_display = 'Sidebar'; $tag->update(); // writes the new display name to the db. Note that the slug won't change in this case, and the id will stay the same. To change the slug: $tag->term = 'sidebar'; $tag->update(); // if the slug 'sidebar' already exists, since they have to be unique, 'sidebar' could be changed into 'sidebar-1', 'sidebar-2', or whatever it takes to get a unique slug As you can see from the above, you aren't assured that what you set as the slug will be what you get, just as is the case with post slugs. This could probably be wrapped in a rename() method, but it hasn't been found necessary yet. Rick On Jan 22, 9:24 pm, Dave Perry <[email protected]> wrote: > I'm playing around with taxonomy and was surprised to find that the > 'renaming' of a term is handled by the 'merge' method; essentially > changing not only the name of the term but also it's id and therefore > requiring changes to the object_terms table also. Is there a reason > that a 'rename' method was not implemented? Are there undesirable > consequences that prevent simply updating the 'term' and > 'term_display' fields? > > Thanks -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev
