Details
-
Type: Improvement
-
Status: Done/Fixed
-
Priority: Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.7.20
-
Fix Version/s: 4.7.31
-
Component/s: Extension System
-
Labels:
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:User and Admin Doc
-
Funding Source:Needs Funding
-
Verified?:No
Description
This is somewhere between a story and a request for an improvement. My production site is a CiviCRM 4.7.19, Drupal 7 site.
My production site uses the Stripe payment processor extension as its sole payment processor. I was receiving some issues with certain contribution and event pages not correctly loading. I figured that something had gotten out of sync in the database and decided to disable the Stripe extension through the UI and then re-enable it.
I wanted to clear the cache as well. I noticed another button about reseting paths and figured it wouldn't hurt to do that as well. The result was that the entire UI to CiviCRM became inaccessible because I was receiving:
PHP Fatal error: require_once(): Failed opening required 'CRM/Core/Payment/Stripe.php'
To get around it, I had to go in to the database and directly disable the payment processors to prevent it from trying to load them. Once I was able to do that, then I could use CiviCRM again to properly reset the extensions directory (in 2 places). I reset it both under Resource URLs civicrm/admin/setting/url?reset=1 and directories civicrm/admin/setting/path?reset=1 - I had to set both of those back to extensions.
It is curious to me that there seems to be 2 settings for the extensions directory. Is there a good reason for that and a distinction or should an effort be made to ensure that there is only a single setting?
The improvement request would be to throw an exception if loading the payment processor (extension) fails. It seems that the logic is try to load this extension, if you cannot find the extension we assume that it is part of core. What I would like to see is a more graceful detection that the extension was not found and that it is not found in core and there for throws an error and redirects to CiviCRM. As long as this scenario does not disable folks from being able to access CiviCRM settings where the admin can then go in and fix things up.
I understand if this might be a bit of an edge case scenario because I am was using extensions instead of ext. The likelihood of others finding themselves in this situation is greatly reduced by just using the default ext path. Nevertheless, I wanted to share and document the experience in case it is helpful for others and if there are some improvements that come from it all the better.