Meta: Re-implement CiviCRM Standalone (CMS-less CiviCRM)
- Base classes (Hook, System, Permission and css/tpl so that Standalone can boot / proof-of-concept
- Basic composer project to handle the code-case (see: https://github.com/mlutfy/civicrm-standalone, will be moved if concept-approved)
- Composer template project that follows best-practices
- Login page
- User management and permissions
- Password reset by email
- Third-party authentication for SSO, such HybridAuth or LDAP (via extension?)
- Clean URLs
- Language switcher
- Installer (using 'civicrm-setup')
Buildkit (mostly, requires
cvsupport, see: https://github.com/civicrm/civicrm-buildkit/pull/662)
cv (workaround works:
CIVICRM_SETTINGS="/var/www/standalone/data/civicrm.settings.php" cv sql:cli)
- Backend themes (test known themes)
- Front-end theme
- Releaser support (create tar.gz for official downloads)
- Demo site
- Installation documentation
Getting started dashlet - alert.civicrm.org needs to be updated to understand "uf=Standalone" since it currently gives error 500, e.g.
Known minor bugs:
/civicrm/adminpage, the links are missing the leading
Because CRM/Utils/System/Standalone.php automatically sets
userID = 1, that CID is the default org record, so some public forms such as Event Registrations, behave incorrectly. Will be fixed when we implement users.
- Might be a local issue but I [DaveD] get the old files system status warning. There's an open ticket somewhere about this happening for drupal 8 sometimes so might be similar.
Base Standalone classes: https://github.com/civicrm/civicrm-core/pull/22227 - needs review
- Some drupal references still in Standalone.php, e.g. the contact entityref New Individual popup triggers one.
- $docTitle in standalone.tpl might not be the right choice. It's not set every page so gives warnings. Maybe it should be set every page in core.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information