CBOX Classic SupportPublic Group active 1 year, 1 month ago
Wiki Tags Issue
- This topic has 5 replies, 2 voices, and was last updated 9 years, 2 months ago by Scott Voth.
January 6, 2014 at 2:15 pm #4156
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?January 6, 2014 at 7:50 pm #4161
Hi Eric – thanks for reporting. I have entered a ticket for this on github. You can track its progress here, and see what the dev team thinks:
Just curious – Are you running the latest version of CBOX and using the CBOX theme? And did the wiki tag cloud work before, and is now problematic? This might help in debugging the issue. From reading your post – it seems that some tag clicks work, while others don’t?
Thanks a lot. And if you can provide a link to your site – that also would help greatly.January 7, 2014 at 8:37 am #4170
Hi Scott, thanks for your help. As of right now we are on CBOX 184.108.40.206 and we are using the CBOX theme. Because the site is an intranet site, it requires authentication so a link won’t provide access . I can create an account for you and pm you a link with credentials. It doesn’t look like I can pm you on this forum though – can you provide me with a place to send the info or tell me how to pm you through the forum?
You are correct – some of the Wiki tags work, others don’t. The cloud has always worked to some degree as far as I know, but once users started adding in content and the tags grew in quantity, this issue became apparent.
-EricJanuary 7, 2014 at 9:54 pm #4176
Hi Eric – the dev team would like a temporary account/credentials to debug the issues, if that is possible. You can send to my email if this is ok (firstname.lastname@example.org) and I will pass it along.March 20, 2014 at 1:29 pm #4502
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:March 20, 2014 at 6:36 pm #4507
@Eric W – thanks for all your research! I have attached your findings to the GitHub issue for Boone to take a look at.
- You must be logged in to reply to this topic.