Forum Replies Created
April 10, 2015 at 10:28 am #5582
Hi Scott, the pagination fix you linked above was added but this didn’t resolve the access permissions issues. I as a site admin can edit the permissions on any document so I have to be sure to test as a different account that isn’t a wp admin. If the account is a normal user and an admin of a BP docs group, they still cannot edit the permissions of a document they didn’t create, even though the permissions imply they should be able to. Since you aren’t seeing this issue Scott, I might go through and start disabling other plugins to see if I can find any conflicts that could be causing it for me. We aren’t running a lot of other things though, but it’s worth one last check before this gets reported as an issue on github.
Jonathan, thanks for responding, I really appreciate it. I’m going to check out your fork and commits. I’m certainly willing to try it out in our dev environment, and if it gives a better experience then it’ll certainly be on the table for production.April 3, 2015 at 10:08 am #5575
Thanks Scott – good to hear from you as well. We do have a full dev environment so I will pull the most recent changes there and see if that has an impact on these two issues. I’ll post back what I find next week sometime.May 7, 2014 at 10:15 am #4721
@scottvoth We do have the latest theme and plugins and still were missing those buttons. I ended up needing to use the TinyMCE advanced plugin and had to check a specific checkbox which says “Link (replaces the Insert/Edit Link Dialog)”. The buttons work now but seem to have a few more options than the standard link buttons. I’m really curious as to why we are missing them natively, so I might try and get the distribution directly from GIT in case any of our files are somehow not actually updated.
-EricMay 6, 2014 at 7:56 am #4704
@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.
May 5, 2014 at 10:00 am #4697
- This reply was modified 9 years, 9 months ago by Eric W.
We have been running 3.9/CBOX in production since 4/22 without any issues.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.January 7, 2014 at 8:37 am #4170
Hi Scott, thanks for your help. As of right now we are on CBOX 18.104.22.168 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.