Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.4.11, 4.5.5
-
Fix Version/s: 4.6
-
Component/s: CiviContribute, Internationalisation
-
Labels:None
-
Documentation Required?:None
Description
We are currently struggling with a bug that prevents our SEPA payment processor from working correctly in a localised environment. I'm also fairly sure that this affects other recurring payment processors as well.
Apparently what happens is that some code deep in the bowels of CiviCRM uses the an OptionValue's label instead of its name/value when creating the recurring contribution entity. The result (running CiviCRM < 4.5) used to be a crash, because it tries to write a localised (i.e. translated) value into the frequency_unit field of civicrm_contribution_recur.
This problem has been around for a while (see CRM-14114, CRM-10860), but the nature of it changed slightly on CiviCRM 4.5, because the type of the frequency_unit field was changed from ENUM to VARCHAR. No SQL error is thrown here, BUT the string written to frequency_unit is still the (localised) label instead of name or value. This is VERY wrong.
We suspect this code section to cause the problem: https://github.com/systopia/civicrm-core/commit/5840da60b5e90c708f0f61604d65193a316700f1
We already stated this problem in a comment in CRM-14114, but I feel this needs to have a higher priority - correct me if I'm wrong.
To reproduce this, try changing the label of the 'month' option value of the 'recur_frequency_units' option group. Then use any (recurring) payment processor on a contribution page to create a recurring contribution.
Attachments
Issue Links
- supplements
-
CRM-14114 Online recurring contribution page does not translate recurring unit
- To Backport