Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-09-06T10:36:42Zhttps://lab.civicrm.org/dev/joomla/-/issues/53[Joomla 4.0] Mosaico build screen clipped (maybe a Mosaico issue)2023-09-06T10:36:42Znicol[Joomla 4.0] Mosaico build screen clipped (maybe a Mosaico issue)Mosaico is loaded in an iFrame, with a fixed position that is lost behind the Joomla UI:
![image](/uploads/752b2ea5a9ccc68e0fe8daedd0e023fe/image.png)
something like
`#crm-mosaico {
left: 288px;
top: 66px;
width: calc(100vw - 288px);...Mosaico is loaded in an iFrame, with a fixed position that is lost behind the Joomla UI:
![image](/uploads/752b2ea5a9ccc68e0fe8daedd0e023fe/image.png)
something like
`#crm-mosaico {
left: 288px;
top: 66px;
width: calc(100vw - 288px);
height: calc(100vh - 66px);
}`
would work if the Joomla sidebar is extended and
`#crm-mosaico {
left: 48px;
width: calc(100vw - 48px);
}`
if it isn't, but there's no helpful Joomla classes to differentiate between these states via a parent selector. Even if that was fixed, to avoid having to force this with `!important`, may be better to address this in Mosaico's absolute positioning script..https://lab.civicrm.org/dev/core/-/issues/4537Event registration breaks when CiviContribute isn't enabled2023-09-02T05:12:02ZJonGoldEvent registration breaks when CiviContribute isn't enabledThis seems closely related to #4492. I wonder where else this might arise?
```
Error: Class "Civi\Api4\LineItem" not found in CRM_Event_WorkflowMessage_EventOnlineReceipt->setParticipantID() (line 97 of /var/www/reg.wiscience.wisc.edu/...This seems closely related to #4492. I wonder where else this might arise?
```
Error: Class "Civi\Api4\LineItem" not found in CRM_Event_WorkflowMessage_EventOnlineReceipt->setParticipantID() (line 97 of /var/www/reg.wiscience.wisc.edu/web/sites/all/modules/civicrm/CRM/Event/WorkflowMessage/ParticipantTrait.php).
```5.66.0https://lab.civicrm.org/dev/core/-/issues/4532Add sort for country/state fields in reports2023-08-24T15:17:42ZyashodhaAdd sort for country/state fields in reportsAdd sort for country/state fields in reportsAdd sort for country/state fields in reports5.66.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4531Afform - Email link doesn't render on individual emails for contacts with pre...2023-09-02T05:12:01ZtottenAfform - Email link doesn't render on individual emails for contacts with preferred localeOverview
----------------------------------------
Afform allows you define email tokens that make quick-links to a form (eg `{afform.afformProfileUrl}`). The token doesn't render in certain contexts.
This issue was identified by @larss...Overview
----------------------------------------
Afform allows you define email tokens that make quick-links to a form (eg `{afform.afformProfileUrl}`). The token doesn't render in certain contexts.
This issue was identified by @larssg in MM (https://chat.civicrm.org/civicrm/pl/rwsgdztjpfbx5dgcpqkzw6x6se). It appears to be a regression circa 5.54. It does not affect CiviMail.
Reproduction steps
----------------------------------------
1. Setup a D7 site. (D8+ and BD should have the same bug.)
1. Find or create an afform. Ensure that it has a URL and email token.
1. Find or create a contact. Ensure that **Preferred Language** is configured.
1. View the contact (`civicrm/contact/view`). Use **Actions: Send Email** to send a message with the token (e.g. `{afform.afformProfileUrl}`)
1. Check the email
Current behavior
----------------------------------------
In the resulting email, the token appears blank.
Expected behavior
----------------------------------------
The token shows a URL/hyperlink.
Comments
----------------------------------------
Under the hood, here are some key ingredients:
* afform registers for token events via [afform_civicrm_config()](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/core/afform.php#L63-L67), which includes a static-guard against re-registration.
* 5.54 included various updates with an aim toward supporting localized email. Consequently, while sending the email, it calls `CRM_Utils_System_*::setUFLocale()`.
* On D7/D8+/BD, `setUFLocale()` calls this:
```php
// Config must be re-initialized to reset the base URL
// otherwise links will have the wrong language prefix/domain.
$config = CRM_Core_Config::singleton();
$config->free();
```
* Consequently, the next time anything calls `CRM_Core_Config::singleton()`, it will reboot the container. This effectively removes any listeners. For afform, the listeners are lost.https://lab.civicrm.org/dev/core/-/issues/4530Search forms - email validation smashes usability2023-09-02T05:12:01ZeileenSearch forms - email validation smashes usabilityWe hit this recently in QF search forms but now I'm seeing it in search forms based on search kit - the email validation means I can't search for an email
@colemanw
![image](/uploads/b4faf0bde8b64ef7eef3d281a907aac5/image.png)We hit this recently in QF search forms but now I'm seeing it in search forms based on search kit - the email validation means I can't search for an email
@colemanw
![image](/uploads/b4faf0bde8b64ef7eef3d281a907aac5/image.png)https://lab.civicrm.org/dev/core/-/issues/4529Loading fails when searching for a group that starts with a number in CiviMail2023-08-23T18:54:15ZbrienneLoading fails when searching for a group that starts with a number in CiviMailOverview
----------------------------------------
Loading of the autocomplete select widget for the *Recipients* field fails within CiviMail if the user searches with a number.
Reproduction steps
---------------------------------------...Overview
----------------------------------------
Loading of the autocomplete select widget for the *Recipients* field fails within CiviMail if the user searches with a number.
Reproduction steps
----------------------------------------
1. Make sure you have at a mailing group that starts with a number. If not, create one.
1. Go to **Mailings > New Mailing**
1. In the *Recipients* (to include) field, start typing the name of the group that starts with a number
1. Get the error message **Loading Failed**
Current behaviour
----------------------------------------
A user cannot search for recipients within CiviMail if the group starts with a number.
![Selection_028](/uploads/eaae1b1a2724b791a5a9bce8de45f0da/Selection_028.png)
vs.
![Selection_029](/uploads/cc93726a78f637591554ddc6c861d468/Selection_029.png)
Expected behaviour
----------------------------------------
A user should be able to search for recipients regardless of if a group starts with a number, letter, or other character.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.64.1
Dev notes
----------------------------------------
PHP TypeError:
```
TypeError: Return value of Civi\Api4\Query\SqlField::render() must be of the type string, null returned in Civi\Api4\Query\SqlField->render() (line 34 of Civi/Api4/Query/SqlField.php).
```
Call stack
```
Civi\Api4\Query\SqlField->render (Civi/Api4/Query/SqlField.php:34)
Civi\Api4\Query\Api4SelectQuery->buildSelectClause (Civi/Api4/Query/Api4SelectQuery.php:201)
Civi\Api4\Query\Api4Query->getSql (Civi/Api4/Query/Api4Query.php:78)
Civi\Api4\Query\Api4Query->getResults (Civi/Api4/Query/Api4Query.php:89)
Civi\Api4\Query\Api4SelectQuery->run (Civi/Api4/Query/Api4SelectQuery.php:101)
Civi\Api4\Generic\DAOGetAction->getObjects (Civi/Api4/Generic/DAOGetAction.php:107)
Civi\Api4\Generic\DAOGetAction->_run (Civi/Api4/Generic/DAOGetAction.php:94)
Civi\Api4\Provider\ActionObjectProvider->invoke (Civi/Api4/Provider/ActionObjectProvider.php:72)
Civi\API\Kernel->runRequest (Civi/API/Kernel.php:158)
Civi\Api4\Generic\AbstractAction->execute (Civi/Api4/Generic/AbstractAction.php:249)
civicrm_api4 (api/api.php:85)
Civi\Api4\Service\Spec\Provider\SearchSegmentExtraFieldProvider::getSets (ext/search_kit/Civi/Api4/Service/Spec/Provider/SearchSegmentExtraFieldProvider.php:55)
Civi\Api4\Service\Spec\Provider\SearchSegmentExtraFieldProvider->modifySpec (ext/search_kit/Civi/Api4/Service/Spec/Provider/SearchSegmentExtraFieldProvider.php:25)
Civi\Api4\Service\Spec\SpecGatherer->getSpec (Civi/Api4/Service/Spec/SpecGatherer.php:70)
Civi\Api4\Generic\DAOGetFieldsAction->getRecords (Civi/Api4/Generic/DAOGetFieldsAction.php:43)
Civi\Api4\Generic\BasicGetFieldsAction->_run (Civi/Api4/Generic/BasicGetFieldsAction.php:97)
Civi\Api4\Provider\ActionObjectProvider->invoke (Civi/Api4/Provider/ActionObjectProvider.php:72)
Civi\API\Kernel->runRequest (Civi/API/Kernel.php:158)
Civi\Api4\Generic\AbstractAction->execute (Civi/Api4/Generic/AbstractAction.php:249)
civicrm_api4 (api/api.php:85)
```https://lab.civicrm.org/dev/wordpress/-/issues/143Plugin compatibility architecture and loss of locale on "Secondary URLs" when...2023-12-06T16:01:59ZhaystackPlugin compatibility architecture and loss of locale on "Secondary URLs" when using PolylangThis issue covers a couple of related matters:
1. A better architecture for providing compatibility with 3rd party plugins
2. Loss of locale on "Secondary URLs" when using Polylang
The first item is necessary in order to implement the ...This issue covers a couple of related matters:
1. A better architecture for providing compatibility with 3rd party plugins
2. Loss of locale on "Secondary URLs" when using Polylang
The first item is necessary in order to implement the second in a reliable fashion. It also has consequences for #133 but I think that @shaneonabike will appreciate the new architecture as a way of better encapsulating WPML support in its own class. Hopefully we can move forward with that issue as well now.
The PR for this issue on CiviCRM-WordPress requires the related PR on CiviCRM-Core. In combination, they solve the following problem:
When Polylang is active, locale is lost on "secondary" or "internal" URLs built by CiviCRM Core. For example, on an Event Info screen (https://example.org/fr/civicrm/event/info/?reset=1&id=3) the "Register" link does not retain the current front-end locale but instead contains no locale information at all (https://example.org/civicrm/event/register/?id=3&reset=1). With the PRs applied, the link becomes https://example.org/fr/civicrm/event/register/?id=3&reset=1 and retains the locale as defined by Polylang.
PR links to follow.haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/4524Tax calculate wrong on Membership signup page2023-12-19T22:19:50ZPradeep Nayakpradpnayak@gmail.comTax calculate wrong on Membership signup pageCiviCRM: 5.64.1
PHP - 8.1
Replicate:
**Financial Account**
1. Tax 1, type=liability, is tax = checked, tax rate= 16%
2. Tax 1, type=liability, is tax = checked, tax rate= 13%
**Financial Type**
1. Assign tax 1 as Sales tax account is ...CiviCRM: 5.64.1
PHP - 8.1
Replicate:
**Financial Account**
1. Tax 1, type=liability, is tax = checked, tax rate= 16%
2. Tax 1, type=liability, is tax = checked, tax rate= 13%
**Financial Type**
1. Assign tax 1 as Sales tax account is to Member dues FT
2. Assign tax 2 as Sales tax account is to Donation FT
**Price Set**
Create a price set to FT = member dues and extends=Membership.
Price fields:
1. Membership, select HTML type, membership type General, amount= 84.48, FT= Member dues
2. Misc, select HTML type, label='Zero', Amount=0, FT=Campaign
3. Donation, Text HTML type, unit price=0.89
Create Online membership page, FT=Member dues and use the price set created above under membership section.
Try doing a online submission
![Screenshot_2023-08-22_at_15.02.05](/uploads/ea2da6a60b5d12483801580b250d4ff3/Screenshot_2023-08-22_at_15.02.05.png)
**Expected Result:**
![Screenshot_2023-08-22_at_15.03.28](/uploads/7fff93e304bc73f6adb312c8a90a828f/Screenshot_2023-08-22_at_15.03.28.png)
**Actual result**
![Screenshot_2023-08-22_at_15.02.49](/uploads/3d3af70ea32b2a5c5bac95cfb5df18c2/Screenshot_2023-08-22_at_15.02.49.png)5.69.0https://lab.civicrm.org/dev/core/-/issues/4521CiviCRM 5.64.1 update does not always enable core extension CiviContribute wh...2023-09-18T23:43:03Zjustinfreeman (Agileware)CiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSODCiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSOD, throwing an error:
`Error: Class 'Civi\Api4\EntityFinancialAccount' not found in CRM_Financial_BAO_FinancialType::getIncomeFinancialType(...CiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSOD, throwing an error:
`Error: Class 'Civi\Api4\EntityFinancialAccount' not found in CRM_Financial_BAO_FinancialType::getIncomeFinancialType() (line 171 of .../civicrm/CRM/Financial/BAO/FinancialType.php).`
OR
`Uncaught Error: Class 'Civi\Api4\PaymentProcessorType' not found`
This is because the **civi_contribute** extension has not been enabled / loaded yet, which is part of a set of core-bundled extensions that map to each CiviCRM component.
This seems to occurs more regularly when an extension update is available for a Payment Processor or other extension which calls on the missing class from CiviContribute.
Can be manually solved by running `cv en civi_contribute` on the CLI. Sometimes the website UI is inaccessible after this error and CLI is only method available to recover.
This error also seems to interrupt the enabling of other core-bundled extensions, eg. CiviReport, CiviMail, CiviEvent etc.
CiviCRM 5.64.1
Agileware ref: CIVICRM-2163https://lab.civicrm.org/dev/joomla/-/issues/52Cannot have a CiviCRM-link menu as default (home) page2024-03-07T23:14:49Zthoni56Cannot have a CiviCRM-link menu as default (home) pageIn Joomla you declare one menu item to be the default "front page" i.e. the one that you get to when no menu is selected, only the web sites base path.
In J3 this also worked for a menu entry that was a CiviCRM-entry, such as Event List...In Joomla you declare one menu item to be the default "front page" i.e. the one that you get to when no menu is selected, only the web sites base path.
In J3 this also worked for a menu entry that was a CiviCRM-entry, such as Event Listing or Mailing List Subscription. (check e.g. https://events.responsive.se which is a J3 site with Event Listing as the default menu entry.)
With J4 this no longer works. When going to the "home page" the menu item is highlighted to indicate that it is active, but there is no output in the content area.
I tried this with a clean J4 and CiviCRM and see the same thing. The underlined "Subscription" indicates that it is the menu entry that is active.The J4 default template Cassiopeia displays breadcrumbs which strangely enough shows "Home" and not "Subscription" (which is the menu entry for CiviCRM Mailing List Subscription form).
This is extra strange because the breadcrumb for the Home menu entry is actually "Home/Home" so the default page Subscription is something in between...
![image.png](/uploads/e82c3a451f5ed6010968e4d25c17d6a5/image.png)Explicitly clicking the "Subscription" menu entry correctly shows the form.
I don't really know enough about Joomlas routing to understand where the problem really is, but I'm starting by reporting it here.https://lab.civicrm.org/dev/core/-/issues/4514AdminUI: Manage ACLs - An ACL mode set to 'Deny' is stored OK but still shows...2023-08-25T08:23:45ZAndy ClarkAdminUI: Manage ACLs - An ACL mode set to 'Deny' is stored OK but still shows on the list of ACLs as 'Allow' (5.64)In 'Manage ACLs' a new mode of 'Allow' or 'Deny' has been added. When you set an ACL to 'Deny' it is correctly stored but in the list of ACLs always shows as 'Allow'.In 'Manage ACLs' a new mode of 'Allow' or 'Deny' has been added. When you set an ACL to 'Deny' it is correctly stored but in the list of ACLs always shows as 'Allow'.seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/4509Search Kit - Links conditional doesn't work with domain_id or domain = curren...2023-08-20T01:19:29ZseamusleeSearch Kit - Links conditional doesn't work with domain_id or domain = current domainWhen creating a menu of links if you have a conditional based on domain_id = current_domain or domain = current_domain the links just get removed because the conditional fails all the timeWhen creating a menu of links if you have a conditional based on domain_id = current_domain or domain = current_domain the links just get removed because the conditional fails all the time5.66.0https://lab.civicrm.org/dev/core/-/issues/4507ctrl.recipients[entityType] is undefined2023-12-20T16:55:15ZStoobctrl.recipients[entityType] is undefinedUpon upgrade to 5.64.0 the Recipients box in CiviMail new mailing (or continue draft) stopped working with this error in js console.
```
TypeError: $element.crmAutocomplete is not a function
Angular 30
jQuery 7
api3 crm.aja...Upon upgrade to 5.64.0 the Recipients box in CiviMail new mailing (or continue draft) stopped working with this error in js console.
```
TypeError: $element.crmAutocomplete is not a function
Angular 30
jQuery 7
api3 crm.ajax.js:120
Angular 14
```
We were using Mosiaco 2.1. Upgrading to 3.2.1691060437 didn't fix the issue.
This bug it affects Traditional and Mosaico mailings equally _**even with Mosaico extension disabled completely**_. So I think the problem is part of CiviMail itself. We are using Drupal 9.5.10, if that matters, and Civi seems functional otherwise.
![recipients1](/uploads/79862d01942c2d7a9edd83423e8ab7c7/recipients1.png)
![recipients2](/uploads/153d826994e70023eb234b3f83716beb/recipients2.png)https://lab.civicrm.org/dev/core/-/issues/4506Composer errors when applying patches2023-08-18T02:07:11ZvrappComposer errors when applying patchesWhen installing a new site with:
**LAMP:**
[res@svr ~]$ cat /proc/version
Linux version 3.10.0-1160.88.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Tue Mar 7 15:41:52 UTC...When installing a new site with:
**LAMP:**
[res@svr ~]$ cat /proc/version
Linux version 3.10.0-1160.88.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Tue Mar 7 15:41:52 UTC 2023
PHP:
PHP Version 8.1.21
Directive Local Value Master Value
allow_url_fopen On On
allow_url_include Off Off
[res@svr ~]$ mysql -V
mysql Ver 14.14 Distrib 5.7.43, for Linux (x86_64) using EditLine wrapper
**Drupal:**
[res@svr d9]$ composer create-project drupal/recommended-project:9.5.1 "../public_html/d9"
…..
Congratulations, you’ve installed the Drupal codebase
from the drupal/recommended-project template!
**CiviCRM:**
Using Composer, all clean until CiviCRM install:
[res@svr d9]$ composer clearcache
Cache directory does not exist (cache-vcs-dir):
Cache directory does not exist (cache-repo-dir):
Cache directory does not exist (cache-files-dir):
Clearing cache (cache-dir): ./.cache/composer
All caches cleared.
[res@svr d9]$ composer config extra.enable-patching true
[res@svr d9]$ composer config minimum-stability dev
[res@svr d9]$ composer require civicrm/civicrm-{core,packages,drupal-8}:'5.64.x-dev'
**getting 12 errors like the 2 examples below:**
1) - Applying patches for adrienrn/php-mimetyper
```
https://patch-diff.githubusercontent.com/raw/adrienrn/php-mimetyper/pull/15.patch (Update gitignore to ensure that sites that manage via git don't miss out on the important db.json file)
Could not apply patch! Skipping. The error was: The "https://patch-diff.githubusercontent.com/raw/adrienrn/php-mimetyper/pull/15.patch" file could not be downloaded: allow_url_fopen must be enabled in php.ini (https:// wrapper is disabled in the server configuration by allow_url_fopen=0
failed to open stream: no suitable wrapper could be found)
```
2) - Applying patches for zetacomponents/mail
```
https://raw.githubusercontent.com/civicrm/civicrm-core/9d93748a36c7c5d44422911db1c98fb2f7067b34/tools/scripts/composer/patches/civicrm-custom-patches-zetacompoents-mail.patch (CiviCRM Custom Patches for ZetaCompoents mail)
Could not apply patch! Skipping. The error was: The "https://raw.githubusercontent.com/civicrm/civicrm-core/9d93748a36c7c5d44422911db1c98fb2f7067b34/tools/scripts/composer/patches/civicrm-custom-patches-zetacompoents-mail.patch" file could not be downloaded: allow_url_fopen must be enabled in php.ini (https:// wrapper is disabled in the server configuration by allow_url_fopen=0
failed to open stream: no suitable wrapper could be found)
```
We have checked and rechecked the **allow_url_fopen** and can be seen from the php.ini and the reported php parameters, this setting is **On**.
**php.ini:**
allow_url_fopen = On
display_errors = Off
enable_dl = Off
file_uploads = On
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
memory_limit = 64M
post_max_size = 8M
session.gc_maxlifetime = 1440
session.save_path = "/var/cpanel/php/sessions/ea-php81"
upload_max_filesize = 2M
zlib.output_compression = Off
I would like to have a clean composer based install for this new site so we can avoid sins of the past sites which were not maintained
via composer. I am not very familiar with composer but if there are things I can do to debug and provide feedback to the code base, I am happy to help.
Thankshttps://lab.civicrm.org/dev/core/-/issues/4501Redis performance issue on delete contact2023-09-23T05:08:34ZeileenRedis performance issue on delete contactWe have a process where we merge contacts and then delete the deleted contacts after a period of time.
However, we have more or less never run the delete deleted contacts script because it is too slow. I dug into it today and found that...We have a process where we merge contacts and then delete the deleted contacts after a period of time.
However, we have more or less never run the delete deleted contacts script because it is too slow. I dug into it today and found that
- on staging it takes 15 seconds to delete 500 contacts
- on production it takes 6-10 minutes to delete 500 contacts
I've spent most of the day digging into why & determined that the queries run are identical & timings are similary. However, on production each time this line of code runs ` Civi::service('prevnext')->deleteItem($id);` it takes a bit over 1 second. This is not the case on staging because there are no users populating the prevnext cache with searches. Hence I have diagnosed that the problem is having users & the solution is to lock their accounts.
More specifically the issue is that the code is going through all the Redis keys to remove the contact - which seems to be inefficient.
![image](/uploads/701ae2d41d47d0eae49ee118f80d4dc4/image.png)
I did wonder if a quick-fix would be to only call `deleteItem` if the contact is not already deleted (which they are in our use case) - I would need to change [the find to fetch here](https://github.com/civicrm/civicrm-core/blob/aef17937a6d1bf00d2ca446bf3c5fc81644b3b92/CRM/Contact/BAO/Contact.php#L907-L911) I think...
Alternatively there is probably some option around queuing the cache clear to happen at the end. However, I think that 1 second + delay is actually not great for users either - e.g when deduping a bunch of contacts than having each form submit take that bit longer would add up.
We are on the cusp of getting `coworker` going so pushing something to a queue to clear out caches might be an option.https://lab.civicrm.org/dev/core/-/issues/4494Undefined $line and $value when sending offline email receipt2023-09-02T05:11:57ZDaveDUndefined $line and $value when sending offline email receiptLooks like some code was moved around and these vars don't make sense out of loop context: https://github.com/civicrm/civicrm-core/blob/effdba1ef120ca88b270606a0e28db5304e3e621/CRM/Event/Form/Participant.php#L1353Looks like some code was moved around and these vars don't make sense out of loop context: https://github.com/civicrm/civicrm-core/blob/effdba1ef120ca88b270606a0e28db5304e3e621/CRM/Event/Form/Participant.php#L13535.64.1https://lab.civicrm.org/dev/core/-/issues/4492(regression) Add/Edit Scheduled Reminders page does not load if CiviContribut...2023-09-02T05:11:57ZJonGold(regression) Add/Edit Scheduled Reminders page does not load if CiviContribute is disabledWorks on 5.63, not on 5.64. Hard to bisect because `getDefaultEntity()` becomes a required method somewhere along the line.
Easy to replicate:
* Disable CiviContribute.
* Try to create a scheduled reminder.
You'll get this error:
```...Works on 5.63, not on 5.64. Hard to bisect because `getDefaultEntity()` becomes a required method somewhere along the line.
Easy to replicate:
* Disable CiviContribute.
* Try to create a scheduled reminder.
You'll get this error:
```
Error: Class "Civi\Api4\ContributionRecur" not found in CRM_Contribute_Tokens->getRelatedTokens() (line 59 of /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Contribute/Tokens.php).
```
Seems related to #4123 (pinging @seamuslee) but that was merged in 5.63 and it seems fine in 5.63.
I'd throw a conditional into `CRM_Contribute_Tokens->getRelatedTokens()` to fix this but given all the work on moving to extensions, I suspect this is a deeper issue that needs looking at.https://lab.civicrm.org/dev/backdrop/-/issues/80global $language should be an object, not a string2023-08-15T00:45:48ZRobert J. Langglobal $language should be an object, not a stringIn file civicrm/CRM/Utils/System/Backdrop.php, in function `setUFLocale()`, the global variables `$language` is set this way:
```
global $language;
$langcode = substr($civicrm_language, 0, 2);
$languages = language_list(FAL...In file civicrm/CRM/Utils/System/Backdrop.php, in function `setUFLocale()`, the global variables `$language` is set this way:
```
global $language;
$langcode = substr($civicrm_language, 0, 2);
$languages = language_list(FALSE, TRUE);
if (isset($languages[$langcode])) {
$language = $languages[$langcode];
...
```
Per https://docs.backdropcms.org/api/backdrop/core%21includes%21bootstrap.inc/function/language_list/1, the call `language_list(FALSE, TRUE)` returns a list whose values are strings, not objects. (For example, "English".)
However, Backdrop CMS expects `$language` to be an object, as can be seen in numerous places, for example, function `entity_get_info()`:
```
function entity_get_info($entity_type = NULL) {
global $language;
// Use the advanced backdrop_static() pattern, since this is called very often.
static $backdrop_static_fast;
if (!isset($backdrop_static_fast)) {
$backdrop_static_fast['entity_info'] = &backdrop_static(__FUNCTION__);
}
$entity_info = &$backdrop_static_fast['entity_info'];
// hook_entity_info() includes translated strings, so each language is cached
// separately.
$langcode = $language->langcode;
...
```
So whenever a CiviCRM page calls a function that uses one of these, it puts one (or a slew) of bad index warnings into the dblog, like this:
Notice: Trying to get property 'langcode' of non-object in entity_get_info() (line 331 of /mysite/core/modules/entity/entity.module).
The solution is to replace the call to `language_list()` with
```
$languages = language_list();
```
This fixes the issue and eliminates the dblog warnings.5.66.0https://lab.civicrm.org/dev/core/-/issues/4487Contribution pages with extra URL parameters lead to incorrect AJAX URL const...2023-08-10T14:20:50ZsebalisContribution pages with extra URL parameters lead to incorrect AJAX URL constructed in buildPaymentBlock – users cannot proceed to payHi,
I encountered an error while building an Engish version of a contribution page on a system that mostly operates in German. While entering translated texts for all elements, I was told that some elements (button captions, the “total”...Hi,
I encountered an error while building an Engish version of a contribution page on a system that mostly operates in German. While entering translated texts for all elements, I was told that some elements (button captions, the “total” text) cannot be configured in the contribution page or the profiles and price sets it includes (for all of which I built translated copies). Instead, they are supplied by core itself so we need to signal to core that they should be produced in English, too.
By default, the language for these elements seems to be determined by the browser language, but I was interested in overriding this and was advised (by @Detlev) that I could add a (Drupal-specific) GET parameter `language=en` to the URL for that purpose. This does work – up to the point where users want to choose their payment options.
My contribution page (on a Drupal 9 system) has a choice between the PayPal and SEPA processors. When users click the respective radio button, an AJAX request is issued to a URL like
`<host>/civicrm/payment/form?formName=Main&is_back_office=&id=14&pre_profile_id=78&processor_id=&language=en3&payment_instrument_id=undefined¤cy=EUR&snippet=json`
Notice that the value for `language` has been extended from `en` to `en3` and the URL parameter for processor_id is empty. This leads to a popup with a complaint about a network error, and users cannot proceed. Inspecting the communication reveals that the AJAX request returns a 500 status, and the Civi log contains information about the empty value for `processor_id` being the problem.
It turns out that the page has some inline JavaScript code that tries to build the processor ID into the AJAX URL in the `buildPaymentBlock` function. It does this by concatenating the parameter `type` to a partial URL that itself is produced using the crmURL smarty tag. On my payment page, the offending line was this:
```
var dataUrl = "/civicrm/payment/form?formName=Main&is_back_office=&id=14&pre_profile_id=78&processor_id=&language=en" + type;
```
This is rendered by the following line in `templates/CRM/common/paymentBlock.tpl`:
```
var dataUrl = "{crmURL p='civicrm/payment/form' h=0 q="formName=`$form.formName``$urlPathVar``$isBackOfficePathVar``$profilePathVar``$contributionPageID``$preProfileID`processor_id="}" + type;
```
It is obviously assumed that the string produced by crmURL ends with `processor_id=`. However, if extra parameters such as `language=en` are present, these end up at the end of the string produced by crmURL, although the parameters in the call to the Smarty tag do not indicate this. Some further lines in the code add other parameters, leading to the full list of parameters given above. But this line is where the problem is created. The line was executed with `type` set to 3 (the ID of the SEPA processor in my setup) and this is how the `language` value became `en3` and `processor_id` remained empty.
I am going to submit a pull request with a solution with this issue. Since we apparently cannot know where `type` should be inserted, the solution had to involve some kind of templating instead of string concatenation. I would have preferred some templating function provided by one of the JavaScript libraries that are already included on the page. The only candidate library I found was Lodash which provides `CRM._.template`. The syntax to use would have been `<%= type %>`, but that gets URL-escaped by the Smarty tag. Correcting this would become messy, so I resorted to a hand-crafted call to String.replace using `__type__` as the placeholder, in the hope that there is no real risk of this string appearing somewhere else in `dataURL` by accident. Edit: I have made the replacement more specific in a second commit, so the risk of it applying in the wrong place should now be vanishingly small.
I hope that this is an acceptable solution. The problem seems generic enough to affect other people too. I encountered and patched this on an old system (5.58.1, there are issues that prevent us from immediately updating), but the line in `templates/CRM/common/paymentBlock.tpl` is unchanged in the current master branch and I assume that the way the crmURL Smarty tag works hasn’t changed either.https://lab.civicrm.org/dev/core/-/issues/4486Cannot change membership price set on contribution pages2023-08-17T21:36:53ZbrienneCannot change membership price set on contribution pagesOverview
----------------------------------------
On the Membership tab of a Contribution page, a user cannot successfully change the Membership Price Set after the initial configuration of the page.
Reproduction steps
-----------------...Overview
----------------------------------------
On the Membership tab of a Contribution page, a user cannot successfully change the Membership Price Set after the initial configuration of the page.
Reproduction steps
----------------------------------------
1. Go to **Memberships > Manage Price Sets** -> Create two price sets, each for memberships
1. Go to **Contributions > Manage Contribution Pages** -> Either create a new page, or if using a civibuild site you can use the pre-built Membership page
1. Click on the *Amounts* tab -> make sure *Contribution Amounts section enabled?* is unchecked
1. Click on the *Memberships* tab ->Set the *Membership Price Set* to your first Price Set
1. Click **Save**
1. Change the *Membership Price Set* to your second Price Set
1. Click **Save**
1. An error message will be displayed and the second price set will not have been saved as the selection:
Current behaviour
----------------------------------------
A user cannot switch the options for the *Membership Price Set* field, and instead get the follow error, despite that the *Amounts* tab is configured correctly (
```
You cannot enable both Membership Signup and a Contribution Price Set on the same online contribution page.
```
Expected behaviour
----------------------------------------
A user should be able to switch the options for the Membership Price Set without error.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.66.alpha1
Comments
----------------------------------------
This issue is being caused by a comparison value problem on line 249 in CRM/Member/Form/MembershipBlock.php. `getFieldValue()` is returning a string padded with non printable characters, and the following `if` statement is trying to compare that to a string without those additional characters, so the two values are determined to be unequal and this error is thrown.
I have a patch on GitHub to resolve this: [#27030](https://github.com/civicrm/civicrm-core/pull/27030)5.64.1