5

Is there a best practice as to whether CiviCRM should be installed on its own site, separate from the public site or as part of the public site?

I think of our internal users doing mailings etc and it doesn’t “feel right” for them to do this on the CMS for our public-facing site, but at the same time we want to allow self-service contributions and event registrations.

Is there any issue to link across sites (for example link public site to membership form served on CiviCRM)? Or is that just a pain.

I’m afraid to just go ahead and install CiviCRM on our production public site. We use WP fwiw.

Appreciate any advice.

Improve this question

4 Answers 4

Reset to default
8

I have a number of clients who use CiviCRM on a subdomain separately from their main content site. It has both pros and cons.

Pros:

1. Security.

The main issue addresssed here is the risk of security lapses on the main site exposing CiviCRM. The reason a separate site can be more secure is that you will typically have more modules and functionality on your main site where ease of use is the primary goal, whereas with CiviCRM, security is a much higher priority. Keeping the CiviCRM site with fewer 'ease of use' tools and generally fewer functions will almost always make it more secure, at least in principle.

Analogously - you can also provide hassle-free administrative access to designers and content editors without risk of inadvertently exposing CiviCRM.

2. Performance.

The primary use case of your main site will typically be anonymous access by visitors, whereas most of your access to CiviCRM will be authenticated. The kind of server setup for those two types of access are frequently at odds, so having them on separate servers can make for better use of machine resources. e.g. you can put your main site on a relatively inexpensive hosting service with heavy caching for anonymous visitors.

Cons:

1. Expertise

Keeping internal resources to understand how multiple systems works can be a hassle and/or expensive. This is really the key driver of the decision - if you already have reasons to keep your CMS where it is, or to move it to a different CMS than your CiviCRM is on, then a split install is often a good choice.

2. Maintenance

The main other cost of the separate installs is maintenance - keeping up two sites instead of one, and updating design elements to keep the visual link between them convincing.

3. Server costs.

Usually, two sites is going to cost more than one, but see note 2. above. Specifically - by having the lower-security functionality all together, you can use your budget more effectively, e.g. you can have a managed CiviCRM install and use more off-the-shelf (read cheap/do-it-yourself) tools for your CMS.

I would also note that you don't need fancy machine-level integration as suggested by ErikH - you just need links back and forth, and an internal clarity that the two pieces are only loosely joined.

For clients who are migrating from other solutions (e.g. separate online processsor services, mailing lists and event services), putting all these together on one CiviCRM site that they manage is already a huge step forward in integrating those pieces, and having that functionality relatively loosely linked to the content site is not usually a show stopper, and in some cases a desirable state.

Examples

Here are few sites that are hosting CiviCRM on a separate subsite:

  1. https://www.awid.org/
  2. https://www.wildernesscommittee.org/
  3. http://www.fairvote.ca/
  4. http://www.patientscanada.ca/
  5. http://everdale.org/
  6. https://wildsight.ca/
  7. https://www.bcndp.ca/
  8. https://www.kairoscanada.org/
Improve this answer
2
  • Thank you so much for the comprehensive answer, great pros/cons, and examples, this is extremely helpful. The integration between www.awid.org and secure.awid.org (and similiarly the others) does not seem onerous, from our standpoint it would be mainly the design elements and an understanding of "what lives where". Security is a major issue and the point about vulnerabilities of other plug-in is a great one. Many thanks for your help!
    – ToddB
    Commented Sep 25, 2017 at 16:35
  • Thanks @Alan. I was too quick, some of our larger customers prefer to have specific API requests with the REST and separated CiviCRM / public website. But there are certainly other solutions as you pointed out.
    – ErikH - CiviCooP
    Commented Sep 26, 2017 at 7:07
2

It depends on your security and privacy requirements. I agree with Pete that for CiviCRM to work most simply, install it on your public facing CMS.

You should realize however, that from a security and privacy viewpoint this is not the most secure option. If that is important to you, you should install CiviCRM on a separate server. However, that does mean that you have to think a little on the communication between your public website and CiviCRM. You can use the REST API to communicate with the CiviCRM server from your public website but is does mean you have to do some coding in your website forms. Again, it depends on your requirements.

Hope this helps!

Improve this answer
7
  • Are you saying the most secure option is Standalone CiviCRM?
    – KarinG - Semper IT
    Commented Sep 25, 2017 at 13:10
  • Or are you saying if you have a Wordpress public (example.org) site -> have a separate Drupal/CiviCRM (secure.example.org)
    – KarinG - Semper IT
    Commented Sep 25, 2017 at 13:39
  • The latter! So have a separate Drupal/CiviCRM. Having them on one is a bit like having your gold room next to the public entrance?
    – ErikH - CiviCooP
    Commented Sep 25, 2017 at 15:13
  • What about webform_civicrm module on a Drupal/CiviCRM -> would you not want to leverage that?
    – KarinG - Semper IT
    Commented Sep 25, 2017 at 15:30
  • That is a choice we usually explain to the customer? If they want the most secure set up they loose Webform CiviCRM. It is a question of priorities. But there is github.com/CiviMRF/cmrf_core. Some of our customers prefer the server separation and specific forms.
    – ErikH - CiviCooP
    Commented Sep 26, 2017 at 6:55
1

We have several clients with a WordPress public site and a Drupal based CiviCRM. to keep their hardworking nonprofit website staff happy.

If your website team insists on Wordpress and you need to take advantage of more advanced features of Drupal for things like portals and more complex integrations it can be a good compromise.

Improve this answer
2
  • We use WP really just because we know it (the test CiviCRM install was very easy. Do you mean there is additional functionality if CivicCRM is based on Drupal as opposed to WP? Thx.
    – ToddB
    Commented Sep 26, 2017 at 21:18
  • Todd, the added functionality is with Drupal and the Drupal/Civi integration. One example is the ability to use CiviCRM data for Drupal views. Both Drupal and WordPress work great for fundraising pages, even registration, and basic profile pages displayed on the website.
    – pkeogan - BackOffice Thinking
    Commented Sep 26, 2017 at 23:57
0

For civicrm to work best/most simply, install it on your public facing CMS.

Improve this answer
1
  • 1
    It is indeed most simple but if you are subject to GDPR you have to carefully consider your security risks and document them. Placing your contact data (which are potentially privacy sensitive) on the most vulnerable part of your configuration (which is your public website) will not automatically be considered a good practise.
    – ErikH - CiviCooP
    Commented Dec 14, 2021 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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