Title: Configuring adminimize on multisite &#8211; bug?
Last modified: August 21, 2016

---

# Configuring adminimize on multisite – bug?

 *  [new_B](https://wordpress.org/support/users/new_b/)
 * (@new_b)
 * [13 years ago](https://wordpress.org/support/topic/configuring-adminimize-on-multisite-bug/)
 * Hi,
 * I tested adminimize on a multisite installation.
 * It seems to partially work. Not sure if others are seeing this behaviour? Is 
   it a bug?
 * If I configure Adminimize Menu Options from the parent site, all changes will
   apply to the same role(s) on the subsites;
 * However, if I make a change to permissions from a subsite for the same role, 
   it doesn’t apply to all sites on the network (at least for the parent site), 
   only the subsite itself
 * I tested thee same thing on another subsite and the permissions applied network
   wide fine.
 * Thus, I’m getting pretty strange and non-consistent behaviour.
 * Thanks in advance
 * [http://wordpress.org/extend/plugins/adminimize/](http://wordpress.org/extend/plugins/adminimize/)

Viewing 6 replies - 1 through 6 (of 6 total)

 *  Thread Starter [new_B](https://wordpress.org/support/users/new_b/)
 * (@new_b)
 * [13 years ago](https://wordpress.org/support/topic/configuring-adminimize-on-multisite-bug/#post-3759049)
 * I tested further and got the same subsite that I originally had problems with
   to apply permissions network wide…strange.
 * I have W3 Total Cache enabled for the parent site; however, it shouldn’t be using
   cache for logged in users though.
 * I tried clearing the cache and it seemed to kick it to show the right menu options
   on the parent site.
 *  Thread Starter [new_B](https://wordpress.org/support/users/new_b/)
 * (@new_b)
 * [13 years ago](https://wordpress.org/support/topic/configuring-adminimize-on-multisite-bug/#post-3759092)
 * Another possible bug occurring on multisite installation:
 * E.g.,
 * Parent site
    – default roles (subscriber, editor, etc.) – custom role A – custom
   role B – Adminimize menu options are configured for this
 * subsite1
    – default roles (subscriber, editor, etc.) – custom role A – custom
   role C
 * If I go to subsite1, and edit the Adminimize – Menu Options for custom role A
   and save it, it will apply to custom role A on the parent site since it has the
   same name; however, also as a consequence, custom role B has all of its Adminimize–
   menu options unchecked after the Adminimize save for subsite1. custom role B 
   does not exist on subsite1
 *  Plugin Contributor [Frank Bueltge](https://wordpress.org/support/users/bueltge/)
 * (@bueltge)
 * [12 years, 11 months ago](https://wordpress.org/support/topic/configuring-adminimize-on-multisite-bug/#post-3759492)
 * The multisite support is more a hack. The plugin was active in all blogs in the
   network, but the settings was saved about all blogs. It is important that you
   create the settings on the blog, there have all options , areas, of all blogs.
   Other it is not possible to set settings about all blogs.
 *  Thread Starter [new_B](https://wordpress.org/support/users/new_b/)
 * (@new_b)
 * [12 years, 11 months ago](https://wordpress.org/support/topic/configuring-adminimize-on-multisite-bug/#post-3759494)
 * Hi,
 * Sorry to clarify, do you mean that the sites all need to have the same set of
   roles (and custom roles) in order for Adminimize to work properly on a network
   enabled setting, assuming that Adminimize menu options is configured for each
   of those roles?
 * I also tried activating it on a site by site basis but noticed there was an issue
   with the parent site not showing all available menu options under Admiminize 
   config to hide admin menu items.
 *  Thread Starter [new_B](https://wordpress.org/support/users/new_b/)
 * (@new_b)
 * [12 years, 11 months ago](https://wordpress.org/support/topic/configuring-adminimize-on-multisite-bug/#post-3759495)
 * Also to add, would it be possible to handle the situation above in a future update,
   when Adminimize is network enabled?
 * If the a custom role (roleA) specific to siteA has Adminimize menu options set
 * and
 * if custom role (roleB) specific to siteB also has its own Adminimize menu set
 * Then changing, one or the other should not wipe out Adminimize settings for roleA
   or roleB (as they have different role names) but it’s what happens in my example
   above. Is it a bug?
 * Thanks.
 *  Thread Starter [new_B](https://wordpress.org/support/users/new_b/)
 * (@new_b)
 * [12 years, 11 months ago](https://wordpress.org/support/topic/configuring-adminimize-on-multisite-bug/#post-3759508)
 * Hi,
 * Just following up as I haven’t heard back regarding this.
 * To try and put it in more simple terms, here’s the condition where I encounter
   the issue.
 * – multisite installation
    – different custom roles on siteA (e.g. roleA) and 
   siteB (e.g., roleB) – identical custom role that exists on siteA and siteB (e.
   g., roleS)
 * When all Adminimize settings (for roleA, roleB, and roleS) are configured, roleS
   is fine and are the same for both siteA and siteB.
 * If roleA is configured last (with roleB already configured), then going back 
   to siteB, roleB’s Adminimize settings are lost.
 * Thanks for any help you can provide.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Configuring adminimize on multisite – bug?’ is closed to new replies.

 * ![](https://s.w.org/plugins/geopattern-icon/adminimize_000000.svg)
 * [Adminimize](https://wordpress.org/plugins/adminimize/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/adminimize/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/adminimize/)
 * [Active Topics](https://wordpress.org/support/plugin/adminimize/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/adminimize/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/adminimize/reviews/)

 * 6 replies
 * 2 participants
 * Last reply from: [new_B](https://wordpress.org/support/users/new_b/)
 * Last activity: [12 years, 11 months ago](https://wordpress.org/support/topic/configuring-adminimize-on-multisite-bug/#post-3759508)
 * Status: not resolved