Group Admins
Wiki Tags Issue
- This topic has 5 replies, 2 voices, and was last updated 10 years, 7 months ago by
.
-
Hello and thanks in advance for any assistance you can provide. We are using CBOX for our site wiki and it has been very well received, however one of our users noted an issue with tags in the wiki docs and I am hoping to get insight into a solution.
We are using the wiki on our site and tagging the content. In the word cloud on the left of the wiki home page, we can click on tags and documents with those tags should display, but that isn’t what’s happening for all of the tags.
Here’s an example: we have several documents tagged with the keyword “assessment”. The tag “assessment” displays prominently in the word cloud on our wiki home page. However, when a user clicks on this tag, they are directed to a search for “assessment-4” which returns 0 results (the link the tag points to is http://oursiteurl/wiki/browse/?bpd_tag=assessment-4 ). Interestingly, I removed the -4 from the URL and we still get no results. In fact, even though each document has been manually tagged with the word “assessment”, the results only show up under the tag “assessment-3”, which does not display in the word cloud.
One more thing which may be related: A difference between our wiki and the demo site. When I click on a wiki tag, the results page I get includes the remove filter line (“You are viewing wiki pages with the following tags: assessment-4 – Remove Filter”), which is like the demo site, but it also includes the Filter by: Attachments Search Tag. Is this a template issue?
Any ideas?
A colleague and I have done some deeper exploration into the Wiki tag issue I reported above and many queries on the tables (wp_terms and wp_term_taxonomy). We created test wiki posts, test blog posts, etc, and doing all of this revealed a pattern. . If a “tag” or “term” already exists in a specific taxonomy, (for example, a “category” or a post_tag”), a new entry is not created in the wp_terms table for that term, but instead a new entry is created in the wp_term_taxonomy table that points to that term_id from the wp_term table. That’s fine and as it should work. The issue that we found is that when a tag previously exists with a different letter case (Assessment vs assessment) in a DIFFERENT taxonomy than where it is being created, multiple entries for the same term end up being added to the wp_terms table, and the slug for that term is “incremented” each time.
Here’s an example: The term Assessment already exists as a tag given to blog posts in WordPress. These have the taxonomy of post_tag. But if someone creates a wiki page and tags it “assessment” (notice the lower case “a”), we have a problem. Instead of realizing that those are the same terms with different case, WordPress is creating a new entry in the terms table, and assigning a new slug by incrementing the previous one, (assessment-2, assessment-3), etc. It’s important to note that this only occurs when the term already exists with a different case in a DIFFERENT taxonomy. If I tag a blog post as “assessment” and later tag another blog post as “Assessment” (both have the post_tag taxonomy), the 2nd tag is corrected to the original tag “assessment” even though the user entered “Assessment”. That makes sense, and that’s how it should be handled, so why not handle it the same way even when the term has a different taxonomy?
To fix the syptoms, we can manually remove the duplicate terms with different slugs, adjust their entries in the taxonomy table to point to the correct term_id, and all will be well. However, that will only fix the tags that are currently in use. The issue can still occur in the future and can occur without CBOX. If a staff member creates a new tag on a new document (a group doc, a wiki, a blog post, a category) and that tag already exists with a different letter case on an alternate document type, this issue will continue to occur – a new term and a slug with a hypen-number will be created. It will be fine if the same case is used as the already existing term. I’ll attach a screenshot that is a join of the wp_terms and the wp_term_taxonomy so you can see what this looks like in the WP database.
One other important thing to note – this occurs both ways. If I create a new term for the first time in the Wiki or Group Docs, then later create a post_tag on the blog and use different case, the same thing happens This is not a Commons in a Box issue, but is a WordPress issue. Maybe CBOX can do something to compensate for this, but that’s where we’re at.
Lastly, just to be clear, our WP database and each of these columns are ci – case-insensitive. This is not happening due to the collation of our DB.Link to screenshot of join here:
- You must be logged in to reply to this topic.
