Answers.Body: <p>It's a good question and it has been asked several times over the years. There are pros and cons for both. Up until around v3.0 civi did have a standalone version, and at the time it was felt that supporting that required too much resources, but as you note there's now 5 CMS's and it seems like just as much work.</p>
  <p><a href="https://civicrm.stackexchange.com/questions/2224/can-civicrm-work-by-itself-e-g-without-drupal">This post</a> is old but not much has changed except I don't think CiviDesk still offers their version.</p>
  <p>For drupal 7 specifically, when drupal 7 itself becomes unsupported civi will probably drop official support for drupal 7, but the community might still unofficially support it for a little longer the same as drupal 6.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-08-06T14:38:18.960Z
Answers.Text: thanks Demerit. Do you know if this point has been discussed and decided in the CiviCRM board? Simply said, is there a clear strategy about the integration of CiviCRM?
Answers.UserDisplayName: Guillaume Sorel
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-08-06T14:47:18.687Z
Answers.Text: The only official roadmap I know of is here: https://civicrm.org/about/roadmap. It doesn't mention anything about this topic. There is sometimes talk in the chat channels about this subject. Otherwise "strategy" comes from either lab tickets, or pull requests that magically appear, but on this topic it's usually because something broke, but indicates that the direction is to keep integrating with CMS's.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-08-06T15:57:42.497Z
Answers.Text: thanks again for the link to the roadmap. ok so near term goals in terms of usability and functionality but nothing clearly defined concerning the integration within the CMS. (that said I have no particular point of view about should or should not be done. I'm just trying to define our own strategy.
Answers.UserDisplayName: Guillaume Sorel
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-03T18:29:07.573Z
Answers.Text: This is a great discussion!  I've been using Joomla for many years and have not explored other CMS in several years. With that, I've now been using Civicrm with Joomla for a few of those years. While Joomla is supported here, it does not seem to have the popularity of the others...meaning topics can be far and few between.
  
  I am considering a move over to Drupal, especially with better integration between Civicrm and Drupal.  What I'm questioning now is if this a smart move for the long-term support.
Answers.UserDisplayName: Taylor Pyles
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-03T18:50:00.107Z
Answers.Text: If you mean moving to drupal 7 instead of 8/9, then no I don't think that's a good idea for long-term. If you mean moving to drupal 8/9 because integration, meaning e.g. Views and Webform, is important to you, then that will be supported long term. If you aren't really planning to use that type of integration and are worried civi might drop joomla, then no I would stick with joomla since that will still be supported long-term for "integration" such as for login accounts.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-03T21:27:11.370Z
Answers.Text: Demerit, Thank You! That's what I was wondering
Answers.UserDisplayName: Taylor Pyles
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-03T23:32:39.063Z
Answers.Text: I wrote a decent amount of the Joomla UI integration and I'm back to being a more active Civi user now.  I think mainly you have to understand that the CMSes are basically a front end to Civi, providing support for passwords/authentication (really hard) and basically a shell for inserting the UI.  It's integration and not an extension.
Answers.UserDisplayName: Elin
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-03T23:38:06.703Z
Answers.Text: Actually @Elin while you're here - if you have a good feel for joomla do you have any thoughts on this: https://lab.civicrm.org/dev/joomla/-/issues/28#note_39175. It's a stumbling block on another still open issue.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-03T23:52:24.227Z
Answers.Text: Hmm not off the top of my head but deleting files is always an extra step I think.  I'll poke around.
Answers.UserDisplayName: Elin
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-03T23:57:23.263Z
Answers.Text: Great thanks. If manually deleting files should be part of the procedure can you comment on that ticket since then the upgrade docs need fixing.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-04T03:08:12.660Z
Answers.Text: Put a comment on the issue, basically I think you should be doing it on postflight(). Overtime there will probably be a running list of files to be deleted.
Answers.UserDisplayName: Elin
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-04T03:13:00.260Z
Answers.Text: Thanks for looking into it!
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-08-06T12:13:33.280Z
Answers.LastActivityDate: 2020-08-06T14:57:11.510Z
Answers.LastEditDate: 2020-08-06T14:57:11.510Z
Answers.UserDisplayName: Demerit
Body: <p>Thinking about <a href="https://civicrm.stackexchange.com/questions/15038/best-platform-for-a-new-website-with-civicrm-wordpress-or-drupal/37290#37290">this topic</a>, I'm wondering about the strategy of CiviCRM in terms of supported CMS?</p>
  <p>CiviCRM can now be embedded on 5 CMS (DRUPAL 7, DRUPAL 8, Joomla, WordPress and Backdrop) and this asks a lot of work from the community to maintain functioning versions on all of them, but not only because it also involves specific documentation for each CMS or functional differences between CMS because Webform is not Caldera or Gravity form and I don't know about Joomla. I can think of this heterogeneous environment to be more of a drawback in 5 years.</p>
  <p>Even if it's very user-friendly, is this strategy sustainable in the long-term? We already use 2 CMS (DRUPAL 7 and WordPress) and with the end-of-life of Drupal 7 we'll probably switch our Drupal instances - some or all of them - to Backdrop in 2021. Which means a 3rd CMS to learn (same-same but always different) and manage.</p>
  <p>Is there a decision taken from the board to stop maintaining in the future Drupal 7 or to make CiviCRM a stand alone web application like vTiger for example, to focus on Drupal 8/9 or to go to another direction?</p>
  <p>Who knows about this?</p>
  
Tags: <cms-integration>
Title: What is the (Long term) strategy for CiviCRM's intergation on CMS?
ThreadText: # What is the (Long term) strategy for CiviCRM's intergation on CMS?
  
  (Asked by: username_0 on 2020-08-06)
  
  Thinking about [this topic](https://civicrm.stackexchange.com/questions/15038/best-platform-for-a-new-website-with-civicrm-wordpress-or-drupal/37290#37290), I'm wondering about the strategy of CiviCRM in terms of supported CMS?
  
  CiviCRM can now be embedded on 5 CMS (DRUPAL 7, DRUPAL 8, Joomla, WordPress and Backdrop) and this asks a lot of work from the community to maintain functioning versions on all of them, but not only because it also involves specific documentation for each CMS or functional differences between CMS because Webform is not Caldera or Gravity form and I don't know about Joomla. I can think of this heterogeneous environment to be more of a drawback in 5 years.
  
  Even if it's very user-friendly, is this strategy sustainable in the long-term? We already use 2 CMS (DRUPAL 7 and WordPress) and with the end-of-life of Drupal 7 we'll probably switch our Drupal instances - some or all of them - to Backdrop in 2021. Which means a 3rd CMS to learn (same-same but always different) and manage.
  
  Is there a decision taken from the board to stop maintaining in the future Drupal 7 or to make CiviCRM a stand alone web application like vTiger for example, to focus on Drupal 8/9 or to go to another direction?
  
  Who knows about this?
  
  **Tags:** cms-integration
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-08-06. Score: 1
  
  It's a good question and it has been asked several times over the years. There are pros and cons for both. Up until around v3.0 civi did have a standalone version, and at the time it was felt that supporting that required too much resources, but as you note there's now 5 CMS's and it seems like just as much work.
  
  [This post](https://civicrm.stackexchange.com/questions/2224/can-civicrm-work-by-itself-e-g-without-drupal) is old but not much has changed except I don't think CiviDesk still offers their version.
  
  For drupal 7 specifically, when drupal 7 itself becomes unsupported civi will probably drop official support for drupal 7, but the community might still unofficially support it for a little longer the same as drupal 6.
  
  > **Comments:**
  > **username_0**: thanks username_1. Do you know if this point has been discussed and decided in the CiviCRM board? Simply said, is there a clear strategy about the integration of CiviCRM?  
  > **username_1**: The only official roadmap I know of is here: https://civicrm.org/about/roadmap. It doesn't mention anything about this topic. There is sometimes talk in the chat channels about this subject. Otherwise "strategy" comes from either lab tickets, or pull requests that magically appear, but on this topic it's usually because something broke, but indicates that the direction is to keep integrating with CMS's.  
  > **username_0**: thanks again for the link to the roadmap. ok so near term goals in terms of usability and functionality but nothing clearly defined concerning the integration within the CMS. (that said I have no particular point of view about should or should not be done. I'm just trying to define our own strategy.  
  > **username_2**: This is a great discussion!  I've been using Joomla for many years and have not explored other CMS in several years. With that, I've now been using Civicrm with Joomla for a few of those years. While Joomla is supported here, it does not seem to have the popularity of the others...meaning topics can be far and few between.  I am considering a move over to Drupal, especially with better integration between Civicrm and Drupal.  What I'm questioning now is if this a smart move for the long-term support.  
  > **username_1**: If you mean moving to drupal 7 instead of 8/9, then no I don't think that's a good idea for long-term. If you mean moving to drupal 8/9 because integration, meaning e.g. Views and Webform, is important to you, then that will be supported long term. If you aren't really planning to use that type of integration and are worried civi might drop joomla, then no I would stick with joomla since that will still be supported long-term for "integration" such as for login accounts.  
  > **username_2**: username_1, Thank You! That's what I was wondering  
  > **username_3**: I wrote a decent amount of the Joomla UI integration and I'm back to being a more active Civi user now.  I think mainly you have to understand that the CMSes are basically a front end to Civi, providing support for passwords/authentication (really hard) and basically a shell for inserting the UI.  It's integration and not an extension.  
  > **username_1**: Actually @username_3 while you're here - if you have a good feel for joomla do you have any thoughts on this: https://lab.civicrm.org/dev/joomla/-/issues/28#note_39175. It's a stumbling block on another still open issue.  
  > **username_3**: Hmm not off the top of my head but deleting files is always an extra step I think.  I'll poke around.  
  > **username_1**: Great thanks. If manually deleting files should be part of the procedure can you comment on that ticket since then the upgrade docs need fixing.  
  > **username_3**: Put a comment on the issue, basically I think you should be doing it on postflight(). Overtime there will probably be a running list of files to be deleted.  
  > **username_1**: Thanks for looking into it!  
  
  ---
  
  