Answers.Body: <p>I think I have a partial answer—or at least, a tool that's looking good.</p>
  
  <p>Answering Demerit's comment: both the Backdrop/CiviCRM and D8/Open Social sites are going to have public pages. My original assumption was that D8 would be primary site, with CiviCRM information fed into it—but the last few days of deeper dives into CiviCRM indicates that so much functionality is available there "for free" that I'm likely to make that the primary site, with a secondary community.mydomain.org domain for the social networking aspects. There's just a ton of stuff I thought I would have to custom-build which someone has already included in core.</p>
  
  <p>Still the case that I need a new user/CiviCRM account to create its equivalent on D8, and that single sign-on would be nice. Both domains are subdomains of mydomain.org, so I can tackle that with cookies, but since I have to do account creation anyway, a more elegant approach that allows new domains to be used would be nice (we currently own four). <a href="https://www.youtube.com/watch?v=mCEcnywRgpE&amp;t=1482s" rel="nofollow noreferrer">This YouTube video</a> on data integration led me to <a href="https://sourceforge.net/projects/pentaho/support" rel="nofollow noreferrer">Pentaho</a>, which looks excellent both for its abstraction capabilities handling any dataset, as well as its scripting interface. Not seeing much point in going through the trouble of learning and implementing SAML if I can do it all in one package. (And for the initial release, there are few methods I could use to avoid all of this—i.e., creating a hash on the primary site that someone has to use to create an account on the second manually, and suggesting they log into both with the "remember me" checkbox turned on.)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-26T13:51:59.300Z
Answers.Text: Since this issue in largely about SSO now - what about porting a D7 SSO module to Backdrop?  It doesn't take much work, and with D7 compatibility mode turned on, it may well just work until you have time to port it properly.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-26T15:00:21.227Z
Answers.Text: If you want to have most of the early/grunt work of a D7 module port to Backdrop done for you, try https://github.com/backdrop-contrib/coder_upgrade
Answers.UserDisplayName: Laryn
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-26T22:40:45.563Z
Answers.Text: SSO is a subset of what I need to accomplish. Open Social and CiviCRM have duplicative data structures—events live in both places, for example, and have different effects in each place—and so creation of a record in one place has to be repeated on the other site.
Answers.UserDisplayName: Jeff Porten
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-26T05:43:34.137Z
Answers.LastActivityDate: 2019-08-26T05:43:34.137Z
Answers.UserDisplayName: Jeff Porten
Body: <p>Working with an architecture of Drupal 8 running Open Social, and Backdrop running CiviCRM. Currently both virtual hosts on the same server, with separate mysql databases. The key issue: after tearing up and throwing out several architectures, I am months behind and need to get a demonstration site up and running yesterday, with a functional 1.0 ready as soon as possible—weeks, not months. The snag: I'm new to nearly every component here, with a background in a dozen CMSes and a few CRMs, but not these.</p>
  
  <p>Have been consuming a firehose of information, and nearly every step has a dozen prerequisites that could take a week each. For example: a new member joining the organization needs a user account in both Drupal and Backdrop, with Backdrop integration to CiviCRM. It seems the "standard" method is to do this with API calls, but I'm new to the API and the three techniques the docs tell me I can use. Would be fine if this were January, but not in August.</p>
  
  <p>Problem 2: whatever I build now is likely to be rapidly obsolesced. When CiviCRM is official for D8, we might decide to consolidate under one roof. Or I might be convinced by the increased security of CiviProxy and segregate the full Civi db behind a VPN. (Skipping it for now, I don't have time to learn what's not available yet.)</p>
  
  <p>My question: are there quick and dirty techniques I can use to bypass the more expert methods? For example: export and import I can learn quickly, so if I write a single abstracted function, I can write data to a local file and use a cron trigger to read it into the other side. Boom, I can move data back and forth without resorting to a custom API script for each function. Nearly everything one site does will need to be reflected in the other; I need the simplest way of doing this.</p>
  
  <p>I'm guessing I'll still need APIs for some activities, i.e., logging into the D8 site should be a single sign-on for both sites. (No idea how to do that. Help requested.) And I'm still totally unclear what UI will live where—that is, do I build members-only content in Backdrop, or do I use D8 views to pull in CiviCRM data and present there only? Again—the fastest and simplest is best, even if ugly; there will be time to retool later.</p>
  
  <p>Suggestions? Many thanks, I'm drowning here.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-24T07:17:51.770Z
