Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-07-01T05:03:24Zhttps://lab.civicrm.org/dev/core/-/issues/2386Support chain-select elements in .setting.php files2023-07-01T05:03:24ZJonGoldSupport chain-select elements in .setting.php filesOverview
----------------------------------------
As we move to metadata-based settings, we need to support existing use cases such as chain-select.
Example use-case
----------------------------------------
1. Go to **Administer » Local...Overview
----------------------------------------
As we move to metadata-based settings, we need to support existing use cases such as chain-select.
Example use-case
----------------------------------------
1. Go to **Administer » Localization » Languages, Currencies, Locations**.
1. The `defaultContactStateProvince` setting can't be represented accurately via metadata.
Current behaviour
----------------------------------------
No way to define either an `onclick` value or a chain-select.
Proposed behaviour
----------------------------------------
A new property `chain_select_settings` contains properties that are passed to the `addChainSelect` method.
Comments
----------------------------------------
There's partial support, and I suspect work on this stopped because `addChainSelect` has a syntax that's tangled up in Smarty. I'll submit a PR to be a conversation piece.
This will also need documentation.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2385Investigate replacing civicase views with something that is not views2021-12-08T09:00:21ZDaveDInvestigate replacing civicase views with something that is not viewsRelated to https://lab.civicrm.org/dev/core/-/issues/2262.
CiviCase uses mysql views (as opposed to drupal views) and is the only component that does so. I'm not sure if they're still truly needed the way they originally were. In additi...Related to https://lab.civicrm.org/dev/core/-/issues/2262.
CiviCase uses mysql views (as opposed to drupal views) and is the only component that does so. I'm not sure if they're still truly needed the way they originally were. In addition to the issue above, they hardcode activity status id and the number 14 (nothing against the number 14, but hey) making it difficult to override those.
I haven't looked at the full query lately but at one time it had a self-join on the view which was where it was convenient to have the view since at the time you couldn't self-join to temporary tables, which might still be true.5.37.0https://lab.civicrm.org/dev/core/-/issues/2383contact custom data date field not working in scheduled reminder2021-04-09T01:59:24Zvakeesan26contact custom data date field not working in scheduled reminderWhen we use the contact custom date field in scheduled reminder condition, then it is not working as expected
![image](/uploads/b7084dc4297fe6a78732529c61d29434/image.png)
CRM_Core_BAO_ActionSchedule::prepareMailingQuery function addi...When we use the contact custom date field in scheduled reminder condition, then it is not working as expected
![image](/uploads/b7084dc4297fe6a78732529c61d29434/image.png)
CRM_Core_BAO_ActionSchedule::prepareMailingQuery function adding Inner join with contact id and custom value table ID field
Eg :-
SELECT reminder.id as reminderID, reminder.contact_id as contactID, reminder.entity_table as entityTable, reminder.*, e.id AS entityID, e.id as entityID, e.*
FROM civicrm_action_log reminder
**INNER JOIN civicrm_contact e ON e.id = reminder.entity_id**
WHERE (reminder.action_schedule_id = 22) AND (reminder.action_date_time IS NULL)5.37.0https://lab.civicrm.org/dev/wordpress/-/issues/90Inconsistent Shortcode rendering2021-10-16T13:15:58ZhaystackInconsistent Shortcode renderingThe issue is kind of complicated. What happens when a Shortcode is embedded in a Post/Page is that the CiviCRM-WordPress plugin goes into "Shortcode Mode", parses the Shortcode and returns the resulting markup to the page.
However, if ...The issue is kind of complicated. What happens when a Shortcode is embedded in a Post/Page is that the CiviCRM-WordPress plugin goes into "Shortcode Mode", parses the Shortcode and returns the resulting markup to the page.
However, if any action is taken via a Shortcode, a query string is appended to the URL and CiviCRM-WordPress goes into "Base Page Mode". The relevant code that tries to sort all of this out (and which has been present in the plugin since before I started work on it) is here:
https://github.com/civicrm/civicrm-wordpress/blob/c40aa7106b21ebad25199e8c2b5d5b0e91d351b1/civicrm.php#L693-L732
Now, one of the results of going into "Base Page Mode" is that the entire content of the Post/Page is replaced via a filter on `the_content` which means - for some layouts and some themes - that the Post/Page is no longer rendered as if the Shortcode _were_ present.
I realise that the current behaviour may now be the "expected" behaviour. Hopefully people can test the PR and let me know what impact (if any) it has for their designs.haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/2381Trigger-based logging crashes on updates to tables with fields of type blob2021-02-23T12:19:14ZDaveDTrigger-based logging crashes on updates to tables with fields of type blobIn https://github.com/civicrm/civicrm-core/pull/18782 binary comparison was added to triggers to allow it to capture changes in upper/lower/accents. For reasons I don't understand at the moment if you apply binary collation to a binary f...In https://github.com/civicrm/civicrm-core/pull/18782 binary comparison was added to triggers to allow it to capture changes in upper/lower/accents. For reasons I don't understand at the moment if you apply binary collation to a binary field (like blob) it says binary doesn't match binary.
`COLLATION 'utf8mb4_bin' is not valid for CHARACTER SET 'binary'`
Description may change as I look closer. Marking regression since it was added in 5.35. Comes up when doing e.g. `UPDATE civicrm_file SET ..something..` which has `document` as a blob field.https://lab.civicrm.org/dev/core/-/issues/2379Geocoding saves values that web UI doesn't accept2023-06-26T12:56:40ZJonGoldGeocoding saves values that web UI doesn't acceptOverview
----------------------------------------
Geocoders can pass back a valid latitude/longitude that looks something like this: `-12.456789012345`. That's 16 characters. However, `CRM_Core_DAO::makeAttribute()` only allows saving `...Overview
----------------------------------------
Geocoders can pass back a valid latitude/longitude that looks something like this: `-12.456789012345`. That's 16 characters. However, `CRM_Core_DAO::makeAttribute()` only allows saving `float` values with a max of 14 characters. So attempting to edit an address with a long lat/lon results in a validation error.
Reproduction steps
----------------------------------------
* Manually enter into the database a `geo_code_1` value of `-12.456789012345` on an address.
* Attempt to edit the address.
Current behaviour
----------------------------------------
![Screen_Shot_2021-02-09_at_9.47.59_AM](/uploads/7627d641a1580c9461916299a97f50d7/Screen_Shot_2021-02-09_at_9.47.59_AM.png)
```
TIP: The best way to convey an error message is to copy it in here and use
three backtick ` symbols. You may edit the message to remove private
information (like passwords). The backticks will help to preserve any
special characters or spaces.
```
Expected behaviour
----------------------------------------
Geocode shouldn't trigger validation errors.5.36.0JonGoldJonGoldhttps://lab.civicrm.org/dev/drupal/-/issues/156system_get_info() is deprecated in drupal 92021-03-04T04:47:08ZDaveDsystem_get_info() is deprecated in drupal 9I'm not sure what I did to trigger the error and I don't see it on d9-master.demo, but the function is clearly not in drupal 9 (https://api.drupal.org/api/drupal/core%21modules%21system%21system.module/function/system_get_info/8.8.x).
I...I'm not sure what I did to trigger the error and I don't see it on d9-master.demo, but the function is clearly not in drupal 9 (https://api.drupal.org/api/drupal/core%21modules%21system%21system.module/function/system_get_info/8.8.x).
I'm just still trying to figure out how to reproduce an error consistently.
`Error: Call to undefined function system_get_info() in CRM_Core_Permission_Drupal8->getAvailablePermissions() (line 61 of ...\vendor\civicrm\civicrm-core\CRM\Core\Permission\Drupal8.php).`5.36.0https://lab.civicrm.org/dev/core/-/issues/2378Status of relationships is not under the control of administrators2023-06-24T05:03:19ZUpperholmeStatus of relationships is not under the control of administratorsOverview
----------------------------------------
As set out in the question below, and the linked comments and answers in the CiviCRM Stack exchange, it is apparent that the status of relationship records is not always under the control...Overview
----------------------------------------
As set out in the question below, and the linked comments and answers in the CiviCRM Stack exchange, it is apparent that the status of relationship records is not always under the control of administrators, and nor is it explicit under what circumstances the nature of a given relationship might change.
https://civicrm.stackexchange.com/questions/28465/how-do-relationships-become-disabled
I raised the question nearly two years ago, and since that time there have been a number of responses on the SE site, some of which I find quite surprising. What is evident is that there are circumstances where a given relationship becomes disabled without the explicit knowledge or consent of administrators. As far as I'm aware there are no settings to control these behaviours.
In my own case I look after a site where memberships are a key driver. The members are organisations, and the memberships are configured such than individuals with an employee/employer relationship have the benefit of membership. This includes inclusion on mailing lists which are driven by smart groups, access to member-only content, event discounts, etc.
What I'm seeing is that employee/employer relationships are often disabled, despite the fact that the team that manages the CRM very rarely uses start or end dates for relationships (we rarely have this information). So, when a relationship is created it should stay enabled until such time as it is manually disabled. We'll manually disable a relationship relatively rarely, when we get information that a person has changed jobs or retired, but this is really very infrequent.
What does happen a lot with our system is that records get merged. People register on the site for events, or sign up for a mailing list, etc., and provide inaccurate information which often leads to duplicate records getting created. So there is a regular day to day activity of spotting and merging duplicates. It is therefore my guess - and it is purely guesswork - that it is this act of merging which is leading to relationship records getting disabled.
What should happen:
-------------------------
If there are rules that are working in the background that are leading to relationships getting disabled, and the information in the Stack Exchange post suggests that there are, then these should be:
1. Made explicit in the documentation, and
1. Controls should be provided either in the UI (preferably), or via the civicrm.settings.php file, whereby site administrators can enable or disable these rules of behaviour.
1. Where a suitably privileged user carries out an action that results in a relationship being disabled an on-screen alert should be displayed, with a link to enable the user to override that disablement.
If there are no rules or background systems that are driving these silent disablements, then there's a nasty bug.https://lab.civicrm.org/dev/wordpress/-/issues/89Civi cannot be installed on Local (previously Local By Flywheel) on Windows2023-12-06T17:15:59ZAndrew WestCivi cannot be installed on Local (previously Local By Flywheel) on WindowsInstalling on [Local](https://localwp.com/) fails due a issue when parsing the schema xml files. On Windows, anyway. Flagging this because Local seems to be increasingly popular as a dev tool - plus is used by people on Flywheel / WP Eng...Installing on [Local](https://localwp.com/) fails due a issue when parsing the schema xml files. On Windows, anyway. Flagging this because Local seems to be increasingly popular as a dev tool - plus is used by people on Flywheel / WP Engine.
What happens is:
1. CRM_Core_CodeGen_Util_Xml::parse() reads xml/schema/Schema.xml. Schema.xml uses <xi:include> tags to include all the other xml schema files in the relevant subdirectories.
2. These inclusions are processed in parse() by a DomDocument object running xinclude(). This fails with a "failed to load external entity" error. Process Monitor shows that it's looking in the wrong directory: it looks for them in the root, rather than under xml/schema.
There's a not-great workaround:
Edit CRM_Core_CodeGen_Util_Xml::parse() and manually set the DomDocument->documentURI to a relative path instead of the absolute path it uses by default. It needs to be relative to the current PHP working directory, which is wp-admin at this point. So under a default WP install this would be: '../wp-content/plugins/civicrm/civicrm/xml/schema/Schema.xml'
I haven't figured out the cause yet. I thought it might be to do with spaces in the directory path (Local uses a folder called "Local Sites" by default on Windows), but it happens outside of that directory too.
The problem doesn't happen XAMP under Windows, so it must be something about the Local setup. I believe it uses Docker behind the scenes. I contacted Local support to see if they had any known issues with xi:include, but no joy.
I'm out of ideas at the moment. Raising an issue so it's at least recorded.https://lab.civicrm.org/dev/financial/-/issues/165Specify text for backend recurring receipts, also cc's and bcc's2022-12-19T03:45:27ZJoeMurraySpecify text for backend recurring receipts, also cc's and bcc'sIf a front end recurring donation is made, then the page's receipt text is added to every recurring receipt (from https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionPage.xml#L326).
If a back end recurr...If a front end recurring donation is made, then the page's receipt text is added to every recurring receipt (from https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionPage.xml#L326).
If a back end recurring donation is made, then the message template Contributions - Receipt (on-line) doesn't output anything from
```
{if $receipt_text}
<p>{$receipt_text|htmlize}</p>
{/if}
```
I think it it would make sense to have this additional text that is added at the top of the receipt specified for backend recurring contributions in core. It would involve a schema change to add a receipt_text field in civicrm_contributioin_recur after https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Contribute/ContributionRecur.xml#L432 , and change the template above to use it.
(Could this be done in an extension, apart from the question of whether it is functionality that completes a feature? The hook at https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterMailContent/ allows the text of a template to be altered. But there is no tooling for modifying a specific part of a template similar to how we've come to use js to modify a page's DOM rather than override its tpl. As a result, it's quite difficult to manage changes to the contents of core templates from extensions as I don't think there is a good way to 'modify its DOM' prior to sending. I suppose a regex every time a receipt is sent to insert the desired text is possible if a bit ugly.)
Simiilarly, there is no ability to cc or bcc these receipts for backend recurring contributions like there is for frontend ones. I'd add fields for this into civicrm_contribution_recur similar to those from civicrm_contribution_page.
I don't believe the is_email_receipt field on civicrm_contribution_recur is exposed on the backend contribution form (anymore). I think it could make sense to add it and the new receipt_text field just under the Receipt Date field on https://dmaster.demo.civicrm.org/civicrm/contact/view/contribution?reset=1&action=add&context=standalone&mode=live. A better approach if we are going to expose them, I think, is to hide these fields in a receipt fieldset, perhaps above Additional Details.
It's likely that many folks would prefer to just specify this once for all backend recurring donations, as it will include text similar to that on the manage contribution page settings for all front end recurring donations through that page. An alternative to adding these fields to the schema for civicrm_contribution_recur, and exposing them for each backend contribution, would be to make them into settings that could be set at Administer > CiviContribute > CiviContribute Component Settings.
Thoughts? Upvotes or even downvotes appreciated if you don't have time for a comment.
Cheers.seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/2377SQL error: role_id is treated as a number instead of string in CRM/Event/Acti...2022-07-03T01:45:05ZalainbSQL error: role_id is treated as a number instead of string in CRM/Event/ActionMapping.php at line 152At line 152 of CRM/Event/ActionMapping.php we find:
`
$query->where("e.role_id IN (#recipList)")
->param('recipList', \CRM_Utils_Array::explodePadded($schedule->recipient_listing));
`
This generates the SQL error "Truncated incor...At line 152 of CRM/Event/ActionMapping.php we find:
`
$query->where("e.role_id IN (#recipList)")
->param('recipList', \CRM_Utils_Array::explodePadded($schedule->recipient_listing));
`
This generates the SQL error "Truncated incorrect DOUBLE value" when a participant has multiple roles.
role_id is a varchar, so quotes are missing. Then I think it should be LIKE instead of IN.
I don't know the best way to fix this code in order to make it work in all situations. But I can help testing the solution.
You can recreate the error by giving a participant multiple roles and creating a scheduled reminder that would select that participant.https://lab.civicrm.org/dev/core/-/issues/2376Related Contributions for recurring contributions not sorted on date2023-06-26T05:03:16ZyashodhaRelated Contributions for recurring contributions not sorted on dateSteps to replicate :
- Go to Recurring Contributions tab for a contact with recurring contributions in place.
- Click _View_ for Recurring Contribution
- Go to _Related Contributions_ section and click the _Received_ column header.
- I...Steps to replicate :
- Go to Recurring Contributions tab for a contact with recurring contributions in place.
- Click _View_ for Recurring Contribution
- Go to _Related Contributions_ section and click the _Received_ column header.
- It is sorted on alphabetic order not date
![related_recurring](/uploads/6e6e03467a8aa3417f9d3c372d6adf63/related_recurring.png)https://lab.civicrm.org/dev/core/-/issues/2375Feature request, De-duplicate rules for Organisations would be more useful if...2023-06-23T05:03:20Zjustinfreeman (Agileware)Feature request, De-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value fieldDe-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value field. Thereby allowing multiple Nicknames (or aliases) for the same organisation to be recorded.
Currently de-duplicate rules for Orga...De-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value field. Thereby allowing multiple Nicknames (or aliases) for the same organisation to be recorded.
Currently de-duplicate rules for Organisations are limited by up to 5 fields. So if you have Organisation Name, Nickname and Email then there are only two fields remaining to compare, which could be used for two custom (Organisation) Nickname fields. You could possibly have a multi-valued custom field for Nickname 2 - have not confirmed if that works at all for de-duplication.
However, it is more commonplace for Organisations to have multiple different abbreviations and shortened versions, not by some "official" naming standard, but simply because people refer to the Organisation differently with varying spelling and abbreviations. eg. IBM, I.B.M, IBM Inc. IBM Intl.
This is a feature request. Open for discussion about other solutions or implementation.
Agileware Ref: CIVICRM-1666https://lab.civicrm.org/dev/core/-/issues/2374Membership Details report, "Payment Amount (most recent)" returns total amoun...2023-06-22T05:03:29Zjustinfreeman (Agileware)Membership Details report, "Payment Amount (most recent)" returns total amount for all membership contributions instead of the most recent Contribution for the Membership renewalMembership Details report, "Payment Amount (most recent)" returns total amount for all membership contributions instead of the most recent Contribution for the Membership renewal.
Steps to reproduce
1. Locate an existing Contact with a ...Membership Details report, "Payment Amount (most recent)" returns total amount for all membership contributions instead of the most recent Contribution for the Membership renewal.
Steps to reproduce
1. Locate an existing Contact with a membership, eg. "Dr. Jacob Terrell-Terry Sr." https://dmaster.demo.civicrm.org/civicrm/contact/view?reset=1&cid=33
2. Renew the membership and enter in a contribution amount, $150
3. Save the contribution
4. Open the Membership Details report, https://dmaster.demo.civicrm.org/civicrm/report/instance/23
5. Display column: "Payment Amount (most recent)"
6. Set Contact filter to locate the contact, eg. Terrell
7. Report displays $250 value for "Payment Amount (most recent)" column
8. Expected result is "Payment Amount (most recent)" shows $150 (not the combined total)
It is also confusing to label the column "Payment Amount (most recent)" and then in the results show the column as "Amount".
As verified on CiviCRM 5.36.alpha1 - https://dmaster.demo.civicrm.org
Agileware Ref: CIVICRM-1664
![Screenshot_20210209_150213](/uploads/e07371ce892ad94af4a09ab08feacd11/Screenshot_20210209_150213.png)
![screencapture-dmaster-demo-civicrm-org-civicrm-report-instance-23-2021-02-09-15_05_16](/uploads/e6ddeaa2622029cf9cb272acac074a34/screencapture-dmaster-demo-civicrm-org-civicrm-report-instance-23-2021-02-09-15_05_16.png)https://lab.civicrm.org/dev/core/-/issues/2373Membership Details report, Net Amount returns null value instead of the most ...2023-06-22T05:03:29Zjustinfreeman (Agileware)Membership Details report, Net Amount returns null value instead of the most recent Contribution for the Membership renewalMembership Details report, Net Amount returns null value instead of the most recent Contribution for the Membership renewal
Steps to reproduce
1. Locate an existing Contact with a membership, eg. "Dr. Jacob Terrell-Terry Sr." https://dm...Membership Details report, Net Amount returns null value instead of the most recent Contribution for the Membership renewal
Steps to reproduce
1. Locate an existing Contact with a membership, eg. "Dr. Jacob Terrell-Terry Sr." https://dmaster.demo.civicrm.org/civicrm/contact/view?reset=1&cid=33
2. Renew the membership and enter in a contribution amount, $150
3. Save the contribution
4. Open the Membership Details report, https://dmaster.demo.civicrm.org/civicrm/report/instance/23
5. Display column: Net Amount
6. Set Contact filter to locate the contact, eg. Terrell
7. Report displays null value for Net Amount column
8. Expected result is Net Value shows $150
As verified on CiviCRM 5.36.alpha1 - https://dmaster.demo.civicrm.org
Agileware Ref: CIVICRM-1663
![Screenshot_20210209_150213](/uploads/862ae11ddee4eb3319584e94295c1eba/Screenshot_20210209_150213.png)
![screencapture-dmaster-demo-civicrm-org-civicrm-report-instance-23-2021-02-09-15_05_16](/uploads/04b31b801b212d1777de30036d0cec3e/screencapture-dmaster-demo-civicrm-org-civicrm-report-instance-23-2021-02-09-15_05_16.png)https://lab.civicrm.org/dev/core/-/issues/2372Prevent double clicking submit button2021-03-21T21:41:08Zahed_compucorpPrevent double clicking submit buttonOverview
----------------------------------------
A typical problem with HTML forms that if you click fast enough, you can submit the form twice - or more, mostly if the server response was slow. CiviCRM is no exception.
Reproduction st...Overview
----------------------------------------
A typical problem with HTML forms that if you click fast enough, you can submit the form twice - or more, mostly if the server response was slow. CiviCRM is no exception.
Reproduction steps
----------------------------------------
- Any page that has a standard form - without Ajax. (e.g. Find Contributions or New Contribution or Some of the result actions).
- Click submit button fast enough.
![2021-02-08_16-26](/uploads/4b85a3b6e4b4fd659955b4e61ab267d7/2021-02-08_16-26.png)
Current behaviour
----------------------------------------
Find Contributions
![Peek_2021-02-08_16-06](/uploads/f552cc398264ba3ffc28de6eee7a1ea7/Peek_2021-02-08_16-06.gif)
New Contribution
![Peek_2021-02-08_16-10](/uploads/fe4c0118c1cba067fab6192c9c78000c/Peek_2021-02-08_16-10.gif)
Send Invoice - Search Action
Will send multiple emails.
![Peek_2021-02-08_16-40](/uploads/7020983f5986408972ea564f53f14e48/Peek_2021-02-08_16-40.gif)
Expected behaviour
----------------------------------------
Disable button during submission. Maybe something like Record Contribution (Ajax form Using the jQuery BlockUI Plugin)
![Peek_2021-02-08_16-14](/uploads/24c71d97550650e78b6629e249f9df76/Peek_2021-02-08_16-14.gif)
Any thoughts on this?
PR: https://github.com/civicrm/civicrm-core/pull/196105.36.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2371Custom setting for boolean checkbox is serialized as int value2022-01-07T09:42:06Zsluc23Custom setting for boolean checkbox is serialized as int valueWhen developing a custom extension and adding a new setting for a boolean checkbox in `settings/myext.setting.php` file as:
```php
<?php
return [
'myext_boolField' => [
'name' => 'myext_boolField',
'type' => 'Boolean',
'htm...When developing a custom extension and adding a new setting for a boolean checkbox in `settings/myext.setting.php` file as:
```php
<?php
return [
'myext_boolField' => [
'name' => 'myext_boolField',
'type' => 'Boolean',
'html_type' => 'checkbox',
'default' => 1,
'is_domain' => 1,
'is_contact' => 0,
'title' => 'Boolean checkbox setting',
'description' => '',
],
];
```
When this value is saved in Admin Form, the value is serialized as **int** i.e.: `i:1;`. This invalidates the code that treat this setting as a boolean value like:
```php
// ** This won't work
if (Civi::settings()->get('myext_boolField') === TRUE) {
// Do something...
}
. . .
// ** This will work
if (Civi::settings()->get('myext_boolField') === 1) {
// Do something...
}
```
We need to treat this value as integer in the code, which is not a programming problem, but I think it gets confusing about variable types.
In my investigation looks like the culprit is this casting to integer:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Admin/Form/SettingTrait.php#L3435.36.0https://lab.civicrm.org/dev/core/-/issues/2370documentation on CIVICRM_CRED_KEYS2023-09-13T05:03:15Zsebalisdocumentation on CIVICRM_CRED_KEYSHi, I have a question about the new config value CIVICRM_CRED_KEYS, as documented in the page on [version-specific upgrades](https://docs.civicrm.org/sysadmin/en/latest/upgrade/version-specific/#smtp-password). The page gives three comma...Hi, I have a question about the new config value CIVICRM_CRED_KEYS, as documented in the page on [version-specific upgrades](https://docs.civicrm.org/sysadmin/en/latest/upgrade/version-specific/#smtp-password). The page gives three commands to generate a value, saying it should be 32 random bytes (256 bits). I can’t comment on the PowerShell example. The PHP example duly generates 32 random bytes and encodes them in base64. The bash example however only generates 16 random bytes and encodes them as hex digits. That does make it a 32-byte string but only four of each character’s eight bits are random. To represent 32 random bytes in text format, some encoding is of course needed and the encoded representation needs to be longer than 32 bytes. The PHP command produces 43 bytes, suggesting that the string representation is indeed allowed to be longer. The question then is which encoding must be used and/or how the choice of encoding should be indicated. The example commands produce different encodings already (PHP: 32 bytes base64-encoded, Bash: 16 random bytes encoded as hex digits) without indicating the encoding. Could someone advise and perhaps amend the page?https://lab.civicrm.org/dev/core/-/issues/2369Fatal error reported when photo cannot be found2021-05-31T15:47:08Zmagnolia61Fatal error reported when photo cannot be foundI use a profile for people to update their profile picture.
For some reason when their photo is not available anymore the error log logs a fatal error.
Also the reporterror extension sends an email on this but of course that's out of cor...I use a profile for people to update their profile picture.
For some reason when their photo is not available anymore the error log logs a fatal error.
Also the reporterror extension sends an email on this but of course that's out of core scope (reported it [there](https://lab.civicrm.org/extensions/reporterror/-/issues/3#note_53134) also)
I have been experiencing this since quite a few versions of CiviCRM back. Currently running 5.34 (Drupal 7.78)
Could it be that the code for this in core is a bit too harsh?
```
[error]
$Fatal Error Details = array:3 [
"message" => "Photo does not exist"
"code" => null
"exception" => CRM_Core_Exception {#3616
-errorData: array:1 [
"error_code" => 0
]
#cause: null
-_trace: null
#message: "Photo does not exist"
#code: 0
#file: "/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Contact/Page/ImageFile.php"
#line: 58
trace: {
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Contact/Page/ImageFile.php:58 {
› else {
› throw new CRM_Core_Exception(ts('Photo does not exist'));
› }
}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:312 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:68 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/drupal/civicrm.module:458 { …}
/var/www/vhosts/xyz/web/includes/menu.inc:527 { …}
/var/www/vhosts/xyz/web/index.php:21 { …}
}
}
]
```5.39.0https://lab.civicrm.org/dev/core/-/issues/2368xdebug_time_index() is incompatible with step-debugging in xdebug 3.02021-02-07T05:09:50ZDaveDxdebug_time_index() is incompatible with step-debugging in xdebug 3.0In xdebug 3.0 they changed some things. There's now an xdebug.mode setting you need to set instead of remote_enable etc. The default value is `develop`, and then the function xdebug_time_index() is available. But for some reason if you s...In xdebug 3.0 they changed some things. There's now an xdebug.mode setting you need to set instead of remote_enable etc. The default value is `develop`, and then the function xdebug_time_index() is available. But for some reason if you set the value to `debug`, which you need for step-debugging, then you get:
`Function must be enabled in php.ini by setting 'xdebug.mode' to 'develop'`
This might be a bug in xdebug itself, but regardless I don't see anywhere where this gets used. It's coming from https://github.com/civicrm/civicrm-core/blob/388745c7b82c2b0114e88ca9510d7a8c450689a1/Civi/API/Subscriber/DebugSubscriber.php#L76.
Is it used in CI/Jenkins?