Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-04-01T01:52:03Zhttps://lab.civicrm.org/dev/core/-/issues/392Support MySQL 8.0 now that it is GA2021-04-01T01:52:03ZJoeMurraySupport MySQL 8.0 now that it is GA# Overview
MySQL 8.0 went General Availability on April 19, 2018. CiviCRM's aim is to support the latest GA for required infrastructure (MySQL, PHP) as soon as feasible.
In reviewing removed features that cause incompatibilities (htt...# Overview
MySQL 8.0 went General Availability on April 19, 2018. CiviCRM's aim is to support the latest GA for required infrastructure (MySQL, PHP) as soon as feasible.
In reviewing removed features that cause incompatibilities (https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) I noticed a couple of issues that definitely require changes, one that might cause syntax errors that are easily fixed when found, and a fourth that we may want to change to improve our functionality and get current.
This is a meta issue for tracking what's needed for MySQL8. I have added a MySQL8 flag to lab for the moment to help in tracking. We can delete that flag after this issue is deemed complete.
# Related issue: Upgrade test infrastructure to enable testing against a version on the edge of being officially supported: https://lab.civicrm.org/dev/core/issues/1142
# Issue: Field Names now Reserved Words https://lab.civicrm.org/dev/core/issues/1143
# Testing issue: dependence on PHP version for MySQL authentication ~~https://lab.civicrm.org/dev/core/issues/1144~~
# Document dealing with changes to MySQL user password library https://lab.civicrm.org/dev/core/issues/1145
# Possible issue: Sort order on GROUP BY clauses
~~I don't think we have any code that tries to specify sort order on GROUP BY fields, but if so we will need to change to add an ORDER BY clause with the sort order. I think we should just try running tests on MySQL 8.0 and using it manually to determine locations in code with this issue, and play whack-a-mole on anything missed.~~
# Nice to have: Upgrade our text fields to support all utf8 characters https://lab.civicrm.org/dev/core/issues/339https://lab.civicrm.org/dev/core/-/issues/394Wildcards are ignored in some smart group criteria, when the smart group is d...2018-10-18T09:37:04ZAndrew WestWildcards are ignored in some smart group criteria, when the smart group is directly generated for a mailingIf you create an Advanced Search with a wildcard in a custom data field*, then use the Actions menu to create a Mailing from these search results, the Mailing won't apply the wildcard. This usually results in fewer recipients than in the...If you create an Advanced Search with a wildcard in a custom data field*, then use the Actions menu to create a Mailing from these search results, the Mailing won't apply the wildcard. This usually results in fewer recipients than in the original search.
But if you create a smart group from the data, and then use the smart group in a new mailing, everything works fine.
Ultimately this happens because of this line in CRM_Contact_BAO_SavedSearch, which is actively stripping out % wildcards from the values in the database:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/BAO/SavedSearch.php#L164
Why is there a difference between the two types of smart group? When you save a smart group directly, you're sent via CRM_Contact_Form_Task_SaveSearch. This serializes the advanced-search form values as query format (? not sure of terminology, sorry). But if you want to create a mailing directly you go via CRM_Mailing_Form_Task_AdhocMailing. This serializes the advanced-search form values directly from quickform.
When these values are unserialized in CRM_Contact_Form_Task_SaveSearch::getFormValues(), the query format ones are fine as-is. But the form values need some processing, and that's when the % is stripped out.
This is a bit low-level for me to start messing around with, so I'm going to Paid Issue Queue this one.
*I haven't tested if this applies to other fields tooMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/395Deadlocked queries cause an instant error for end-users, but are retried in o...2023-07-15T05:03:21ZAndrew WestDeadlocked queries cause an instant error for end-users, but are retried in other circumstancesWe have a lot of smart groups, and consequently a lot of deadlocks. There's already code in Civi that detects deadlock Exceptions, and then retries the query a few times (https://github.com/civicrm/civicrm-packages/pull/197/files). This ...We have a lot of smart groups, and consequently a lot of deadlocks. There's already code in Civi that detects deadlock Exceptions, and then retries the query a few times (https://github.com/civicrm/civicrm-packages/pull/197/files). This is really helpful - I have extra logging on this, and I can see that it prevents a lot of errors. But this code doesn't kick in for people directly using the UI - they get the 'unknown error' yellow-screen-of-death immediately. This can happen on exports, or when opening complex groups. I dug into this and sort-of know why it's happening:
* When a deadlock happens, an exception is thrown if $GLOBALS['_PEAR_default_error_options'][1] is set to 'exceptionHandler'. This exception triggers the code which retries the query.
* An exception is not thrown if $GLOBALS['_PEAR_default_error_options'][1] is set to 'handle'.
* $GLOBALS['_PEAR_default_error_options'][1] is set to 'exceptionHandler' when you generate smart groups via the API, and in most other circumstances
* But $GLOBALS['_PEAR_default_error_options'][1] is set to 'handle' in the UI in general (?) - at least, it is on exports and when using 'Manage Groups'. So in this case no exception is raised. And if there's no exception, the try-catch blocks have nothing to work with and front-end users get 'unknown error' immediately.
This is WP and Civi 5.3.1. We've done / commissioned a lot of work to optimize smart groups to ease the strain on the server in general. But we're always going to have some dynamic smart groups, so it'd be nice to get around this one if possible.
I am happy to fund a fix for this, but I'm not sure what I'm getting myself into. Is this a bug, or is it a consequence of how error handling needs to work for end users?https://lab.civicrm.org/dev/core/-/issues/396date ranges are lost when creating smart groups2018-11-09T22:11:45Zjamiedate ranges are lost when creating smart groupsIf you conduct a search using a core date field and specify a date range (not a relative date range, but a regular date range), then save the results as a group.
When you open the group, the results will be as if the date was not specif...If you conduct a search using a core date field and specify a date range (not a relative date range, but a regular date range), then save the results as a group.
When you open the group, the results will be as if the date was not specified at all. When you edit the smart group criteria the date range is not there.5.7https://lab.civicrm.org/dev/core/-/issues/397Dedupe for Individual Birth Date Results in Error2019-02-13T20:28:31ZjasonobrownDedupe for Individual Birth Date Results in Error```
civicrm: $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_in...```
civicrm: $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => INSERT INTO dedupe (id1, id2, weight) SELECT t1.id id1, t2.id id2, 5 weight FROM civicrm_contact t1 JOIN civicrm_contact t2 USING (birth_date) JOIN dedupe_copy ON dedupe_copy.id1 = t1.id AND dedupe_copy.id2 = t2.id WHERE t1.contact_type = 'Individual' AND t2.contact_type = 'Individual' AND t1.id < t2.id AND t1.birth_date IS NOT NULL AND t1.birth_date <> '' GROUP BY id1, id2, weight ON DUPLICATE KEY UPDATE weight = weight + VALUES(weight) [nativecode=1292 ** Incorrect date value: '' for column 'birth_date' at row 1]
[type] => DB_Error
[user_info] => INSERT INTO dedupe (id1, id2, weight) SELECT t1.id id1, t2.id id2, 5 weight FROM civicrm_contact t1 JOIN civicrm_contact t2 USING (birth_date) JOIN dedupe_copy ON dedupe_copy.id1 = t1.id AND dedupe_copy.id2 = t2.id WHERE t1.contact_type = 'Individual' AND t2.contact_type = 'Individual' AND t1.id < t2.id AND t1.birth_date IS NOT NULL AND t1.birth_date <> '' GROUP BY id1, id2, weight ON DUPLICATE KEY UPDATE weight = weight + VALUES(weight) [nativecode=1292 ** Incorrect date value: '' for column 'birth_date' at row 1]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="INSERT INTO dedupe (id1, id2, weight) SELECT t1.id id1, t2.id id2, 5 weight FROM civicrm_contact t1 JOIN civicrm_contact t2 USING (birth_date) JOIN dedupe_copy ON dedupe_copy.id1 = t1.id AND dedupe_copy.id2 = t2.id WHERE t1.contact_type = 'Individual' AND t2.contact_type = 'Individual' AND t1.id < t2.id AND t1.birth_date IS NOT NULL AND t1.birth_date <> '' GROUP BY id1, id2, weight ON DUPLICATE KEY UPDATE weight = weight + VALUES(weight) [nativecode=1292 ** Incorrect date value: '' for column 'birth_date' at row 1]"]
)
```5.12.0https://lab.civicrm.org/dev/core/-/issues/637Schedule Reminder re: event generates fatal mysql error2019-01-08T07:41:15ZUpperholmeSchedule Reminder re: event generates fatal mysql errorI have a schedule reminder set up for an event. The reminder is set up to send on a specific date, and then repeat every 14 days until 2 weeks prior to the event start date.
Here's the log entry when the scheduled job gets triggered:
J...I have a schedule reminder set up for an event. The reminder is set up to send on a specific date, and then repeat every 14 days until 2 weeks prior to the event start date.
Here's the log entry when the scheduled job gets triggered:
Jan 04 14:54:26 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -2
[message] => DB Error: syntax error
[mode] => 16
[debug_info] =>
``SELECT e.contact_id as contact_id, e.id as entity_id, "civicrm_participant" as entity_table, 30 as action_schedule_id, MAX(reminder.action_date_time) as latest_log_time
FROM civicrm_participant e
INNER JOIN civicrm_event r ON e.event_id = r.id
INNER JOIN civicrm_contact c ON c.id = e.contact_id AND c.is_deleted = 0 AND c.is_deceased = 0
INNER JOIN civicrm_action_log reminder ON reminder.contact_id = e.contact_id AND
reminder.entity_id = e.id AND
reminder.entity_table = 'civicrm_participant' AND
reminder.action_schedule_id = 30
WHERE (r.id IN ("38")) AND (r.is_active = 1) AND (r.is_template = 0) AND (e.status_id IN (5)) AND ("20190104145426" <= DATE_SUB(, INTERVAL 2 week))
GROUP BY reminder.contact_id, reminder.entity_id, reminder.entity_table
HAVING (TIMESTAMPDIFF(HOUR, latest_log_time, CAST(20190104145426 AS datetime)) >= TIMESTAMPDIFF(HOUR, latest_log_time, DATE_ADD(latest_log_time, INTERVAL 1 MONTH)))``
[nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' INTERVAL 2 week))
GROUP BY reminder.contact_id, reminder.entity_id, reminder.en' at line 9]
[type] => DB_Error
[user_info] => ``SELECT e.contact_id as contact_id, e.id as entity_id, "civicrm_participant" as entity_table, 30 as action_schedule_id, MAX(reminder.action_date_time) as latest_log_time
FROM civicrm_participant e
INNER JOIN civicrm_event r ON e.event_id = r.id
INNER JOIN civicrm_contact c ON c.id = e.contact_id AND c.is_deleted = 0 AND c.is_deceased = 0
INNER JOIN civicrm_action_log reminder ON reminder.contact_id = e.contact_id AND
reminder.entity_id = e.id AND
reminder.entity_table = 'civicrm_participant' AND
reminder.action_schedule_id = 30
WHERE (r.id IN ("38")) AND (r.is_active = 1) AND (r.is_template = 0) AND (e.status_id IN (5)) AND ("20190104145426" <= DATE_SUB(, INTERVAL 2 week))
GROUP BY reminder.contact_id, reminder.entity_id, reminder.entity_table
HAVING (TIMESTAMPDIFF(HOUR, latest_log_time, CAST(20190104145426 AS datetime)) >= TIMESTAMPDIFF(HOUR, latest_log_time, DATE_ADD(latest_log_time, INTERVAL 1 MONTH)))``
[nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' INTERVAL 2 week))
GROUP BY reminder.contact_id, reminder.entity_id, reminder.en' at line 9]
[to_string] => [db_error: message="DB Error: syntax error" code=-2 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="``SELECT e.contact_id as contact_id, e.id as entity_id, "civicrm_participant" as entity_table, 30 as action_schedule_id, MAX(reminder.action_date_time) as latest_log_time
FROM civicrm_participant e
INNER JOIN civicrm_event r ON e.event_id = r.id
INNER JOIN civicrm_contact c ON c.id = e.contact_id AND c.is_deleted = 0 AND c.is_deceased = 0
INNER JOIN civicrm_action_log reminder ON reminder.contact_id = e.contact_id AND
reminder.entity_id = e.id AND
reminder.entity_table = 'civicrm_participant' AND
reminder.action_schedule_id = 30
WHERE (r.id IN ("38")) AND (r.is_active = 1) AND (r.is_template = 0) AND (e.status_id IN (5)) AND ("20190104145426" <= DATE_SUB(, INTERVAL 2 week))
GROUP BY reminder.contact_id, reminder.entity_id, reminder.entity_table
HAVING (TIMESTAMPDIFF(HOUR, latest_log_time, CAST(20190104145426 AS datetime)) >= TIMESTAMPDIFF(HOUR, latest_log_time, DATE_ADD(latest_log_time, INTERVAL 1 MONTH)))``
[nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' INTERVAL 2 week))
GROUP BY reminder.contact_id, reminder.entity_id, reminder.en' at line 9]"]
)5.11https://lab.civicrm.org/dev/core/-/issues/398Respect pre hook for relationship to alter id in $params2019-04-03T16:58:46ZPradeep Nayakpradpnayak@gmail.comRespect pre hook for relationship to alter id in $paramsI don't want to create duplicate relationship and want to bypass the rule https://github.com/civicrm/civicrm-core/pull/6515 using an extension. I am using pre hook to send $params['id'] but CRM_Contact_BAO_Relationship::add() doesn't use...I don't want to create duplicate relationship and want to bypass the rule https://github.com/civicrm/civicrm-core/pull/6515 using an extension. I am using pre hook to send $params['id'] but CRM_Contact_BAO_Relationship::add() doesn't use $params['id'] after pre hook is invoked and leads to duplicate relationship.
PR(https://github.com/civicrm/civicrm-core/pull/12834) fixes the above problem and allows hook to send $params['id'].https://lab.civicrm.org/dev/core/-/issues/399Relationship form inputs are reversed2018-09-25T00:28:19ZRudloffRelationship form inputs are reversedHello,
I am using CiviCRM 5.5.1 on WordPress.
It seems that since https://lab.civicrm.org/dev/core/issues/34, the relationship edit form sets the wrong permissions.
The AB radio input sets the BA permission and the BA radio input sets ...Hello,
I am using CiviCRM 5.5.1 on WordPress.
It seems that since https://lab.civicrm.org/dev/core/issues/34, the relationship edit form sets the wrong permissions.
The AB radio input sets the BA permission and the BA radio input sets the AB permission.5.6https://lab.civicrm.org/dev/core/-/issues/401Processing profiles during user registration ignores e-mail address2022-08-29T05:03:38ZjensschuppeProcessing profiles during user registration ignores e-mail addressWhen using a profile on the user registration form for mailing list subscription, the newly registered user/contact should then be going through the usual double-opt-in process. This is not happening.
The following code in `CRM_Profile_...When using a profile on the user registration form for mailing list subscription, the newly registered user/contact should then be going through the usual double-opt-in process. This is not happening.
The following code in `CRM_Profile_Form::buildQuickForm()` (line 747) causes this side effect:
```PHP
// since the CMS manages the email field, suppress the email display if in
// register mode which occur within the CMS form
if ($this->_mode == self::MODE_REGISTER && substr($name, 0, 5) == 'email') {
unset($this->_fields[$name]);
continue;
}
```
This removes any e-mail field from a profile when used on the user registration form (as the CMS already collects an e-mail address). That's fine. However, nothing takes care of passing the submitted e-mail address back into the profile processing cycle, which causes group memberships being registered as "Added (by admin)", which (as far as we recognized) does not trigger the double-opt-in process for this contact.
Within `CRM_Profile_Form::postProcess()` (lines starting 1156 and 1202), the profile submission is being excluded from double opt-in functionality because of the missing e-mail address.https://lab.civicrm.org/dev/core/-/issues/402Typo in templates/CRM/Tag/Page/Tag.tpl:2018-09-23T16:12:34Zr4zoliTypo in templates/CRM/Tag/Page/Tag.tpl:During the translation i transifex common-base: 4426 Duplicate ths tag
the "ths" should be "this"
[dmaster.png](/uploads/6a1176fa7baca711ed8657b35acde6bb/dmaster.png.jpg)"
templates/CRM/Tag/Page/Tag.tpl:During the translation i transifex common-base: 4426 Duplicate ths tag
the "ths" should be "this"
[dmaster.png](/uploads/6a1176fa7baca711ed8657b35acde6bb/dmaster.png.jpg)"
templates/CRM/Tag/Page/Tag.tpl:https://lab.civicrm.org/dev/core/-/issues/403Petition confirmation email places space at end of confirmation URL2021-04-16T05:24:24ZsudomanPetition confirmation email places space at end of confirmation URLThe space placed at the end of the URL in petition confirmation emails, which gets copied by some users, results in visiting an invalid URL.
I tried this with Icedove/Thunderbird and Abrowser/Firefox, Chromium and Midori (WebKit) but wa...The space placed at the end of the URL in petition confirmation emails, which gets copied by some users, results in visiting an invalid URL.
I tried this with Icedove/Thunderbird and Abrowser/Firefox, Chromium and Midori (WebKit) but was not able to reproduce the issue. The person who reported this to us was using Disroot mail and Firefox.
It would be great if the trailing space was removed so that less users run into this problem.5.38.0https://lab.civicrm.org/dev/core/-/issues/404Support recording contributions in crypto-currencies2022-08-29T05:03:37ZgalgeekSupport recording contributions in crypto-currenciesCivi does not currently support recording contributions in crypto-currencies.
@eileen noted "I think it's better to not do it in core at this stage & stick to local experimentation (ie. add it on your own database). There are other issu...Civi does not currently support recording contributions in crypto-currencies.
@eileen noted "I think it's better to not do it in core at this stage & stick to local experimentation (ie. add it on your own database). There are other issues around bitcoin (length of characters supported for currencies) that need to be resolved. You can also alter what length of decimal places different fields support in the DB. I think BTC support will take a lot more than just..." minor edits to xml/templates/civicrm_currency.tpl.
If I can figure out what it does take, I'll document it here!https://lab.civicrm.org/dev/core/-/issues/405CiviCase: unable to save case type config2018-10-09T16:51:14ZlcdwebCiviCase: unable to save case type configTo reproduce, visit Administer > CiviCase > Case Types and edit an existing or create a new case type. The save button is not available and there doesn't appear to be any missing required data that would prevent it from being enabled.To reproduce, visit Administer > CiviCase > Case Types and edit an existing or create a new case type. The save button is not available and there doesn't appear to be any missing required data that would prevent it from being enabled.https://lab.civicrm.org/dev/core/-/issues/4065.5.2: Import is not happy on PHP-7.2 (Countable)2019-01-08T02:47:10ZDmitry Smirnov5.5.2: Import is not happy on PHP-7.2 (Countable)~~~~
2018/09/25 18:15:04 [error] 33#33: *451 FastCGI sent in stderr: "PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 375
P...~~~~
2018/09/25 18:15:04 [error] 33#33: *451 FastCGI sent in stderr: "PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 375
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 387
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 396
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 408
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 417
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 426
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 435
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 444
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 455
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 464
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 476" while reading response header from upstream, client: 192.168.0.2, server: civicrm.local, request: "POST /wp-admin/admin.php?page=CiviCRM&q=civicrm/impor
~~~~5.8https://lab.civicrm.org/dev/core/-/issues/813Profile listings don't show some address/phone fields (all but "main"): work,...2022-10-11T05:03:33ZcalbasiProfile listings don't show some address/phone fields (all but "main"): work, home, etc. But I can see/edit it at contact recordAfter upgrade my CiviCRM (from 4.6.x to 5.10) in a Debian 8 server, with php 5.4 (I'm going to migrate to Debian 9/10 later, to meet php new requeriments) I get this error when render listings with phone/address fields:
Notice: Undefine...After upgrade my CiviCRM (from 4.6.x to 5.10) in a Debian 8 server, with php 5.4 (I'm going to migrate to Debian 9/10 later, to meet php new requeriments) I get this error when render listings with phone/address fields:
Notice: Undefined property: CRM_Core_DAO::$Feina-phone-1 en CRM_Profile_Selector_Listings->getRows() (línea 659 de .../sites/all/modules/civicrm/CRM/Profile/Selector/Listings.php).
where "Feina" means "Work" on Catalan.
That is, I can render phone / address field if I choose "main" address/phone at profile builder, but not secondary fields (home/work/work2, etc).
But I can view/edit this info at contact record form, then, it's just a Profile listing error, what I think mean it's a bug/issue, and not just an isolated issue from my install.
I don't know if problem could be related with the use of other language than English or not.
Ps.: I've submitted a question at stackexchange, but not lucky
[there](https://civicrm.stackexchange.com/questions/28755/notice-undefined-property-crm-core-daofeina-phone-2-a-crm-profile-selector)https://lab.civicrm.org/dev/core/-/issues/407Error with currency localization when recording a payment2019-03-07T09:36:01ZjohansError with currency localization when recording a paymentThis has been posted on stackexchange: https://civicrm.stackexchange.com/questions/26612/problem-with-incoerent-local-currency-in-contribution
I am using civicrm 5.4.1 with drupal 7.
My localization is Italian with decimal delimiter , (...This has been posted on stackexchange: https://civicrm.stackexchange.com/questions/26612/problem-with-incoerent-local-currency-in-contribution
I am using civicrm 5.4.1 with drupal 7.
My localization is Italian with decimal delimiter , (comma) in civicrm/admin/setting/localization?reset=1
When I confirm the record of a payment for a contribution the operation goes on forever and I have to exit the page although when I enter the contribution again the payment is registered.
When I look into the ajax requests with the Chrome DevTools I see that when the "record a new payment" popup is loaded it loads this script from the server (extract):
<span id='totalAmount'>
<select class="eight crm-select2 eight crm-form-select required" name="currency" id="currency">↵
<option value="EUR" selected="selected">EUR (€)</option>
</select> <input size="6" maxlength="14" name="total_amount" type="text" value="1.00" id="total_amount" class="eight six crm-form-text required" />
</span>
<span class="status">Balance Owed: € 1,00</span>
Why is the value in total_amount 1.00 and the value showed in the Balance Owed 1,00?
When I confirm and register the payment the loading of the page goes on forever and when I look into the DevTools I see that this happens as the ajax request answers with an error:
> Sorry, due to an error, we are unable to fulfill your request at the
> moment. You may want to contact your administrator or service provider
> with more details about what action you were performing when this
> occurred. amount is not a valid amount: 1.00
If I change the decimal delimiter to . (point) it works fine.
I have checked this on dmaster.demo.civicrm.org it it has the same problem.5.8https://lab.civicrm.org/dev/core/-/issues/408priority_id getting set incorrectly2023-04-29T05:03:20Zddoligalskipriority_id getting set incorrectlyA modification in CRM/Member/BAO/Membership.php made in 4.7.20 is causing a db constraint error when attempting to make payment on a membership. (See https://github.com/civicrm/civicrm-core/commit/66a1e31f279137676e395ce60eda2cc14bcde5f1...A modification in CRM/Member/BAO/Membership.php made in 4.7.20 is causing a db constraint error when attempting to make payment on a membership. (See https://github.com/civicrm/civicrm-core/commit/66a1e31f279137676e395ce60eda2cc14bcde5f1#diff-f43c8498e32f5b2d68ab27bcd243ca36)
The specific modification (in multiple places) is to set the value of 'priority_id' to 'Normal'. It previously was set to 2. My guess is that 'Normal' should be looked up in option_values with the value saved to priority_id.https://lab.civicrm.org/dev/core/-/issues/409Contribution widget requires time zone to be set in Date.php (or at least som...2022-09-12T05:03:52ZtimatIDGContribution widget requires time zone to be set in Date.php (or at least someplace not set in a new install)On a new Drupal install of CiviCRM 5.5.1 could not get contribution widget to work. It required adding a line to Date.php at /public_html/sites/all/modules/civicrm/CRM/Utils/Date.php (used `date_default_timezone_set("America/Chicago");`...On a new Drupal install of CiviCRM 5.5.1 could not get contribution widget to work. It required adding a line to Date.php at /public_html/sites/all/modules/civicrm/CRM/Utils/Date.php (used `date_default_timezone_set("America/Chicago");` at top of file). This would get overwritten if update CiviCRM, so not a good solution!
php.ini already showing timezone set:
```
**date**
date/time support enabled
"Olson" Timezone Database Version 2016.10
Timezone Database internal
Default timezone America/Chicago
Directive Local Value Master Value
date.default_latitude 31.7667 31.7667
date.default_longitude 35.2333 35.2333
date.sunrise_zenith 90.583333 90.583333
date.sunset_zenith 90.583333 90.583333
date.timezone America/Chicago no value
```
and Drupal also set in the same way at /admin/config/regional/settings
Rather obscure that this makes Contribution Widget show only "placeholder" text and get javascript errors.
Also, as stated in issue 20, can't put Contribution Widget on the contribution page itself, and putting the progress thermometer on this page is a common need. (Work-around I used was a Drupal block with a special version suppressing display in CSS of the description, etc., so not totally redundant.)ErikHommelErikHommelhttps://lab.civicrm.org/dev/core/-/issues/412Avoid truncated UTF-8 strings when using substr()2018-10-24T20:56:26ZjensschuppeAvoid truncated UTF-8 strings when using substr()[`CRM_Core_BAO_Mapping::getCustomGroupName()`](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/BAO/Mapping.php#L1000-1002) truncates custom group names when longer than 10 characters using `substr()`, which causes multibyte charact...[`CRM_Core_BAO_Mapping::getCustomGroupName()`](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/BAO/Mapping.php#L1000-1002) truncates custom group names when longer than 10 characters using `substr()`, which causes multibyte characters being cut in half when at the truncating position.
This should use `CRM_Utils_String::ellipsify()` instead, which utilises `mb_substr()`.
Maybe someone with more core code insight should inspect a `grep substr(` result for more places where that happens.
Steps to reproduce:
1. Create a custom field group with a name with a multibyte character at the 10th position, e.g. German umlaut `ö`
2. Add any custom field
3. Do a contact search, select some contacts, choose "export" action
4. Choose "Select fields to export"
5. Notice a JavaScript console error: "Uncaught syntax error: Unexpected token ,", inspect the source and notice the missing custom field name for the field in the custom field group
Edit: It should be noted that this causes the export field selection screen not working (no fields can be selected) anymore because of the JavaScript error
Patch: [avoid-truncated-utf-8-strings-when-using-substr.diff](/uploads/5af89995ffab165ccab95d8fed961a8e/avoid-truncated-utf-8-strings-when-using-substr.diff)5.8https://lab.civicrm.org/dev/core/-/issues/413<abbr> date and time format not to Google Analytics liking2022-09-02T05:03:34Zthoni56<abbr> date and time format not to Google Analytics likingWe have been starting to get errors from Google Search Console saying "Illegal value type in field hcalendar#dtstart" (or something, translated from Swedish).
Inspecting the page elements you find
<div class="crm-section event_date...We have been starting to get errors from Google Search Console saying "Illegal value type in field hcalendar#dtstart" (or something, translated from Swedish).
Inspecting the page elements you find
<div class="crm-section event_date_time-section">
<div class="label">När</div>
<div class="content">
<abbr class="dtstart" title="20 oktober, 2016 08:30">
20 oktober, 2016 08:30</abbr>
till
<abbr class="dtend" title="17:00">
17:00
</abbr>
</div>
<div class="clear"></div>
</div>
This corresponds to the event information pane in an event page.
Looking at http://microformats.org/wiki/abbr-design-pattern you can see that it, in fact, does not match the proposed formats.
I have no knowledge of the state of this format, it seems a little harsh from Google to point this out as an error, but there you are. Maybe they just want us to know that they found an event, but could not parse the information. And that's fine.
Google offers this: https://developers.google.com/search/docs/data-types/event
I have no non-localized CiviEvent to try this out on, so I don't know if this is a localization issue or a general problem.