7

The easiest common installation pattern is to have CiviCRM and the frontend website on the same server using the CMS as the website but it is often said there are benefits to keeping them separate. Multiple approaches and extensions have been developed to facilitate this - but our documentation does not (yet!) provide any guidance on these.

The purpose of this question is to gather information about the various tools that exist, what problems they solve and how they fit together as the basis for a new section in the documentation.

  • What extensions exist to connect a frontend website with a backend CiviCRM?

  • What can they be used for? Eg - mailing list signup, event signup, personal profile updates, contributions etc

  • What front-end extensions/modules/plugins work with them?

  • What back-end extensions work with them?

Notes:

  1. I know the normal advice is not to ask multiple questions in one SE question. But think of those as sub-parts of the overall question "How can I connect my website to CiviCRM on a remote server?"
  2. There are some previous related questions but the aim here is to get a comprehensive list of current recommended methods. Eg: creating contacts from remote websites Webform CiviCRM integration with REST Using iframes to present contribution page on remote site CiviCRM and WordPress on different hosts?

  3. If we get one great all-encompassing answer, that can become the basis for the documentation update. More likely, we'll get a selection of answers on particular tools that will need to be consolidated.

5

I am not even going to try and answer it all in one go :-) But I am happy to share the configuration that my customers with remote CiviCRM's use.

They all basically have a public website (Drupal 7 or 8 in most cases, Wordpress in some but in theory any CMS would do) on a server and a separate CiviCRM in a "dummy" Drupal 7 on another server. I use the word "dummy" because in this case Drupal 7 on this CiviCRM server really only is the operating system that makes CiviCRM run.

They all use CMRF on their public website to be able to connect to another server. CMRF is a framework that enables a website to connect to one or more CiviCRM instance(s). The core is CMS agnostic, and there are currently implementations for Drupal 7, Drupal 8 and Wordpress. If an organization would want to use another CMS they could develop a CMRF implementation for that specific CMS.

Almost all of our customers that work in that way use CiviProxy as a gatekeeper for their CiviCRM instance(s). CiviProxy is a a kind of policeman that checks if the request you want to send to the CiviCRM server is allowed. So the public website (or other webservices!) sends a request to CiviProxy, CiviProxy checks if the credentials are correct and if the request is allowed and if so, sends it to CiviCRM and returns the result. Documentation on CiviProxy: https://docs.civicrm.org/civiproxy/en/latest/

We use the Form Processor extension (https://civicrm.org/extensions/form-processor) to create webforms on the public website that communicate with CiviCRM. If the website is in Drupal 7, there is a module called CMRF Form Processor that makes it a little easier. Documentation on the Form Processor: https://docs.civicrm.org/formprocessor/en/latest/

We use the Data Processor extension (https://civicrm.org/extensions/data-processor) when we want to show data from CiviCRM on the public website.

| improve this answer | |
  • Thanks very much for sharing! Just wondering if it is still possible to use views to display Civi data when it is on a separate server? – Ben Jun 24 at 9:12
  • 1
    Not as it is now, Views uses the tables from the CiviCRM database and not the API. – ErikH - CiviCooP Jun 24 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.