• Hi Josie,

    First, thank you for creating a great plugin. Our club has used it without issues for a number of years. I am in the process of creating a new site for our club and I have run into a bit of a snag so I am looking for a little guidance.

    I have created a user role called ProjectedChair that definitely has “edit_users” permission set. However, when logged in as the ProjectedChair, I am unable to view the EW Permissions item on the admin menu.

    However, if ProjectedChair has “manage_options” permission, the EW menu item is visible. The state of the edit_user permission does not seem to affect the visibility of the EW Permissions menu item when “manage_options” is true.

    This situation seems to contradict the Help documentation which, as you know states:

    As of version 1.2.28, either ‘edit_users’ or ‘manage_options’ WordPress capability is required to see the Permissions page. Earlier versions of entrywizard required manage_options. Both are by default restricted to admin.

    We are using PeachPress’s Capabilities plugin (v. 2.8.1) to manage role permissions. Our site is using WordPress version 6.2.2 with PHP 8.1.8 and the Twenty-TwentyThree theme. This issue is not mission critical but it would be nice if I did not have to expose the “manage_options” permissions to the ProjectedChair role.

    Thanks in advance for any suggestions and information.

    DWTurner

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author Josie Stauffer

    (@joanne123)

    Apologies, it certainly looks as if you’ve found a bug.

    I agree, for a limited-membership club, manage_options should not be needed to manage user permissions, and I thought I had dealt with that.

    Life is pretty busy right now, and properly testing any change takes time, but I’ll do what I can to get a fix out.

    Thread Starter dwturner

    (@dwturner)

    Hi Josie,

    Thank you very much for your quick reply. I do understand about being busy so please do not worry too much about the permissions issue.

    Unfortunately, I appear to have a much bigger problem using EW. Specifically, the “Submit” button on the user’s front end of the webforms (for uploading images) does not change from disabled=disabled when a file has been selected for uploading.

    I am not certain but this appears to be related to the fact that the ewzG_ object does not seem to be passed to the browser client. I have had a brief look at your code and tested to confirm that $ewzG is created at lines 79 to 87 in ewz-upload.php but the wp_localize_script() does not seem to be working.

    There may be a second issue related to the JS events that should display the “Clear” buttons but I cannot test that issue until I get the ewzG object to be loaded.

    There are a few possibilities that I have looked into but not being that familiar with the WP core or your plugin code I am struggling to determine what is happening

    One possibility is that the execution timing of the wp_enqueue_scripts hook has been delayed in the new full site editing model and as a result the wp_localize_script() may execute before the ewz-upIoad.js file gets attached. I have tried altering line 99 in entrywizard.php to attach the ewz_register function to an earlier action hook (i.e. get_header) but that did not seem to make any difference.

    As you have probably surmised, am floundering a bit. If you have any suggestions about things I might try to resolve this issue, it would be very greatly appreciated.

    DWTurner

    • This reply was modified 1 year, 5 months ago by dwturner.
    Thread Starter dwturner

    (@dwturner)

    Follow-up to disabled submit button issue:

    Hi again Josie,

    I seem to have had some success clearing up the issue with the submission button but I have not really tested the fix yet.

    In ewz_upload.php the code at line 90 (the wp_localize_script function) was replaced with:

    //    wp_localize_script( "ewz-upload", "ewzG_$webform_id",  ewz_html_esc( $ewzG ));
    
    // To replace preceding ling and move execution of the rendering of ewzG_ object to the footer hook
    
    $ewz_object = json_encode(ewz_html_esc($ewzG));
    
    $ewz_object_name = 'ewzG_'.$webform_id;
    
    add_action('wp_footer', function() use ($ewz_object_name, $ewz_object){
      printf('<script type="text/javascript">var %s = %s</script>', $ewz_object_name, $ewz_object);
    });
    

    This change seems to work but I do not yet know if there are any other parts of your plugin that might need to have the execution order altered in a similar manner. I would be interested in any comments or suggestions that you might have. Thanks in Advance.

    DWTurner

    • This reply was modified 1 year, 5 months ago by dwturner.
    Plugin Author Josie Stauffer

    (@joanne123)

    I can’t reproduce this problem, so it’s difficult to say. So far, I’ve not heard of it from anyone else.

    The first thing to try is usually to temporarily disable all other plugins, and then reenable them one by one to see if there is a conflict. Start with any you installed or updated recently.

    If it turns out to be a conflict, please let me know which plugin. If it isn’t, then I’d probably need more information about your hosting and user environment — OS, php version, browser, …. Did anything change recently?

    Thread Starter dwturner

    (@dwturner)

    Hi Josie,

    I understand. I will continue to test the and let you know what I find. Just so you know, this problem occurred on a fresh install of WP 6.2.2 running on a shared Apache server 2.4.57 with PHP 8.1.8 and MySQL 5.47.1 I was able to replicate the issue on a clean local install of WAMPServer running the same versions of the stack with only EntryWizard and EWZ-Rating as active plugins. There were some other plugins installed but not active.

    Plugin Author Josie Stauffer

    (@joanne123)

    Which theme?

    Thread Starter dwturner

    (@dwturner)

    Oops, sorry about that. I created a child theme of TwentyTwentyThree. The only alterations to the child have been cosmetic and made using the Full Site Editing feature of WP 6.2.2. There is no added or altered code in the theme.

    Plugin Author Josie Stauffer

    (@joanne123)

    I tried TwentyTwentyThree, and with that was able to (I think) reproduce the problem. What seemed to happen was that the javascript function that displays the image to be uploaded was not found.

    I’ve no time to do more at the moment, but I’d suggest changing your theme, possibly to an older one, might help.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Permissions Issue’ is closed to new replies.