Looking for partners for WordPress multisite integration

[krypto]

Hi all,

We're interested in getting Civi working with WordPress multisite. We've spoken with Christian Wach, who has done remarkable work on the WordPress integration in 4.6, and is interested in extending this to the multisite setup.

Having looked at the work needed we've realised we can't cover the full project on our own, so we're hoping there might be others out there willing to partner with us.

Our particular aim is for multiple sites on a single WP installation to be able to access the same Civi database and users. But we're happy to pitch in on a more generic implementation that also allows for the features seen on the drupal side of things, such as independent contacts per domain etc.

Please let me know if you're interested!

Cheers,

Andrew West
British Humanist Association

[nicolas]

Hi Andrew,

I would eventually be interested to contribute time (ie. programming/testing/documentation) to this integration, but am not very enthusiastic about WordPress multisite in itself as, as far as I know, it does not allow individual sites to have their own themes/plugins folders. In the context of hosting for different, unrelated organizations as this would be the case for me this is pretty much a no-go.

But maybe this is something we can discuss between the three of us with Christian. You can PM me if you want to pursue.

Thanks,
--Nicolas.

[krypto]

Hi Nicolas,

Thanks! Yes, WP Multisite is more for administering groups of sites. So for developers who control a bunch of client sites, or networks where the users have control over content only.

Cheers,

Andrew

[danaskallman]

This would be a great option for networks that use a WP multisite and provide a CRM option to their chapters for example.

With CiviCRM it's about multi-domain, meaning it works outside of a WP multisite and allows two or more separate websites connect to the same CiviCRM instance. However, there are limitations since access to groups are managed through the ACLs and that only applies to contacts.

If events was a component that wanted to be provided for each chapter to use, currently it's done on event by event basis. Meaning if the user role chapters gets access to CiviEvent, they can view and modify all events. This is outlined in the Functional Separation in Multisite section of this wiki page: http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=86213708

It seems that looking at that outside of the CMS first would be ideal, since there are core limitations on what can be done currently. Is there any new work we know of on that front?

[haystack]

It seems that looking at that outside of the CMS first would be ideal, since there are core limitations on what can be done currently.

@danaskallman, does this mean that Civi's multi-domain implementation is not really ready for general deployment because there's not enough separation between "domains"? Would you therefore recommend that the first stage of WordPress multisite integration should be limited to @krypto's less general solution, where all sites (or perhaps chosen sites) on the network get access to the same data in Civi? This would still requires a raft of changes to Civi core - see my quick audit here:
https://github.com/civicrm/civicrm-wordpress/pull/63#issuecomment-61738465

[haystack]

I would eventually be interested to contribute time (ie. programming/testing/documentation) to this integration, but am not very enthusiastic about WordPress multisite in itself as, as far as I know, it does not allow individual sites to have their own themes/plugins folders. In the context of hosting for different, unrelated organizations as this would be the case for me this is pretty much a no-go.

@nicolas WordPress multisite does allow all sites on the network to have their own theme. You're right that plugins are shared across the network, however, although each site can have a different combination of active plugins. Some plugins can be network activated, meaning that they will be active on all sites by default. None of this should prevent you hosting separate organisations on a single WordPress multisite instance - it is a common use case for multisite. Think wordpress.com, which hosts hundreds of thousands (if not millions) of separate organisations on a single codebase.

The wider question of Civi-WordPress integration at this level is that there are multiple use cases for WordPress multisite that even its core team are having difficulty categorising. See, for example:
https://make.wordpress.org/core/2015/02/18/multisite-objective-defining-network-types/

I personally spend most of my time building "trusted" multisite instances, where the network is a "single" site for the use of just one community or organisation, but am aware that this is only one kind of network. Things get even more complex when you consider that you can extend WordPress multisite to become "multi-network", where you can host multiple multisite instances in the same codebase. I have this setup for the non-profit that I'm a member of - we have three related organisations in different countries, each of which has its own multisite instance. It makes code maintenance a whole heap simpler and enables cross-network content sharing.

I think the roadmap for Civi multi-domain -- WordPress multisite integration depends on the use cases that can be identified and, as @danaskallman identifies, Civi's limitations.

[danaskallman]

@danaskallman, does this mean that Civi's multi-domain implementation is not really ready for general deployment because there's not enough separation between "domains"?

