CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-01-11T13:56:44Zhttps://lab.civicrm.org/dev/core/-/issues/4060On 5.57.0 Joomla3, cv fails with 'Failed to start application'2023-01-11T13:56:44Zaydunsaidan.saunders@squiffle.ukOn 5.57.0 Joomla3, cv fails with 'Failed to start application'Overview
----------------------------------------
On a 5.57.0 Joomla 3.10.9 system, the `cv` command fails with 'Failed to start application'
(Logging against core rather than cv since the problem appears to be here)
Reproduction steps...Overview
----------------------------------------
On a 5.57.0 Joomla 3.10.9 system, the `cv` command fails with 'Failed to start application'
(Logging against core rather than cv since the problem appears to be here)
Reproduction steps
----------------------------------------
1. Try running various commands such as `cv vars:show`, `cv api Contact.get`
Current behaviour
----------------------------------------
```
In Factory.php line 137:
Failed to start application
vars:show [--out OUT] [--flat [FLAT]] [--level LEVEL] [--hostname HOSTNAME] [-t|--test] [-U|--user USER]
```
Expected behaviour
----------------------------------------
No error!
Environment information
----------------------------------------
* __CiviCRM:__ _5.57.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.3__
* __CMS:__ _Joomla 3.10.9._5.57.1aydunsaidan.saunders@squiffle.ukaydunsaidan.saunders@squiffle.ukhttps://lab.civicrm.org/dev/core/-/issues/4055Extension cannot found its own classes during install when opcache is enabled2023-03-16T13:12:50ZkainukExtension cannot found its own classes during install when opcache is enabledI start with the following configuration:
* PHP 8.1.7 _Using the docker image FROM php:8.1.7-apache-buster_
* OPCache enabled _standard configuration_
* Buildkit _CiviCRM install for Drupal 9_ see below:
````
civibuild create patch \
...I start with the following configuration:
* PHP 8.1.7 _Using the docker image FROM php:8.1.7-apache-buster_
* OPCache enabled _standard configuration_
* Buildkit _CiviCRM install for Drupal 9_ see below:
````
civibuild create patch \
--type drupal9-demo \
--civi-ver master \
--url http://patch.kainuk \
--cms-ver 9.5
````
Now, when I enable the Action Provider extension (just from the extension screen), the following error is thrown.
````
Error: Class "Civi\ActionProvider\Symfony\Component\DependencyInjection\DefinitionAdapter" not found in action_provider_civicrm_container() (line 15 of /buildkit/build/patch/web/sites/default/files/civicrm/ext/action-provider/action_provider.php)
````
`cv flush` lets the problem disappear, and for the Action Provider that is no problem because only code is installed (it does not change the database). However, other extensions can have more problems because the installation is interrupted, and possible incomplete.
The problem is, however, reproducible. When I disable the extension, and uninstall it, the error reappears after installing.
I did some duty time in the debugger and found the following code in the extension class loader (CRM_Extension_ClassLoader)
````php
$file = $this->getCacheFile();
if (file_exists($file)) {
$this->loader = require $file;
}
else {
$this->loader = $this->buildClassLoader();
$ser = serialize($this->loader);
file_put_contents($file,
sprintf("<?php\nreturn unserialize(%s);", var_export($ser, 1))
);
}
````
`$this->buildClassLoader()` is an expensive procedure, so after calculation the result is saved for reuse. When a new extension is installed, the saved file is removed because it does not contain the new extension configuration. A new classloader with all the extension stuff is calculated and an updated file is written.
For loading the class, the PHP construct `require` is used. This construct was designed for loading PHP code. The assumption is that PHP code does not change much, and OPCache used this assumption, to store the file in memory. The risk is here is that not the newly written configuration is used, but an old one from memory. On my configuration, I observed with the PHP debugger, that when the `hook_civicrm_container` the old classloader is loaded with require. Just put a breakpoint before the `$this->loader = require $file` line.
When the OPCache is disabled, the problem does not appear.5.59.0https://lab.civicrm.org/dev/core/-/issues/4028CMS Database Integration - Per-table prefixes are no longer supported2023-02-06T22:26:31ZolivierCMS Database Integration - Per-table prefixes are no longer supportedOverview
----------------------------------------
Since Drupal 8.2 per-table prefixes are no longer supported, so System Settings / CMS Database Integration menu should no longer display the 'Drypal 7' mapping table
Example use-case
---...Overview
----------------------------------------
Since Drupal 8.2 per-table prefixes are no longer supported, so System Settings / CMS Database Integration menu should no longer display the 'Drypal 7' mapping table
Example use-case
----------------------------------------
1. Click on **System Settings -> CMS Database Integration**.
Current behaviour
----------------------------------------
$databases['default']['default']['prefix']= [
'default' => 'drupal_',
'civicrm_acl' => '',
'civicrm_acl_cache' => '',
'civicrm_acl_contact_cache' => '',
'civicrm_acl_entity_role' => '',
'civicrm_action_log' => '',
'civicrm_action_mapping' => '',
'civicrm_action_schedule' => '',
'civicrm_activity' => '',
'civicrm_activity_contact' => '',
....
Proposed behaviour
----------------------------------------
$databases['civicrm']['default'] = [
'database' => 'xxxxxx',
'username' => 'xxxxxx',
'password' => 'set your db password',
'host' => '127.0.0.1',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
'namespace' => 'Drupal\Core\Database\Driver\mysql',
'collation' => 'utf8mb4_general_ci',
];
Comments
----------------------------------------
_Anything else you would like the reviewer to note._5.60.0https://lab.civicrm.org/dev/core/-/issues/4026Custom field value not saved first time after membership type changed2024-03-15T01:10:51ZdanmurrayCustom field value not saved first time after membership type changedOverview
----------------------------------------
Membership type B has a custom field set but Membership type A does not. When a membership of type A is edited and changed to type B, the custom field set appears in the editor and value...Overview
----------------------------------------
Membership type B has a custom field set but Membership type A does not. When a membership of type A is edited and changed to type B, the custom field set appears in the editor and values can be set for the custom fields. However when the membership is saved, the custom field values are not remembered. The values are only remembered if the membership is edited a second time, and the custom fields are set and saved again.
Reproduction steps
----------------------------------------
Go to https://dmaster.demo.civicrm.org/
Add new custom field set used for Memberships -> General
Add new field to field set: a dropdown field with option 1 and option 2
Find any membership of type Student and edit it
Change membership type from Student to General, the new custom field appears for editing
![image](/uploads/2eae0c3199111e0605609f82408c7961/image.png)
Select option 1 in the custom field and save the membership
![image](/uploads/6863ef5c318c458537b090be791cfde6/image.png)
View the membership - the custom field value is not set
![image](/uploads/ddb4b7fc4f85ca0b9c1ceeaee751e449/image.png)
Edit the membership again, again select option 1 in the custom field and save the membership
View the membership again - the custom field value is now set
![image](/uploads/61578005173f4af4c10fb784446e4cd2/image.png)
Current behaviour
----------------------------------------
The first time a custom field value is set after a membership type is changed, the value is not remembered. It is only remembered after the second time it is saved.
Expected behaviour
----------------------------------------
The custom field value should be remembered the first time it is saved.
Environment information
----------------------------------------
Reproduced on https://dmaster.demo.civicrm.org/ 9th Dec 2022
Comments
----------------------------------------5.72.0https://lab.civicrm.org/dev/core/-/issues/4022PHP 7.4, 8+ TypeError: array_flip(): Argument #1 ($array) must be of type arr...2023-01-05T02:18:09ZeldonthianPHP 7.4, 8+ TypeError: array_flip(): Argument #1 ($array) must be of type array, string givenOverview
----------------------------------------
Fresh install seemed to work, after going through checklist and setting up preferences,
somehow the search preferences page now throws this error. not sure what the exact cause is.
http...Overview
----------------------------------------
Fresh install seemed to work, after going through checklist and setting up preferences,
somehow the search preferences page now throws this error. not sure what the exact cause is.
https://civicrm.stackexchange.com/q/43060/14046
Reproduction steps
----------------------------------------
This seems to come up whenever ANY of the options are changed and attempting to save on search preferences page. i.e., custom fields, search options or quick search fields selection/deselection, reorder, etc.
Current behaviour
----------------------------------------
upon saving any changes on the search preferences page.
go back to the page, all ordering gone, default fields only, and selections.. just click save, and things begin to work as first install. Can not select/deselect any field to be saved. new selections are not saved..
```
TypeError: array_flip(): Argument #1 ($array) must be of type array, string given in /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/SettingTrait.php on line 380 #0 /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/SettingTrait.php(380): array_flip('\x01sort_name\x01cont...')
#1 /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/SettingTrait.php(224): CRM_Admin_Form_Setting::reorderSortableOptions('quicksearch_opt...', Array)
#2 /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/Setting.php(66): CRM_Admin_Form_Setting->addFieldsDefinedInSettingsMetadata()
#3 /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/Setting/Search.php(47): CRM_Admin_Form_Setting->buildQuickForm()
#4 /code/vendor/civicrm/civicrm-core/CRM/Core/Form.php(689): CRM_Admin_Form_Setting_Search->buildQuickForm()
#5 /code/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Display.php(76): CRM_Core_Form->buildForm()
#6 /code/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Admin_Form_Setting_Search), 'display')
#7 /code/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Admin_Form_Setting_Search), 'display')
#8 /code/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle('display')
#9 /code/vendor/civicrm/civicrm-core/CRM/Utils/Wrapper.php(98): CRM_Core_Controller->run()
#10 /code/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(292): CRM_Utils_Wrapper->run('CRM_Admin_Form_...', 'Search Preferen...', Array)
#11 /code/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem(Array)
#12 /code/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke(Array)
#13 /code/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke(Array)
#14 /code/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke(Array)
#15 [internal function]: Drupal\civicrm\Controller\CivicrmController->main(Array, '')
#16 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#17 /code/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#18 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#19 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#20 /code/vendor/symfony/http-kernel/HttpKernel.php(169): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /code/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /code/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /code/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /code/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /code/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /code/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /code/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /code/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /code/web/core/lib/Drupal/Core/DrupalKernel.php(709): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /code/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#31 {main}
```
Expected behaviour
----------------------------------------
Search preferences should be able to be saved with changes.. and accessible at
civicrm/admin/setting/search?reset=1
Environment information
----------------------------------------
* __CiviCRM: 5.55.2, 5.56
* __PHP: 7.4, 8.0, 8.1
* __CMS: Drupal 9.4.8
* __Database: MariaDB 10.4.25
* __Web Server: nginx/1.21.65.57.0https://lab.civicrm.org/dev/core/-/issues/4012Contribution Page credit card expiry months are incorrectly offset when the t...2022-12-17T23:11:48ZbgmContribution Page credit card expiry months are incorrectly offset when the timezone is WhitehorseFound an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster...Found an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster / drupal7:
- login as the demo user
- change the user's timezone to America/Whitehorse
Then go to a contribution page:
https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=2
![image](/uploads/ea61f948003f258501391a3c90e2a6e3/image.png)5.58.0https://lab.civicrm.org/dev/core/-/issues/4000only update `contributionRecur` when `templateContribution` is updated IF it ...2023-03-16T21:47:09Zeileenonly update `contributionRecur` when `templateContribution` is updated IF it is actively marked as suchIn https://github.com/civicrm/civicrm-core/pull/21473 code was added to update the Currency and Amount of the template contribution is updated. However, the code appears to me to be too aggressive and updating the amount or currency of A...In https://github.com/civicrm/civicrm-core/pull/21473 code was added to update the Currency and Amount of the template contribution is updated. However, the code appears to me to be too aggressive and updating the amount or currency of ANY contribution in the series causes it to update. There are good reasons to update individual contributions without any implicit template update.5.61.0https://lab.civicrm.org/dev/core/-/issues/3994Auto renew options for membership types are not saving for a contribution page2023-12-07T00:06:08ZKurund JalmiAuto renew options for membership types are not saving for a contribution pageSteps to replicate on vanilla CiviCRM install
- Membership type configuration
![Screenshot_from_2022-11-18_10-51-50](/uploads/02d45ded17660376a461d6738c287c48/Screenshot_from_2022-11-18_10-51-50.png)
- In the contribution page configur...Steps to replicate on vanilla CiviCRM install
- Membership type configuration
![Screenshot_from_2022-11-18_10-51-50](/uploads/02d45ded17660376a461d6738c287c48/Screenshot_from_2022-11-18_10-51-50.png)
- In the contribution page configuration try to make option 'Required' and save.
![Screenshot_from_2022-11-18_10-52-30](/uploads/9f50922426022defea7b99c53a386def/Screenshot_from_2022-11-18_10-52-30.png)
- However, it not saved
![Screenshot_from_2022-11-18_10-52-41](/uploads/57717f65ddd9e0df971821cafade9752/Screenshot_from_2022-11-18_10-52-41.png)5.69.0Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3977Payment processor handling of `billing-country-5` inconsistent2022-11-11T02:07:08ZeileenPayment processor handling of `billing-country-5` inconsistentThis is a follow on from https://lab.civicrm.org/dev/core/-/issues/3918 / https://github.com/civicrm/civicrm-core/pull/24232 / https://github.com/civicrm/civicrm-core/pull/24903
The original PR https://github.com/civicrm/civicrm-core/pu...This is a follow on from https://lab.civicrm.org/dev/core/-/issues/3918 / https://github.com/civicrm/civicrm-core/pull/24232 / https://github.com/civicrm/civicrm-core/pull/24903
The original PR https://github.com/civicrm/civicrm-core/pull/24903 did not explain what problem was being solved & it didn't come out in the review process.... so I think in the first instance we should establish that.
This is my best guess to reverse engineer the point of the original change ...
All calls to `doPayment` are expected to pass through the documented parameters https://docs.civicrm.org/dev/en/latest/extensions/payment-processors/create/#billing-fields - in this case the relevant parameter is `billing_country-5`. That parameter is a bit of a pig so some/ most code ALSO passes `country` - and this seems to be done consistently enough that `Paypal` and `Authorize.net` (our oldest processors) are using `country`.
I do think it is important that when payment processors are sending out an array the contract of what keys they should pass out is clear. If we want to deprecate `billing_country-5` in favour of 'country' that seems OK (we would need to update the docs) - but at the moment there seems to be some code that passes `country` in a format that is not correct - which led to the regression.
I feel like in the first instance we should find & fix (with tests) the reported instances of that that came up in https://lab.civicrm.org/dev/core/-/issues/3918
Looking at the code for `setBillingCountry` and the validation - I have a feeling that code may only be hit from the unit tests? In which case the case for reducing the validation seems strong enough.
One thing we COULD do in the test suite is register a hook on all unit tests for `alterPaymentProcessor` & validate the `country` field in it - that might track down any errant ones
I should note that `PropertyBag` isn't a subsitute for us fixing core code to pass the contract parameters5.56.0https://lab.civicrm.org/dev/core/-/issues/3963Mix of auto renewing membership types and non-auto renewing membership types ...2024-03-15T21:08:28ZEdselopezMix of auto renewing membership types and non-auto renewing membership types not handled properly in pricesets.Overview
----------------------------------------
On a membership price set, it is possible to specify a mix of auto renewing memberships as well as non auto renewing memberships, but allow the selection of only one at a time (by virtue ...Overview
----------------------------------------
On a membership price set, it is possible to specify a mix of auto renewing memberships as well as non auto renewing memberships, but allow the selection of only one at a time (by virtue of it being a radio select). It seems CiviCRM doesn't know how to handle this properly, as it assumes that multiple options can be selected.
The code here https://github.com/civicrm/civicrm-core/blob/master/CRM/Price/BAO/PriceSet.php#L1290 seems to fetch the HTML type (which should be the deciding factor on if the payment processor is compatible with handling multiple concurrent transactions) but doesn't really do anything with it.
Reproduction steps
----------------------------------------
1. Create a membership price set
2. Add a price field of type radio
3. Proceed to create selections having membership types selected, but be sure to include a mix of auto renewing membership types and non-auto renewing membership types
4. Add the price field on a contribution page and click save.
Current behaviour
----------------------------------------
(I have tested this for PayPal - Website Payments Standard, but it should be replicable for any payment processor which doesn't support "MultipleConcurrentPayments".
Error shown when trying to save
"Price Set
The membership price set associated with this online contribution allows a user to select BOTH an auto-renew AND a non-auto-renew membership. This requires submitting multiple processor transactions, and is not supported for one or more of the payment processors enabled under the Amounts tab."
Expected behaviour
----------------------------------------
The contribution form should recognize that the price field is a single select field, and therefore allow me to save the configuration.
Environment information
----------------------------------------
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _Master/5.20.0/5.19.1/5.18.2/..._ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.0/7.1/7.2/7.3/...__
* __CMS:__ _Backdrop 1.5/Drupal 7.30/Joomla 3.3/WordPress 4.5/..._
* __Database:__ _MySQL 5.7.7/MariaDB 10.4/..._
* __Web Server:__ _Apache 2.4/Nginx 1.16/..._5.69.5seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/3962Bool token formatting2022-11-18T14:27:07ZeileenBool token formattingI hit an issue today where we were using tokens in smarty. We already have this format in several message templates - e.g
`{if '{contact.current_employer}'} ({contact.current_employer}){/if}`
The single quotes are necessary as `{if } ...I hit an issue today where we were using tokens in smarty. We already have this format in several message templates - e.g
`{if '{contact.current_employer}'} ({contact.current_employer}){/if}`
The single quotes are necessary as `{if } {/if} ` will fail - so it renders to `{if ''} {/if} `
However, the problem we hit is if the employer is `O'Malley Construction'` which renders as `{if 'O'Malley Construction'} {/if} `
I think the solution is to add a bool modifier & allow any token to be passed through it - it would also simplify the smarty a little - ie
`{if {contact.current_employer|bool}} ({contact.current_employer}){/if}`5.57.0https://lab.civicrm.org/dev/core/-/issues/3937Importing "No" values to Boolean field results in empty2023-04-03T02:21:49ZelilisseckImporting "No" values to Boolean field results in emptyOverview
----------------------------------------
Contact imports to custom "Yes or No" fields work with values 1 or 0. "Yes" also appears to work.
If you import a "No" value, however, the field will be blank for that contact instead o...Overview
----------------------------------------
Contact imports to custom "Yes or No" fields work with values 1 or 0. "Yes" also appears to work.
If you import a "No" value, however, the field will be blank for that contact instead of having the "No"/0 label/value.
Technical details
----------------------------------------
["strtoboolstr"](https://github.com/civicrm/civicrm-core/blob/4ce53ba3de860a5d9aac1b1bbd22b7a29e839af2/CRM/Utils/String.php#L424) gets run twice on this data. [Once on the raw value returning a boolean](https://github.com/civicrm/civicrm-core/blob/902fc38d0d6cd9d09ee02f30cc6621747151a06a/CRM/Import/Parser.php#L1602) and [once later in the code here](https://github.com/civicrm/civicrm-core/blob/902fc38d0d6cd9d09ee02f30cc6621747151a06a/CRM/Contact/Import/Parser/Contact.php#L328)
When you run this on a boolean value (you shouldn't, according to the comments, but perhaps we should check for this), "Yes"/true will _look_ like it's working okay because the preg_match will match for (bool)true but it won't match for (bool)false. I'm sure this has something to do with a PHP oddity I know nothing about but related to the fact that `strlen((bool)true)` is `1` and `strlen((bool)false)` is `0`.
Proposed solution is:
1) Don't run strtoboolstr twice. We don't need that second iteration of it because it's already been run on the data. I'm not sure of any other impacts for this so also:
2) Write a test for importing to a Yes/No field with the 6 values that should work (1,0,yes,no,true,false). I've started writing this test following examples but i'm having trouble getting my import data actually in properly to run the assertEquals on. I will open a WIP PR with this test.
Any other thoughts welcome!
Reproduction steps
----------------------------------------
1. Create a custom field with data type "Yes or No"
2. Create a csv to import first,last,custom_fieldID with data for your custom field "Yes" and "No"
3. Run the import normally through the GUI in the Contacts > Import Contacts workflow
4. Observe custom field results on the imported contacts
Expected behaviour
----------------------------------------
According to code comments, this type of field import should accept "1", "0", "Yes", "No", "true", "false" and they should all fill a "Yes or No" field correctly.
Environment information
----------------------------------------
This was reproduced on the master branch in d9 (5.56.alpha1)5.61.0https://lab.civicrm.org/dev/core/-/issues/3935PHP Notice: Undefined offset in _civicrm_member_roles_sync()2022-12-01T02:47:03ZAndrew WassonPHP Notice: Undefined offset in _civicrm_member_roles_sync()Overview
----------------------------------------
This is an issue that I have noticed in several Drupal 7 / CiviCRM websites. When the CiviCRM Member Roles Synch activity takes place, my recent log messages get inundated with PHP Notice...Overview
----------------------------------------
This is an issue that I have noticed in several Drupal 7 / CiviCRM websites. When the CiviCRM Member Roles Synch activity takes place, my recent log messages get inundated with PHP Notices:
> Notice: Undefined offset: x in _civicrm_member_roles_sync() (line 607 of /civicrm/drupal/modules/civicrm_member_roles/civicrm_member_roles.module).
Reproduction steps
----------------------------------------
1. Enable civicrm member roles sync.
1. Add a rule to synch some member type to a role.
1. Configure to run at Drupal Cron
1. Run Cron and observe as Reports -> Recent Log Messages get filled with notices.
Steps to Resolve
----------------------------------------
line 607 of /civicrm/drupal/modules/civicrm_member_roles/civicrm_member_roles.module contains the following statement:
`if (is_array($memberroles[$membership['membership_type_id']])) {`
If the array is not set then the notice will be raised so if we check it first as follows, the notice goes away:
`if (isset($memberroles[$membership['membership_type_id']]) && is_array($memberroles[$membership['membership_type_id']])) {`
Environment information
----------------------------------------
* __CiviCRM:__ _5.54.0_
* __PHP:__ _7.4/8.1__
* __CMS:__ _Drupal 7.92_
* __Database:__ _MySQL 5.7.4_
* __Web Server:__ _Apache 2.x_5.57.0https://lab.civicrm.org/dev/core/-/issues/3926Need to increase data size for 'url' column on 'civicrm_website' table2022-10-28T15:46:49ZyashodhaNeed to increase data size for 'url' column on 'civicrm_website' tableOverview
----------------------------------------
Currently _url_ column of the _civicrm_website_ table is of maxlength 124. This is not sufficient for some website in which case it truncates and renders them useless.
Proposed behavio...Overview
----------------------------------------
Currently _url_ column of the _civicrm_website_ table is of maxlength 124. This is not sufficient for some website in which case it truncates and renders them useless.
Proposed behaviour
----------------------------------------
The Proposal is to change the maxlength of the _url_ column of the _civicrm_website_ table to 255 instead of 124.5.56.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3918Contribution in Australia returns yellow error banner with "setBillingCountry...2022-11-22T22:57:09ZjhungerfordContribution in Australia returns yellow error banner with "setBillingCountry expects ISO 3166-1 alpha-2 country code"Overview
----------------------------------------
After upgrading to CiviCRM 5.54.0, test donations result in a yellow error banner with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```. I haven't tried a real ...Overview
----------------------------------------
After upgrading to CiviCRM 5.54.0, test donations result in a yellow error banner with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```. I haven't tried a real donation. We are located in Australia, and we use Stripe as the payment processor.
I asked a question about this issue here: https://chat.civicrm.org/civicrm/pl/atwjzr4ozf8fbdkokzegze9iiw
Reproduction steps
----------------------------------------
1. Upgrade a CiviCRM site to 5.54.0
2. Navigate to a Test-drive contribution page
3. Attempt to make a test contribution
Current behaviour
----------------------------------------
A yellow error banner appears with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```.
Expected behaviour
----------------------------------------
The test contribution should be processed, and the donor should be redirected to the thank-you page.
Environment information
----------------------------------------
* __Browser:__ Chromium 105.0.5195.125 (Official Build) Arch Linux (64-bit)
* __CiviCRM:__ 5.54.0 (upgraded from 5.53.0)
* __PHP:__ 7.4.30
* __CMS:__ Drupal 7.92, also tested on Drupal 9.4.7
* __Database:__ 10.3.36-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
* __Web Server:__ Apache 2.4
* __civicrm-Stripe version:__ 6.7.11, also tested on 6.7.10
* __Payment Shared version:__ 1.2.9, also tested on 1.2.8
Comments
----------------------------------------
I'll post an example of a failing test contribution page in the chat linked above.
Reverting to CiviCRM 5.53.0 results in a working contribution page.5.55.1https://lab.civicrm.org/dev/core/-/issues/3905Need to increase data size for 'data' column on 'civicrm_job_log' table2022-10-12T13:27:08ZyashodhaNeed to increase data size for 'data' column on 'civicrm_job_log' tableOverview
----------------------------------------
Currently _data_ column of the _civicrm_job_log_ table is of data type TEXT. This is sufficient for running most jobs. However we have a some comprehensive log for mailchimp sync extensio...Overview
----------------------------------------
Currently _data_ column of the _civicrm_job_log_ table is of data type TEXT. This is sufficient for running most jobs. However we have a some comprehensive log for mailchimp sync extension and it would throw errors when running the job.
`INSERT INTO civicrm_job_log (domain_id , job_id , name , command , ...", "1406 ** Data too long for column 'data' at row 1`
Proposed behaviour
----------------------------------------
The Proposal is to change the data type of the _data_ column of the _civicrm_job_log_ table to LONGTEXT instead of TEXT.5.56.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3893Searchkit: Change Rewrite field to textarea2023-11-15T14:51:59ZshaneonabikeSearchkit: Change Rewrite field to textareaHey there,
After realizing that we can use SMARTY conditions in Searchkit this really took one of our clients systems to an entire new level. Thanks so much for all the hard work on Searchkit!
## Problem
Presently, the Searchkit Rewri...Hey there,
After realizing that we can use SMARTY conditions in Searchkit this really took one of our clients systems to an entire new level. Thanks so much for all the hard work on Searchkit!
## Problem
Presently, the Searchkit Rewrite field is a textfield, which is fine if you want to append a few characters to the end or before a value. It gets extremely hard to read and also modify (I have to use a texteditor beside) to modify if you start using SMARTY attributes.
In the situation below, we are generating one column that contains one of two values using a SMARTY ```if```.
![Selection_001](/uploads/57432093e023009c9b311a77f1fe00eb/Selection_001.png)
to generate
![Selection_002](/uploads/1a87132c9a0e9ce080c8e9bd2418c5ea/Selection_002.png)
## Proposed solution
Would it be difficult to modify this field to a textarea instead? It would make it much easier to modify and read. I really don't know if this would be a massive change but I think it would really help. Also, we could provide a help icon to inform people that they can use SMARTY in these fields as long as they put quotes around the different values being retrieved (this was the element I was missing when I first tried and didn't get it working.
![Selection_003](/uploads/10973172b4588429613fbc87616ea879/Selection_003.png)5.56.0https://lab.civicrm.org/dev/core/-/issues/3844Dummy payment processor should be flagged as such on LIVE page2023-01-31T09:53:32ZyashodhaDummy payment processor should be flagged as such on LIVE pageWhen dummy payment processor is configured for contribution pages/ event, there is no indication that is NOT a real transaction. This could be confusing and we should flag any LIVE page that is configured with dummy processor.
![dummy](...When dummy payment processor is configured for contribution pages/ event, there is no indication that is NOT a real transaction. This could be confusing and we should flag any LIVE page that is configured with dummy processor.
![dummy](/uploads/7cbf8624f40a97ab1c89d123ab4b4941/dummy.png)
![con_page](/uploads/1ea201d5b3c96e90e5385b5f82596996/con_page.png)
No indication that this is a Dummy payment processor
![contr+page](/uploads/456a92cbdafa407721c1ac4545cbb22e/contr+page.png)
This would similar to what we already do for TEST transactions.5.59.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3802Symfony 6 can't find the EventDispatcher when adding hooks that are defined i...2022-08-15T02:11:04ZDaveDSymfony 6 can't find the EventDispatcher when adding hooks that are defined in getSubscribedEventsThey did this, and also a little higher up you can see they removed the constructor: https://github.com/symfony/event-dispatcher/commit/0bc2e0d8ba8a6eb353a42d19890f57a3dee410a5#diff-f3f413e17bbd20e345b3721f9c4556ed5e319d133c32bf7492dffd5...They did this, and also a little higher up you can see they removed the constructor: https://github.com/symfony/event-dispatcher/commit/0bc2e0d8ba8a6eb353a42d19890f57a3dee410a5#diff-f3f413e17bbd20e345b3721f9c4556ed5e319d133c32bf7492dffd55a024d0efR57
So what happens is this https://github.com/civicrm/civicrm-core/blob/da21dc84950b013a03d3fe5e72e12e7d652cce7f/Civi/Core/Container.php#L93 is expecting it to be called `dispatcher`, but this https://github.com/symfony/event-dispatcher/commit/0bc2e0d8ba8a6eb353a42d19890f57a3dee410a5#diff-f3f413e17bbd20e345b3721f9c4556ed5e319d133c32bf7492dffd55a024d0efR57 is expecting it to be called `event_dispatcher`, so that returns early and never calls `$container->findTaggedServiceIds('kernel.event_listener'`, so doesn't pick up any of the getSubscribedEvents hooks, e.g. civi.token.eval and others.
The naive fix of calling `$container->setAlias('event_dispatcher', 'dispatcher')` doesn't seem to be enough and causes a crash later which I haven't tracked down yet.5.54.0https://lab.civicrm.org/dev/core/-/issues/3774Can't submit backend credit card contribution unless you have at least one pa...2022-08-04T21:07:47ZJonGoldCan't submit backend credit card contribution unless you have at least one payment processor that supports a future start dateIf you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* S...If you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* Submit a backend credit card contribution with PayPal Pro. Should go through (or tell you invalid credentials).
* Delete the default processor of type "Dummy Payment Processor".
* Submit another backend credit card contribution with PayPal Pro.
### Expected Result
Absence of a dummy test processor shouldn't affect the ability to submit a credit card processor.
### Actual result
```
Please correct the following errors in the form fields below:
Date Received is a required field.
```
### Why
In `CRM_Contribution_Form_AbstractEditPayment::assignProcessors()` is this line:
```
$this->assign('processorSupportsFutureStartDate', CRM_Financial_BAO_PaymentProcessor::hasPaymentProcessorSupporting(['FutureRecurStartDate']));
```
This will return `TRUE` if *any* payment processor supports a future start date. Which in turn causes the `receive_date` to appear on `templates/CRM/Contribute/Form/Contribution.tpl`.
Without the `receive_date` on the form, even hidden, you can't submit the form.
The workaround is to create a dummy processor on your site. I have to run, but tomorrow I'll try to put together a PR that fixes this at the template level.
Is this a regression? I mean, technically yes, but it's two years old. And tricky to catch because the test suite creates the dummy processor in `setUp()`. To catch this we might have to move that out of `setUp()` and into its own helper function.5.52.0JonGoldJonGold