Forum Replies Created
-
@scottvoth Interesting Scott. I checked to make sure it wasn’t specific to just my sites by testing the demo site at demo.commonsinabox.org. Is also has the missing link buttons on the wiki editor and group docs as well. I took the original screenshot from the demo site because the toolbar looks exactly as it does on my site.
I’m on WP 3.9 and have the latest version of CBOX installed.
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:
