CiviCRM Community Forums (archive)

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.

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?

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, 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.

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?

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

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.