Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-12-19T22:19:50Zhttps://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/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/4484Feature request: New contact buttons on the API 4 autocomplete widget2023-11-01T18:20:41ZbrienneFeature request: New contact buttons on the API 4 autocomplete widgetOverview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such a...Overview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such as for selecting a Contributor on a backend contribution.
![Selection_015](/uploads/30fc0ecdd3268ebc5906ce0aa06dae9a/Selection_015.png)
Example use-case
----------------------------------------
1. Add the *Existing Contact* field to a FormBuilder form
1. A user can look up a contact to select, but if there are no results/a new one is needed, they can click a **New Individual** button to add one without being redirected from the original form
Current behaviour
----------------------------------------
The APIv4 autocomplete widget does not allow for creating new contacts.
![Selection_014](/uploads/d97659f7dddfd4858bd316acb0dda2b6/Selection_014.png)
Proposed behaviour
----------------------------------------
The APIv4 autocomplete widget should have feature parity when it comes to creating new contacts on the spot as the Select2 optionhttps://lab.civicrm.org/dev/core/-/issues/4466Roles - Define default taxonomy (for standalone deployments)2023-12-04T21:13:40ZtottenRoles - Define default taxonomy (for standalone deployments)Now that we have a mechanism for [defining users and roles in standalone](https://lab.civicrm.org/dev/core/-/issues/4053), there's another question: What roles should we define by default? How do we maintain those roles? A few ideas:
* ...Now that we have a mechanism for [defining users and roles in standalone](https://lab.civicrm.org/dev/core/-/issues/4053), there's another question: What roles should we define by default? How do we maintain those roles? A few ideas:
* __Light-touch with open taxonomy.__ This is what D7 does -- you just get 2-3 roles (anonymous, authenticated, admin). Then the site-builder can fill-in more roles to taste. When you upgrade, you may need to re-tune the roles.
* __Strong defaults with hackable taxonomy__ This is what WP does -- you get several roles out-of-the-box. Site-builders are not particularly encouraged to refine them, but it is possible (esp using APIs/add-ons). When you upgrade, it can (*I assume*) add or update roles.
* __Library of example roles__: This idea comes from looking at Google Cloud -- they have an extensive library of roles. Some of the roles are similar/overlapping (e.g. there are older and newer flavors of "File Admin"/"Storage Admin"). The upshot is that you get a presumption of continuity while still allowing the taxonomy to evolve. The downside is that the list is a bit overwhelming. But treating these as templates might mitigate that (*library of possible roles is long -- but the local site only enables a handful*).
There are some related questions - if you have strong defaults or a library of examples, then how do you deal with extensions (*i.e. the list of available perms may fluctuate depending on the extensions*).https://lab.civicrm.org/dev/core/-/issues/4465Afform - Default value for boolean filters not displayed correctly in all fie...2023-11-06T00:00:55Zxavi-xalocAfform - Default value for boolean filters not displayed correctly in all field types## Overview
A PR (https://github.com/civicrm/civicrm-core/pull/25605) has been merged to solve issues ( https://lab.civicrm.org/dev/core/-/issues/4113, for instance) with default values for booleans filters in Search Kit. Although that ...## Overview
A PR (https://github.com/civicrm/civicrm-core/pull/25605) has been merged to solve issues ( https://lab.civicrm.org/dev/core/-/issues/4113, for instance) with default values for booleans filters in Search Kit. Although that PR solves many of the issues identified, some problems still remain.
## Current behaviour
Although filter works fine when the field is of type "radio button", that's not the case when the type is "select" or "checkboxes":
- Select: Works fine when "yes" is the default value, but doesn't show default value when it is set to "no"
- Checkboxes: Doesn't get checked when default value is set to "yes".
## Environment information
* **CiviCRM:** _5\.61.2_Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/4459Uncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLoca...2023-08-04T12:51:55ZyurgUncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLocationTypeLabel() must be of the type string, null returnedOverview
----------------------------------------
WordPress contacts import from CSV, CiviCRM 5.61.2. (not reproduceable on dmaster).
https://civicrm.stackexchange.com/questions/45332/contacts-import-issue-at-crm-contact-import-form-map...Overview
----------------------------------------
WordPress contacts import from CSV, CiviCRM 5.61.2. (not reproduceable on dmaster).
https://civicrm.stackexchange.com/questions/45332/contacts-import-issue-at-crm-contact-import-form-mapfieldgetlocationtypelabel
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Import Contacts**.
2. Add a CSV file, leave all settings intact and click **Continue**.
3. Got a Wordpress WSOD and php error log message "**Uncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLocationTypeLabel() must be of the type string, null returned in /data/sites/web/pedesdev/www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Form/MapField.php:480**".
Expected behaviour
----------------------------------------
Process to the next import step
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* CiviCRM: 5.61.2
* PHP: 7.4.3
Comments
----------------------------------------
Fixed by changing from
- protected function getLocationTypeLabel($type): string {
to
- protected function getLocationTypeLabel($type): ?string {
in www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Form/MapField.php:480
however not sure if this is the right way.https://lab.civicrm.org/dev/core/-/issues/4456Saving event with custom file field gives fatal error2024-02-07T19:47:09ZwouterhSaving event with custom file field gives fatal error1. Create a file field for event(s).
1. Go to an existing event containing this custom file field – Press save.
1. Red alert box "network error" and the custom fields don't display.
`TypeError: Cannot access offset of type string on st...1. Create a file field for event(s).
1. Go to an existing event containing this custom file field – Press save.
1. Red alert box "network error" and the custom fields don't display.
`TypeError: Cannot access offset of type string on string in include() (regel 59 van /var/www/html/web/sites/default/files/civicrm/templates_c/nl_NL/%%1D/1DB/1DB03A28%%CustomField.tpl.php).`
Using CiviCRM 5.62.0 & PHP 8. Doesn't happen in PHP 7.5.71.0https://lab.civicrm.org/dev/core/-/issues/4451parent_id constraint on civicrm_activity can lead to data loss2023-08-08T22:21:55ZDaveDparent_id constraint on civicrm_activity can lead to data lossIt has probably always been like this but it seems dangerous.
1. Create an activity.
1. Let's give it subject "a1" so we can tell it apart.
1. Fill out the schedule followup section at the bottom. Give it subject "a2".
1. Save.
1. Delet...It has probably always been like this but it seems dangerous.
1. Create an activity.
1. Let's give it subject "a1" so we can tell it apart.
1. Fill out the schedule followup section at the bottom. Give it subject "a2".
1. Save.
1. Delete activity "a1".
Expected result: Just a1 is deleted.
Actual result: a1 and a2 are both deleted.
The constraint should be ON DELETE SET NULL.
As with the fix for original_id, in a large db an upgrade script might timeout or take a long time, so would need to direct the user to do it manually.5.64.0https://lab.civicrm.org/dev/core/-/issues/4450Standalone: set the page title2023-11-28T19:33:31ZbgmStandalone: set the page titleCurrently the `<title>` attribute (in head) is empty.Currently the `<title>` attribute (in head) is empty.RichRichhttps://lab.civicrm.org/dev/core/-/issues/4449Status check about accessible dirs can be slow2023-07-26T23:18:26ZDaveDStatus check about accessible dirs can be slowThis is a followup to https://github.com/civicrm/civicrm-core/pull/26771#issuecomment-1629756698 and https://github.com/civicrm/civicrm-core/pull/26889.
Putting more info than needed in here cuz I already typed it.
I think the speedup ...This is a followup to https://github.com/civicrm/civicrm-core/pull/26771#issuecomment-1629756698 and https://github.com/civicrm/civicrm-core/pull/26889.
Putting more info than needed in here cuz I already typed it.
I think the speedup in 26889 wasn't quite a "fix", and there was maybe more than one issue there. In general as noted in 26771 servers that only handle one request at a time, synchronously, will have trouble with these checks because of deadlock, i.e.
```
> (caller) call for status check
=> (server) hello, processing
> call for file
=> hello, hold please
... second caller hangs up eventually ...
> first request can now finish
=> server switches phone line to caller on hold => oh you're not there anymore, ok.
```
And a gotcha during testing is it's not sufficient to just simulate the second GET using tool X (browser, curl-cli, cv, etc), it needs to be the combo of doing the GET from within code that is triggered by the first GET.
For the php built-in webserver, while the `isBrowsable` check could be legit, the status check about `isDirAccessible` might give a false positive even if it _was_ working, since .htaccess files don't do anything for the built-in webserver, and there's no nginx-like config you could do to secure it. So maybe it is best to just skip this check for built-in, in which case I would skip it for all php versions not just `<8`.
But in general, to make this work with one-request-at-a-time servers seems like it would require an architecture redesign. Using guzzle/curl to specify a timeout makes the time shorter, so is an improvement, but it doesn't seem possible to ever get a correct result for `isDirAccessible` on these servers at the moment, and at least for the built-in one, we already know it's not possible to prevent GET'ing files under sites/default/files/civicrm.
I don't know a way to detect if a (potentially remote) server is one-request-at-a-time, without just waiting for a timeout. Ideally the check would be skipped for _any_ such server.
So let's do as much as we can: Use guzzle/curl to set the shorter timeout, and skip for the known built-in server.5.65.0https://lab.civicrm.org/dev/core/-/issues/4445Upgrade to 5.65 shows incorrect message about Petition - Signature Added mess...2023-07-27T01:33:29ZlarsssandergreenUpgrade to 5.65 shows incorrect message about Petition - Signature Added message template upgradeWhen upgrading to 5.65 on a recently rebuild install with no customization of any message templates, the following message appears:
The default copies of the message templates listed below will be updated to handle new features or corre...When upgrading to 5.65 on a recently rebuild install with no customization of any message templates, the following message appears:
The default copies of the message templates listed below will be updated to handle new features or correct a problem. Your installation has customized versions of these message templates, and you will need to apply the updates manually after running this upgrade. View detailed instructions.
Petition - signature added - Update to use tokens
---
@eileen, looks like this is from [#26546](https://github.com/civicrm/civicrm-core/pull/26546).5.65.0https://lab.civicrm.org/dev/financial/-/issues/216Financial Batches: remove the creation of activities for New/Edit2023-08-09T18:28:27ZbgmFinancial Batches: remove the creation of activities for New/EditI fell down a rabbit hole while testing the New Financial Batch form, and noticed that it creates an activity whenever a batch is created or edited. It also creates an activity when the batch is exported, but not when closed or deleted.
...I fell down a rabbit hole while testing the New Financial Batch form, and noticed that it creates an activity whenever a batch is created or edited. It also creates an activity when the batch is exported, but not when closed or deleted.
The "Create Batch" and "Edit Batch" activities do not seem useful to me. I would leave the "Export Accounting Batch" activity for now.
Any objections to removing?
(I'm creating this issue for visibility, but will send a PR that might be more clear)
cc @JoeMurray5.66.0