Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-08-25T17:04:50Zhttps://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/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/37015.51 - Import - Notice error on map fields form2023-03-20T10:09:00Ztschuettler5.51 - Import - Notice error on map fields formReproduction steps
----------------------------------------
1. Enable Debugging: https://dmaster.demo.civicrm.org/civicrm/admin/setting/debug?reset=1
1. Import a contact
1. Got an e-notice on the match fields forms: `Notice: Undefined i...Reproduction steps
----------------------------------------
1. Enable Debugging: https://dmaster.demo.civicrm.org/civicrm/admin/setting/debug?reset=1
1. Import a contact
1. Got an e-notice on the match fields forms: `Notice: Undefined index: isCheked in include() (line 35 of /srv/buildkit/build/dmaster/web/sites/default/files/civicrm/templates_c/en_US/%%72/72E/72E39105%%MapField.tpl.php).`
Current behaviour
----------------------------------------
The e-notice will appear regardless whether a saved field mapping is used or not.
Forcing an form validiation when trying to go to the preview form will not show the e-notice, since the form rule will set the template variable.
Expected behaviour
----------------------------------------
No e-notice shown.
Comments
----------------------------------------
I can reproduce this with 5.50.4 and since there don't seem to be any recent change, I would assume that it is no (recent) regression.
I can't wrap my head around, what the javascript in https://github.com/civicrm/civicrm-core/blob/4a01628cfa19ac305b5734e8ea36713f363b8d91/templates/CRM/Contact/Import/Form/MapField.tpl#L24-L34 is actually supposed to achieve, but here is an uneducated fix for making the e-notice go away: https://github.com/civicrm/civicrm-core/pull/239065.61.0https://lab.civicrm.org/dev/core/-/issues/3700Search Kit: More options on field transformations of a Date Field2023-02-16T16:00:40ZGhost UserSearch Kit: More options on field transformations of a Date FieldOverview
----------------------------------------
We are trying to replicate the behaviour that the Contribution Summary Report has. We want the Search Kit to be able to group by Month and Year. As in the image below:
![image](/uploads/...Overview
----------------------------------------
We are trying to replicate the behaviour that the Contribution Summary Report has. We want the Search Kit to be able to group by Month and Year. As in the image below:
![image](/uploads/681b1ed526a0554aa11029b7dae99034/image.png)
Current behaviour
----------------------------------------
Currently, in v.5.52, you can group by by Month.
![image](/uploads/53a95111430b13d4b44d69317d62d059/image.png)
But when showing the results it shows just a date instead of showing just the Month.
![image](/uploads/a4286678845bd0ffae98cc3d88569fe7/image.png)
This happens because in field transformations there is no option of selecting what to show in a Date Field. Currently only Aggregation options are showed, so it is treated as an integer.
![image](/uploads/a4f5a3c8ae92343f3cf18504bf7cecde/image.png)
Proposed behaviour
----------------------------------------
In field transformation it should show different options that let you choose what to show. For example, select between Day/Month/Year so that the column is showed as the Contribution Summary Report.https://lab.civicrm.org/dev/core/-/issues/3699CRM-12989 Editing memberships, contributions, event registrations or contact ...2024-02-29T05:03:25Zjustinfreeman (Agileware)CRM-12989 Editing memberships, contributions, event registrations or contact profile in multiple tabs replaces dataReviving an Jira Bug Report which is marked "In progress" and still causing issues for users today. See https://issues.civicrm.org/jira/browse/CRM-12989
> When you have memberships being edited in multiple tabs the information from one ...Reviving an Jira Bug Report which is marked "In progress" and still causing issues for users today. See https://issues.civicrm.org/jira/browse/CRM-12989
> When you have memberships being edited in multiple tabs the information from one will replace another.
>
> To replicate (this works on the current demo)
>
> 1. Access Memberships dashboard
> 2. For one record (A) right click 'edit' and open into a new tab
> 3. Then for another record (B) right click 'edit' and open into a new tab
> 4. Go to the tab for record A, make no changes and press 'Save'
>
> After doing the above you will see all of the details (Level, Date, Source, Since, Start/End Dates) for record A will be saved to B along with the success message displaying you have successfully updated the record for the name of record B.
>
> I'm assuming this is some kind of session error but it's a major error that we've just discovered on a client's setup that has caused membership records to now have the wrong levels set.
Relates to https://lab.civicrm.org/documentation/docs/user-en/-/issues/347https://lab.civicrm.org/dev/core/-/issues/3698Too many custom groups2024-03-08T05:03:22ZkristinecToo many custom groupsTwo years ago, I reported an issue with "too many custom fields" [Issue #1330](https://lab.civicrm.org/dev/core/-/issues/1330). It seems that I have now surpass the limit for the **custom groups** instead of _custom fields_. If I add cus...Two years ago, I reported an issue with "too many custom fields" [Issue #1330](https://lab.civicrm.org/dev/core/-/issues/1330). It seems that I have now surpass the limit for the **custom groups** instead of _custom fields_. If I add custom group number 94, accessing some cases produces an error "case_id is not valid : 1.". Keeping the number of custom groups at 93 removes the error.https://lab.civicrm.org/dev/core/-/issues/3697libxml_disable_entity_loader is deprecated in php8, which comes up if your sy...2022-06-29T12:34:47ZDaveDlibxml_disable_entity_loader is deprecated in php8, which comes up if your system temp dir has spaces in the pathIt's a little confusing. And it's not really a civi issue. I should post this over at symfony, but in case anyone else comes up against it here it is. It may or may not be more common on windows, where the temp folder might be something ...It's a little confusing. And it's not really a civi issue. I should post this over at symfony, but in case anyone else comes up against it here it is. It may or may not be more common on windows, where the temp folder might be something like `C:\users\ACME Widgets\Appdata\Local\Temp`, as opposed to `/tmp`.
The version of symfony/dependency-injection that ships with core is 3.4. It includes a simple guard, so that it only calls libxml_disable_entity_loader based on libxml version. https://github.com/symfony/dependency-injection/blob/3.4/Loader/XmlFileLoader.php#L623. So spaces are irrelevant.
In 4.3, dependency-injection removes this guard, but leaves it calling libxml_disable_entity_loader ALWAYS.
In 4.4, they added a fancier guard. Since drupal 9+ ends up with v4.4 (at least for me, and it seems for [E2E tests too]( https://test.civicrm.org/job/CiviCRM-D8-Matrix/905/BKPROF=max,BLDTYPE=drupal9-clean,CIVIVER=master,SUITES=phpunit-e2e,label=bknix-tmp/consoleText)), everything's ok as long as there's no spaces in the path.
In php8, what happens is shouldEnableEntityLoader() ends up returning true anyway, because the little test that function is doing fails validation when there's spaces, i.e. `<xsd:include schemaLocation="file:///'.str_replace('\\', '/', $tmpfile).'" />` doesn't give a correct encoding for the schemaLocation.
It comes up for example when creating the container, e.g. after clearing cache.
And it's the same code in symfony in v5 and v6.https://lab.civicrm.org/dev/core/-/issues/3696Should MessageTemplate.send support tplParams with Smarty disabled?2024-03-09T05:03:24ZRichShould MessageTemplate.send support tplParams with Smarty disabled?The api3 MessageTemplate.send action has supported `tplParams` since its inception in 2013, exposed explicitly in the api spec since 2015.
They allow a way to specify content for arbitrary email template parameters: `{$paramname}` - whi...The api3 MessageTemplate.send action has supported `tplParams` since its inception in 2013, exposed explicitly in the api spec since 2015.
They allow a way to specify content for arbitrary email template parameters: `{$paramname}` - which are different to `[entity.tokens]`. It's **super useful** for transactional mail where you want to include extra info as a one-off.
The api has done this by assigning the given key value pairs as Smarty variables.
More recently (2020) the api action added support for disabling Smarty, since it wasn't playing nicely with message template content generated by Mosaico.
Without Smarty, `tplParams` does not work.
## I would like to see support for `tplParams` without Smarty.
I think the concept of a message template is that it is a flexible template for emails. (Adding token support for one-off context-sensitive use-cases is very inefficient and is likely to end up with hackish situations where the data that needs to be in the email does not need to be in the database.)
I mistakenly thought that it used to work this way, and so I wrote a PR to fix what I saw as a regression, adding tests to boot. https://github.com/civicrm/civicrm-core/pull/19062 however this stalled, because it turns out it wasn't a regression, and so was felt to need more discussion. Hence this post.
The PR is a minor change and I can't see that it has any negative consequences/side effects (very few people will disable smarty anyway), but it does mean the tplParams feature is supported with/out Smarty, which I think is valuable.
There could be nicer ways to specify such content, but this isn't a proposal about a whole new way of doing things.
Thoughts?https://lab.civicrm.org/dev/translation/-/issues/77Translation of message for multiple registrations missing2022-08-19T15:24:12Zthoni56Translation of message for multiple registrations missingIf you allow multiple registrations to an event, and select a number greater than 1 when you register (from the web view) the following string is displayed:
Fill in your registration information on this page. You will be able to ent...If you allow multiple registrations to an event, and select a number greater than 1 when you register (from the web view) the following string is displayed:
Fill in your registration information on this page. You will be able to enter the registration information for additional people after you complete this page and click "Continue".
This string can not be translated in Transifex (since it does not exist). The string there is (probably):
Fill in your registration information on this page. If you are registering additional people, you will be able to enter their registration information after you complete this page and click "Review your registration".
We are running 5.50.4 on Joomla.https://lab.civicrm.org/dev/core/-/issues/3695Search Kit: Commas in event types break IN operator2024-03-06T22:16:53ZJonGoldSearch Kit: Commas in event types break IN operatorWhen you have an event type with a comma in it, you can't search for it using the `WHERE` clause using the `IN` operator.
### Steps to Replicate
* Create a new event type with a comma in the label (which will propagate to the name).
* C...When you have an event type with a comma in it, you can't search for it using the `WHERE` clause using the `IN` operator.
### Steps to Replicate
* Create a new event type with a comma in the label (which will propagate to the name).
* Create an event with the new event type.
* Create a SK search with a `WHERE` event type `is one of` the new event type.
### Expected Result
The new event will appear.
### Actual Result
Event doesn't appear.
See screenshots comparing `=` and `is one of`.
### Comments
SK assumes that `name` fields can't have commas, so it can explode the string on a comma delimiter. This is the API query for the screenshot above (below).
If event types were their own table, I'd suggest making the `name` field be snake-cased. However, this goes against a long-standing (and probably unwise) design decision around `civicrm_option_value` names, which can be used to match on import with external systems. So this may have to get fixed in SK.
```
{
"version": 4,
"select": [
"id",
"title",
"event_type_id:label"
],
"orderBy": {},
"where": [
[
"event_type_id:name",
"IN",
[
"Development",
"Administration"
]
]
],
"groupBy": [],
"join": [],
"having": []
}
```
![Selection_1550](/uploads/03d0a44e852b431289d54eb9b9951d6e/Selection_1550.png)
![Selection_1551](/uploads/afce4bfb38cd7c3e6cd9e979e0f0c463/Selection_1551.png)https://lab.civicrm.org/dev/core/-/issues/3694Get offline contribution-receipt fully working with preview screen2024-03-18T05:03:27ZeileenGet offline contribution-receipt fully working with preview screenThere is a long-term goal to get all templates working in the preview screen. This focusses on the backoffice contribution receipt.
Aside from the Usability benefit the process adds test cover and will eventually allow us to remove a si...There is a long-term goal to get all templates working in the preview screen. This focusses on the backoffice contribution receipt.
Aside from the Usability benefit the process adds test cover and will eventually allow us to remove a significant amount of unreliable and hard-to-read code (even the first PR wound up removing some data leakage). It also means the templates can be fired form outside the forms and separates the logic from the forms - which is important for alternate form layers
This involves that all variables in it can be provided by the workflow-template / example combo
- [ ] `$lineItem` -> supported variable -> `$lineItems` https://github.com/civicrm/civicrm-core/pull/23870
- [ ] `$getTaxDetails` - no longer used in default template https://github.com/civicrm/civicrm-core/pull/23870
- [ ] `$dataArray` -> supported variable -> `$taxRateBreakdown` https://github.com/civicrm/civicrm-core/pull/23870
- [ ] Amount before Tax - add a new token for this & use that - it is `{contribution.total_amount}` - `{contribution.tax_amount}` & can be added at apiv4 level - similar to https://github.com/civicrm/civicrm-core/pull/23802
- [ ] `$ccContribution`, `$formValues.hidden_CreditCard` - probably of marginal value - check the specific values instead before displaying or not
- [ ] `$billingName`, `$address` - add billing tokens - builds on https://github.com/civicrm/civicrm-core/pull/23845
- [ ] `$credit_card_type`, `$credit_card_number`, `$credit_card_exp_date` - potentially Payment tokens?
- [ ] `$customGroup` - propose removal https://lab.civicrm.org/dev/core/-/issues/3693
- [ ] `$softCreditTypes` `$softCredits` - fix is similar to line items - keep but rationalise & handle in WorkFlow Template
- [ ] `$formValues.product_name`, `$formValues.product_name`, `$formValues.product_option`, `$formValues.product_sku` `$fulfilled_date` - fix is similar to line items - keep but rationalise & handle in WorkFlow Template
Note `$formValues.receipt_text` REALLY IS tied to the form - as it is not stored in the DB - so that is an appropriate use of formValues.https://lab.civicrm.org/dev/core/-/issues/3693Proposal - remove `CustomGroups` section from default contribution backoffice...2024-03-05T05:03:25ZeileenProposal - remove `CustomGroups` section from default contribution backoffice receiptI'm proposing we remove the following chunk of code from the back-office contribution receipt where it has not been customised
```
{if !empty($customGroup)}
{foreach from=$customGroup item=value key=customName}
<tr>
...I'm proposing we remove the following chunk of code from the back-office contribution receipt where it has not been customised
```
{if !empty($customGroup)}
{foreach from=$customGroup item=value key=customName}
<tr>
<th {$headerStyle}>
{$customName}
</th>
</tr>
{foreach from=$value item=v key=n}
<tr>
<td {$labelStyle}>
{$n}
</td>
<td {$valueStyle}>
{$v}
</td>
</tr>
{/foreach}
{/foreach}
{/if}
```
This code adds details about all the custom fields associated with the contribution. For many sites this is not an issue as there are none :-)
However, for those that have contribution custom fields there are generally a mix of fields that are public facing and private facing (I've seen organisations accidentally send out commission information in the past).
It is now possible to use contribution tokens in all contribution workflow templates so the idea would be that
- if the offline template is uncustomised and the site has contribution custom fields they get a pre-upgrade message
- the message would say that if they upgrade the above section will be removed & emails would not have custom field information going forwards and point them to version-specific-upgrade-docs
- the upgrade docs would offer two options (not recommended) - put back the above block, which may not be supported forever or (recommended) construct the fields they want with tokens on the 'pdf letter for contributions screen' and copy it backhttps://lab.civicrm.org/dev/core/-/issues/3692Replace all calls to deprecated method CRM_Core_PseudoConstant::activityType()2024-03-11T05:03:24ZherbdoolReplace all calls to deprecated method CRM_Core_PseudoConstant::activityType()There are calls to `CRM_Core_PseudoConstant::activityType()` (deprecated) in many places such as `$activityTypes = CRM_Core_PseudoConstant::activityType(TRUE, FALSE, FALSE, 'name');` ~~but the actual method accepts no parameters. And cha...There are calls to `CRM_Core_PseudoConstant::activityType()` (deprecated) in many places such as `$activityTypes = CRM_Core_PseudoConstant::activityType(TRUE, FALSE, FALSE, 'name');` ~~but the actual method accepts no parameters. And changes to that method predate the migration from SVN... so some guesswork needs to be done~~.
Update: oops I just noticed it has `func_get_args()` so it is accepting parameters after all.
In some cases it seems that it can be replaced with `CRM_Core_PseudoConstant::getKey('CRM_Activity_BAO_Activity', 'activity_type_id', 'ACTIVITYNAME')` but in other cases it actually does need a list of activity types. And in some cases needs to filter out disabled components, which is what the original method is doing.https://lab.civicrm.org/dev/core/-/issues/3691Improve code comments for Activity: parent_id and source_record_id2022-06-25T11:47:09ZherbdoolImprove code comments for Activity: parent_id and source_record_idI've done some investigating of the codebase to try to figure out what two columns for Activity entity are for and whether I can. I think I've figured it mostly out but not sure where to document. At the very least I'll improve the comme...I've done some investigating of the codebase to try to figure out what two columns for Activity entity are for and whether I can. I think I've figured it mostly out but not sure where to document. At the very least I'll improve the comments in the codebase. We don't seem to have a section in the dev guide to deal with this.
So if someone creates a generic activity and schedules a follow-up, the new follow-up activity references the first activity in `parent_id` column. Then assigning it to a contact will send an email to that contact and create an activity. And that activity references the follow-up activity in the source_record_id column. I haven't found much documentation yet, except in the parent_id column description where it says that it's for "follow-up items" but claims that it is "not currently implemented." Hm...
The description of `source_record_id` also seems to be the only documentation:
> Artificial FK to original transaction (e.g. contribution) IF it is not an Activity. Table can be figured out through activity_type_id, and further through component registry.
As far as I can tell, "table can be figured out", means just checking for particular activity types before trying to figure out the "FK", and assuming the code creating the activity assigned the `activity_type_id` properly.
I'm not really sure what "component registry" means here. As far as I can tell from the code, the component doesn't matter. It's only based on checking the right `activity_type_id`.
If Activity was created fresh now I'm guessing it would have gotten entity_table and entity_id instead of this older approach?5.52.0https://lab.civicrm.org/dev/core/-/issues/3690Form Builder/Search Kit: Date filters do not work when picking dates2022-09-03T14:27:07ZJonGoldForm Builder/Search Kit: Date filters do not work when picking datesWhen creating a Form Builder form based on a Search Kit, the "Receive Date" filter doesn't work if you use "Pick Date".
### Steps to Replicate
* Create a SK that groups Contributions by Financial Type, and displays a count of IDs and a ...When creating a Form Builder form based on a Search Kit, the "Receive Date" filter doesn't work if you use "Pick Date".
### Steps to Replicate
* Create a SK that groups Contributions by Financial Type, and displays a count of IDs and a sum of Total Amount. Screenshot and exported SK are below.
* Embed the search in a Form Builder form, and add a "Date Received" filter. Screenshot and afform markup below.
* Use the form to filter by *Date Received* is **This calendar year**. Observe that it filters correctly.
* Change the *Date Received* to **Choose Date Range** and select 1/1/2022-12/31/2022 (or just 1/1/2022-today).
### Expected Result
Same as filtering by "This calendar year".
![Selection_1547](/uploads/55fa1017e814c8d80fb0071eb75eee49/Selection_1547.png)
### Actual Result
Date filter is ignored.
![Selection_1548](/uploads/bb092e9b7871e36fae3a385df6c68a72/Selection_1548.png)
#### Search Kit
![Selection_1545](/uploads/0aeaa229651b9a46e24c1aff105727e7/Selection_1545.png)
```
[
{
"name": "SavedSearch_date_test",
"entity": "SavedSearch",
"cleanup": "unused",
"update": "unmodified",
"params": {
"version": 4,
"values": {
"name": "date_test",
"label": "date test",
"form_values": null,
"mapping_id": null,
"search_custom_id": null,
"api_entity": "Contribution",
"api_params": {
"version": 4,
"select": [
"COUNT(id) AS COUNT_id",
"SUM(total_amount) AS SUM_total_amount"
],
"orderBy": [],
"where": [],
"groupBy": [
"financial_type_id"
],
"join": [],
"having": []
},
"expires_date": null,
"description": null
}
}
}
]
```
#### Form Builder
![Selection_1546](/uploads/333e237b15b1c16742d67c40cf453d7c/Selection_1546.png)
```
<div af-fieldset="">
<af-field name="receive_date" defn="{input_type: 'Select', search_range: true, input_attrs: {}}" />
<crm-search-display-table search-name="date_test" display-name=""></crm-search-display-table>
</div>
```colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3689error upgrading from CiviCRM 5.36.0 to 5.50.3.2022-06-26T23:17:29Zcaliginouserror upgrading from CiviCRM 5.36.0 to 5.50.3.--previously posted on stackexchange, no replies - https://civicrm.stackexchange.com/q/42177/5858
I'm on wordpress 6.0, linux, upgrading from CiviCRM 5.36.0 to 5.50.3.
When I try and run the upgrade script i.e. wp-admin/admin.php?page=...--previously posted on stackexchange, no replies - https://civicrm.stackexchange.com/q/42177/5858
I'm on wordpress 6.0, linux, upgrading from CiviCRM 5.36.0 to 5.50.3.
When I try and run the upgrade script i.e. wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fupgrade&reset=1
I get the following error in my debug log and the upgrade fails:
Current behaviour
----------------------------------------
```
Jun 22 20:55:28 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -14
[message] => DB Error: no database selected
[mode] => 16
[debug_info] => SELECT *
FROM `civicrm_component`
[nativecode=2006 ** MySQL server has gone away]
[type] => DB_Error
[user_info] => SELECT *
FROM `civicrm_component`
[nativecode=2006 ** MySQL server has gone away]
[to_string] => [db_error: message="DB Error: no database selected" code=-14 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="SELECT *
FROM `civicrm_component`
[nativecode=2006 ** MySQL server has gone away]"]
)
Jun 22 20:56:14 [debug] $backTrace = #0 /var/www/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(954): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/html/wp-content/plugins/civicrm/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /var/www/html/wp-content/plugins/civicrm/civicrm/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: no database selected", -14, 16, (Array:2), "SELECT * \n FROM `civicrm_component` \n \n \n \n \n \n [nativecode=2006 *...")
#3 /var/www/html/wp-content/plugins/civicrm/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-14, 16, (Array:2), "SELECT * \n FROM `civicrm_component` \n \n \n \n \n \n [nativecode=2006 *...")
#4 /var/www/html/wp-content/plugins/civicrm/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR::_raiseError(Object(DB_mysqli), NULL, -14, 16, (Array:2), "SELECT * \n FROM `civicrm_component` \n \n \n \n \n \n [nativecode=2006 *...", "DB_Error", TRUE)
#5 /var/www/html/wp-content/plugins/civicrm/civicrm/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#6 /var/www/html/wp-content/plugins/civicrm/civicrm/vendor/pear/db/DB/mysqli.php(936): DB_common->raiseError(-14, NULL, NULL, "SELECT * \n FROM `civicrm_component` \n \n \n \n \n \n [nativecode=2006 *...", "2006 ** MySQL server has gone away")
#7 /var/www/html/wp-content/plugins/civicrm/civicrm/vendor/pear/db/DB/mysqli.php(391): DB_mysqli->mysqliRaiseError(-14)
#8 /var/www/html/wp-content/plugins/civicrm/civicrm/vendor/pear/db/DB/common.php(1234): DB_mysqli->simpleQuery("SELECT * \n FROM `civicrm_component` \n \n \n \n \n \n")
#9 /var/www/html/wp-content/plugins/civicrm/civicrm/packages/DB/DataObject.php(2696): DB_common->query("SELECT * \n FROM `civicrm_component` \n \n \n \n \n \n")
#10 /var/www/html/wp-content/plugins/civicrm/civicrm/packages/DB/DataObject.php(451): DB_DataObject->_query("SELECT * \n FROM `civicrm_component` \n \n \n \n \n \n")
#11 /var/www/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Component.php(74): DB_DataObject->find(FALSE)
#12 /var/www/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Component.php(37): CRM_Core_Component::getComponents()
#13 /var/www/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Component.php(116): CRM_Core_Component::_info(FALSE)
#14 /var/www/html/wp-content/plugins/civicrm-admin-utilities/includes/civicrm-admin-utilities-single.php(2269): CRM_Core_Component::getEnabledComponents()
#15 /var/www/html/wp-includes/class-wp-hook.php(307): CiviCRM_Admin_Utilities_Single->shortcuts_menu_add(Object(WP_Admin_Bar))
#16 /var/www/html/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, (Array:1))
#17 /var/www/html/wp-includes/plugin.php(524): WP_Hook->do_action((Array:1))
#18 /var/www/html/wp-includes/admin-bar.php(95): do_action_ref_array("admin_bar_menu", (Array:1))
#19 /var/www/html/wp-includes/class-wp-hook.php(307): wp_admin_bar_render("")
#20 /var/www/html/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters("", (Array:1))
#21 /var/www/html/wp-includes/plugin.php(476): WP_Hook->do_action((Array:1))
#22 /var/www/html/wp-admin/admin-header.php(267): do_action("in_admin_header")
#23 /var/www/html/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/Base.php(312): require_once("/var/www/html/wp-admin/admin-header.php")
#24 /var/www/html/wp-content/plugins/civicrm/civicrm/CRM/Utils/System.php(202): CRM_Utils_System_Base->theme("<div id=\"crm-container\" class=\"crm-container\" lang=\"en\" xml:lang=\"en\"...", FALSE, FALSE)
#25 /var/www/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(452): CRM_Utils_System::theme("<div id=\"crm-container\" class=\"crm-container\" lang=\"en\" xml:lang=\"en\"...")
#26 /var/www/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(PEAR_Exception))
#27 /var/www/html/wp-content/plugins/civicrm/civicrm.php(1199): CRM_Core_Invoke::invoke((Array:2))
#28 /var/www/html/wp-includes/class-wp-hook.php(307): CiviCRM_For_WordPress->invoke("")
#29 /var/www/html/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters("", (Array:1))
#30 /var/www/html/wp-includes/plugin.php(476): WP_Hook->do_action((Array:1))
#31 /var/www/html/wp-admin/admin.php(259): do_action("toplevel_page_CiviCRM")
```https://lab.civicrm.org/dev/core/-/issues/3687Improvement for event online registrations: Add additional profiles on 'top o...2024-03-07T05:03:21ZTobias Voigttobias.voigt@civiservice.deImprovement for event online registrations: Add additional profiles on 'top of page'When setting up the 'Registration Screen' for online registrations of events, it is possible to select only one profile to be included at the 'top of page'. On the other hand, for the 'bottom of page' it is possible to add several profil...When setting up the 'Registration Screen' for online registrations of events, it is possible to select only one profile to be included at the 'top of page'. On the other hand, for the 'bottom of page' it is possible to add several profiles.
I think it would be useful to be able to add several profiles for the 'top of page' as well (instead of only one).
While setting up the events module for one of our clients, I prepared several profiles, each containing a small 'block' for the registration screen. The idea behind this was that the client would then be able to quickly setup a registration screen for a new event by freely choosing a combination of 'blocks' (profiles) that fits the individual needs for that particular event (e.g. basic contact data + additional info + newsletter registration + privacy statement). This way neither we nor the client would have to create individual profiles for each event.
But - when I added fees to the events I realized that the section related to event fees is positioned after the 'top of page' profile (and thereby above any profiles that are included in the 'bottom of page' section). Furthermore, when I added the option to pay via PayPal (and selected PayPal in the form), I realized that the 'Checkout with PayPal' button is positioned just below the fees section. So - since I had added several profiles at the 'bottom of page' - my checkout button now was positioned at the center of my form (instead of the end of the form, where any user would expect it to be).
I think using profiles in a modular way (like I described above) could be very useful and time-saving. But since it isn't possible to add more than one profile at the 'top of page' section, the freedom in positioning the profiles on the registration screen is rather limited.https://lab.civicrm.org/dev/core/-/issues/3686Extension downloader does not flush correctly, leading to flaky+circumstantia...2024-03-06T05:03:24ZtottenExtension downloader does not flush correctly, leading to flaky+circumstantial behaviorOverview
----------------------------------------
The `Extension` system provides a mechanism for downloading upgrades (which is primarily used through the web UI, but it can also run via API/CLI). There is a problem in how file-loading...Overview
----------------------------------------
The `Extension` system provides a mechanism for downloading upgrades (which is primarily used through the web UI, but it can also run via API/CLI). There is a problem in how file-loading and system-flushing work with the downloader.
I believe this problem has existed since ~v4.2 and has been reported anecdotally. However, the symptoms present in diverse ways (*often asymptomatic; occasionally as hard-crashes; occasionally as forgetable quirks*), and the symptoms clear up upon inspection. This report is (hopefully) a more precise and reproducible demonstration.
Reproduction steps
----------------------------------------
I've posted an extension (`badflush`) with two version (`1.0`, `2.0`) to demonstrate the problem. Both versions implement a hook (but with different logic). To see the problem, you can simply install each version. (*This is normally done via web UI, but it's easier to control with API-calls.*)
1. Install `badflush-1.0`.
```
cv api Extension.download key=badflush url='http://think.hm/tmp/badflush-1.0.zip'
```
which has the code:
```php
function badflush_civicrm_managed(&$entities) {
$entities[] = [
'module' => 'badflush',
'name' => 'oldthing',
'entity' => 'OptionValue',
'params' => [
'version' => 4,
'values' => [
'option_group_id.name' => 'activity_type',
'label' => 'Old Thing',
'name' => 'oldthing',
],
]
];
}
```
2. In web UI, open the "New Activity" screen. Look for an activity type named "Old Thing".
3. Install `badflush-2.0`
```
cv api Extension.download key=badflush url='http://think.hm/tmp/badflush-2.0.zip'
```
This also implements the same hook, but the code is different. "Old Thing" is replaced with "New Thing".
```php
function badflush_civicrm_managed(&$entities) {
$entities[] = [
'module' => 'badflush',
'name' => 'newthing',
'entity' => 'OptionValue',
'params' => [
'version' => 4,
'values' => [
'option_group_id.name' => 'activity_type',
'label' => 'New Thing',
'name' => 'newthing',
],
]
];
}
```
4. In web UI, open the "New Activity" screen. Look for an activity type named "New Thing".
Current behaviour
----------------------------------------
At step 4, the "New Thing" is not displayed. Instead, it still displays the "Old Thing".
However, if you make a new request to flush caches, then it displays "New Thing".
Expected behaviour
----------------------------------------
At step 4, the "New Thing" should be displayed.
Comments
----------------------------------------
The root problem can be understood with this pseudocode for the download/upgrade process:
```php
<?php
/*1:*/ start_civicrm();
/*2:*/ download_and_extract($codeUrl, $localFolder);
/*3:*/ system_flush();
```
Step 1 loads the old version of `badflush.php`. Steps 2 replaces `badflush.php` with the new version. Step 3 resets the system. But PHP still has an old copy of `badflush.php` in active memory. It doesn't matter how many times you run `system_flush()` in this context - it will continue to reset with the old code.
The scope of impact makes it difficult to reproduce.
* The problem *only* affects people who use the built-in downloader to upgrade code. (Many developers+triagers don't.)
* There is no problem if you install new/clean extensions. (Most developers+triagers rely on feeds that only give the latest version of the extension.)
* There is no problem if you use `git`, `svn`, `wget`, `composer`, or other download tools.
* As soon as you do a system-flush, the problem goes away.
* The problem only matters for files+functions which are implicated in *actively rehydrating data*. Thus, you might notice it with `hook_managed`, `hook_alterMenu`, `hook_xmlMenu`, `hook_container`, etc. But you would not notice it with `hook_pre`, `hook_post`, `hook_alterMailParams`, `hook_buildForm`, etc.
* If the change affects the main `mymodule.php`, then it's always problematic. If the changes are spread among other files (eg `*.mgd.php` files), then... it depends on (exactly) when+how the files are loaded. New files, deleted files, and not-yet-loaded files might work alright - but you cannot reload a PHP file that was loaded before the download.
* Even if two systems have the same extension and upgrade to the same version, they may not produce the same errors... if they *started* from different versions.
I'm not really certain the best way to fix it, but... brainstorming a bit...
* If one changed the system-flush to **strictly/only** delete old data (*never rehydrate data in the same pageload*), that could fix it.
* If one could split the upgrade process into multiple PHP requests, that could fix it.
* If you radically change the file-format of the extension (eg use fewer top-level functions and top-level classes; use more data-files and anonymous callables), then you could theoretically resolve it.https://lab.civicrm.org/dev/core/-/issues/3685CiviCRM sample data - use a price set for at least one contribution page & event2024-01-23T03:11:11ZeileenCiviCRM sample data - use a price set for at least one contribution page & eventI want to propose that at least one of the sample data contribution pages or events is set to 'is_quick_config' = FALSE. It's an easy technical change but people might have preferences as to whichI want to propose that at least one of the sample data contribution pages or events is set to 'is_quick_config' = FALSE. It's an easy technical change but people might have preferences as to whichhttps://lab.civicrm.org/dev/joomla/-/issues/41Cron issue with Joomla 42022-10-27T01:07:08ZmcherkesCron issue with Joomla 4After the Joomla update, from v3 to v4, the automated launch of cron failed.
![Screenshot_from_2022-06-22_17-36-37](/uploads/9cc4a38b2c89b5809c6918fde51ab631/Screenshot_from_2022-06-22_17-36-37.png)
Have tried to launch it manually with...After the Joomla update, from v3 to v4, the automated launch of cron failed.
![Screenshot_from_2022-06-22_17-36-37](/uploads/9cc4a38b2c89b5809c6918fde51ab631/Screenshot_from_2022-06-22_17-36-37.png)
Have tried to launch it manually with wget , but received errors on the screen bellow
![Screenshot_from_2022-06-22_17-30-55](/uploads/43692831e44b6dfad9c934c36bb5c487/Screenshot_from_2022-06-22_17-30-55.png)
Our assumption is the folders and files in Joomla 4 differ from Joomla 3.5.56.0