PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Modifying Site Admin capabilities with plugin

  1. UWEX
    Member

    We've been using the following custom plugin to restrict access to advanced features on our MultiSite network, and it worked great with 1.6.2, but no longer works properly with the latest public release I was trying to upgrade to.

    http://pastebin.com/wmVvp7VY

    The bits that strip out Post and Pricing fields continue to work, but it no longer prevents Site Admins from accessing the Settings page or form creation/editing pages.

    Any idea what changed from 1.6.2 to 1.6.4.4.2 that would let the Site Admins access those features now when they couldn't before? Thanks!

    (and no, we can't really use the recommended user capabilitiy plugins for our architecture)

    Posted 12 years ago on Friday June 1, 2012 | Permalink
  2. UWEX
    Member

    Hate to bump this, but I've spent a ton of time looking into it myself and am getting nowhere. Is there any extra information I can provide? I confirmed that this code does what I want when used in conjunction with 1.6.2, but does what I describe with 1.6.4.4.2

    Any ideas or other info I can give or try to help? Thanks

    Posted 12 years ago on Tuesday June 5, 2012 | Permalink
  3. UWEX
    Member

    I did yet some more digging, and discovered what I _think_ is the difference, and I hope you can confirm and offer some help. It looks that in 1.6.4.4.2, being a Site Administrator just automatically gives you access to all this stuff. That is, if I also set the following in my code:

    $allcaps['administrator'] = false;

    then my desired functionality is restored. However, that's certainly not something I want to do and I'm afraid of repercussions with other features.

    Posted 12 years ago on Tuesday June 5, 2012 | Permalink
  4. David Peralty

    I've pointed this thread to one of our developers.

    Posted 12 years ago on Tuesday June 5, 2012 | Permalink
  5. Yes, there was a change made that would give site administrators full access by default, so that is the root cause of your problem.

    I haven't tested this, but I believe if you make sure your user_has_cap hook runs after Gravity Forms' your problem will be solved.
    To do that, change line 69:

    add_filter('user_has_cap', 'ces_gravity_forms_modifier_capabilities', 1, 3);

    To the following:

    add_filter('user_has_cap', 'ces_gravity_forms_modifier_capabilities', 11, 3);

    If that doesn't do the trick, let me know and I will dig deeper.

    Posted 12 years ago on Wednesday June 6, 2012 | Permalink
  6. UWEX
    Member

    Nope - I'd tried mucking with the priority earlier. It doesn't seem to matter when it's called, if being a Site Administrator just overrules any of the specific gravifyforms_ capabilities anyway.

    Thanks for looking into this - I really appreciate it.

    Posted 12 years ago on Wednesday June 6, 2012 | Permalink
  7. Ok. I will be glad to take a closer look if you can send me an FTP login as well as WP network admin login to alex@rocketgenius.com

    Posted 12 years ago on Wednesday June 6, 2012 | Permalink
  8. Hello Jason.
    I believe I got it to work ( http://pastie.org/4046400 ). The trick was to remove the Gravity Forms user_has_cap filter, making sure your priority is under 10 (so that it executes before Gravity Forms).
    Let me know if you have any issues with it.

    Posted 12 years ago on Thursday June 7, 2012 | Permalink
  9. UWEX
    Member

    Alex - that seems to do the trick! Thanks so much!

    Posted 12 years ago on Friday June 8, 2012 | Permalink