Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-11-09T19:36:12Zhttps://lab.civicrm.org/dev/core/-/issues/4323Date is incorrect when editing a contribution2023-11-09T19:36:12ZJDrueryDate is incorrect when editing a contributionWhen editing a contribution, Date Received is always set 05/30/2013 in the edit dialog. Under Payment Details, the date is correct (see first and second images below). When adding a new date in the Edit Contribution dialog, the popup cal...When editing a contribution, Date Received is always set 05/30/2013 in the edit dialog. Under Payment Details, the date is correct (see first and second images below). When adding a new date in the Edit Contribution dialog, the popup calendar always defaults to May of 2013. The year selector doesn't allow selecting anything after 2013 (third and fourth images).
A workaround is to change Date Preferences for activityDateTime. Changing the end offset from the default setting of 10 to 0 allows for dates up to the current year. I suspect this bug is caused by the end offset being interpreted as number of years before the current year, instead of number of years after the current year. Setting the end offset to -10 has the same effect as setting it to +10 (only dates 10 years before the current year are allowed).
![image](/uploads/68cdb261f247a35c092d34cab44e8f52/image.png)
![image](/uploads/501943aeba9f96ff61e9a0cd5c7449d5/image.png)
![image](/uploads/cba0d6b5a42f2b81ec28cd8e77890062/image.png)
![image](/uploads/d4d9340b4c377ef828a4a4cadf3a09ac/image.png)5.66.0https://lab.civicrm.org/dev/translation/-/issues/52POT Scan: Update for sequentialcreditnotes, eventcart, flexmailer, etc2023-11-09T18:52:41ZtottenPOT Scan: Update for sequentialcreditnotes, eventcart, flexmailer, etcOver the past half-year, there have been a few new folders within the `civicrm-core` file-hierarchy, e.g.
```
setup
ext/sequentialcreditnotes
ext/flexmailer
ext/eventcart
ext/ewaysingle
ext/financialacls
ext/greenwich
ext/afform
ext/sea...Over the past half-year, there have been a few new folders within the `civicrm-core` file-hierarchy, e.g.
```
setup
ext/sequentialcreditnotes
ext/flexmailer
ext/eventcart
ext/ewaysingle
ext/financialacls
ext/greenwich
ext/afform
ext/search
```
The POT scanner should check these folders. Eventually, we're going to notice missing strings. There are mitigating factors - e.g. the corpus of strings isn't huge, and a lot of the strings existed before (either in different core folders or in a standalone extension), so there may be a bit of lag-time between the file-reorg and the appearance of symptoms.
There are currently two distinct localization flows -- iirc:
* The core flow - which splits strings into multiple POT files (`contribute.pot`, `event.pot`, etc), sends those to transifex, gets the PO's back out, and recombines into one MO (`civicrm.mo`). To capture the updated folders in this flow, we'd need to update `create-pot-files.sh`.
* The ext flow - which scans multiple repos, creating one POT per repo, sends those to transifex, gets the PO's back out, and publishes multiple MOs. To capture the updated folders in this flow, we'd need to update `civiextensions-update-transifex.php` and/or `create-pot-files-extensions.sh` and/or the scheduled-job.https://lab.civicrm.org/dev/core/-/issues/1630Membership auto-renew is not optional if using price set2023-11-09T05:03:26ZAllenShawMembership auto-renew is not optional if using price setThe "optional auto-renew" setting for a membership type is not honored on the contribution page if using a price set.
**Repro steps:**
1. Configure a membership type with "auto-renew option" = "Give option, but not required", e.g., "Ge...The "optional auto-renew" setting for a membership type is not honored on the contribution page if using a price set.
**Repro steps:**
1. Configure a membership type with "auto-renew option" = "Give option, but not required", e.g., "General type A"
1. Create a membership price set with a "membership type" field (radio) including at least the "General type A" membership type.
1. Create a contribution page using this price set;
1. Just in case, ensure the contribution page uses a payment processor that supports recurring contributions (not sure if this step is necessary for repro, but it would be in the real world)
1. Open the contribution page in "live" mode
1. Below the "Membership type" price field, observe the message "Membership will renew automatically."; also observe there is no checkbox labeled "Please renew my membership automatically." (which would be expected for optional auto-renewal).
**Bonus repro:**
1. Edit the configuration for "General type A" membership type, so that "auto-renew option" = "No auto-renew option".
1. Reload the contribution page and observe that auto-renew is not required.
**Bonus repro 2:**
1. Create another contribution page, this time offering the "General type A" membership type without using a price set (i.e., in the "quick config" membership type options under the Membership tab), and set the "Auto-renew" option to "Give option" for this membership type.
1. Open this contribution page in "Live" mode and observe that the checkbox labeled "Please renew my membership automatically." appears as expected.
**Other notes:**
1. Just to be sure I'm not imagining things, this did used to work; here are a couple of sources indicating I should be able to use a membership price set and still have the membership types "auto-renew is optional" setting be honored on the contribution page:
- https://civicrm.stackexchange.com/questions/10048/auto-renew-option-not-appearing-for-membership
- https://issues.civicrm.org/jira/browse/CRM-17197
1. Using the browser developer's console to edit on-page html I can make the hidden/forced checkbox visible and uncheck it; when the form is submitted in this state, the membership is created without auto-renewal; this indicates the issue is primarily with the creation of the page (e.g., hiding via JavaScript, etc.), and that form validation still allows optional renewal.https://lab.civicrm.org/dev/core/-/issues/2968Dashoard not loading - invalid assets path generated when using symlinks2023-11-09T05:03:25ZfpalewackiDashoard not loading - invalid assets path generated when using symlinksOverview
----------------------------------------
I've just installed 5.43.2 on my local machine and it appears CiviCRM is not resolving SOME assets paths correctly.
At first I thought that it's related to the project placement as my D...Overview
----------------------------------------
I've just installed 5.43.2 on my local machine and it appears CiviCRM is not resolving SOME assets paths correctly.
At first I thought that it's related to the project placement as my Drupal was available at the `dev.test/drupal` path (it needs to be there for one of my projects) - but even after I've moved the project to the domain's root (`dev.test`) it's still **spilling server paths** in the urls generating invalid assets urls in result.
The project files are located at `/vagrant/drupal` on the server
All of this results in empty dashboard page as some of the js/css files are not loaded.
Other CiviCRM pages load semi-correctly but are missing some assets (css/js files) and in result look incomplete/broken
edit:
What I found out is that **this is only happening if the project is symlinked**
I've got the project located at `/vagrant/drupal` and this dir is symlinked as `/var/www/public` and later that symlink is served by apache.
Serve the project directly from the `/vagrant/drupal` then the issue is not occurring.
Not using the symlink is not a solution here.
The issue is not existing on CiviCRM 5.12
Reproduction steps
----------------------------------------
1. Install CiviCRM 5.42/5.43.2
1. Site symlink must be served by the server instead of the real directory
1. Visit the admin dashboard
1. (Optionally) Check the browser's console for errors
1. (Optionally) Check the HTML source for invalid path's
Current behaviour
----------------------------------------
![obraz](/uploads/4cfc90c10f452995cfe09fc7ad1985a0/obraz.png)
![obraz](/uploads/1d8edfa135966ca97ffc71e7f1eff35d/obraz.png)
![obraz](/uploads/3a405a60a8b5d3834507bef46c831bee/obraz.png)
![obraz](/uploads/64b63d1355b3d6dd69de2802593cc0e2/obraz.png)
Expected behaviour
----------------------------------------
- CiviCRM assets paths are resolved correctly,
- No server paths are visible in the HTML source code
- Assets are loaded correctly
- Dashboard page is working correctly
Environment information
----------------------------------------
* __Browser:__ ANY
* __CiviCRM:__ 5.43.2/5.42
* __PHP:__ 7.2/7.3
* __CMS:__ Drupal 7.67
* __Database:__ MySQL 5.7.7
* __Web Server:__ Apache 2.4
Comments
----------------------------------------
This is a fresh install of both Drupal 7 and CiviCRM but I got this issue after upgrading the CiviCRM to 5.42 on my client's server so I started to investigate.
Page was working fine before the upgrade from CiviCRM 5.12 - It was an long overdue upgrade.
Installed 5.12 again locally, it's working just fine, no errors or anything so this must be something with the newer versions
![obraz](/uploads/dbcf99ca4437a6c3a72812086f897943/obraz.png)https://lab.civicrm.org/dev/core/-/issues/4758[PHP 8.0] Curly brace syntax for accessing array elements2023-11-08T16:24:07Zjofranzfranz@systopia.de[PHP 8.0] Curly brace syntax for accessing array elements```
FILE: civicrm-core/tools/extensions/org.civicrm.angularex/angularex.civix.php
-----------------------------------------------------------------------------------------------------------------------------------------------------------...```
FILE: civicrm-core/tools/extensions/org.civicrm.angularex/angularex.civix.php
--------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------------------------------------------------------------------------------------
247 | ERROR | [x] Curly brace syntax for accessing array elements and string offsets has been deprecated in PHP 7.4 and removed in PHP 8.0. Found: $entry{0}
--------------------------------------------------------------------------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------------------------------------------------------------------------------------
``5.69.0https://lab.civicrm.org/dev/financial/-/issues/206"Amount before tax" is wrong on online contribution receipt2023-11-08T15:33:16ZDaveD"Amount before tax" is wrong on online contribution receiptIt's because totalTaxAmount seems to have gone missing, so the amount before tax ends up the same as after tax. The total is correct though.
To reproduce:
1. Turn on and set up taxes: https://docs.civicrm.org/user/en/latest/contribution...It's because totalTaxAmount seems to have gone missing, so the amount before tax ends up the same as after tax. The total is correct though.
To reproduce:
1. Turn on and set up taxes: https://docs.civicrm.org/user/en/latest/contributions/sales-tax-and-vat/
2. Create a price set using that financial type.
3. Create an online donation for it where it's set up to send a receipt. It also happens if you use the send receipt action later from find contributions, since this also uses the online template (as opposed to editing the contribution and checking the box to send receipt, which uses the offline template).
I don't know exactly when it started. It's not working in 5.52 or master.5.69.0https://lab.civicrm.org/dev/core/-/issues/4554CiviCRM core exception when trying to import contributions2023-11-08T15:21:35ZwmortadaCiviCRM core exception when trying to import contributionsOverview
----------------------------------------
We are getting a core exception when trying to import contributions on a client site via Contribution Import.
We've have seen the same behaviour in another client site that is using the...Overview
----------------------------------------
We are getting a core exception when trying to import contributions on a client site via Contribution Import.
We've have seen the same behaviour in another client site that is using the CSV import extension.
Reproduction steps
----------------------------------------
1. Go to Import Contributions
1. Complete first three steps of import process up to the point where you preview the contributions to import
2. Click Import Now
Current behaviour
----------------------------------------
Sometimes the import works, sometimes it doesn't. This depends on the job number that CiviCRM chooses for the import.
If there **isn't** a row in the `civicrm_queue` table with a matching job number (or if you delete the matching row before import) then the import is successful.
If there **is** a row in the `civicrm_queue` table with a matching job number then the import fails and you get the error below:
```
CRM_Core_Exception: Cannot execute queue "user_job_8". The "civicrm_queue.runner" property is missing. in /var/www/html/sites/all/modules/civicrm/CRM/Queue/Runner.php on line 163
Exception trace
# Function Location
0 CRM_Queue_Runner->assertRequirementsBackground() /var/www/html/sites/all/modules/civicrm/CRM/Queue/Runner.php:163
1 CRM_Queue_Runner->runAllInteractive() /var/www/html/sites/all/modules/civicrm/CRM/Import/Form/Preview.php:120
2 CRM_Import_Form_Preview->runTheImport() /var/www/html/sites/all/modules/civicrm/CRM/Import/Form/Preview.php:100
3 CRM_Import_Form_Preview->postProcess() /var/www/html/sites/all/modules/civicrm/CRM/Core/Form.php:612
4 CRM_Core_Form->mainProcess() /var/www/html/sites/all/modules/civicrm/CRM/Core/StateMachine.php:144
5 CRM_Core_StateMachine->perform() /var/www/html/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Next.php:43
6 CRM_Core_QuickForm_Action_Next->perform() /var/www/html/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php:203
7 HTML_QuickForm_Controller->handle() /var/www/html/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php:103
8 HTML_QuickForm_Page->handle() /var/www/html/sites/all/modules/civicrm/CRM/Core/Controller.php:355
9 CRM_Core_Controller->run() /var/www/html/sites/all/modules/civicrm/CRM/Core/Invoke.php:319
10 CRM_Core_Invoke::runItem() /var/www/html/sites/all/modules/civicrm/CRM/Core/Invoke.php:69
11 CRM_Core_Invoke::_invoke() /var/www/html/sites/all/modules/civicrm/CRM/Core/Invoke.php:36
12 CRM_Core_Invoke::invoke() /var/www/html/sites/all/modules/civicrm/drupal/civicrm.module:471
13 civicrm_invoke() /var/www/html/includes/menu.inc:527
14 menu_execute_active_handler() /var/www/html/index.php:21
15 {main}
```
Expected behaviour
----------------------------------------
The import should be successful every time.
Environment information
----------------------------------------
* __CiviCRM:__ _5.62.1_
* __PHP:__ _8.1.22_ (also tried on PHP 7.4 and 8.0)
* __CMS:__ _Drupal 7.98_
* __Database:__ _MySQL 5.7.43_
* __Web Server:__ _Apache 2.4.56_
Comments
----------------------------------------
See also this post on StackExchange for the same/similar issue: https://civicrm.stackexchange.com/questions/45073/why-would-the-civicrm-queue-runner-property-be-missing
Workaround
------------
RUN THIS QUERY AT YOUR OWN RISK. Please test first.
First flush the CiviCRM cache (e.g. `cv flush`) to remove any expired items form the `civicrm_user_job` table.
Then run the following query to delete the rows in `civicrm_queue` that don't have matching rows in `civicrm_user_job`:
```sql
DELETE q FROM civicrm_queue q
LEFT JOIN civicrm_user_job uj ON q.name = CONCAT('user_job_', uj.id)
WHERE uj.id IS NULL;
```5.68.0https://lab.civicrm.org/dev/core/-/issues/4289Multi record Profile forms not saving and redirecting on "Add New Record".2023-11-08T14:04:31Zdarren.woodsMulti record Profile forms not saving and redirecting on "Add New Record".Overview
----------------------------------------
Multi record Profile forms are no longer respecting the "Redirect URL" for the Profile:-
![image](/uploads/3b349b061965a160ec7a51cfab703972/image.png)
Reproduction steps
----------------...Overview
----------------------------------------
Multi record Profile forms are no longer respecting the "Redirect URL" for the Profile:-
![image](/uploads/3b349b061965a160ec7a51cfab703972/image.png)
Reproduction steps
----------------------------------------
1. Under "Administer/Custom Data and Screens/Display Preferences" deselect "Enable Popup Forms".
2. Create a multi record custom data group and add a field.
2. Create a Profile which exposes these fields as a standalone form, setting the "Redirect URL" to be a valid URL.
3. Embed this Profile in a WordPress page using a shortcode, e.g.: [civicrm component="profile" gid="16" mode="edit" hijack="0"]
4. View the Page and click "Add new record", enter some valid data and click "Submit button.
Current behaviour
----------------------------------------
Form data is not saved and user is redirected to /civicrm/profile/edit which results in a blank WordPress page.
Expected behaviour
----------------------------------------
Form data is saved and user is redirected to the Redirect URL.
Environment information
----------------------------------------
CiviCRM 5.61.2
WordPress 6.2
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/2752Financial entity permissions2023-11-08T05:03:19ZeileenFinancial entity permissionsI hit an issue where a contact without 'Administer CiviCRM' but WITH 'view all contributions' cannot access a payment search display - [as described](https://civicrm.org/blog/eileen/searching-payments-civi)
I think the VIEW permissions ...I hit an issue where a contact without 'Administer CiviCRM' but WITH 'view all contributions' cannot access a payment search display - [as described](https://civicrm.org/blog/eileen/searching-payments-civi)
I think the VIEW permissions on all financial entities should be 'view all contributions' because otherwise we will keep hitting issues where part but not all of a contribution can be retrieved
@JoeMurray @monish.deb @seamusleehttps://lab.civicrm.org/dev/core/-/issues/4757[PHP 8.2] Using ${var} in strings is deprecated2023-11-08T02:24:46Zjofranzfranz@systopia.de[PHP 8.2] Using ${var} in strings is deprecated```
FILE: civicrm-core/CRM/Profile/Selector/Listings.php
-------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
------------------------...```
FILE: civicrm-core/CRM/Profile/Selector/Listings.php
-------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
-------------------------------------------------------------------------------------------------------------
601 | WARNING | Using ${var} in strings is deprecated since PHP 8.2, use {$var} instead. Found: ${typeName}
-------------------------------------------------------------------------------------------------------------
```5.69.0https://lab.civicrm.org/dev/core/-/issues/4038Import contribution fails in update mode even if contribution id is provided.2023-11-08T01:41:46ZKurund JalmiImport contribution fails in update mode even if contribution id is provided.Here is the error:
![Screenshot_from_2022-12-18_14-06-52](/uploads/f55f363f6c213e0280815a7d69321e44/Screenshot_from_2022-12-18_14-06-52.png)Here is the error:
![Screenshot_from_2022-12-18_14-06-52](/uploads/f55f363f6c213e0280815a7d69321e44/Screenshot_from_2022-12-18_14-06-52.png)Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/4755Activity type label has gone missing when editing case activity2023-11-08T00:54:22ZDaveDActivity type label has gone missing when editing case activityIt's blank and you get a warning about Undefined array key "label"
Probably https://github.com/civicrm/civicrm-core/pull/27498It's blank and you get a warning about Undefined array key "label"
Probably https://github.com/civicrm/civicrm-core/pull/274985.68.0https://lab.civicrm.org/dev/core/-/issues/4756CV crashes if LoginSecurity extension is enabled on Drupal8/9/102023-11-08T00:49:16ZufundoCV crashes if LoginSecurity extension is enabled on Drupal8/9/10Any cv call crashes if the [LoginSecurity](https://lab.civicrm.org/extensions/loginsecurity/-/issues) extension is enabled on D8+.
```
civicrm@c307847fd84a:/var/www/html$ cv -vvv vars:show
... [all looks good until] ...
[Bootstrap:no...Any cv call crashes if the [LoginSecurity](https://lab.civicrm.org/extensions/loginsecurity/-/issues) extension is enabled on D8+.
```
civicrm@c307847fd84a:/var/www/html$ cv -vvv vars:show
... [all looks good until] ...
[Bootstrap:notice] Call core bootstrap
In Drupal.php line 169:
[Drupal\Core\DependencyInjection\ContainerNotInitializedException]
\Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container.
Exception trace:
at /var/www/html/web/core/lib/Drupal.php:169
Drupal::getContainer() at /var/www/html/web/core/lib/Drupal.php:267
Drupal::request() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php:945
CRM_Utils_System_Drupal8->ipAddress() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/System.php:1292
CRM_Utils_System::ipAddress() at /var/www/html/web/modules/civicrm/ext/loginsecurity/CRM/Loginsecurity/BAO/LoginSecurityDevice.php:37
CRM_Loginsecurity_BAO_LoginSecurityDevice::logCurrentSession() at /var/www/html/web/modules/civicrm/ext/loginsecurity/loginsecurity.php:16
loginsecurity_civicrm_config() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:272
CRM_Utils_Hook->runHooks() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Hook/DrupalBase.php:73
CRM_Utils_Hook_DrupalBase->invokeViaUF() at /var/www/html/vendor/civicrm/civicrm-core/Civi/Core/CiviEventDispatcher.php:310
Civi\Core\CiviEventDispatcher::delegateToUF() at /var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:220
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() at /var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:56
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() at /var/www/html/vendor/civicrm/civicrm-core/Civi/Core/CiviEventDispatcher.php:263
Civi\Core\CiviEventDispatcher->dispatch() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:168
CRM_Utils_Hook->invoke() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:1440
CRM_Utils_Hook::config() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Core/Config.php:94
CRM_Core_Config::singleton() at phar:///usr/local/bin/cv/lib/src/Bootstrap.php:97
Civi\Cv\Bootstrap->boot() at phar:///usr/local/bin/cv/lib/src/Util/BootTrait.php:73
Civi\Cv\Command\ShowCommand->_boot_full() at phar:///usr/local/bin/cv/lib/src/Util/BootTrait.php:47
Civi\Cv\Command\ShowCommand->boot() at phar:///usr/local/bin/cv/src/Command/ShowCommand.php:21
Civi\Cv\Command\ShowCommand->execute() at phar:///usr/local/bin/cv/vendor/symfony/console/Command/Command.php:127
Cvphar\Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/cv/vendor/symfony/console/Application.php:637
Cvphar\Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/cv/vendor/symfony/console/Application.php:190
Cvphar\Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/cv/src/Application.php:67
Civi\Cv\Application->doRun() at phar:///usr/local/bin/cv/vendor/symfony/console/Application.php:101
Cvphar\Symfony\Component\Console\Application->run() at phar:///usr/local/bin/cv/src/Application.php:33
Civi\Cv\Application::main() at phar:///usr/local/bin/cv/bin/cv:28
require() at /usr/local/bin/cv:14
```
It looks to me like the extension is trying to call the `CRM_Utils_System::ipAddress()` function before the Drupal container is ready.
And that something like https://lab.civicrm.org/dev/core/-/commit/5e383d9d992335f2f6e743c3e1f3d0ce1b175ab9 should fix it?5.69.0https://lab.civicrm.org/dev/core/-/issues/4739Fatal Error "invalid locale" with scheduled jobs and tax receipts (and others...2023-11-07T12:25:25ZkcristianoFatal Error "invalid locale" with scheduled jobs and tax receipts (and others) and php 8.1.25 & civicrm 5.66.xAfter updating to php 8.1.25
```
PHP 8.1.25 (cli) (built: Oct 27 2023 13:02:10) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.25, Copyright (c) Zend Technologies
with Zend OPcache v8.1.25, Copyright (c), by Zend Technologies
``...After updating to php 8.1.25
```
PHP 8.1.25 (cli) (built: Oct 27 2023 13:02:10) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.25, Copyright (c) Zend Technologies
with Zend OPcache v8.1.25, Copyright (c), by Zend Technologies
```
Any attempt to call cron (cli with cv, or in the UI) fails with the following erro:
```
[28-Oct-2023 10:50:42 America/New_York] PHP Fatal error: Uncaught IntlException: datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR in /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php:105
Stack trace:
#0 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php(105): IntlDateFormatter->__construct()
#1 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php(204): PHP81_BC\{closure}()
#2 [internal function]: PHP81_BC\{closure}()
#3 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php(185): preg_replace_callback()
#4 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/Log.php(887): PHP81_BC\strftime()
#5 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/Log/file.php(294): Log->formatTime()
#6 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(590): Log_file->log()
#7 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(562): CRM_Core_Error::debug_log_message()
#8 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(442): CRM_Core_Error::debug_var()
#9 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException()
#10 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm.php(1199): CRM_Core_Invoke::invoke()
#11 /home/cvdemo/public_html/wp-includes/class-wp-hook.php(310): CiviCRM_For_WordPress->invoke()
#12 /home/cvdemo/public_html/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()
#13 /home/cvdemo/public_html/wp-includes/plugin.php(517): WP_Hook->do_action()
#14 /home/cvdemo/public_html/wp-admin/admin.php(259): do_action()
#15 {main}
thrown in /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php on line 105
```
I am finding this on:
WP 6.3.2
CiviCRM 5.64.x and greater
The only workaround I could find was temporarily reverting to php 7.45.67.0https://lab.civicrm.org/dev/core/-/issues/483New Individual: Unfilled fields "Custom Email Greeting", "Custom Postal Greet...2023-11-07T05:03:22ZPradeep Nayakpradpnayak@gmail.comNew Individual: Unfilled fields "Custom Email Greeting", "Custom Postal Greeting", "Custom Addressee" are hiddenLog in to CRM
Select menu item "Contacts"
Click submenu item "New Individual"
Input the data to the fields "First Name" and "Last Name" : [Test @name__of__creator]
Open block "Communication Preferences"
Choose for fields "Email Greeting"...Log in to CRM
Select menu item "Contacts"
Click submenu item "New Individual"
Input the data to the fields "First Name" and "Last Name" : [Test @name__of__creator]
Open block "Communication Preferences"
Choose for fields "Email Greeting", "Postal Greeting" and "Addressee": Customized
Click the button "Save"
Result: The fields "Custom Email Greeting", "Custom Postal Greeting", "Custom Addressee" are hidden (see Custom.png). The fields are visible after choosing another data in the fields "Custom Email Greeting", "Custom Postal Greeting", "Custom Addressee" then choosing 'Customized'. (see custom1.png)
Note: The same for page "New Organization"
Expected result: This fields are required. The user should be warned that the fields are required.
![custom1](/uploads/8d7265787c9266bf152b82fb607fe1ee/custom1.png)
![Custom](/uploads/63f96c694e860d5bbe0188378112f973/Custom.png)https://lab.civicrm.org/dev/core/-/issues/1206False negative on installer screen for DOES THE SERVER EXIST when installing ...2023-11-07T05:03:22ZDaveDFalse negative on installer screen for DOES THE SERVER EXIST when installing on Azure MySQL(It's not a recent issue.)
Some details at [Stackexchange 1](https://civicrm.stackexchange.com/questions/31794/civicrm-on-azure-not-finding-the-server) and [Stackexchange 2](https://civicrm.stackexchange.com/questions/28884/your-databas...(It's not a recent issue.)
Some details at [Stackexchange 1](https://civicrm.stackexchange.com/questions/31794/civicrm-on-azure-not-finding-the-server) and [Stackexchange 2](https://civicrm.stackexchange.com/questions/28884/your-database-settings-dont-appear-to-be-correct-all-green-but-still-error) but the short version is the DOES THE SERVER EXIST check in the installer is a bit odd - https://github.com/civicrm/civicrm-core/blob/5.16.2/install/index.php#L1038 - it doesn't use the username and password, and then as long as the error is less than code 2000 it says ok that's probably fine. On Azure though the error code is 9002 if you don't provide a properly formatted username and password.
So simple fix is to use the username/password. And it should also use the port for completeness but that's not the problem here.
For reference whether the username/pass is the right combo or not doesn't matter to Azure at this stage, as long as it's the right format it will return the same error code 1045 that the current code receives back from other systems when you pass nulls.
It's not clear if the check even needs to be there when there's similar checks right after - I guess to help narrow down whether the problem is the hostname or something else. But is that really needed.https://lab.civicrm.org/dev/core/-/issues/3007Use of translation functions in menu logic is... odd.2023-11-07T00:43:20ZBradley TaylorUse of translation functions in menu logic is... odd.See this screenshot of the CiviCRM nav menu with the site locale set to Spanish:
![Screenshot_2021-12-24_at_15.10.04](/uploads/869b3e37c228d258c61ee6fe40867771/Screenshot_2021-12-24_at_15.10.04.png)
The bulk of the labels are translate...See this screenshot of the CiviCRM nav menu with the site locale set to Spanish:
![Screenshot_2021-12-24_at_15.10.04](/uploads/869b3e37c228d258c61ee6fe40867771/Screenshot_2021-12-24_at_15.10.04.png)
The bulk of the labels are translated, except for the middle "Hide menu". My first thought was that this was just down to a lack of translation, but it turns out things are not that simple.
The home menu items themselves are defined as hardcoded strings in `app/public/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/Navigation.php` (`CRM_Core_BAO_Navigation::buildHomeMenu`):
```
$item['child'] = [
[
'attributes' => [
'label' => 'CiviCRM Home',
'name' => 'CiviCRM Home',
'url' => 'civicrm/dashboard?reset=1',
'weight' => 1,
],
],
[
'attributes' => [
'label' => 'Hide Menu',
'name' => 'Hide Menu',
'url' => '#hidemenu',
'weight' => 2,
],
],
[
'attributes' => [
'label' => 'Log out',
'name' => 'Log out',
'url' => 'civicrm/logout?reset=1',
'weight' => 3,
],
],
];
```
Later in `CRM_Admin_Page_AJAX::formatMenuItems` the labels are passed through the `ts()` function:
```
if (!empty($props['label'])) {
$item['label'] = ts($props['label'], ['context' => 'menu']);
}
```
Some of the strings are used elsewhere (e.g. 'CiviCRM Home') and so are caught by the translation string extraction, and therefore get translated when passed into `ts()` as a variable `$props['label']`. This isn't the case for the string 'Hide Menu' however.
I suggest that `CRM_Core_BAO_Navigation::buildHomeMenu` is updated so that each label is passed through `ts()`. I'm not sure if this should include `['context' => 'menu']` to match `CRM_Admin_Page_AJAX::formatMenuItems`.
Best practice says that variables should not be passed as the first argument to `ts()`. However, `CRM_Admin_Page_AJAX::formatMenuItems` already works in this way, so it could be seen as a break to backwards compatiability to change this. If we don't change this, then there is the edge-case where a string would be double-translated, which could lead to unexpected results when combined with word replacement. So I'm not sure if this method should be updated or not.https://lab.civicrm.org/dev/core/-/issues/4694PHP 8.2 Deprecated ${} string interpolation drupal.module file2023-11-06T18:55:40ZAndrew WassonPHP 8.2 Deprecated ${} string interpolation drupal.module file## Overview
_CiviCRM can not be installed or updated on PHP 8.2.x because of a PHP 8.2 Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._
_This issue is referenced at:_ https://lab....## Overview
_CiviCRM can not be installed or updated on PHP 8.2.x because of a PHP 8.2 Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._
_This issue is referenced at:_ https://lab.civicrm.org/dev/core/-/issues/3958#note_152174
## Reproduction steps
1. Provision a Drupal website on PHP 8.2.x
2. Install of update CiviCRM.
3. Got an error "**Fatal error:** _Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._".
## Environment information
* **CiviCRM:** version 5.66.0 (any version)
* **PHP:** _8.2.x_
* **CMS:** Drupal 7.98 (any Drupal 7 version)
* **Database:** _MySQL 5.7.7/MariaDB 10.4/..._
* **Web Server:** _Apache 2.4/Nginx 1.16/..._
## Comments
_Will supply PR shortly._
* How do I add Labels to relate this to PHP 8.2 and Drupal 7?5.68.0https://lab.civicrm.org/dev/core/-/issues/3020Environments as collections of settings2023-11-06T05:03:22ZtottenEnvironments as collections of settingsOverview
----------------------------------------
Revise the conception of "environment" so that it can more usefully model these distinctions:
* As a developer working on patches with abstract sample data, you want to toggle some sett...Overview
----------------------------------------
Revise the conception of "environment" so that it can more usefully model these distinctions:
* As a developer working on patches with abstract sample data, you want to toggle some settings/behaviors (eg `backtrace=1`).
* As a developer/trainer/etc working on with a local copy of real data, you want to toggle different settings/behaviors (eg restricting cron jobs that might communicate to real people).
This issue proposes that an `environment` is *merely and strictly* a collection of settings - changing the environment will change the active settings.
Off-shoot of discussion circa https://github.com/civicrm/civicrm-core/pull/22377#issuecomment-1006058134
Current behaviour
----------------------------------------
* Sysadmins can design bespoke meta-settings by editing `civicrm.settings.php`
* `civibuild` users can design bespoke meta-settings by placing files [`/etc/civicrm.settings.d/*.php`](https://docs.civicrm.org/dev/en/latest/tools/civibuild/#settings-civicrm)
* The setting `environment` has the primary effect of toggling some guards for `JobManager` / `mailing_backend` / `runInNonProductionEnvironment`.
Proposed behaviour
----------------------------------------
1. Use `environment` to load files which list standard/default values for various settings. eg
* `civicrm-core.git:env/Development.json` has a list of defaults to use in "Development" envs
* `/etc/civicrm.settings.d/env/Development.json` has a list of local overrides to use in "Development" envs
2. Make it easier to set `environment` on new builds, eg
* Add an install option (eg `cv core:install --env=Demo`)
* Add an env-var (eg `CIVICRM_ENVIRONMENT=Staging`) - respected by both installer+runtime
* Add a self-documenting subcommand to configure `civibuild`, eg
```bash
civibuild config --env=Development
```
3. Don't hard-code `environment` behaviors in PHP. Always use settings. eg
* For the JobManager/runInNonProductionEnvironment stuff, there should be a setting `restrictScheduledJobs`. For "Development" envs, the effective-default is `restrictScheduledJobs=true`.
For example, the standard definition of a "Development" environment might be:
```javascript
// FILE: civicrm-core.git:env/Development.json
{
"debug_enabled": true,
"backtrace": true,
"restrictScheduledJobs": true,
"assetCache": 0
}
```
But I could still tune it for my system:
```javascript
// FILE: /etc/civicrm.settings.d/env/Development.json
{
"restrictScheduledJobs": false,
"mailing_backend": {
"outBound_option" => 0,
"smtpServer": "localhost",
"smtpPort": 1025,
"smtpAuth": FALSE
}
}
```
In a similar vein, it may also help to allow `global $civicrm_setting` to target by environment:
```php
## Normal usage
$civicrm_setting['domain']['backtrace'] = 1;
## Target settings per environment.
$civicrm_setting['#Development']['backtrace'] = 1;
$civicrm_setting['#Production']['backtrace'] = 0;
```https://lab.civicrm.org/dev/core/-/issues/2855Preserve pristine ids' for further manipulation via hooks for reports2023-11-06T05:03:21ZyashodhaPreserve pristine ids' for further manipulation via hooks for reportsPreserve pristine ids' for further manipulation via hooks for reports. Ids like state_province_id, country_id, etc are all over-written by the respective look up.
There could be a use-case to display abbreviated forms for some of these ...Preserve pristine ids' for further manipulation via hooks for reports. Ids like state_province_id, country_id, etc are all over-written by the respective look up.
There could be a use-case to display abbreviated forms for some of these fields for which we need the id. I suggest that we push the pristine ids to the bunch (we already have link, hover, etc).yashodhayashodha