I have several custom post types and custom roles. Users of a particular role should be able to select posts from a drop down but this behaviour has stopped working.
I will need to provide login details and explain more as it is all for logged in users only..
The logged in screenshot looks like the attached picture - the bit that is not loading is the dropdown where it says 'select the doula profile parent' This works for admins but not for the custom role (it did work for them previously). There is a console message as per the other attached image.
Hi, I am activating private reply fields here so you can share login credentials. It would be great if you can provide both an admin login and a custom role user login.
Okay I don't see anything obviously wrong here. The Access settings seem okay, and the Form seems to be set up correctly with the proper shortcodes. I tried turning off the "select2.js" style fields temporarily to see if the problem was resolved. You can turn off the fancy select2.js field by adding use_select2="never" in the field shortcode:
[cred_field field="_wpcf_belongs_doula-profile_id" value="" use_select2="never"]
...
[cred_field field="_wpcf_belongs_doula-mentor_id" value="" use_select2="never"]
Unfortunately the page stopped working whenever I turned off select2.js for the doula-profile parent field. If I turned off select2 for only the doula-mentor parent field, that field began working correctly and I could see the mentor options (about 100) as expected. As soon as I turn it off for the doula-profile field, the page stopped working by truncating the output right after the "Add recognition" page header. My guess is it's memory-related...perhaps too many options (about 800), but that's really irrelevant at this point. The system should work with the select2.js feature enabled for this input.
I'd like to see if this problem is replicable in my own environment. I can see your site is using the legacy post relationships system. I don't have a good legacy relationships test environment set up currently, so it will probably faster if I can clone your site and run tests locally using that clone. This will allow me to monitor code execution and watch the database. If that's okay with you, I will install the Duplicator plugin here and create the site clone. Please let me know if you approve, and I can get started.
Yes, that’s fine. Please go ahead and duplicate the site so you can debug things.
Thanks, I have made a clone and I will begin running some tests. I'll give you an update shortly.
Well, I have good news and bad news. The good news - I was able to figure out a way to solve the problem. The bad news - the solution is to deactivate your custom theme and activate the parent Genesis theme. I've done that now in dev, and you can see the select2.js fancy select fields are working for the DM user. That's unfortunate, because at this point I am a bit stuck in terms of what I can offer. Toolset seems to be working correctly until the custom theme is activated, so that means there is a conflict somewhere in the custom code. If there's some code in the theme that touches any Toolset APIs, I can definitely help investigate a problem in those API hooks. However, I'm not able to troubleshoot your theme in general. If I were you I would look for anything that filters this post type, as well as anything that hooks into admin-ajax.php, since the options are driven by an AJAX response. I would also try turning off select2.js in the shortcode attributes again and investigate the error I mentioned earlier that caused the site to crash. Let me know if there's something specific and Toolset-related that I can help with.
Many thanks.
There is some stuff in functions.php that may be the issue.
I'll look into this some more and let you know if I need any more help.
Many thanks
Lines 642 - 651 contain this code to block access to wp-admin -
/**
* Block wp-admin access for non-admins
*/
function ace_block_wp_admin() {
if (!current_user_can('edit_users') ) {
wp_safe_redirect( '/my-account');
exit;
}
}
add_action( 'admin_init', 'ace_block_wp_admin' );
When I comment out that code, it works as expected. As this used to work, this must surely be the result of updates to Toolset.
Any suggestions you have would be very welcome.
Many thanks
Chris
That redirect code should not be triggered for AJAX events, so if we add some AJAX conditions it should work as expected again:
/**
* Block wp-admin access for non-admins (not while doing AJAX, see https://toolset.com/forums/topic/custom-role-no-longer-able-to-perform-same-tasks/)
*/
function ace_block_wp_admin() {
if (!current_user_can('edit_users') && ( !defined('DOING_AJAX') || !DOING_AJAX ) ) {
wp_safe_redirect( '/my-account');
exit;
}
}
add_action( 'admin_init', 'ace_block_wp_admin' );
I tested locally and it seems to do the trick. Please try this update and let me know if the problem is not resolved.
My issue is resolved now. Thank you!
