On 9/8/07, Ryan Boren <[EMAIL PROTECTED]> wrote: > > Tags and categories of the same name *are* supposed to be able to live > > together in harmony, correct? Intuitively, it seems like "Plugin > > Concepts" + "plugins", which has an ID of 7, was created when the data > > was imported, then "Plugin Concepts" + "plugin-concepts," which has an > > ID of 10, was created when the post was updated? But why did it create a > > new term with a new slug? > > When creating a new tag we key off of the slug rather than the name > when checking to see if the tag already exists. Looks like we need to > check name and then slug to catch these cases.
This brings up some bigger issues, however. We currently key off of slug so that we don't create new tags for every variation on a name. "Plugins" and "plugins", for example. Of course this can do the wrong thing for tags where the case is meaningful: "GNU" and "Gnu". Also, for the case where "Plugin Concepts" exists with a slug of "plugins" and a "Plugins" tag is requested, "Plugins" will return the term id of "Plugin Concepts" since they both have the same slug. Perhaps we should give up worrying about case differences and do this: When creating a tag, first check to see if the name matches an existing term. If so, use that term. If it doesn't match name then see if there is a slug match. If so, then we have terms with different names but the same slugs. In that event, make the slug on the new tag unique by appending a number. For our "Plugins" example, "Plugins" would have a slug of "plugins-2" so that it doesn't collide with the slug for "Plugin Concepts". All of this would require a key on the name in the terms table. _______________________________________________ wp-testers mailing list [email protected] http://lists.automattic.com/mailman/listinfo/wp-testers
