Details
-
Type: Improvement
-
Status: Done/Fixed
-
Priority: Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.4.5
-
Fix Version/s: 4.5
-
Component/s: Extension System
-
Labels:None
-
Documentation Required?:Developer Doc
Description
Tim and I had a long IRC chat about this (see http://irc.civicrm.org/logs/%23civicrm.log.2014-06-13.txt).
This conversation started because I added a managed entity to CiviVolunteer but wasn't seeing the change in sites already running the extension.
For sites where CiviVolunteer is already installed, it was difficult to get CiviCRM to load the managed entity. I had to run "drush cvapi system.flush" or hit /civicrm/clearcache. Even creating a dummy upgrade_n hook would not cause CiviCRM to load the managed entity.
However, installing the same code on a CiviCRM instance that didn't have CiviVolunteer already installed did work as expected.
When CiviCRM checks for releases and downloads new code, it calls CRM_Extension_Manager::replace(), which doesn't seem to do a cache-clear, unlike all the other stages in the extension lifecycle.
We concluded that upgrades managed through CiviCRM (i.e., through the web UI, the extension API, and drush), the user should not be required to take additional steps to get the managed entities loaded into CiviCRM.
To support admins who upgrade extensions more manually (e.g., git pull, curl, etc.), a new API call is needed: extension.upgrade. This is analogous to Drupal's updatedb.