Premium WordPress Themes and Support

Home Forums General WordPress disable Plugins for User

This topic contains 7 replies, has 3 voices, and was last updated by  Nick 2 years, 8 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #3303

    Luc Malmendier
    Participant
    WP Private
    Post count: 37

    Hi @all,

    Nick posted in another Threat the “Plugin Logic” Plugin, which make it possible to disable Plugins on different sites…

    Is there another Plugin which makes it possible to disable Plugins for different users or usergroups in backend and frontend?

    Nick you know the best ways. Any Idea for that?

    Thanks for any ideas

    Best Regards

    #3304

    Nick
    Keymaster
    WP Colonel
    Post count: 721

    I can’t find any plugins that does what you are looking for. Therefore, we need to think and come up with a custom solution. The only thing that I could think of within 5 minutes is the following, hopefully I can think of a better one later on, or someone else will have a better idea.

    Before starting though, I want to correct your first sentence above – you typed “… which make it possible to disable Plugins on different sitesโ€ฆ”. That is an incorrect statement, the correct statement is “…which make it possible to disable Plugins PER PAGE/POSTโ€ฆ There is a big difference between the 2 sentences…

    OK, back to our problem, how to disable plugins per usergroups, ie: Admins, Editors, Subscribers, Custom Roles, etc…

    We are going to use:

    1. Some custom code to redirect users to to a page depending on user role.
    2. Use the WP-Tux’s menu per page feature.
    3. Use Plugin Logic to enable/disable the plugins per page.

    1. Use this technique to create the redirects for each role group – http://wpsnipp.com/index.php/functions-php/redirect-based-on-user-roles-or-capabilities/

    2. Once you land on a particular landing page, directed in step 1. depending your role, you can “trap” your users, with custom menus, so each user group will only bounce through a menu system designed just for them – look attached picture.

    3. Use the Plugin Logic plugin to configure which plugins will be loaded/disabled per page.

    Depending how many pages and user roles you have, you might see the size of your website pages/posts increase dramatically. The above method will work, but ideally you would want a way to dynamically enable/disable plugins per user/user role. You will need to hire a programmer for that I’m afraid.

    That said, the real question I have is: Why are you trying to load plugins per user group? I can’t see a real need for this. Why can’t you just stick to the standard use of the Plugin Logic? What am I missing?

    Attachments:
    You must be logged in to view attached files.
    #3306

    Luc Malmendier
    Participant
    WP Private
    Post count: 37

    Hmm Nick. I think you dont understand my Statement ๐Ÿ˜‰

    I have as sample the WR Pagebuilder, which is seen when i create a post/page. But i want to disable it for users which have a lower role than admin. The reason is: my costumers can write own Blogs, but they dont need WR Pagebuilder. But they dont deactivate it. But when i dont deactive it WR pagebuilder adds by standart a code for row and colum.

    On the Page then Pagebuilder loads lots of css and JavaScript on everypage. I only use Pagebuilder on my indexsite…

    For better Performance and understanding for my customers i want to turn off WR pagebuilder for my customers. When they write their Blogs, they dont Need to use ist…

    #3307

    Nick
    Keymaster
    WP Colonel
    Post count: 721

    Yeah I did, and my above solution is exactly for that. It could be my English, but I think you did not understand my above solution… Nevertheless, now that I know your real purpose for this, there is even an easier solution, although with a different approach.

    Simply disable the WR Page Builder for the posts, and for any another custom post type for that matter. Just have it on for pages. This is a different approach. Instead of disabling the plugin by user role, we are disabling it by post type (btw, a page is a post type).

    You now have 2 possible options, pick one.

    Look attachment.

    Attachments:
    You must be logged in to view attached files.
    #3309

    Nick
    Keymaster
    WP Colonel
    Post count: 721

    I forgot to mention, that besides disabling the WR for posts, and other custom post types, if I were you, I would still use the Plugin Logic, to enable the WR Page Builder only for the pages that you need, which in your case, it would be the front page I guess…

    So this would be the result.

    1. By using the WR Page Builder’s options screen, I would only use the builder for pages only.
    2. By using the Plugin Logic, I would load the plugin only for the page that the builder is been used.

    I hope it’s clear now.

    #3326

    Luc Malmendier
    Participant
    WP Private
    Post count: 37

    Hi Nick thats a Solution that i found out. But it only works for Pagebuilder. But there are some Plugins which i cannot turn off. Some Plugins have the posibility to turn it off for user Groups, but some not ๐Ÿ™

    But many many Thanks for your Help Nick…When i have any Problem i say to my coworkers “wait, i ask Nick” ๐Ÿ˜‰

    Its nice that you are very active here and help the users! Great work Nick ๐Ÿ˜‰

    #3332

    Fred
    Participant
    WP Private
    Post count: 21

    There is a great little plugin that will let you restrict access to plugins here. I have used it and it works perfectly. The end user doesn’t even know that extra plugins are even installed, because they never see them in the plugin directory under their user.

    https://wordpress.org/plugins/advanced-access-manager/

    You have the get the extra extension for the plugin management, but very worth the minimal cost for it.

    #3333

    Nick
    Keymaster
    WP Colonel
    Post count: 721

    @Luc: Thanks for your kind words. That said, and after I posted the latest solution, I realized that you were correct. I did misunderstand what you were looking for, but only because I assumed a few things, and as a result disregarded the backsite requirement. Once you explained the “why”, I knew the correct solution for you then.

    @Fred: Thanks for the recommendation, I will test it later on today…

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.