@haystack multidomain can be used for general deployment if the admin roles are managed centrally, meaning only admins can manage events, etc across all chapters. If the goal is give chapters/sub-sites the ability to manage those components on their own, then yes I don't think it's ready for general deployment. There is limited separation between sites for Civi components. Especially as compared to what we are used to with WP Multisite.

I do know that there are many changes that would need to be made core and I know there have been discussions about this. In the past I've discussed briefly with @GinkgoFJG and @Eileen, so maybe they have some insight that would be helpful too.

[nicolas]

@danaskallman, does this mean that Civi's multi-domain implementation is not really ready for general deployment because there's not enough separation between "domains"?

There is a very nice discussion on what CiviCRM Multisite does and does not do at: http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=86213708. I have personally found it well adapted to chapter-based organizations (ie. hierarchical permissions on the database, sharing of the same membership types between subdomains, etc) and have used it successfully with a few of my customers.

Maybe what would be needed is more 'settings' on what is shared vs segregated between the subdomains, ie. for some organizations it might make sense to have different membership types in each chapters, or different emaling templates, etc. A list of entities with a 'shared / segregated' toggle might make sense ... but then people will ask about other options like 'inherited from level above' or 'shared for all except ...' ... and there will come the rabbit's hole.

@nicolas WordPress multisite does allow all sites on the network to have their own theme. You're right that plugins are shared across the network, however, although each site can have a different combination of active plugins. Some plugins can be network activated, meaning that they will be active on all sites by default. None of this should prevent you hosting separate organisations on a single WordPress multisite instance - it is a common use case for multisite. Think wordpress.com, which hosts hundreds of thousands (if not millions) of separate organisations on a single codebase.

Yes, what (afaik) is missing is an isolation layer for the themes/plugins, ie. everyone sees all that is available. In Drupal you have sites/all/modules for 'network' modules and sites/mycharity.org/modules for 'mycharity,org only' modules. This is what I am looking for as I do not want all my customers to start installing that home-made not-really-tested plugin some other of my customers has created, not can I reasonably forbid any of my customer to install any plugin of their choosing.

[haystack]

There is a very nice discussion on what CiviCRM Multisite does and does not do at: http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=86213708.

I've read that but - like @danaskallman - I'm curious as to whether the page represents the true state of play. The "Functional Separation in Multisite" section hasn't been updated since the page was created.

I have personally found it well adapted to chapter-based organizations (ie. hierarchical permissions on the database, sharing of the same membership types between subdomains, etc) and have used it successfully with a few of my customers.

In which case your experience of multi-domain would be very valuable (at least to me) whether you're skeptical of WP multisite or not. I have zero experience in that regard 

[gharris]

I'll admit, I'm getting a bit confused.  It seems like there are three distinct setups being discussed with only two terms being used.  Should it not be something more like:
A.  Multi-Site - Different sites under one umbrella organization with a shared user base and "straightforward" hierarchical structure, i.e. chapters
B.  Multi-Domain - Different forward facing organizations with a somewhat shared user base but different hierarchical structures, i.e. Building Permits office and the Community center hosted by a city
C.  Multi-Tenant - Completely autonomous organizations sharing a common code base and/or database server, i.e. Wordpress.com

In addition, it appears that there is also a server/network layer.  I can't seem to come up with the correct term but would essentially be Clustered, i.e. multiple sites served from multiple servers connecting to a separate backend CiviCRM.  This could be mixed and matched with all three setups above.

Wordpress doesn't seem to handle Multi-Tenant too well when you are looking at having autonomous administration between sites for themes and the like.  Also, Multi-Tenant seems to be where the rabbit hole really comes in to play.

Am I reading this right?  According to the definitions above I am interested in Multi-Domain, but Multi-Tenant seems most useful for hosting services.  I'm still trying to figure out how it all works and getting things set up, so I can't say I can be of much help, but I'm hoping this discussion helps me set it up correctly!  Is this Multi-Domain setup what you are shooting for?

[danaskallman]

I know the multisite and multidomain is confusing. My understanding is multisite is more about the CMS setup, so if WP, Drupal or Joomla are setup as such. For CiviCRM connecting to a multisite it would be the same installation process referenced here: http://wiki.civicrm.org/confluence/display/CRMDOC/Multi+Site+Installation

Meaning that no matter if CiviCRM is connecting to 2 sites on a multisite or 2 independent websites, each site gets an ID in the DB.

[haystack]

