|
|
[[_TOC_]]
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
# Disclaimers
|
|
# Why Standalone?
|
|
|
|
|
|
|
|
This is a personal initiative (not backed by the Core Team) that aims to make CiviCRM work without a CMS. This was possible some time ago, but not very popular and was removed somewhere in the 3.x series.
|
|
CiviCRM Standalone aims to make CiviCRM work without a CMS. This was possible some time ago, but not very popular and was removed somewhere in the 3.x series:
|
|
|
|
|
|
|
|
As CiviCRM has evolved, and so has content management systems, and how organisations manage their CRM, it seems like a good time to bring CiviCRM Standalone back.
|
|
- CiviCRM Extensions barely existed, and most customizations where in Drupal modules.
|
|
|
|
- Theming was mostly done using the CMS theme. Today we have a few options (Shoreditch, Finsbury Park, Haystack Theme, Ahh), and some Bootstrap support in CiviCRM Core.
|
|
|
|
- User management options in Standalone were limited, and SSO was recommended.
|
|
|
|
- Most developers came from the Drupal world, and were more comfortable with Drupal tooling.
|
|
|
|
|
|
|
|
* A lot of organizations do not expose their CRM, or they might only expose specific forms, on a sub-domain.
|
|
As CiviCRM has evolved, so have content management systems, and the organizations using CiviCRM. It seems like a good time to bring CiviCRM Standalone back:
|
|
|
* Managing a website and a CRM coupled together can be challenging.
|
|
|
|
|
* CMSes have become more and more complex, with increasing conflicts between CiviCRM and the CRM. Having to install a CMS before installing a CRM is extra friction. Many people view Drupal9 as too complicated, and WordPress as risky.
|
|
- CiviCRM tooling has improved a lot, from SearchKit, to Form Builder, 'cv', the extension and theming eco-system. Having a CMS is not a requirement anymore.
|
|
|
|
- Managing a website and a CRM coupled together can be challenging
|
|
|
|
- Different teams might be working on the web frontend, and another team on the CRM
|
|
|
|
- Many organizations do not expose their CRM, or they might only expose specific forms, on a sub-domain.
|
|
|
|
- CMSes have become more and more complex, with increasing conflicts between CiviCRM and the CRM.
|
|
|
|
- For completely new users to CiviCRM, who may not come from Drupal or WordPress, having to install a CMS before installing a CRM is extra friction. Many people view Drupal9 as too complicated, and WordPress as risky. Sure, WordPress or Joomla are easy to install, but installing CiviCRM under a CMS is not as easy as we would like. It should be easy to "unzip" CiviCRM onto a server and get started, as well as easy upgrades.
|
|
|
|
- CiviCRM should have an "out of the box" experience that looks good and works well, including a modern interface/theme and translation support.
|
|
|
|
|
|
|
|
Don't worry! Having CMS integrations will always be what makes CiviCRM standout compared to other solutions. CiviCRM must be a good fit for small organizations with limited technical and financial means, and also be a good fit as we help those organizations grow.
|
|
|
|
|
|
|
|
# Todo
|
|
# Todo
|
|
|
|
|
|
| ... | | ... | |
