Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-12-19T06:34:36Zhttps://lab.civicrm.org/dev/wordpress/-/issues/137" is not of type String" when activating, deactivating, installing or uninsta...2022-12-19T06:34:36Zcbpq" is not of type String" when activating, deactivating, installing or uninstalling a pluginI recently migrated a CiviCRM instance from Drupal to WordPress. CiviCRM is mostly functional, but I have multiple issues, namely with payment processors. The following error may be unrelated, but at this point I'm at a loss for what mig...I recently migrated a CiviCRM instance from Drupal to WordPress. CiviCRM is mostly functional, but I have multiple issues, namely with payment processors. The following error may be unrelated, but at this point I'm at a loss for what might be going wrong, so I thought I would bring it up.
- CiviCRM version 5.53
- WordPress version 6.1.1
Whenever I activate, deactivate, install or uninstall a plugin, the action is successful, but I get the following error:
```
Dec 12 17:09:41 [error]
$Fatal Error Details = array:3 [
"message" => " is not of type String"
"code" => null
"exception" => CRM_Core_Exception {#15941
-errorData: array:1 [
"error_code" => 0
]
#cause: null
-_trace: null
#message: " is not of type String"
#code: 0
#file: "/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php"
#line: 1769
trace: {
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php:1769 {
› elseif ($abort) {
› throw new CRM_Core_Exception("{$item[0]} is not of type {$item[1]}");
› }
}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php:1619 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/CustomOption.php:238 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/OptionValue.php:145 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/OptionValue.php:34 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/Traits/DAOActionTrait.php:170 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/Traits/DAOActionTrait.php:141 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/DAOUpdateAction.php:31 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractUpdateAction.php:93 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Provider/ActionObjectProvider.php:69 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php:149 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php:234 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/api/api.php:85 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php:257 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php:144 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php:112 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:417 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Extension/Manager.php:425 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Admin/Form/Extensions.php:197 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php:573 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/StateMachine.php:144 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Next.php:43 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php:203 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php:103 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php:355 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Page/Basic.php:334 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Page/Basic.php:140 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Admin/Page/Extensions.php:105 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:319 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:69 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:36 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm.php:1199 { …}
/home/SITE/public_html/wp-includes/class-wp-hook.php:308 { …}
/home/SITE/public_html/wp-includes/class-wp-hook.php:332 { …}
/home/SITE/public_html/wp-includes/plugin.php:517 { …}
/home/SITE/public_html/wp-admin/admin.php:259 { …}
}
}
]
Dec 12 17:09:41 [debug] $backTrace = #0 /home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(441): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(CRM_Core_Exception))
#2 /home/SITE/public_html/wp-content/plugins/civicrm/civicrm.php(1199): CRM_Core_Invoke::invoke((Array:3))
#3 /home/SITE/public_html/wp-includes/class-wp-hook.php(308): CiviCRM_For_WordPress->invoke("")
#4 /home/SITE/public_html/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters("", (Array:1))
#5 /home/SITE/public_html/wp-includes/plugin.php(517): WP_Hook->do_action((Array:1))
#6 /home/SITE/public_html/wp-admin/admin.php(259): do_action("toplevel_page_CiviCRM")
#7 {main}
```
It may be worth noting that extension updates fail as well, although the error code is "DB Error: unknown" so I assume it is something else. Sorry for the confusion, I'm really not sure what to do with these issues and if they are related.https://lab.civicrm.org/dev/core/-/issues/1510"_[custom field id number]" suffix is causing issues2020-01-10T13:06:15Zndavis"_[custom field id number]" suffix is causing issuesThis custom field id number changes between environments requiring a lookup algorithm to get the correct field name when writing code.
Why add this ID at all? Developers should be entrusted to name their custom fields the way they see f...This custom field id number changes between environments requiring a lookup algorithm to get the correct field name when writing code.
Why add this ID at all? Developers should be entrusted to name their custom fields the way they see fit. If this causes a name collision that's on the developer. It's not the project's responsibility to manage custom field names.
At the most you should force a "custom_" prefix or something similar. Forcing an _[custom field id number] suffix causes more problems than it solves, at least for those of us that don't develop on our production server since these ids change from one environment to the next, depending on what order features get implemented by the organizational development team. _PLEASE_ fix this. It makes custom fields nearly unusable for some organizations.https://lab.civicrm.org/dev/core/-/issues/760"Access denied" when updating a recurring contribution2023-05-01T05:03:21Zken"Access denied" when updating a recurring contributionIn 5.10.4, when I make a recurring contribution, the receipt sent to me includes a link to update the recurring contribution.
As an anonymous user, when I click on that link, I get an access denied message ("Ensure you are still logged ...In 5.10.4, when I make a recurring contribution, the receipt sent to me includes a link to update the recurring contribution.
As an anonymous user, when I click on that link, I get an access denied message ("Ensure you are still logged in and have permission to access this feature"). Sometimes this prevents me updating the contribution (the form is read only) and other times I can edit it.
The URL in the email is https://example.com/civicrm/contribute/updaterecur?reset=1&coid=xxxxx&cs=xxxxxxxxxxxxx_xxxxxxx_inf
The URL which throws the 403 is https://example.com/civicrm/custom?type=ContributionRecur&entityID=xxx&qf=xxxxxx_xxxx&action=2&cgcount=1&snippet=jsonhttps://lab.civicrm.org/dev/backdrop/-/issues/3"Actions > Create User Record" is not working correctly2022-08-18T14:33:52Zlaryn"Actions > Create User Record" is not working correctlyWhen trying to use the "Actions" button menu on a contact screen to "Create User Record", the form that is presented seems to create the user successfully, but then create a new/separate CiviCRM contact for that email address which is co...When trying to use the "Actions" button menu on a contact screen to "Create User Record", the form that is presented seems to create the user successfully, but then create a new/separate CiviCRM contact for that email address which is connected to the new Backdrop user. It then tries to link the new user to the contact that you are working on and clicked the button from, which causes a fatal error since that Backdrop user is already linked in the `uf_match` table. Once you get out of the fatal error screen, you are left with the additional empty contact (email address linked to Backdrop user) and the original contact which is still not linked to any user.
![Screen_Shot_2021-10-22_at_2.42.13_PM](/uploads/ca2edea00baae102c11c540fc1a2e3c2/Screen_Shot_2021-10-22_at_2.42.13_PM.jpg)
> Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
DB Error: already existshttps://lab.civicrm.org/dev/core/-/issues/4239"Add to Contact Summary Page" cannot be turned off2023-04-18T17:52:03ZBobS"Add to Contact Summary Page" cannot be turned offOverview
----------------------------------------
After enabling the "Add to Contact Summary Page" option and then disabling it, the form remains visible on contact records.
Reproduction steps
----------------------------------------
1....Overview
----------------------------------------
After enabling the "Add to Contact Summary Page" option and then disabling it, the form remains visible on contact records.
Reproduction steps
----------------------------------------
1. Administer | Custom Data and Screens | Formbuilder | Search Forms
1. Edit one of the listed forms, e.g. Administer Payment Processors.
1. Select "Add to Contact Summary Page"
1. Save
1. Open a contact record and observe that the Administer Payment Processors form is visible on the Summary page.
1. Return to editing the form, and deselect "Add to Contact Summary Page"
1. Save
1. Refresh the contact Summary page page.
Current behaviour
----------------------------------------
The form remains displayed on contact Summary pages, even after "Add to Contact Summary Page" has been unselected.
Expected behaviour
----------------------------------------
The form should not be displayed on Contact records after "Add to Contact Summary Page" has been unselected.
Environment information
----------------------------------------
https://dmaster.demo.civicrm.org (5.62.alpha1)https://lab.civicrm.org/dev/user-interface/-/issues/21"Allow sharing through social media?" – misleading label2020-10-12T22:26:23Znicol"Allow sharing through social media?" – misleading label![image](/uploads/6cafff09b7214f580edef390a8272825/image.png)
Without going into the design / etc issues of the Help Spread the Word social media box at the bottom of event and contribution pages, the checkbox enabling and disabling it ...![image](/uploads/6cafff09b7214f580edef390a8272825/image.png)
Without going into the design / etc issues of the Help Spread the Word social media box at the bottom of event and contribution pages, the checkbox enabling and disabling it is a little confusing. Users could turn it on by mistake because they check a box asking them to "Allow sharing through social media?" of the event or contribution page in question.
![image](/uploads/5121c784856610036c72466d1e7c9346/image.png)
Obviously everyone clicks yes to that. But in reality obviously any public page can be shared through social media - this checkbox neither enables nor blocks social sharing. Unless I'm badly mistaken, checking it simply adds Facebook/Twitter/LinkedIn share buttons and tracking code to the foot of the event or contribution page in a green box. It would be clearer to label this as "Add social media sharing button footer".
![image](/uploads/2765ae670a5d063ce3316dc1a02e1f95/image.png)
Post-GDPR & CCPA it might also be good to state in the info box that turning this on will add Facebook/Twitter/LinkedIn tracking code, as that could impact the site's privacy policy/cookie declaration.5.32.0https://lab.civicrm.org/dev/financial/-/issues/206"Amount before tax" is wrong on online contribution receipt2023-11-08T15:33:16ZDaveD"Amount before tax" is wrong on online contribution receiptIt's because totalTaxAmount seems to have gone missing, so the amount before tax ends up the same as after tax. The total is correct though.
To reproduce:
1. Turn on and set up taxes: https://docs.civicrm.org/user/en/latest/contribution...It's because totalTaxAmount seems to have gone missing, so the amount before tax ends up the same as after tax. The total is correct though.
To reproduce:
1. Turn on and set up taxes: https://docs.civicrm.org/user/en/latest/contributions/sales-tax-and-vat/
2. Create a price set using that financial type.
3. Create an online donation for it where it's set up to send a receipt. It also happens if you use the send receipt action later from find contributions, since this also uses the online template (as opposed to editing the contribution and checking the box to send receipt, which uses the offline template).
I don't know exactly when it started. It's not working in 5.52 or master.5.69.0https://lab.civicrm.org/dev/core/-/issues/1891"applyLocale()" does not apply desired locale when "inheritLocale" is set2023-09-05T13:38:59Zhaystack"applyLocale()" does not apply desired locale when "inheritLocale" is setFollowing up on #1890 it seems that the locale string in the `language` column in the `civicrm_uf_match` table is also redundant.
It is set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM...Following up on #1890 it seems that the locale string in the `language` column in the `civicrm_uf_match` table is also redundant.
It is set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/ConfigSetting.php#L173) when there is a locale requested in a URL that uses the `lcMessages` query param or when there's an existing locale set in the session.
The session locale is set from the `$ufm->language` locale [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/ConfigSetting.php#L187) when there's a logged-in user and the locale hasn't been determined by the `lcMessages` query param or there's no locale set in the session.
I cannot find anywhere else in the CiviCRM Core code where `$ufm->language` is read or set, so this appears to be circular logic that seems redundant to me.
Can we remove it since it's never actually used for anything practical?
**Correction:** both the `$ufm->language` and `lcMessages` session variable are set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Admin/Form/Setting/Localization.php#L336-L338), but this only sets the locale for the Contact/User that saves that particular form. It doesn't alter the circularity of the logic in `applyLocale()`.5.29.0haystackhaystackhttps://lab.civicrm.org/dev/financial/-/issues/129"billing address is the same as above" doesn't show/hide billing address fields2023-11-23T07:37:19ZJonGold"billing address is the same as above" doesn't show/hide billing address fieldsTo replicate on the demo server:
* Add a profile to a contribution page that has all the required fields to expose the "billing address is the same as above" checkbox ("Name and Address" works).
* Load the page.
* Click the checkbox.
Ex...To replicate on the demo server:
* Add a profile to a contribution page that has all the required fields to expose the "billing address is the same as above" checkbox ("Name and Address" works).
* Load the page.
* Click the checkbox.
Expected behavior:
* Checking/unchecking the box should show/hide the billing fields.
Actual behavior:
* No change.
It's not a JS error because JS is still firing.https://lab.civicrm.org/dev/translation/-/issues/72"Cancel" in registration update should have different translation than "cance...2023-03-14T01:46:02Zthoni56"Cancel" in registration update should have different translation than "cancel" as in "abort operation"When you change status of a registration, especially through the self-service registration update, you can choose between "Transfer" or "Cancel" in English. The Swedish translation of that precis "Cancel" should not be "Avbryt" (meaning ...When you change status of a registration, especially through the self-service registration update, you can choose between "Transfer" or "Cancel" in English. The Swedish translation of that precis "Cancel" should not be "Avbryt" (meaning something like "Abort"), as is the case with most of the other instances. In Swedish, at least, it should be translated to something different, like "Avbokad" (which means "Deregister") as that is used in the rest of the Swedish translation.
This seems to be impossible since the same translation for "Cancel" is used everywhere (correct me if I'm wrong and how to distinguish the two). I don't know if this is a problem with the tools for managing translations as this type of problem has popped up a few times.
I'm one of the main contributors to the Swedish translation.
(Sorry if I posted this issue in the wrong place. Please direct me to the right place and update the instructions on https://civicrm.org/bug-reporting as they say "Click Create New Issue in at the top of the left panel". I don't have that... This makes new Issue Tracker very confusing, disclosing the internal structure of the project.)https://lab.civicrm.org/dev/core/-/issues/1539"Cannot add field", row size "is greater than maximum allowed size (8126) for...2023-02-01T05:03:52ZDmitry Smirnov"Cannot add field", row size "is greater than maximum allowed size (8126) for a record on index leaf page"CiviCRM 5.21.1; Spotted the following in MariaDB logs:
```
[Warning] InnoDB: Cannot add field `postal_greeting_display` in table `wordpress-civicrm`.`civicrm_contact` because after adding it, the row size is 8486 which is greater than m...CiviCRM 5.21.1; Spotted the following in MariaDB logs:
```
[Warning] InnoDB: Cannot add field `postal_greeting_display` in table `wordpress-civicrm`.`civicrm_contact` because after adding it, the row size is 8486 which is greater than maximum allowed size (8126) for a record on index leaf page.
[Warning] InnoDB: Cannot add field `confirm_text` in table `wordpress-civicrm`.`civicrm_event` because after adding it, the row size is 8275 which is greater than maximum allowed size (8126) for a record on index leaf page.
```
No idea how serious this is...
Any ideas how to address the issue? Thanks.https://lab.civicrm.org/dev/core/-/issues/4556"Check number" field isn't shown on Pending check payments (workaround exists)2023-12-12T19:08:26ZAllenShaw"Check number" field isn't shown on Pending check payments (workaround exists)(Similar to behavior described in https://lab.civicrm.org/dev/core/-/issues/60)
**One way to repro this on dmaster.demo.civicrm.org:**
1. Log in and navigate to any contact record.
2. Create and save a contribution with these attributes...(Similar to behavior described in https://lab.civicrm.org/dev/core/-/issues/60)
**One way to repro this on dmaster.demo.civicrm.org:**
1. Log in and navigate to any contact record.
2. Create and save a contribution with these attributes:
- Status: Pending
- Payment method: Check
3. Observe this contribution is displayed in the contact's Contributions tab.
4. Open the contribution for viewing, and select the "Record Payment" link or button; this opens the New Payment form.
5. In the New Payment form, observe that the Payment Method is pre-selected as "Check".
6. Observe expected vs actual (bad) behavior:
- Expected behavior: Because the Payment Method is "Check", the field "Check Number" should be displayed for data entry
- **Actual (bad) behavior:** "Check Number" field is not displayed.
**Workaround:**
Continuing from Step 6 above: Change the Payment Method to anything other than "Check", then change it back to "Check". Observe that the "Check Number" field is now available for data entry.
Screencap of problem and workaround from dmaster.demo.civicrm.org today:
![anim](/uploads/f951056d3c2c0c91aaff0d6f17a8b1b4/anim.gif)
(Joinery reference: F#1220)https://lab.civicrm.org/dev/core/-/issues/60"Check number" isn't shown on Pay Later event registrations when edited2023-09-06T16:08:21Zlaryn"Check number" isn't shown on Pay Later event registrations when editedThis happens to me with an event registration that comes through 'webform_civicrm' as a "Pending (Pay Later)". When I try to edit the participant record to record a payment, the "Check Number" field never shows up despite "Check" being s...This happens to me with an event registration that comes through 'webform_civicrm' as a "Pending (Pay Later)". When I try to edit the participant record to record a payment, the "Check Number" field never shows up despite "Check" being selected as the payment instrument.
**I was able to reproduce on a demo server by doing the following**:
* Create a registration, marking it as "Pending (Pay Later)" and unchecking "Record Payment"
* Edit the new participant you just created, check "Record Payment" and make sure "Check" is selected as the payment instrument.
No "Check Number" field is shown.
![Screen_Shot_2018-04-11_at_3.52.02_PM](/uploads/02f92e016aa97074be80d410ca596db1/Screen_Shot_2018-04-11_at_3.52.02_PM.jpg)5.2.0eileeneileenhttps://lab.civicrm.org/dev/core/-/issues/4884"CiviCRM News" on Backdrop has awkward accordions on default themes2024-01-04T22:21:56Ztotten"CiviCRM News" on Backdrop has awkward accordions on default themesOn Backdrop (eg https://bmaster.demo.civicrm.org/civicrm/ ; user: `demo`; pass: `demo`) with default themes, the "CiviCRM News" dashlet is looking weird:
![Screenshot_2024-01-03_at_9.08.21_PM](/uploads/8d22ff7703e5f9eaf856a9e413be66dd/...On Backdrop (eg https://bmaster.demo.civicrm.org/civicrm/ ; user: `demo`; pass: `demo`) with default themes, the "CiviCRM News" dashlet is looking weird:
![Screenshot_2024-01-03_at_9.08.21_PM](/uploads/8d22ff7703e5f9eaf856a9e413be66dd/Screenshot_2024-01-03_at_9.08.21_PM.png)
Theories:
* At first blush, it feels like it would be a regression related to the accordion updates circa 5.69.x (eg https://lab.civicrm.org/dev/user-interface/-/issues/60). However, there's a similar problem in 5.68. This suggests that it's not a simple regression:
![Screenshot_2024-01-03_at_10.21.14_PM](/uploads/ebe6ad88b770ba5337a965cc887d194b/Screenshot_2024-01-03_at_10.21.14_PM.png)
(Note: Slightly different visual appearance with double arrows)
* Could it be that there's always been a bug like this.
* Could it be that the accordion cleanup led to changes in the news feed? In which case, maybe the question is about infra: How to make the feed(s) work with different versions of Civi?
* Interestingly, I went to an old/local copy of `bcmaster`, updated to 5.68+5.69+master, and... it seemed to display fine. But on clean builds of 5.68 and master, it didn't. (This suggests that it might still be some kind of regression.)
* (*It could be that I have a cache of an older feed? This might support the idea of an issue in how the feed works with different client environments?*)5.69.0https://lab.civicrm.org/dev/core/-/issues/588"CiviMail Draft" appears twice in non-Mosaico test emails2018-12-13T04:45:56ZJonGold"CiviMail Draft" appears twice in non-Mosaico test emailsCiviCRM 5.8.0 I believe this is a side effect of https://github.com/civicrm/civicrm-core/pull/12758.CiviCRM 5.8.0 I believe this is a side effect of https://github.com/civicrm/civicrm-core/pull/12758.5.8.1https://lab.civicrm.org/dev/core/-/issues/2429"Class not found" error on `\Civi\*` because hook_civicrm_config runs after h...2021-03-08T16:34:44ZJonGold"Class not found" error on `\Civi\*` because hook_civicrm_config runs after hook_civicrm_container`hook_civicrm_config` is responsible for telling the autoloader which classes exist in extensions, so must run before any other hooks.
However:
* `hook_civicrm_fieldOptions` is called before `hook_civicrm_config`; this is issue #1132, a...`hook_civicrm_config` is responsible for telling the autoloader which classes exist in extensions, so must run before any other hooks.
However:
* `hook_civicrm_fieldOptions` is called before `hook_civicrm_config`; this is issue #1132, and there's a [PR](https://github.com/civicrm/civicrm-core/pull/19580).
* `hook_civicrm_container` runs before `hook_civicrm_config`; this ticket discusses that.
Here are some examples (with backtraces):
* Issue #2334 appears to be this issue.
There's also the backtrace below, which happens when my Drupal cron runs.
This only happens on classes in the `\Civi` namespace, which isn't as common in extensions, which is why this isn't more widespread.
I don't know enough about `hook_civicrm_config` and `hook_civicrm_container`, but it seems we should guarantee that `hook_civicrm_config` always runs first.
```
Mar 02 15:54:01 [debug] $pdfapi-backtrace = #0 /var/www/mysite.org/web/sites/all/civicrm-custom/extensions/org.civicoop.pdfapi/pdfapi.php(14): CRM_Core_Error::backtrace("pdfapi-backtrace", TRUE)
#1 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Utils/Hook.php(271): pdfapi_civicrm_container(Object(Symfony\Component\DependencyInjection\ContainerBuilder))
#2 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Utils/Hook/DrupalBase.php(73): CRM_Utils_Hook->runHooks((Array:99), "civicrm_container", 1, Object(Symfony\Component\DependencyInjection\ContainerBuilder), NULL, NULL, NULL, NULL, NULL)
#3 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/CiviEventDispatcher.php(168): CRM_Utils_Hook_DrupalBase->invokeViaUF(1, Object(Symfony\Component\DependencyInjection\ContainerBuilder), NULL, NULL, NULL, NULL, NULL, "civicrm_container")
#4 /var/www/mysite.org/web/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(214): Civi\Core\CiviEventDispatcher::delegateToUF(Object(Civi\Core\Event\GenericHookEvent), "hook_civicrm_container", Object(Civi\Core\CiviEventDispatcher))
#5 /var/www/mysite.org/web/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(44): Symfony\Component\EventDispatcher\EventDispatcher->doDispatch((Array:1), "hook_civicrm_container", Object(Civi\Core\Event\GenericHookEvent))
#6 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/CiviEventDispatcher.php(129): Symfony\Component\EventDispatcher\EventDispatcher->dispatch("hook_civicrm_container", Object(Civi\Core\Event\GenericHookEvent))
#7 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Utils/Hook.php(167): Civi\Core\CiviEventDispatcher->dispatch("hook_civicrm_container", Object(Civi\Core\Event\GenericHookEvent))
#8 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Utils/Hook.php(2523): CRM_Utils_Hook->invoke((Array:1), Object(Symfony\Component\DependencyInjection\ContainerBuilder), NULL, NULL, NULL, NULL, NULL, "civicrm_container")
#9 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/Container.php(334): CRM_Utils_Hook::container(Object(Symfony\Component\DependencyInjection\ContainerBuilder))
#10 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/Container.php(69): Civi\Core\Container->createContainer()
#11 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/Container.php(564): Civi\Core\Container->loadContainer()
#12 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Core/Config.php(93): Civi\Core\Container::boot(TRUE)
#13 /var/www/mysite.org/web/sites/all/modules/civicrm/drupal/civicrm.module(227): CRM_Core_Config::singleton()
#14 /var/www/mysite.org/web/sites/all/modules/civicrm/drupal/modules/civicrmtheme/civicrmtheme.module(98): civicrm_initialize()
#15 /var/www/mysite.org/web/includes/module.inc(965): civicrmtheme_custom_theme()
#16 /var/www/mysite.org/web/includes/menu.inc(1760): module_invoke_all("custom_theme")
#17 /var/www/mysite.org/web/includes/menu.inc(1782): menu_get_custom_theme(TRUE)
#18 /var/www/mysite.org/web/includes/common.inc(5376): menu_set_custom_theme()
#19 /var/www/mysite.org/web/includes/bootstrap.inc(2552): _drupal_bootstrap_full()
#20 /usr/local/src/drush7/lib/Drush/Boot/DrupalBoot7.php(74): drupal_bootstrap(7)
#21 /usr/local/src/drush7/includes/bootstrap.inc(313): Drush\Boot\DrupalBoot7->bootstrap_drupal_full()
#22 /usr/local/src/drush7/includes/bootstrap.inc(429): drush_bootstrap(5, 6)
#23 /usr/local/src/drush7/lib/Drush/Boot/BaseBoot.php(56): drush_bootstrap_to_phase(6)
#24 /usr/local/src/drush7/drush.php(70): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#25 /usr/local/src/drush7/drush.php(11): drush_main()
#26 {main}
```https://lab.civicrm.org/dev/core/-/issues/1387"config_backend" should be thoroughly removed2023-02-05T05:03:36Ztotten"config_backend" should be thoroughly removedOverview
----------------------------------------
In CiviCRM 4.7.0, the column `civicrm_domain.config_backend` was migrated to the `civicrm_setting` table. However, the migration was incomplete.
Reproduction steps
----------------------...Overview
----------------------------------------
In CiviCRM 4.7.0, the column `civicrm_domain.config_backend` was migrated to the `civicrm_setting` table. However, the migration was incomplete.
Reproduction steps
----------------------------------------
1. Create a new site (e.g. `civibuild create dmaster`)
2. Run `DESC civicrm_domain`
3. Observe that column `config_backend` exists
Current behaviour
----------------------------------------
* If a site upgrades from `$ver <= 4.6`, then the column `civicrm_domain.config_backend` does NOT exist.
* If a new site is created in `4.7 <= $ver <= 5.21`, then the column `civicrm_domain.config_backend` DOES exist.
Expected behaviour
----------------------------------------
The column should not exist in v5.21 (or whatever gets the fix). It should not matter if the site originated on v4.5, v4.7, or v5.20.
Comments
----------------------------------------
Historically, this field is related to `CRM_Core_BAO_ConfigSetting`. One should grep on both `config_backend` and `ConfigSetting` to track down code-paths that may be referencing it.
It is still desirable to retain upgrade/transitional logic (eg `CRM_Upgrade_Incremental_php_FourSeven`, `Civi\Core\SettingsBag`); but otherwise these should be removed, and any dependent code-paths should be re-tested.https://lab.civicrm.org/dev/core/-/issues/3392"Confirm Event Invitation" message template has a bad variable2023-09-04T07:59:16ZJonGold"Confirm Event Invitation" message template has a bad variableIn the above-mentioned template, there are two URLs generated that are ostensibly the same:
```
{capture assign=selfService}{crmURL p='civicrm/event/selfsvcupdate' q="reset=1&pid=`$participantID`&{contact.checksum}" h=0 a=1 fe=1}{/captur...In the above-mentioned template, there are two URLs generated that are ostensibly the same:
```
{capture assign=selfService}{crmURL p='civicrm/event/selfsvcupdate' q="reset=1&pid=`$participantID`&{contact.checksum}" h=0 a=1 fe=1}{/capture}
```
and:
```
{capture assign=selfService}{crmURL p='civicrm/event/selfsvcupdate' q="reset=1&pid=`$participant.id`&{contact.checksum}" h=0 a=1 fe=1}{/capture}
```
`$participant.id` is a valid token in this context. `$participantID` isn't. Easy fix.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3368"Confirm from waitlist" doesn't consider whether participant roles are counted.2022-04-22T16:21:55ZJonGold"Confirm from waitlist" doesn't consider whether participant roles are counted.To test this:
* Set your Participant Role of "Host" as not Counted. Keep "Attendee" as Counted.
* Create an event with a max enrollment of 1.
* Register a host.
* Observe that everywhere you can look in the UI, the non-counted participan...To test this:
* Set your Participant Role of "Host" as not Counted. Keep "Attendee" as Counted.
* Create an event with a max enrollment of 1.
* Register a host.
* Observe that everywhere you can look in the UI, the non-counted participant isn't counted; registration is still open.
* Register an attendee.
* Add an attendee to the waitlist.
* Cancel (or delete) the registered attendee's participant record.
* At this point, everything STILL works correctly.
The issue only arises when the person gets the "Confirm you want to come off the waitlist" email and clicks the link, bringing them to `<site>/civicrm/event/confirm`. This page says that registration is closed - because it's counting the Host against the max enrollment count.
After working through this, I realized this is very similar to event#7 - the function `CRM_Event_BAO_Participant::pendingToConfirmSpaces()` is a dog. It duplicates code found elsewhere, but poorly.
I replaced the one reference to this function with a call to `CRM_Event_BAO_Participant::eventFull()`, which I tweaked slightly to accommodate this use case. This means that:
* We removed a 50-line function by adding 5 lines to another function;
* We replaced an untested function with a tested one.5.23.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1005"Confirm this subscription" URL generated by MailingEventSubscribe API should...2019-06-03T11:24:05Zhaystack"Confirm this subscription" URL generated by MailingEventSubscribe API should always be a front-end URLFollowing on from discussion on [this WordPress issue](https://lab.civicrm.org/dev/wordpress/issues/27#note_18352), it seems that [the code in CiviCRM Core which generates the URL](https://github.com/civicrm/civicrm-core/blob/master/CRM/...Following on from discussion on [this WordPress issue](https://lab.civicrm.org/dev/wordpress/issues/27#note_18352), it seems that [the code in CiviCRM Core which generates the URL](https://github.com/civicrm/civicrm-core/blob/master/CRM/Mailing/Event/BAO/Subscribe.php#L232-L235) for use in the subscription confirmation email triggered via the `MailingEventSubscribe` API does not always force the URL to be a front-end URL.
This can be reproduced by using the CiviCRM API Explorer in WordPress but also applies (as is the case for the reporter) when a form is submitted via the standard WordPress AJAX route of `admin_url('admin-ajax.php')`.
PR to follow.5.15.0