It seems like there are three distinct setups being discussed with only two terms being used. Should it not be something more like:
A.  Multi-Site - Different sites under one umbrella organization with a shared user base and "straightforward" hierarchical structure, i.e. chapters
B.  Multi-Domain - Different forward facing organizations with a somewhat shared user base but different hierarchical structures, i.e. Building Permits office and the Community center hosted by a city
C.  Multi-Tenant - Completely autonomous organizations sharing a common code base and/or database server, i.e. Wordpress.com

But... but... there are many more identified use cases for WordPress multisite than this. See, for example the list here:
https://github.com/jeremyfelt/multisite-notes/issues/5

In terms of developing a "taxonomy of network types", I agree with @danaskallman when she points out that "multidomain" is a Civi concept in some ways similar to WordPress "multisite" but it's not the same as "mapping separate domains to a single WordPress install" as per your option B. I think we need to use these terms carefully - in my mind "multidomain" only applies to Civi, while "multisite" only applies to WordPress.

I do, however, disagree with Dana where she says that:

no matter if CiviCRM is connecting to 2 sites on a multisite or 2 independent websites, each site gets an ID in the DB.

This is not necessarily the case, nor should it be. For example, in my NGO multi-network WordPress install I want Civi data to be shared across multiple WordPress multisite instances (each with its own domain but in the same WordPress install) and would therefore not want different domain IDs per site that connects to Civi.

My first concern is for Civi to honour the paths of its host WordPress install such that Civi can actually be used on each site on the network - at present, it doesn't and it can't be. I'm reposting my list of where it doesn't for reference:

https://github.com/civicrm/civicrm-wordpress/pull/63#issuecomment-61738465

I think this goal is probably the most achievable in the first instance. If Civi stopped making assumptions about the host WordPress install, then the way in which it maps to WordPress can be manipulated accordingly later. If a different domain ID is required when a particular site connects to Civi, this can already be done by "late-loading" Civi and defining 'CIVICRM_DOMAIN_ID' prior to civicrm.settings.php being read.

Wordpress doesn't seem to handle Multi-Tenant too well when you are looking at having autonomous administration between sites for themes and the like.  Also, Multi-Tenant seems to be where the rabbit hole really comes in to play.

Personally I think "Multi-Tenant" is a misguided use of WordPress multisite. If you really want complete separation of users and data, why would you use WordPress multisite at all? The whole point of it is that it provides some shared data and resources. WP-CLI makes it straightforward to automate the management of separate installs, so what benefit does multisite confer? Furthermore, the issues of data separation on the Civi multidomain side make "Civi as a service" practically impossible at present, unless AFAICT it's pretty much limited to contact management only.

Is this Multi-Domain setup what you are shooting for?

tl;dr Sort of

[gharris]

And I'm lost why?!?     Seriously though, it did help.  At least a little bit. 

I think we need to use these terms carefully - in my mind "multidomain" only applies to Civi, while "multisite" only applies to WordPress.

YES! YES! YES!  -  That's why I was trying to lay out a definition of the terms, at least in my own mind.  Your clearer delineation helps.  Also, your objection to Dana scares me, as that's the road I was hoping we would follow over the long term.  I think that we would run into the same problems you are staring down.   

Thanks.

[haystack]

That's why I was trying to lay out a definition of the terms, at least in my own mind.

It's a noble aim Everyone's trying to understand "multisite" - though with limited success it seems! See, for example, the latest musings from the WordPress multisite development crew yesterday:
https://make.wordpress.org/core/2015/02/25/multisite-office-hours-recap-february-24-2015/
In particular the commentary here:
https://make.wordpress.org/core/2015/02/18/multisite-objective-defining-network-types/

Also, your objection to Dana scares me, as that's the road I was hoping we would follow over the long term.  I think that we would run into the same problems you are staring down.

I think any solution needs to be flexible enough to accommodate the variety of networks that people are capable of building without being too prescriptive. As I said previously, a first step would be to fix the assumptions in Civi core first. At that point we can argue about how it interfaces with that various different types of WordPress multisite.

[suz]

Salutations!

I understand this is an old thread, but I am interested in standalone CRMs for Wordpress. I have a working multisite network I can offer for testing, if that would help your project.

My client sells fruit to fundraising teams, who in turn sell to their constituents. Each team gets its own site (within the multisite network) and their own separate woocommerce cart and catalog.

Likewise, we'd like to offer CiviCRM to each team, and we can install that on our server too. Then we'd use the WP plugin to hook them up.

If anyone was wondering if there is interest in this integration, there is!