CiviCRM Community Forums (archive)

Hello everyone

I have seen some mention of installing Civi and a WP multisite and most of them are several months old.  I am hoping us WP folk, will all learn from this conversation.  What are the current pros and cons of doing this?

Have some of you implemented this and found it to present some challenges?
If so, what have you noticed?

Or has it been problem-free?

Or would you suggest the best practice be to stick with installing Civi on a single WP site?

Personally, without the under-the-hood knowledge, I lean strongly towards the latter.

Looking forward to hearing back from you
Neil with OpenOakland hat on

Have you continued in civi and WP multisite? Just curious if over time you have found it more to your liking. I am swapping from using civi in Joomla to Wordpress and am considering a WP Multisite. Was wondering if it was a good or bad idea.

First off, Civi requires that you Activate the plugin, so installing as a Must-Use plugin is completely out of the question. This would be my preferred method as it removes the temptation to fiddle from the subsite administrators, by hiding the plugin from the lists of plugins in each site. Ah well, later for that then.

I think there are two scenarios interwoven here. First is where you want to share a single Civi instance across all sites on your network. In this case, Civi can be network-activated which means it doesn't have to be activated on each sub-site. This does mean that the Civi admin menu item is available on the sub-site, but you can easily remove it by removing the plugin's menu item action on sub-sites. One can also do that for the Civi shortcode button on post edit screens.

The second scenario is where you want each sub-site to have its own Civi instance. This is possible because (as I understand it) Civi has multiple "site" capability, though I've only heard of it being implemented in a Drupal context. I have yet to try this out for myself, but in principle it looks like it would be possible to create a Civi-as-a-service system in WordPress where each sub-site has a fresh Civi. The civicrm.settings.php is a bit of a roadblock on the way to this since it doesn't lend itself to the dynamic setting up of Civi.

What I have discovered is that Civi will always call the base blog in the network, blog 1.  This means every time your users from any subsite activate a Civi admin page, they are yanked out of their home site, and plopped into the Network site. Not a good thing(tm).  Not only is this disorienting, it may mean you have to grant your editors or other lesser team members access to the Network admin context. Undesirable.

I agree that it's annoying about the URL not respecting the sub-site you may happen to be on. This should not be the case and needs fixing. However, you do not have to grant network admin status to anyone for them to be able to access Civi on the main site - just adjust the Civi permissions to allow access to a role and give that role to the user in question.

A little more stream-of-consciousness...

First off, I think the scenario where each sub-site has its own clean Civi instance is a fairly distant prospect. Looking at the state of play for Civi multisite http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=86213708 it seems that quite a lot of data has little if no separation between Civi "domains" when the same database is being used. There's a way to go before one can spin up a fresh, new Civi instance simply by defining a new domain in Civi per WordPress sub-site. There's possibly a way forward through creating a fresh Civi database per WordPress sub-site, but that also looks far from trivial to implement.

Which leaves us with the option to share a single Civi instance across all sites on the network. The question then becomes how to organise this so it makes sense. One Civi instance per WordPress network rather implies that the data in Civi applies equally across the WordPress network. In some situations, then, managing all access to Civi admin through the main site is reasonable...

For example, the scenario I work with most often is where the WordPress multisite network is (or appears to be) a complete site. Sub-sites are spin-offs of the main site, such as BuddyPress Groupblogs and variants thereof. Civi is mostly used to track activity across the network but its functionality is available via the main site. The gist which I posted a link to above contains a plugin that will modify (or rather limit) Civi's behaviour across the network so that sub-sites do not have access to Civi via their admin menu (nor does the shortcode button appear on sub-site post edit screens) although Civi itself can be loaded. So, for example, when a user profile is edited, the changes can be synced to Civi regardless of the site that the changes occurred on. Sitewide operations like mailings happen from the main site, however. This works fine.

I can imagine scenarios where the above does not hold. Say you have an organisation where the main site is dedicated to the umbrella organisation and sub-sites are managed by regional organisations, then your WordPress sub-sites should have a closer relationship with Civi. In this instance, the Civi database would be shared, but sub-site activity would need to be flagged as pertaining to the sub-site in question. This looks like it can be done with "domain groups" in https://github.com/eileenmcnaughton/org.civicrm.multisite/ but I've not tried it.

As things stand, the Civi dashboard will load on WordPress sub-sites, but attempting further navigation will bounce you to the main site because Civi makes assumptions about the WordPress admin url in a number of places, mostly assuming that it is at 'wp-admin/admin.php' which is not the case with, for example, WordPress subfolder multisite installs. I'm not clear about how to remedy this so that the Civi admin pages function as expected on a sub-site.

And then things get even more complex when plugins such as Networks for WordPress https://wordpress.org/plugins/networks-for-wordpress/ or WP Multi Network https://wordpress.org/plugins/wp-multi-network/ are factored in.

In summary, there's a lot of thinking that needs to be done.