• Resolved mrjarbenne

    (@mrjarbenne)


    I just upgraded to version 3.3 of Jetpack on a Multisite install, on which I have allowed subdomain administrators to enable JetPack using their own WP credentials. I’m worried about the wording of the new Plugin Management option, which seems to infer that plugin management can now be accessed by any admin on the network, rather than just the super-admin: “Enabling allows all existing, connected Administrators to modify your site from WordPress.com.

    I run an additional plugin to help tailor the plugins that subdomain users can access, giving them some plugins that are end-user activated, without giving them access to all the available plugins on the network (https://wordpress.org/plugins/multisite-plugin-manager/). This functionality seems to circumvent that, allowing users the ability to enable and disable plugins I may have active, and don’t want deactivated, or plugins I’m using in specific instances, but don’t want other sites to be able to access.

    Is there a way to disable this module multisite wide, so that my users can continue to manage the curated list of plugins I make available, without breaking their sites activating things that shouldn’t be active on their site?

    https://wordpress.org/plugins/jetpack/

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter mrjarbenne

    (@mrjarbenne)

    In the meantime, until the “Learn More” link is populated with info and I can get a better sense of what this allows (the link to http://jetpack.me/support/site-management is currently broken), I’ve hidden the prompt to Activate Site Management with this mu-plugin


    http://pastebin.com/ugxdNKN2

    I’m not sure what else I’m hiding when I kill the jetpack-message.is-opt-in class, so this fix is pretty temporary.

    Thread Starter mrjarbenne

    (@mrjarbenne)

    Scratch that. The previous pastebin only did half the job, hiding the nag on the Jetpack Settings page. Then I found the large banner nag on the Dashboard. Because some of the CSS seems to be element.style and marked !important, the best I could come up with was changing it to visibility: hidden;, instead of display: none;, which leaves a gapping hole in the header of the dashboard, but hides the Activate button, which was my objective until someone comes in with the more elegant solution.

    http://pastebin.com/WtKaLWmv

    Cheers.

    Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    Instead of using CSS, I’d suggest using this filter to hide the Remote management banner on one site, or on all of them. You could add it to an mu-plugin for example:

    add_filter( 'can_display_jetpack_manage_notice', '__return_false' );

    Admins will still be able to go to Jetpack > Settings > JSON API > Configure and activate remote site management there, though.

    (the link to http://jetpack.me/support/site-management is currently broken)

    It should work now.

    This functionality seems to circumvent that, allowing users the ability to enable and disable plugins I may have active

    That’s correct. Once Remote Site Management is active, any admins will be able to activate and deactivate plugins. That’s something we should address. I created a GitHub issue about it here:
    https://github.com/Automattic/jetpack/issues/1427

    Is there a way to disable this module multisite wide

    If you disable the JSON API module and hide it on all sites, your users won’t be able to activate it.

    You can use some of the filters in this post to hide a module from the Jetpack menu screen:
    http://jeremy.hu/customize-the-list-of-modules-available-in-jetpack/

    For example, you could do something like this:

    // First, hide the Remote Site Management banner
    add_filter( 'can_display_jetpack_manage_notice', '__return_false' );
    
    /*
     * Then, force deactivate the JSON API module if it was activated in the past
     * Note that this can break things you're using,
     * like remote editors such as StackEdit or Display Posts widgets displaying content from that site
     */
    function jeherve_force_deactivate_jsonapi() {
    	if ( class_exists( 'Jetpack' ) && Jetpack::is_module_active( 'json-api' ) ) {
    		Jetpack::deactivate_module( 'json-api' );
    	}
    }
    add_action( 'init', 'jeherve_force_deactivate_jsonapi' );
    
    // And now, hide the JSON API module from the listing
    function jeherve_kill_jsonapi( $modules ) {
    	unset( $modules['json-api'] );
    	return $modules;
    }
    add_filter( 'jetpack_get_available_modules', 'jeherve_kill_jsonapi' );

    I hope this helps.

    Thread Starter mrjarbenne

    (@mrjarbenne)

    That helps immensely. That’s the “more elegant” solution I knew greater minds could conjure.

    I should also thank you for that post, which @blobaugh pointed at in reference to this ticket, so I’ve got most of the modules already filtered, but I couldn’t seem to sort out how to do the same with the Plugin Management. I’m not sure if I can disable JSON-API without negatively affecting the iOS app –(which is odd)– on our multisite.

    Thanks for the help.

    Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    I’m not sure if I can disable JSON-API without negatively affecting the iOS app

    I just double checked, and I was able to post from the iOS app to a site where the JSON API module is disabled.
    Jetpack is not required to use the WordPress iOS app, so whether you use the JSON API Module shouldn’t really matter here.

    If you experience issues with the app, maybe try posting in the iOS forums again?

    Thread Starter mrjarbenne

    (@mrjarbenne)

    That was my experience as well, but other users expressed having issues, and activating JSON seemed to rectify it, as seen in that forum post from iOS. It seemed quite random, and has possibly been repaired. Seems the only way to test is in development. I’ll check it out.

    thefandango

    (@thefandango)

    This seems to still be happening, so does that mean any admin can control all plugins on a network through Jetpack? If so, that is surely a massive security issue that needs dealing with ASAP?

    Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    does that mean any admin can control all plugins on a network through Jetpack?

    They can only activate and deactivate the plugin on their own site, and won’t be able to update the plugin, unless their site is the main site of the network. Their permissions basically match the permissions they have as admins in a Multisite network.

    If, on the other hand, you’ve manually edited roles in your network to remove some permissions for site admins, Jetpack won’t know about it. That’s something we do indeed need to address, and you can follow our progress here:
    https://github.com/Automattic/jetpack/issues/1427

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Plugin Management Option on Multisite’ is closed to new replies.