CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-10-20T20:07:11Zhttps://lab.civicrm.org/dev/core/-/issues/3702DOMDocument::loadHTML(): Tag af-field invalid in Entity when loading dashboard2022-10-20T20:07:11ZDaveDDOMDocument::loadHTML(): Tag af-field invalid in Entity when loading dashboardI'm not sure if this is new or not. This might be something coming up for me now with php8. The error comes up in phpquery which is now provided by vendor/rubaboquery which is new, but I'm not sure it's from any differences there. I thin...I'm not sure if this is new or not. This might be something coming up for me now with php8. The error comes up in phpquery which is now provided by vendor/rubaboquery which is new, but I'm not sure it's from any differences there. I think the error is technically legit.
What's happening is during hook_civicrm_angularModules, afform loads all the blocks, such as this one: https://github.com/civicrm/civicrm-core/blob/6fa8c627a2f406329370f2b03d656dbc565ccb9f/ext/afform/core/ang/afblockContactAddress.aff.html
At https://github.com/civicrm/civicrm-core/blob/6fa8c627a2f406329370f2b03d656dbc565ccb9f/ext/afform/core/Civi/Afform/Symbols.php#L38, it creates a DOMDocumentWrapper around it, which is provided by rubaboquery. Note that it considers the block html (as opposed to e.g. xml), so calls DOMDocument->loadHTML. So I believe what's happening is that loadHTML validates it against the html schema, and `<af-field>` is not a real html tag.
See also https://www.php.net/manual/en/domdocument.loadhtml.php#125526, although I'm not saying that is the best solution. I don't know at the moment.5.56.0https://lab.civicrm.org/dev/core/-/issues/3703Confirmation emails are not sent if it is a recurring payment2022-08-25T17:04:50ZMariaVConfirmation emails are not sent if it is a recurring payment**Current behavior apparently:**
One-time donations: A confirmation email comes right after you fill out the donation form
Recurring donations: A confirmation email comes each time after the payment is processed
This works quite well ...**Current behavior apparently:**
One-time donations: A confirmation email comes right after you fill out the donation form
Recurring donations: A confirmation email comes each time after the payment is processed
This works quite well for online payment processors like PayPal, where the first payment is made within seconds of submitting the donation form.
With "asynchronous payment processors" such as SEPA, however, this approach works quite poorly, because it can take several weeks before the next payment run happens (usually once a month).
Currently this does not work at all.
Moreover, from a fundraiser's point of view, it is a real disadvantage if these confirmations are sent with every payment: People will be reminded every time that they still haven't cancelled their recurring donations.
**In contrast, the behavior most of us would like to see would be:**
One-time and recurring donations: A confirmation email comes right after you fill out the donation form
Further confirmations for recurring donations will only come if this has been set in a configuration setting.
**My suggestion:**
There could be an additional radio button:
One option that will be choosed by default which explains that the mail is only sent for recurring donations when a payment has actually been received (and for one-time donations directly). And for this purpose, there will be another option that says that a confirmation will be sent once directly after the form has been submitted - regardless of whether it is a one-time or recurring donation.
This will ensure that this function will continue to work for everyone who actually wants to use it that way - even if there are probably not many.https://lab.civicrm.org/dev/core/-/issues/3705CiviReport email sending fails if multiple recipient are specified in 'to' field2024-03-05T05:24:43ZKurund JalmiCiviReport email sending fails if multiple recipient are specified in 'to' field### Steps to replicate
1. Create report an instance
2. Configure `Email Delivery Settings`; add multiple emails in `to` field.
3. Configure this report instance to send emails via Scheduled Job
Emails are never sent
## Error in CiviCR...### Steps to replicate
1. Create report an instance
2. Configure `Email Delivery Settings`; add multiple emails in `to` field.
3. Configure this report instance to send emails via Scheduled Job
Emails are never sent
## Error in CiviCRM logs
```bash
[error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => 10006
[message] => Failed to send data [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfigura
tion in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 554, response: Tra
nsaction failed: Domain contains illegal character)]
[mode] => 16
[debug_info] =>
[type] => PEAR_Error
[user_info] =>
[to_string] => [pear_error: message="Failed to send data [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfiguration in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 554, response: Transaction failed: Domain contains illegal character)]" code=10006 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info=""]
)
```
This happens because multiple emails gets converted in to invalid emails due to `CRM_Utils_Mail::formatRFC822Email()`https://lab.civicrm.org/dev/core/-/issues/3711Permissions reset on upgrade or configuration change2022-08-25T21:41:06ZAdam WoodPermissions reset on upgrade or configuration changeApplies to CiviCRM running on Joomla.
The permission "See CiviCRM is installed" keeps resetting by itself. This definitely occurs whenever CiviCRM is upgraded (issue observed up to and including 5.50.4) and/or an extension is installed,...Applies to CiviCRM running on Joomla.
The permission "See CiviCRM is installed" keeps resetting by itself. This definitely occurs whenever CiviCRM is upgraded (issue observed up to and including 5.50.4) and/or an extension is installed, enabled/disabled, updated etc, and may occur at other times. I cannot discern the pattern!
This means that CiviCRM disappears from the 'Components' administrator menu unless you are logged in as Super Administrator.
Since CiviGrant was migrated to an extension, the same issue now applies to "access CiviGrant", "edit grants" and "delete in CiviGrant" - I have to keep re-applying these after each upgrade.https://lab.civicrm.org/dev/core/-/issues/3714CiviCRM Contribution Page, total amount calculation is sometimes off by one o...2023-07-18T05:40:43Zjustinfreeman (Agileware)CiviCRM Contribution Page, total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being usedWhen using a **CiviCRM Contribution Page** the total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being used.
In the case of ...When using a **CiviCRM Contribution Page** the total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being used.
In the case of Stripe, the _correct amount_ is _pre-authorised_. When the payment is _confirmed_ the _incorrect amount_ is used and because the two amounts do not match, the **transaction fails**. As a result this bug prevents payments from working with Stripe as a payment processor for certain amounts.
# Steps to reproduce
1. Enable tax and invoicing
2. Add e.g. a 10% GST account to Member Dues
3. Create a membership prices set with one field that has three checkbox options:
4. 318.18182 (350 incl tax)
5. 22.72727 (25 incl tax)
6. 24.54545 (27 after tax - note that this would actually work out to 27.01 with the older premature rounding based off-by one issue)
7. Use this price set on a contribution page
8. Submit a test using this contribution page.
9. Note in the summary that the line totals are 350.00, 25.00, and 27.00
## Expected result
Total should be **$402**
## Actual result
Total is **$401.99** - which is one cent less than the expect value, and two cents less than the value you would get with premature rounding.
## Tested environment
Bug has been confirmed using **CiviCRM 5.52.alpha1** on https://wpmaster.demo.civicrm.org/
## Workaround
Adjust the amount to account for the rounding error. In this case, change the amount: 24.54545 to 24.5363636364 which then changes the total to $401.99. This is then matches the total on the Thank You page.
![image](/uploads/ddf3c7cbeaf3cdc4700079f79b01c7d6/image.png)
![image](/uploads/5eb33f84dfa49cad5697570a019c6936/image.png)
# Contribution page with membership options selected - correct total is shown
![image](/uploads/f35b520763e5e9f3545585f27ff42812/image.png)
# Thank you page - incorrect total is shown
![image](/uploads/d6fa209c43cbf2d721d4cf085882b1f8/image.png)
# Set up - Membership Types
![image](/uploads/01450b1f2a777f3c279e694d5ea7e007/image.png)
# Set up - Priceset
![image](/uploads/672f5c3de5b72e7817dc063388f08c38/image.png)
Agileware Ref: CIVICRM-2007https://lab.civicrm.org/dev/core/-/issues/3730Search Kit: data exported to spreadsheet as strings where numbers expected2023-08-25T14:47:13ZAndreasandreas.howiller@civiservice.deSearch Kit: data exported to spreadsheet as strings where numbers expectedOverview
----------------------------------------
When exporting spreadsheets from Search Kit in some cases data types seem to be exported incorrectly as strings where they should be numbers.
Reproduction steps
------------------------...Overview
----------------------------------------
When exporting spreadsheets from Search Kit in some cases data types seem to be exported incorrectly as strings where they should be numbers.
Reproduction steps
----------------------------------------
1. Create Search Kit search for **Contributions** on demo.
2. Add columns for **Total Amount** and **Date Received** and click **Search**.
3. Export results via **Action** → **Download Spreadsheet** and choose **.ods** (or **.xlsx**).
4. Open document with office software.
Current behaviour
----------------------------------------
While the Contribution ID column is correctly formatted as a number, Total Amount and Date Received are formatted as **strings**.
Note: Numbers are also left-aligned in Search Kit exports (column A).
Here is what the file looks like in LibreOffice 6.4.7.2:
![grafik](/uploads/ede5de9d9898448c1e0d2676863cfc17/grafik.png)
…and here the corresponding XML in content.xml:
![grafik](/uploads/9487cc0e42f0980eb08e958bea23e7f4/grafik.png)
Expected behaviour
----------------------------------------
Numbers and Date fields are exported in correct data type.
Additional ideas / Comments
----------------------------------------
- it would probably be very useful to have **more Field Transformations** to have some choice for data types, esp. to be able to output money values with our without money signs
- maybe numbers should not be left-aligned anymore (as it is the standard behaviour in spreadsheets)
Environment information
----------------------------------------
* CiviCRM: 5.52.alpha1 and 5.50.3
* PHP: 7.4
* CMS: WordPress 6.0 and Drupal 9.3.14https://lab.civicrm.org/dev/core/-/issues/3738Feature request - APIv4 Get action, provide ability to define aliases for the...2024-03-15T14:56:37Zjustinfreeman (Agileware)Feature request - APIv4 Get action, provide ability to define aliases for the select fields so that external integrations with CiviCRM do not break when the field name changes OR a different field is selectedThis is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enab...This is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enable external CiviCRM integrations to be more robust, by allowing the fields selected in the Get action to be **changed** and but continue to use the **same alias**, thus not changing the structure of the results, the external integration would continue to work.
The other benefit would be that very long CiviCRM field names could be reduced to something shorter or more logical. eg. Instead of "email.email" the alias could just be set to "email". Or instead of "email_greeting_id:label" the alias could just be "email_greeting".
![image](/uploads/2ccae5082e4f50f5fc924d8e6998ffaa/image.png)https://lab.civicrm.org/dev/core/-/issues/3740Set default lock level to READ COMMITTED2023-10-20T07:57:25ZJoeMurraySet default lock level to READ COMMITTEDDrupal recently changed the default lock level slightly down from REPEATABLE READ to READ COMMITTED, which has the effect of avoiding some db locks. See https://www.drupal.org/node/3269885 We have seen over recent years some issues with ...Drupal recently changed the default lock level slightly down from REPEATABLE READ to READ COMMITTED, which has the effect of avoiding some db locks. See https://www.drupal.org/node/3269885 We have seen over recent years some issues with deadlocks, primarily on rebuilding group contact cache when there are hierarchies of smart groups. Should CiviCRM be more explicit about what isolation level we expect in order to get more repeatable results, and should we follow Drupal in its move to READ COMMITTED? I tend to think so.
See responses in MM chat from @demeritcowboy
https://chat.civicrm.org/civicrm/pl/gnmhfdxes7rgb8k7ppoaezo45ahttps://lab.civicrm.org/dev/core/-/issues/3752Membership terms present in price set not get used in the offline form signup.2024-03-15T02:23:37ZsunilMembership terms present in price set not get used in the offline form signup.Overview
----------------------------------------
Number of Terms present in priceset not get used while signing up using offline form.
Reproduction steps
----------------------------------------
1. Crete Price and field of Select opti...Overview
----------------------------------------
Number of Terms present in priceset not get used while signing up using offline form.
Reproduction steps
----------------------------------------
1. Crete Price and field of Select option.
1. Use Membership type `Student` which is 1 year duration.
1. Use the same membership type with different terms.
1. Now, go to the contact and sign up for membership using priceset.
1. Use Membership with 2 or 3 year terms.
1. Result : it extends by only 1 year.
Current behaviour
----------------------------------------
Irrespective of different terms of membership, membership only extends by only one year.
Expected behaviour
----------------------------------------
Membership should extend as per terms set in the price set field option.https://lab.civicrm.org/dev/core/-/issues/3759Logging table schemas should be updated when extension table schemas are updated2022-08-24T19:17:07ZJonGoldLogging table schemas should be updated when extension table schemas are updatedI just ran into an issue while enabling Geocoder on a relatively fresh Civi install. `install.sql` generated a table, then `hook_civicrm_managed` tried adding all those record in `.mgd.php`, which failed because `log_civicrm_geocoder` d...I just ran into an issue while enabling Geocoder on a relatively fresh Civi install. `install.sql` generated a table, then `hook_civicrm_managed` tried adding all those record in `.mgd.php`, which failed because `log_civicrm_geocoder` didn't exist.
I know this isn't a simple lift - but given the recent conversations that `civix` might phase out the generation of `.sql` files, this seems like the opportune moment to raise the issue.https://lab.civicrm.org/dev/core/-/issues/3760Add server side validation for afform2023-03-08T17:56:47ZKurund JalmiAdd server side validation for afformCurrently, there is some work done on the frontend to add client side validation and it would be good to add the same at the API end.Currently, there is some work done on the frontend to add client side validation and it would be good to add the same at the API end.Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3761Form Builder roadmap2023-11-10T12:30:28ZwmortadaForm Builder roadmapThis roadmap is based on a [Google Doc](https://docs.google.com/document/d/1PfgV48_Fc6rup5PexPpxOvnd5nV9NOjN8dieglxHAyM/edit#) created as part of the regular Form Builder / SearchKit meetings.
It could do with some tidying up and more d...This roadmap is based on a [Google Doc](https://docs.google.com/document/d/1PfgV48_Fc6rup5PexPpxOvnd5nV9NOjN8dieglxHAyM/edit#) created as part of the regular Form Builder / SearchKit meetings.
It could do with some tidying up and more details on some items.
See also dev/core#3912 for tracking conversion of Admin screens and dev/core#3762 for SearchKit items
## Support more entities
- [x] CiviCase
- [x] Participants https://github.com/civicrm/civicrm-core/pull/24420
- [ ] Surveys/Petitions
- [x] Grants
- [ ] Contributions
- [ ] Group opt ins
- [ ] Generalized entity support (generic create/edit forms for any entity type, including custom civix-generated entities)
## Support more workflows
- [x] Ability to add tokens to form submission redirect URL https://github.com/civicrm/civicrm-core/pull/24016
- [x] Add to navigation menu https://github.com/civicrm/civicrm-core/pull/24013
- [x] CAPTCHA support https://lab.civicrm.org/dev/core/-/issues/3173
- [ ] Multi-step forms
- [ ] Conditional fields https://github.com/civicrm/civicrm-core/pull/24699
- [ ] Form-only fields that can be used in conditionals. Eg. _"for example I want to ask 'Do you want to add another child?' and have yes or no, the yes then opens another individual contact to be created on the form, but i don't want to have this question as a custom field as it will never be looked at."_
- [ ] Display values after submission
- [ ] Support remote display and submission (https://civicrm.org/make-it-happen/formbuilder-remote-forms)
## Other improvements
- [x] Improve validation
- [.] Client side validation https://github.com/civicrm/civicrm-core/pull/23604
- This is only partially implemented and does not work for select2 and multiple checkboxes (at least) - see https://github.com/civicrm/civicrm-core/pull/25535 and https://github.com/civicrm/civicrm-core/pull/25536 for details.
- [x] Server side validation https://lab.civicrm.org/dev/core/-/issues/3760
- [ ] Payment processors
- [ ] Price sets
- [ ] “Pagebuilder”
- [x] Support entity ref with pre-population
- [ ] Embed on remote site - check inlay (https://lab.civicrm.org/extensions/inlay)
- [x] Display-only fields (https://lab.civicrm.org/dev/core/-/issues/3779)
- [x] ‘Add New’ button ([Added to SearchKit](https://github.com/civicrm/civicrm-core/pull/24512/commits/8d0bafa435d7b2eed771cd2dd2c180e566063592))
- [ ] Add a config link shown to admins
- [ ] More/better APIs/examples for hooking into forms (from extensions)
- [ ] post-submit tokens
- [ ] contact widget in drupal webform
- limit an entity-ref
- pull up data for contact from entity-ref (get their name/address)
- [x] entity-ref: is it api4 or api3? https://github.com/civicrm/civicrm-core/pull/24832
- [ ] More in-place “Edit” links (for admins)
- [ ] WordPress Gutenberg block
- see [Afform - support embedding forms via WP](https://github.com/civicrm/civicrm-core/pull/19687/files#diff-5af5dcb53864f5076881abda3a70b38143ee4b7be5b1c1fce453bf4721db74f2R533-R549) for inspiration
- [ ] Tag support
- [x] Deduplication https://github.com/civicrm/civicrm-core/pull/24552
- [ ] Support url-params and other config options for Values in Submmission forms https://lab.civicrm.org/dev/core/-/issues/3910
- [ ] Hidden fields https://github.com/civicrm/civicrm-core/pull/24161
- [x] Copy a search display in the UI
- [x] Add a 'Copy' button for repeating elements - like the existing 'Add' button but copying the values entered in the source. Was "Bulk create defaults" dev/core#3986 https://github.com/civicrm/civicrm-core/pull/26071
- [ ] Date filtering options dev/core#3985
- [ ] Add tab display see https://github.com/civicrm/civicrm-core/pull/24981
- [ ] Add way to link to local URL's in helptext see https://github.com/civicrm/civicrm-core/pull/24981
- [ ] Decide how to handle popup help text currently in `.hlp` files - new element on form? eg see https://github.com/civicrm/civicrm-core/pull/24981
- [ ] Add way to handle popup warnings before action see https://github.com/civicrm/civicrm-core/pull/24981
- [ ] Allow 'Add New' button to open full-page, not just pop-up - eg https://github.com/civicrm/civicrm-core/pull/24937
- [ ] Add general purpose button? eg 'Manage Personal Campaign Pages' button - see https://github.com/civicrm/civicrm-core/pull/24937
- [ ] Improve SK UX - see dev/user-interface#49
- [ ] Allow generic / "preset" formatting instead of hardcoding colours etc. per form. Eg specify preset "Generic search form" to make it look like every other search form.
- [ ] Conditional field formatting based on other field values.
- [ ] Create a way to add someone to a group from a Submission form
- [ ] In SK, be able to use custom fields in joins. (Eg with Related Contacts, want to include if custom field matches criteria. NB you can use custom fields in Where clauses but that turns 'with (optional)' into 'with (required)' dev/core#3972
- [ ] Smart totals for monetary amounts: a listing of contributions £1, £2, $3 should show a total of £3, $3 not '6'. Many contribution reports need this. More generically, allow aggregates over more multiple fields but summing contribution amounts is possibly the main use case. dev/core#4207
## Reimplement in a framework other than AngularJS
AngularJS was released in 2010 with Google discontinuing support at the end of 2021. It is the primary javascript technology used in SearchKit and especially FormBuilder.
- [x] Research options including health and market share momentum of project/community, impact on developer experience, etc. Options might include React, Angular, etc.
- [X] discuss with community at Manchester Sprint
- [X] Develop scope and estimates for migrating to React as part of a large grant proposal
- [ ] develop prioritized epics for migration starting with some proof of concept LExIM extensions
- [ ] through MIHs and developer commitments plan how to resource a phased migration to the selected new technology optionhttps://lab.civicrm.org/dev/core/-/issues/3762SearchKit roadmap2023-11-10T12:30:29ZwmortadaSearchKit roadmapThis roadmap is based on a [Google Doc](https://docs.google.com/document/d/1PfgV48_Fc6rup5PexPpxOvnd5nV9NOjN8dieglxHAyM/edit#) created as part of the regular Form Builder / SearchKit meetings.
It could do with some tidying up and more d...This roadmap is based on a [Google Doc](https://docs.google.com/document/d/1PfgV48_Fc6rup5PexPpxOvnd5nV9NOjN8dieglxHAyM/edit#) created as part of the regular Form Builder / SearchKit meetings.
It could do with some tidying up and more details on some items.
See also dev/core#3761
## Improvements
- [ ] [Action permissions](https://docs.google.com/document/d/1SM_kdMVmxgV0jarYphXHuysERRdEt-w1bhKzZTwVaKA/edit#heading=h.g2m0sr8ujije)
- [ ] Data visualisations - develop support for advanced visualisations for SearchKit data display
- [ ] Emailing results of SearchKits
- [ ] Embed on remote site - check inlay (https://lab.civicrm.org/extensions/inlay)
- [ ] [Recreate core screens as Search Displays](https://lab.civicrm.org/dev/core/-/issues/3912)https://lab.civicrm.org/dev/core/-/issues/3769Change the default font family to sans-serif in print.css2024-03-19T20:19:43ZwmortadaChange the default font family to sans-serif in print.cssThe font family is set as `DejaVu Sans` but the fallback is `serif` in `print.css`. Surely this should be `sans-serif`?
See https://github.com/civicrm/civicrm-core/blob/master/css/print.css#L23
```
#crm-container {
overflow: visible ...The font family is set as `DejaVu Sans` but the fallback is `serif` in `print.css`. Surely this should be `sans-serif`?
See https://github.com/civicrm/civicrm-core/blob/master/css/print.css#L23
```
#crm-container {
overflow: visible !important;
font-family: DejaVu Sans, serif;
margin: 0px 10px 0px 10px;
}
```https://lab.civicrm.org/dev/core/-/issues/3789Site language set back to English after update to 5.51.02023-06-16T02:58:58Zpal_urSite language set back to English after update to 5.51.0Overview
----------------------------------------
I've got a CiviCRM site running on Drupal7, with Hungarian language settings.
There are two available languages, English and Hungarian.
I updated my CiviCRM 5.50.3 to 5.51.0, than to ...Overview
----------------------------------------
I've got a CiviCRM site running on Drupal7, with Hungarian language settings.
There are two available languages, English and Hungarian.
I updated my CiviCRM 5.50.3 to 5.51.0, than to 5.52.0, and I lost my site language: it's set back to English, and I'm not able to set back to Hungarian. My translation file is in /sites/all/modules/civicrm/l10n/hu_HU, and the site language is set to hungarian, and in the `civicrm_setting` table there are the following values: `contact_default_language`: `s:5:"hu_HU";`, `lcMessages` `s:5:"hu_HU";`, `uiLanguages` `a:2:{i:0;s:5:"en_US";i:1;s:5:"hu_HU";}`, `format_locale` `s:5:"hu_HU";`.
Reproduction steps
----------------------------------------
Site works with English language.
Current behaviour
----------------------------------------
Expected behaviour
----------------------------------------
Because of the settings I'd like to use my site in Hungarian.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.51.0/5.52.0_
* __PHP:__ _PHP 7.4.30 (cli)__
* __CMS:__ Drupal 7.91_
* __Database:__ _10.3.34-MariaDB-0+deb10u1 - Debian 10_
* __Web Server:__ _Apache/2.4.38 (Debian)_
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/3807Download invoice button on contribution fails to attach it to activity on win...2024-03-28T00:43:35ZDaveDDownload invoice button on contribution fails to attach it to activity on windowsEverything else works, but the attachment doesn't get attached to the activity.
In https://github.com/civicrm/civicrm-core/blob/2aaf9d423288b5acb322379eb135324f380faca4/CRM/Core/BAO/File.php#L117-L130, it uses DIRECTORY_SEPARATOR when i...Everything else works, but the attachment doesn't get attached to the activity.
In https://github.com/civicrm/civicrm-core/blob/2aaf9d423288b5acb322379eb135324f380faca4/CRM/Core/BAO/File.php#L117-L130, it uses DIRECTORY_SEPARATOR when it should just always use '/', and in the one place it does need to use DIRECTORY_SEPARATOR it only checks '/':
```php
$path = explode('/', $data); // <--- THIS IS WRONG
$filename = $path[count($path) - 1];
// rename this file to go into the secure directory
if ($entitySubtype) {
$directoryName = $config->customFileUploadDir . $entitySubtype . DIRECTORY_SEPARATOR . $entityID;
}
else {
$directoryName = $config->customFileUploadDir;
}
CRM_Utils_File::createDir($directoryName);
if (!rename($data, $directoryName . DIRECTORY_SEPARATOR . $filename)) {
```https://lab.civicrm.org/dev/core/-/issues/3808[ext:message_admin] Available preview choices should be based on the site's c...2024-03-26T18:25:12ZDaveD[ext:message_admin] Available preview choices should be based on the site's configIt has fixed choices. And formatting like the comma/dot separators it uses may or may not make sense for the selected preview.It has fixed choices. And formatting like the comma/dot separators it uses may or may not make sense for the selected preview.https://lab.civicrm.org/dev/core/-/issues/3809[ext:message_admin] It's not obvious there's a preview function, and even whe...2024-03-28T00:43:21ZDaveD[ext:message_admin] It's not obvious there's a preview function, and even when told you might have trouble finding itIt should be a button on the message template edit page, down with the other buttons, where preview buttons normally are.It should be a button on the message template edit page, down with the other buttons, where preview buttons normally are.https://lab.civicrm.org/dev/core/-/issues/3813Performance issue on Redis with arrays2022-11-15T04:01:55ZeileenPerformance issue on Redis with arraysBoth WMF and AUG have achieved a significant performance improvement with [this patch](https://github.com/civicrm/civicrm-core/pull/24156) which removes unnecessary calls to the underlying cache provider. However, in both cases we are us...Both WMF and AUG have achieved a significant performance improvement with [this patch](https://github.com/civicrm/civicrm-core/pull/24156) which removes unnecessary calls to the underlying cache provider. However, in both cases we are using `Redis` and `Redis` itself is performing well.
I'm left with the conclusion that the issue is the way in which the php layer is handling arrays when using `redis`.
On digging we are specifically calling [`serialize`](https://github.com/civicrm/civicrm-core/blob/53a48c5aacea52dd6507a45e111a00ccbed0fdaa/CRM/Utils/Cache/Redis.php#L116) and [`unserialize`](https://github.com/civicrm/civicrm-core/blob/53a48c5aacea52dd6507a45e111a00ccbed0fdaa/CRM/Utils/Cache/Redis.php#L138) in `CRM_Utils_Cache_Redis`.
Discussion on the interweb thingee suggests that `json_encode` & `json_decode` *may* be faster but that is a moving target over php versions .... https://stackoverflow.com/questions/22718903/storing-an-array-of-data-using-redis-from-laravel
Another option appears to be the `h` methods within the `Redis php` class - I note in our `PrevNextRedisCache` implementation we do use some of these hash specific methods and I wonder if using them here would help
https://stackoverflow.com/questions/22718903/storing-an-array-of-data-using-redis-from-laravelhttps://lab.civicrm.org/dev/core/-/issues/3816Saving event intermittently throws 500 error2023-02-08T21:37:50ZBobSSaving event intermittently throws 500 errorOverview
----------------------------------------
Saving an event intermittently results in a hang with:
* Greyed out tab contents
* Spinning cursor
* Error in the browser console: "VM6153:1 POST https://dmaster.demo.civicrm.org/civicrm/...Overview
----------------------------------------
Saving an event intermittently results in a hang with:
* Greyed out tab contents
* Spinning cursor
* Error in the browser console: "VM6153:1 POST https://dmaster.demo.civicrm.org/civicrm/ajax/inline?class_name=CRM_UF_Form_Inline_PreviewById&id=14&snippet=json&crmAngularModules=crmApp,crmProfileUtils,crmResource,crmUi,crmUtil,ngRoute,ngSanitize,volunteer 500 (Internal Server Error)"
Upon a page reload following a hang, the following popup is displayed:
```We can't load the requested web page. This page requires cookies to be enabled in your browser settings. Please check this setting and enable cookies (if they are not enabled). Then try again. If this error persists, contact the site administrator for assistance.<br /><br />Site Administrators: This error may indicate that users are accessing this page using a domain or URL other than the configured Base URL. EXAMPLE: Base URL is http://example.org, but some users are accessing the page via http://www.example.org or a domain alias like http://myotherexample.org.<br /><br />Error type: Could not find a valid session key.```
Problem confirmed on https://dmaster.demo.civicrm.org.
Reproduction steps
----------------------------------------
1. Go to https://dmaster.demo.civicrm.org
1. Click **Events** | **Manage Events**.
1. **Rain-forest Cup Youth Soccer Tournament**: Click **Configure** | **Online Registration**.
1. Click **Save**
Current behaviour
----------------------------------------
About 50% of the time it will hang as described above.
Oddly, the failures do not seem to be randomly distributed. It seems that it will tend to fail consistently for several minutes, and then to save successfully for several minutes. Or maybe I'm doing something subtly different that I have not noticed which makes the problem appear.
Problem has been observed upon saving various tabs (Info and Settings, Event Location, Online Registration)
Problem has not been observed upon clicking __Save and Done__.
__Stress Testing__
After a page load and successful save, it appears that every subsequent save will be successful. To stress test, therefore, the following sequence must be repeated:
1. Refresh page
1. Save
__GET/POST Requests__
When saving the Online Registration tab, the following sequence is observed in the browser's Network tab for a successful save:
1. POST https://dmaster.demo.civicrm.org/civicrm/event/manage/registration?action=update&id=3&component=event&qfKey=CRMEventFormManageEventRegistrationlkkd3ym1nsgogsggw8scokgo8kw04w0cw00wsg8csgwkc4gcw_4298&snippet=json&crmAngularModules=crmApp,crmProfileUtils,crmResource,crmUi,crmUtil,ngRoute,ngSanitize,volunteer
1. GET https://dmaster.demo.civicrm.org/civicrm/event/manage/registration?reset=1&action=update&id=3&component=event&qfKey=CRMEventFormManageEventRegistrationlkkd3ym1nsgogsggw8scokgo8kw04w0cw00wsg8csgwkc4gcw_4298&snippet=json&crmAngularModules=crmApp,crmProfileUtils,crmResource,crmUi,crmUtil,ngRoute,ngSanitize,volunteer
1. GET https://dmaster.demo.civicrm.org/civicrm/ajax/inline?class_name=CRM_UF_Form_Inline_PreviewById&id=12&snippet=json&crmAngularModules=crmApp,crmProfileUtils,crmResource,crmUi,crmUtil,ngRoute,ngSanitize,volunteer
When the save fails, however, only the third request is observed, and it throws a 500 error.
__Civi Log__
```
Aug 20 14:07:08 [error]
$Fatal Error Details = array:3 [
"message" => "We can't load the requested web page. This page requires cookies to be enabled in your browser settings. Please check this setting and enable cookies (if they are not enabled). Then try again. If this error persists, contact the site administrator for assistance.<br /><br />Site Administrators: This error may indicate that users are accessing this page using a domain or URL other than the configured Base URL. EXAMPLE: Base URL is http://example.org, but some users are accessing the page via http://www.example.org or a domain alias like http://myotherexample.org.<br /><br />Error type: Could not find a valid session key."
"code" => null
"exception" => CRM_Core_Exception {#1777
-errorData: array:1 [
"error_code" => 0
]
#cause: null
-_trace: null
#message: "We can't load the requested web page. This page requires cookies to be enabled in your browser settings. Please check this setting and enable cookies (if they are not enabled). Then try again. If this error persists, contact the site administrator for assistance.<br /><br />Site Administrators: This error may indicate that users are accessing this page using a domain or URL other than the configured Base URL. EXAMPLE: Base URL is http://example.org, but some users are accessing the page via http://www.example.org or a domain alias like http://myotherexample.org.<br /><br />Error type: Could not find a valid session key."
#code: 0
#file: "/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Controller.php"
#line: 861
trace: {
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Controller.php:861 {
› $msg = ts("We can't load the requested web page. This page requires cookies to be enabled in your browser settings. Please check this setting and enable cookies (if they are not enabled). Then try again. If this error persists, contact the site administrator for assistance.") . '<br /><br />' . ts('Site Administrators: This error may indicate that users are accessing this page using a domain or URL other than the configured Base URL. EXAMPLE: Base URL is http://example.org, but some users are accessing the page via http://www.example.org or a domain alias like http://myotherexample.org.') . '<br /><br />' . ts('Error type: Could not find a valid session key.');
› throw new CRM_Core_Exception($msg);
› }
}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Controller.php:856 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Controller.php:316 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Controller.php:193 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Controller/Simple.php:49 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Utils/Wrapper.php:62 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Page/AJAX.php:63 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php:285 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php:69 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/drupal/civicrm.module:471 { …}
/var/www/clients/client1/web3/web/drupal/includes/menu.inc:527 { …}
/var/www/clients/client1/web3/web/drupal/index.php:197 { …}
}
}
]
Aug 20 14:07:08 [debug] $backTrace = #0 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Error.php(441): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(CRM_Core_Exception))
#2 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/drupal/civicrm.module(471): CRM_Core_Invoke::invoke((Array:3))
#3 /var/www/clients/client1/web3/web/drupal/includes/menu.inc(527): civicrm_invoke("ajax", "inline")
#4 /var/www/clients/client1/web3/web/drupal/index.php(197): menu_execute_active_handler()
#5 {main}
```
__Possibly Related__
Upon loading any of the event tabs, the following error is always displayed in the console:
```
angular.js:15697 TypeError: Cannot read properties of undefined (reading 'id')
at angular-modules.c3b61f5213a83292c272ff9114e7a62a.js?rgx685:2098:66
at m.$digest (angular.js:19270:23)
at angular.js:19562:15
at Yg.completeTask (angular.js:21403:7)
at angular.js:6879:7
```
Expected behaviour
----------------------------------------
The Save should complete without error.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _Chrome 104.0.5112.101_
* __CiviCRM:__ _5.52_, _5.54.alpha1_
* __PHP:__ _7.4_
* __CMS:__ _Drupal 7.91_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._seamusleeseamuslee