- This topic has 42 replies, 2 voices, and was last updated 6 years, 5 months ago by
.
-
Posts
-
I found and fixed a bug in the child pages ID list selection algorithm. Thanks a lot for your help in isolating this bug.
I see the same posts list currently at your test site as I do at my local test environment.I added 1 month to your subscription in return for your help.
your screenshot did not actually show the correct access. I’m looking for the user to have access only to GTO posts/pages/etc. Your screenshot showed access to all 86 posts.
You prohibited access to the posts with “Curator Access” taxonomies ID according this list: 96, 97, 98, 100, 101, 102, 103, 137. After login with test user Jane do you see any post with this ‘Div.’ taxonomy in the list of those 86 available posts. I don’t. There are 2 posts with allowed GTO taxonomy and others – uncategorized. Uncategorize at ‘Div.’ taxonomy posts are not prohibited as they don’t have a this taxonomy at all. Possible workaround – add to the list of ‘Div.’ taxonomies some dummy item to use as uncategorized, assign it to these posts and add such dummy taxonomy ID to the list of prohibited taxonomies or just assign them some existing ‘Div.’ taxonomy.
I didn’t see your response right away because it was on the second page, I apologize.
I really appreciate your help on this, too! And thanks for the added month!
Yes, test user Jane looks correct now! I see what you mean, with the non-categorized showing up. I plan to assign them to Admin Access Only, so that will be taken care of. It looks like the test site is working. Now how to update the real site? Will you push out an update or could I change the code somewhere?
Thank you! The only thing that doesn’t appear to work is Sticky. If I have a Sticky post, it disregards the Curator Access term, and automatically shows it without the Curator Access term.
Hello Vladimir,
I seem to be having the same problem again. Using User Role Editor, I created a role “ECD Curator”. At role level, I prohibited taxonomy IDs. No posts show up in the Edit screen, even author’s own posts. The nav shows All (68) Published (66) etc.
Please advise.
Vladimir, also here is the exact list of Taxonomy IDs that are Prohibited:
96, 97, 98, 101, 102, 103, 105, 137, 1640
For some reason, it seems to work okay with just:
96, 97, 98, 101, 102, 105, 137, 1640
except of course, posts in 103 taxonomy also show up.
We have pages, posts, and a CPT called tribe_events that all use these taxonomy terms. Could that be causing the issue? I’m stumped.
Hi,
Is it possible to to get a copy of your site files (without wp-content/uploads) and database to analyse this issue at my local development environment? If Yes, send download link (DropBox or similar) to suport [at-sign] role-editor.com
Hi,
I can not repeat an issue on a provided data copy. All 3 users with ecd_curator role see posts (All – 68, Publshed – 66).
I suppose that it could be some caching problem. Try to add 103 taxonomy back to the prohibited list and make another test.
I tried again, and get the same response.
Hmm, the staging site wouldn’t have caching. Is there a limit on the number of characters that can go in the Users > User Role Editor > [role] > Posts Edit > Access with category taxonomy IDs?
Strange. There is no a limit on the number of characters in ID lists.
I will make another test with your data copy. Just in case I deactivated some conflicting plugin.
I found a reason. Your assumption about string length limit was near to true. But this limit was set by your hosting WP Engine (WPE). It has an automatically executed code at ‘mu-plugins’ folder which restricts SQL query text length to 16384 characters.
wp-content/mu-plugins/wp-engine-common/plugin.php, line #2518:if ( $query_length > self::QUERY_LENGTH_MAX ) { return ''; }SQL query you get for full list of categories grows up to 16543 characters long. WPE just prevents its execution writing to the system log:
“KILLED QUERY (16543 characters long generated: SELECT …”
It’s a pity, that they do this silently, without raising exception. So you and me should waste a time searching what’s going wrong.What workaround is possible:
1) define WPE_GOVERNOR PHP constant with FALSE value, add this line to wp-config.php file:define('WPE_GOVERNOR', false);It should force WPE to ignore SQL query length.
Be aware, that it could not work if this PHP constant is defined already by WPE themselves. So just try it.2) You have 3027 posts, plus some pages and events. When you restrict role by defining categories in which you prohibit to edit posts, there are 3228 post ID in the list, which are prohibited. If define categories in which you allow to edit posts, then this list will be much shorter: 68 items only.
I include comma separated list of post ID into the SELECT SQL query. That’s why this command could become longer then a limit set by WPE.Aw, that is a bummer to waste both of our time. Thanks for seeing the issue though! I will add code to wp-config.php file and test again.
Wouldn’t the list be just as long with Allow? I would be adding a lot more IDs to the list: all the tags, all the categories, and the one taxonomy term in Curator Access taxonomy. I already tried adding the tax. term only, which hid all the categories and tags in WP post edit screen. Not cool!
- You must be logged in to reply to this topic.