Comments.Text: An extension to the above remarks: looking into single sign-on, I note that D8 can handle external auth but the only Backdrop method appears to be a commercial service. So now I'm thinking, instead of D8 being the main site with CiviCRM contributing particular pages, it's easier to make Backdrop the main site and farm out to D8 when I need Open Social functionality. Might not be "best," but certainly simplest.
Comments.UserDisplayName: Jeff Porten
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-24T16:54:31.977Z
Comments.Text: For sharing user accounts / single-sign-on, you could use something like the modules that let you sign in with google or facebook. I'd expect open social already has that, and I'm not too familiar with backdrop but drupal 7 has modules for it. e.g. https://www.drupal.org/project/social_login. For the rest of it, at least for civi, did you already rule out the 3-database approach, where the 3rd database has all the civicrm_* tables and you point CIVICRM_DSN in civicrm.settings.php on both sites to that 3rd shared database?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-25T03:01:12.090Z
Comments.Text: The D8 does not have CiviCRM installed, which I gather is necessary for this method? The docs say, “Thou shalt not directly reference the database.” And I’m too new to know what rules I can break.
Comments.UserDisplayName: Jeff Porten
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-25T03:09:18.453Z
Comments.Text: Maybe I misunderstood. Are both sites public and you need to sync anything that happens on d8 to backdrop and backdrop to d8, but the civi part doesn't currently need to sync anywhere?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-25T03:34:47.320Z
Comments.Text: Will answer in a post below as I have a tool now that might solve the issue. Need to wait until at keyboard.
Comments.UserDisplayName: Jeff Porten
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-08-25T21:52:45.303Z
Comments.Text: "When CiviCRM is official for D8, we might decide to consolidate under one roof" - what are you main blockers about using d8 now? it seems like all the effort you may invest to not have things under one roof could potentially remove those blockers.
Comments.UserDisplayName: petednz - fuzion
Tags: <drupal-views><drupal-8><backdrop>
Title: Quick and dirty decoupled CiviCRM with cron and export/import?
ThreadText: # Quick and dirty decoupled CiviCRM with cron and export/import?
  
  (Asked by: username_0 on 2019-08-24)
  
  Working with an architecture of Drupal 8 running Open Social, and Backdrop running CiviCRM. Currently both virtual hosts on the same server, with separate mysql databases. The key issue: after tearing up and throwing out several architectures, I am months behind and need to get a demonstration site up and running yesterday, with a functional 1.0 ready as soon as possible—weeks, not months. The snag: I'm new to nearly every component here, with a background in a dozen CMSes and a few CRMs, but not these.
  
  Have been consuming a firehose of information, and nearly every step has a dozen prerequisites that could take a week each. For example: a new member joining the organization needs a user account in both Drupal and Backdrop, with Backdrop integration to CiviCRM. It seems the "standard" method is to do this with API calls, but I'm new to the API and the three techniques the docs tell me I can use. Would be fine if this were January, but not in August.
  
  Problem 2: whatever I build now is likely to be rapidly obsolesced. When CiviCRM is official for D8, we might decide to consolidate under one roof. Or I might be convinced by the increased security of CiviProxy and segregate the full Civi db behind a VPN. (Skipping it for now, I don't have time to learn what's not available yet.)
  
  My question: are there quick and dirty techniques I can use to bypass the more expert methods? For example: export and import I can learn quickly, so if I write a single abstracted function, I can write data to a local file and use a cron trigger to read it into the other side. Boom, I can move data back and forth without resorting to a custom API script for each function. Nearly everything one site does will need to be reflected in the other; I need the simplest way of doing this.
  
  I'm guessing I'll still need APIs for some activities, i.e., logging into the D8 site should be a single sign-on for both sites. (No idea how to do that. Help requested.) And I'm still totally unclear what UI will live where—that is, do I build members-only content in Backdrop, or do I use D8 views to pull in CiviCRM data and present there only? Again—the fastest and simplest is best, even if ugly; there will be time to retool later.
  
  Suggestions? Many thanks, I'm drowning here.
  
  **Tags:** drupal-views, drupal-8, backdrop
  
  > **Comments:**
  > **username_0**: An extension to the above remarks: looking into single sign-on, I note that D8 can handle external auth but the only Backdrop method appears to be a commercial service. So now I'm thinking, instead of D8 being the main site with CiviCRM contributing particular pages, it's easier to make Backdrop the main site and farm out to D8 when I need Open Social functionality. Might not be "best," but certainly simplest.  
  > **username_1**: For sharing user accounts / single-sign-on, you could use something like the modules that let you sign in with google or facebook. I'd expect open social already has that, and I'm not too familiar with backdrop but drupal 7 has modules for it. e.g. https://www.drupal.org/project/social_login. For the rest of it, at least for civi, did you already rule out the 3-database approach, where the 3rd database has all the civicrm_* tables and you point CIVICRM_DSN in civicrm.settings.php on both sites to that 3rd shared database?  
  > **username_0**: The D8 does not have CiviCRM installed, which I gather is necessary for this method? The docs say, “Thou shalt not directly reference the database.” And I’m too new to know what rules I can break.  
  > **username_1**: Maybe I misunderstood. Are both sites public and you need to sync anything that happens on d8 to backdrop and backdrop to d8, but the civi part doesn't currently need to sync anywhere?  
  > **username_0**: Will answer in a post below as I have a tool now that might solve the issue. Need to wait until at keyboard.  
  > **username_2**: "When CiviCRM is official for D8, we might decide to consolidate under one roof" - what are you main blockers about using d8 now? it seems like all the effort you may invest to not have things under one roof could potentially remove those blockers.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2019-08-26. Score: 0
  
  I think I have a partial answer—or at least, a tool that's looking good.
  
  Answering username_1's comment: both the Backdrop/CiviCRM and D8/Open Social sites are going to have public pages. My original assumption was that D8 would be primary site, with CiviCRM information fed into it—but the last few days of deeper dives into CiviCRM indicates that so much functionality is available there "for free" that I'm likely to make that the primary site, with a secondary community.mydomain.org domain for the social networking aspects. There's just a ton of stuff I thought I would have to custom-build which someone has already included in core.
  
  Still the case that I need a new user/CiviCRM account to create its equivalent on D8, and that single sign-on would be nice. Both domains are subdomains of mydomain.org, so I can tackle that with cookies, but since I have to do account creation anyway, a more elegant approach that allows new domains to be used would be nice (we currently own four). [This YouTube video](https://www.youtube.com/watch?v=mCEcnywRgpE&t=1482s) on data integration led me to [Pentaho](https://sourceforge.net/projects/pentaho/support), which looks excellent both for its abstraction capabilities handling any dataset, as well as its scripting interface. Not seeing much point in going through the trouble of learning and implementing SAML if I can do it all in one package. (And for the initial release, there are few methods I could use to avoid all of this—i.e., creating a hash on the primary site that someone has to use to create an account on the second manually, and suggesting they log into both with the "remember me" checkbox turned on.)
  
  > **Comments:**
  > **username_3**: Since this issue in largely about SSO now - what about porting a D7 SSO module to Backdrop?  It doesn't take much work, and with D7 compatibility mode turned on, it may well just work until you have time to port it properly.  
  > **username_4**: If you want to have most of the early/grunt work of a D7 module port to Backdrop done for you, try https://github.com/backdrop-contrib/coder_upgrade  
  > **username_0**: SSO is a subset of what I need to accomplish. Open Social and CiviCRM have duplicative data structures—events live in both places, for example, and have different effects in each place—and so creation of a record in one place has to be repeated on the other site.  
  
  ---
  
  