Search multisite directories for civicrm.settings.php

[christianwach]

Jira issue: https://issues.civicrm.org/jira/browse/CRM-18099

This may be more a more complicated issue than this solution alone can fix, depending on how CiviCRM has been installed. It's possible, for example, for CiviCRM to be enabled on more than one network, which will lead to more than one CiviCRM "files" directory. The search routine fails to take this into account. Still, this fixes the simplest use cases in the meantime.

[kcristiano]

@christianwach This looks good. For now, I think this is the only solution that will work will all Wordpress Multi-Sites

[christianwach]

@kcristiano I'm looking into the situation I outlined. It's quite neat that separate sub-site installs of CiviCRM have their own 'files' directory and 'civicrm.settings.php' file, but that search method doesn't support it. Quite how to recognise which Civi instance is to be targeted when a particular external script is triggered... well, it's making my head spin.

[kcristiano]

@christianwach does your Multi-Sites each have a separate CiviCRM db? or are you working with a single CiviCRM DB?

[christianwach]

At present on the live site, there's only one Civi instance on a secondary multisite instance in the multi-network install. So I'll be okay with the current PR :-) What I'm investigating are the various further scenarios that could exist: (a) sharing a single database and (b) individual dbs.

[kcristiano]

We should take this offline, but a single CiviCRM install with a single database can be achieved with switch statements in the settings file. this won't cover Multi-Network. I still believe that this patch is best case for right now and we should revisit CRM-14987 and look to storing the locations in the DB.

[christianwach]

a single CiviCRM install with a single database can be achieved with switch statements in the settings file

But not when there are multiple settings files, as there will be in a "simple" multisite install where CiviCRM is not network-activated but activated on individual sites. Each activation produces it's own install procedure and settings file.

[danaskallman]

Does the outline above allow for the following scenarios:

• One CiviCRM shared across multiple WP single install sites (not multisite)
• WP multisite for something like chapter organizations who want to share the same CiviCRM instance/DB and use ACLs or extension to limit access
• WP multi network, each network has it's own CiviCRM DB but could forseeably do the previous option on sharing a DB within a specific network of the multi network?

[danaskallman]

Adding another use case:

• WP multi network that shares a single CiviCRM DB instance across specific networks

Which I then wonder would this could this be done alongside some networks in the multinetwork having their own CiviCRM DB too?

[christianwach]

@danaskallman This PR is only a temporary fix for certain situations. It won't handle more complex scenarios yet. The roadmap should point to what @kcristiano suggests, which would be far more flexible.

[danaskallman]

@christianwach you note:

This PR is only a temporary fix for certain situations.

What situation or use case would this change be helpful for? Is it each multisite network on a multi-network can have their own Civi instance?

[christianwach]

This PR is only a temporary fix for certain situations.

What situation or use case would this change be helpful for?

I have a WordPress multi-network install where CiviCRM is active on a network that does not have the "root blog" as its main site. Not only that, but the instance predates the change in file storage location that was implemented with WordPress 4.0, so all non-root sites store their files in 'wp-content/blogs.dir/BLOG_ID/'. Post-4.0, these are stored in 'wp-content/uploads/sites/BLOG_ID/'. CiviCRM therefore places its 'civicrm.settings.php' file in a subdirectory in one of these locations.

Is it each multisite network on a multi-network can have their own Civi instance?

No, unfortunately not. As it stands, 'civicrm.config.php' can only reference one instance of CiviCRM. This PR fixes the search for where that instance's settings file is located.

[kcristiano]

No, unfortunately not. As it stands, 'civicrm.config.php' can only reference one instance of CiviCRM. This PR fixes the search for where that instance's settings file is located.

Thinking this through, would a setting by domain id be a better (more bulletproof) way to do this? I had thought to avoid adding more settings, but the further I dig in, I beleive this is the only way.

I would like to see this merged now to solve the issues we have, and then we can create new PRs to address the settings that we'll need.

[christianwach]

Worth looking at this for context http://civicrm.stackexchange.com/a/9603/520

[kcristiano]

Agreed - we use that for what we call WP Multi-Site CiviCRM MultiDomain -- but for us that is one CiviCRM DB, many WP sites all sharing that DB. We'd still need to tweak to get separate CiviCRM's in a WP Multi-Site and/or Muli-Network

[christianwach]

Thanks for the clarification @kcristiano - the latter is the setup I'm after, but a proper solution needs to accommodate the former too :-)

[colemanw]

Hi guys. Is this ready to merge?

[kcristiano]

THis works for us in production for me, so yes, please merge.