CiviCRM Core issues
https://lab.civicrm.org/dev/core/-/issues
2024-03-07T12:13:16Z
https://lab.civicrm.org/dev/core/-/issues/5002
Number field input validation does not respect decimal separator (member cust...
2024-03-07T12:13:16Z
CΓ©sar
Number field input validation does not respect decimal separator (member custom field)
## Overview
Hello I think its related to: https://lab.civicrm.org/dev/core/-/issues/4941 and https://lab.civicrm.org/dev/core/-/issues/4154
## Reproduction steps
1. Under Administer > Localization > Languages, Currency, Locations, set...
## Overview
Hello I think its related to: https://lab.civicrm.org/dev/core/-/issues/4941 and https://lab.civicrm.org/dev/core/-/issues/4154
## Reproduction steps
1. Under Administer > Localization > Languages, Currency, Locations, set "Thousands Separator" to "." (dot) and "Decimal Delimiter" to "," (comma).
2. Create a custom field extending Memberships. Data type: Number. (money works)
3. Edit an existing member (or: add a new member). In the number field, enter a number that includes a comma, such as "1,5".
## Current behaviour
Validation fails with the error message "**Error One of parameters (value: 1,5) is not of the type Float**"
## Environment information
Tested on https://dmaster.demo.civicrm.org/ 5.72.alpha1
https://lab.civicrm.org/dev/core/-/issues/5001
PHP 8.1 Event Warnings
2024-02-12T19:29:56Z
tresero
PHP 8.1 Event Warnings
There are many warnings when using PHP 8.1.
They should probably be cleaned up at some point, since they are just clogging up the server logs.
**Environment**: WordPress with CiviCRM
**Description**: Several PHP warnings were encount...
There are many warnings when using PHP 8.1.
They should probably be cleaned up at some point, since they are just clogging up the server logs.
**Environment**: WordPress with CiviCRM
**Description**: Several PHP warnings were encountered during the registration process for an event. These warnings suggest issues with undefined array keys and attempts to read properties on null values in the CiviCRM templates and extensions.
**Errors Encountered**:
1. PHP Warning: Attempt to read property "value" on null in **`wp-content/uploads/civicrm/templates_c/en_US/.../Register.tpl.php`** on various lines.
2. PHP Warning: Undefined array key "confirm_footer_text" in **`wp-content/uploads/civicrm/templates_c/en_US/.../Confirm.tpl.php`**.
3. PHP Warning: Undefined array key "showBlocks" in **`wp-content/uploads/civicrm/templates_c/en_US/.../showHide.tpl.php`**.
4. PHP Warning: Undefined array key "hideBlocks" in the same file.
5. PHP Warning: Undefined array key "elemType" in the same file.
6. PHP Warning: Trying to access array offset on value of type null in **`wp-content/uploads/civicrm/ext/ogp-1.4/ogp.php`**.
7. PHP Warning: Undefined array key "lineItem", "pcpBlock", "totalTaxAmount" in **`wp-content/uploads/civicrm/templates_c/en_US/.../Confirm.tpl.php`**.
8. PHP Warning: Undefined array key 1 in **`wp-content/uploads/civicrm/templates_c/en_US/.../EventInfoBlock.tpl.php`**.
**Referer**: All warnings were encountered during the event registration process, with URLs sanitized to **`https://[sanitized_url].org/civicrm/event/register/...`**.
**Note**: The specific template and extension files, along with the exact line numbers for each warning, are available upon request. The warnings suggest missing data handling in the template logic or missing initialization of expected data structures.
https://lab.civicrm.org/dev/core/-/issues/5000
SearchKit: Allow formatting of the totals in the footer
2024-02-14T10:06:39Z
simon.hermann
SearchKit: Allow formatting of the totals in the footer
SearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either ...
SearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either an option to choose a formatting (decimal separators, thousand separators, currencies if applicable etc) or if the total would reflect the formatting of the column it sums.
https://lab.civicrm.org/dev/core/-/issues/4999
Imagine a world without CodeGen
2024-03-05T04:32:51Z
colemanw
Imagine a world without CodeGen
Currently we use `CRM_Core_CodeGen` to take our schema/xml files and generate DAO.php, install.sql and uninstall.sql files, which have to be periodically regenerated. This is a minor inconvenience for a core developer, a potential gotcha...
Currently we use `CRM_Core_CodeGen` to take our schema/xml files and generate DAO.php, install.sql and uninstall.sql files, which have to be periodically regenerated. This is a minor inconvenience for a core developer, a potential gotcha for an extension developer, and a major coordination difficulty across *all* extensions in `universe` (whenever any aspect of the generated code needs to change).
But what if we didn't have to generate those files? What if we could read schema information directly from the xml (or potentially a different source).
Current Structure:
-----
**Key:** βοΈ Handwritten file | π Generated file
| File | Purpose | In Core | In Extensions |
| --- | --- | --- | --- |
| βοΈ `schema/xml` | Canonical declaration of entity + all metadata | Run `setup.sh -g` | Run `civix generate:entity-boilerplate` |
| π Install sql | Add schema tables | `civicrm.mysql` | `auto_install.sql` |
| π Uninstall sql | Drop schema tables | `civicrm_drop.mysql` | `auto_uninstall.sql` |
| π Entity.php | Declare entity's existence | `AllCoreTables.data.php` | `*.entityType.php` + `entity-types-php` mixin |
| π `CRM/Core/I18n/SchemaStructure.php` | Lists localizable table columns | Seems kinda redundant with other metadata? | Doesn't exist |
| βοΈ `CRM_Core_DAO` | Base class for all generated DAOs | All DAOs extend this class | Extension DAOs also extend core class (makes change-management across `universe` difficult) |
| π `CRM_*_DAO_*` | Generated from the xml file | Must be generated | Must be generated |
The generated DAO file (including stuff it inherits from `CRM_Core_DAO`) serves a variety of purposes:
1. OO class that allows a database table to be used like a php object, e.g.
```
$contact = new CRM_Contact_DAO_Contact();
$contact->first_name = 'Bob';
$contact->save();
```
This is a neat idea and probably ahead of its time, but is basically deprecated now, mostly because, in a relational database, having access to only one table at a time isn't very useful. If it weren't for legacy core & extension code still using this pattern, we could drop it in favor of more robust tools like APIv4.
2. Static methods like `fields()` and `indices()` which return the data from the xml file in php format.
3. Localizes strings, because CodeGen wraps titles and labels in `ts()`.
4. A bunch of other random static methods (e.g. `disableFullGroupByMode()`) which seem like they'd be better-placed in a separate utility class.
New Structure
----------
If we no longer want to generate files and just read from a canonical source, then the main question is, "what should be the canonical source of entity metadata?"
1. **Stick with XML:** Keep the existing xml files but delete the generated stuff. Parse the xml at runtime to get that data.
- Pro: It's already there, no rewrites needed.
- Con: Poor DX (developers don't generally enjoy writing XML files).
- Con: It's very slow (the slowest by far of all the options) so heavy caching would be needed.
- Con: Without generating php files, another method of i18n string extraction would be needed ([such as this](https://github.com/civicrm/civistrings/pull/17)).
2. **DAO Files:** Delete the `schema/xml` files and run everything from the generated DAO files, which going forward will be hand-edited instead of regenerated.
- Pro: DAO files are already there.
- Con: Also poor DX (the boilerplate in those files would not be fun to write/edit by hand).
3. **Somewhere Else:** Move schema info to e.g. json files or better-structured PHP files.
- Pro: DX and performance could be optimized.
- Con: XML files must be rewritten (could be scripted).
- Con: Migration management for core and extensions.
Supporting Dynamic/Virtual Entities
--------
It's also worth keeping in mind that there are now several types of entities that are dynamic & share a DAO:
- Multi-record custom fields
- ECK entities
- SearchKit materialized displays
The DAO structure doesn't cope with this very well, as the assumption has always been 1-1-1 between table, entity & DAO class. But while we're restructuring things let's avoid adding more code that makes this assumption. An ideal DAO from the POV of virtual entities would be an object that takes entity name in its constructor & initializes itself with the appropriately corresponding tablename, fields, and other metadata.
https://lab.civicrm.org/dev/core/-/issues/4998
[PHP 8] Undefined properties @ ext/Standaloneusers DAO
2024-02-14T10:05:35Z
jofranz
franz@systopia.de
[PHP 8] Undefined properties @ ext/Standaloneusers DAO
PhpStan is reporting some Undefined properties on current master @ eacd1f4206fab41f0cf14bcbd80b5f7187b42bea
```
β standaloneusers (master) phpstan analyse -c ~/repositories/ext/phpstan.d11.neon.dist -l 0 . ...
PhpStan is reporting some Undefined properties on current master @ eacd1f4206fab41f0cf14bcbd80b5f7187b42bea
```
β standaloneusers (master) phpstan analyse -c ~/repositories/ext/phpstan.d11.neon.dist -l 0 . β β
50/50 [ββββββββββββββββββββββββββββ] 100%
------ --------------------------------------------------------------------------------------
Line CRM/Standaloneusers/DAO/Role.php
------ --------------------------------------------------------------------------------------
100 Access to an undefined property CRM_Standaloneusers_DAO_Role::$__table.
π‘ Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ --------------------------------------------------------------------------------------
------ --------------------------------------------------------------------------------------
Line CRM/Standaloneusers/DAO/Session.php
------ --------------------------------------------------------------------------------------
74 Access to an undefined property CRM_Standaloneusers_DAO_Session::$__table.
π‘ Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ --------------------------------------------------------------------------------------
------ --------------------------------------------------------------------------------------
Line CRM/Standaloneusers/DAO/User.php
------ --------------------------------------------------------------------------------------
171 Access to an undefined property CRM_Standaloneusers_DAO_User::$__table.
π‘ Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ --------------------------------------------------------------------------------------
------ --------------------------------------------------------------------------------------
Line CRM/Standaloneusers/DAO/UserRole.php
------ --------------------------------------------------------------------------------------
65 Access to an undefined property CRM_Standaloneusers_DAO_UserRole::$__table.
π‘ Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ --------------------------------------------------------------------------------------
------ ---------------------------------------------------------------------
Line Civi/Api4/Action/User/PasswordReset.php
------ ---------------------------------------------------------------------
36 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
45 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ ---------------------------------------------------------------------
------ ---------------------------------------------------------------------
Line Civi/Api4/Action/User/SendPasswordReset.php
------ ---------------------------------------------------------------------
40 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ ---------------------------------------------------------------------
------ -----------------------------------------------------------------------------------------
Line Civi/Api4/Action/User/WriteTrait.php (in context of class Civi\Api4\Action\User\Create)
------ -----------------------------------------------------------------------------------------
56 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
59 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ -----------------------------------------------------------------------------------------
------ ---------------------------------------------------------------------------------------
Line Civi/Api4/Action/User/WriteTrait.php (in context of class Civi\Api4\Action\User\Save)
------ ---------------------------------------------------------------------------------------
56 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
59 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ ---------------------------------------------------------------------------------------
------ -----------------------------------------------------------------------------------------
Line Civi/Api4/Action/User/WriteTrait.php (in context of class Civi\Api4\Action\User\Update)
------ -----------------------------------------------------------------------------------------
56 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
59 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ -----------------------------------------------------------------------------------------
------ ------------------------------------------------------------------------------------------------------------
Line Civi/Standalone/Security.php
------ ------------------------------------------------------------------------------------------------------------
24 Unsafe usage of new static().
π‘ See: https://phpstan.org/blog/solving-phpstan-error-unsafe-usage-of-new-static
328 Regex pattern is invalid: Unknown modifier '+' in pattern: /
^
\$([a-z0-9-]{1,32}) # Match 1 algorithm identifier
(\$v=[0-9+])? # Match 2 optional version
(\$[a-z0-9-]{1,32}=[a-zA-Z0-9/+.-]*(?:,[a-z0-9-]{1,32}=[a-zA-Z0-9/+.-]*)*)? # 3: optional parameters
\$([a-zA-Z0-9/+.-]+) # Match 4 salt
\$([a-zA-Z0-9/+]+) # Match 5 B64 encoded hash
$/x
------ ------------------------------------------------------------------------------------------------------------
[ERROR] Found 15 errors
```
Touches #4072
Config used: https://github.com/jofranz/civicrm-code-scans
https://lab.civicrm.org/dev/core/-/issues/4997
Anonymous visitors cannot access a contribution page with financial type by A...
2024-02-12T21:08:46Z
andyburns
Anonymous visitors cannot access a contribution page with financial type by ACL enabled
On a vanilla WP 6.4.3 and CiviCRM 5.70 dummy site, enabling `Enable Access Control by Financial Type` results in the contribution page being inaccessible and redirects back to the home page.
The goal of using this feature is for back-e...
On a vanilla WP 6.4.3 and CiviCRM 5.70 dummy site, enabling `Enable Access Control by Financial Type` results in the contribution page being inaccessible and redirects back to the home page.
The goal of using this feature is for back-end contribution access for different types of users.
![image.png](/uploads/bea2e67bd300271650dbef7de9267ba7/image.png)
* `add_contributions_of_type_donation` and `view_contributions_of_type_donation` permissions are given to the `anonymous_user` role.
* I've [hit this before](https://chat.civicrm.org/civicrm/pl/5wzfkebnebfutbi1o8orkxsh8c) but that was when these permissions were missing and I updated the [docs to reflect this requirement](https://docs.civicrm.org/user/en/latest/initial-set-up/permissions-and-access-control/#financial-type-permissions).
* Event Registration pages work without issue when the financial types are properly granted to the anonymous_user `add_contributions_of_type_event_fee` and `view_contributions_of_type_event_fee`
* I've reproduced this issue back to at least Civi 5.68. Last worked on 5.65.1. I'm sure others use this feature so odd I'm reporting but there you go.
## Anonymous User Permissions
* access_all_custom_data
* access_civimail_subscribe_unsubscribe_pages
* access_uploaded_files
* add_contributions_of_type_donation
* add_contributions_of_type_event_fee
* add_contributions_of_type_member_dues
* make_online_contributions
* profile_create
* profile_edit
* profile_view
* register_for_events
* sign_civicrm_petition
* view_contributions_of_type_donation
* view_contributions_of_type_event_fee
* view_contributions_of_type_member_dues
* view_event_info
* view_my_invoices
* view_public_civimail_content
## Backtrace error:
```plaintext
2024-02-09 19:16:28+0000 [debug] $API Request Authorization failed = #0 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(151): CRM_Core_Error::backtrace("API Request Authorization failed", TRUE)
#1 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php(256): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOGetAction))
#2 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Financial/BAO/FinancialType.php(181): Civi\Api4\Generic\AbstractAction->execute()
#3 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/ContributionPage.php(822): CRM_Financial_BAO_FinancialType::getIncomeFinancialType(TRUE)
#4 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Api4/Utils/FormattingUtil.php(306): CRM_Contribute_BAO_ContributionPage::buildOptions("financial_type_id", "validate", (Array:2))
#5 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Api4/Utils/FormattingUtil.php(257): Civi\Api4\Utils\FormattingUtil::getPseudoconstantList((Array:37), "financial_type_id:name", (Array:2), "get")
#6 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Api4/Query/Api4SelectQuery.php(108): Civi\Api4\Utils\FormattingUtil::formatOutputValues((Array:2), (Array:48), "get", (Array:2))
#7 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/DAOGetAction.php(107): Civi\Api4\Query\Api4SelectQuery->run()
#8 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/DAOGetAction.php(94): Civi\Api4\Generic\DAOGetAction->getObjects(Object(Civi\Api4\Generic\Result))
#9 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Api4/Provider/ActionObjectProvider.php(72): Civi\Api4\Generic\DAOGetAction->_run(Object(Civi\Api4\Generic\Result))
#10 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(156): Civi\Api4\Provider\ActionObjectProvider->invoke(Object(Civi\Api4\Generic\DAOGetAction))
#11 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php(256): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOGetAction))
#12 /home/user/example.org/wp-content/plugins/civicrm/civicrm/api/api.php(91): Civi\Api4\Generic\AbstractAction->execute()
#13 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/API/EntityLookupTrait.php(111): civicrm_api4("ContributionPage", "get", (Array:3))
#14 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/ContributeFormTrait.php(81): CRM_Contribute_Form_ContributionBase->lookup("ContributionPage", "financial_type_id:name")
#15 /home/user/example.org/wp-content/plugins/civicrm/civicrm/ext/financialacls/financialacls.php(431): CRM_Contribute_Form_ContributionBase->getContributionPageValue("financial_type_id:name")
#16 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(276): financialacls_civicrm_preProcess("CRM_Contribute_Form_Contribution_Main", Object(CRM_Contribute_Form_Contribution_Main))
#17 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook/WordPress.php(136): CRM_Utils_Hook->runHooks((Array:16), "civicrm_preProcess", 2, "CRM_Contribute_Form_Contribution_Main", Object(CRM_Contribute_Form_Contribution_Main), NULL, NULL, NULL, NULL)
#18 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Core/CiviEventDispatcher.php(314): CRM_Utils_Hook_WordPress->invokeViaUF(2, "CRM_Contribute_Form_Contribution_Main", Object(CRM_Contribute_Form_Contribution_Main), NULL, NULL, NULL, NULL, "civicrm_preProcess")
#19 /home/user/example.org/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(251): Civi\Core\CiviEventDispatcher::delegateToUF(Object(Civi\Core\Event\GenericHookEvent), "hook_civicrm_preProcess", Object(Civi\Core\UnoptimizedEventDispatcher))
#20 /home/user/example.org/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(73): Symfony\Component\EventDispatcher\EventDispatcher->callListeners((Array:1), "hook_civicrm_preProcess", Object(Civi\Core\Event\GenericHookEvent))
#21 /home/user/example.org/wp-content/plugins/civicrm/civicrm/Civi/Core/CiviEventDispatcher.php(263): Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object(Civi\Core\Event\GenericHookEvent), "hook_civicrm_preProcess")
#22 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(168): Civi\Core\CiviEventDispatcher->dispatch("hook_civicrm_preProcess", Object(Civi\Core\Event\GenericHookEvent))
#23 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(476): CRM_Utils_Hook->invoke((Array:2), "CRM_Contribute_Form_Contribution_Main", Object(CRM_Contribute_Form_Contribution_Main), NULL, NULL, NULL, NULL, "civicrm_preProcess")
#24 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(733): CRM_Utils_Hook::preProcess("CRM_Contribute_Form_Contribution_Main", Object(CRM_Contribute_Form_Contribution_Main))
#25 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Display.php(76): CRM_Core_Form->buildForm()
#26 /home/user/example.org/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Contribute_Form_Contribution_Main), "display")
#27 /home/user/example.org/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), "display")
#28 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle("display")
#29 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(322): CRM_Core_Controller->run((Array:3), NULL)
#30 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:18))
#31 /home/user/example.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
#32 /home/user/example.org/wp-content/plugins/civicrm/civicrm.php(1231): CRM_Core_Invoke::invoke((Array:3))
#33 /home/user/example.org/wp-content/plugins/civicrm/includes/civicrm.shortcodes.php(433): CiviCRM_For_WordPress->invoke()
#34 /home/user/example.org/wp-includes/shortcodes.php(433): CiviCRM_For_WordPress_Shortcodes->render_single((Array:5), "", "civicrm")
#35 [internal function](): do_shortcode_tag((Array:7))
#36 /home/user/example.org/wp-includes/shortcodes.php(273): preg_replace_callback("/\[(\[?)(civicrm)(?![\w-])([^\]\/]*(?:\/(?!\])[^\]\/]*)*?)(?:(\/)\]|\](?:([^\...", "do_shortcode_tag", "[civicrm component=\"contribution\" id=\"1\" action=\"transact\" mode=\"live\...")
#37 /home/user/example.org/wp-content/plugins/civicrm/includes/civicrm.shortcodes.php(232): do_shortcode("[civicrm component=\"contribution\" id=\"1\" action=\"transact\" mode=\"live\...")
#38 /home/user/example.org/wp-includes/class-wp-hook.php(324): CiviCRM_For_WordPress_Shortcodes->prerender(Object(WP))
#39 /home/user/example.org/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, (Array:1))
#40 /home/user/example.org/wp-includes/plugin.php(565): WP_Hook->do_action((Array:1))
#41 /home/user/example.org/wp-includes/class-wp.php(830): do_action_ref_array("wp", (Array:1))
#42 /home/user/example.org/wp-includes/functions.php(1336): WP->main("")
#43 /home/user/example.org/wp-blog-header.php(16): wp()
#44 /home/user/example.org/index.php(17): require("/home/user/example.org/wp-blog-header.php")
#45 {main}
```
## System Info
PHP version 8.0.30
**Extensions**
* AuthX: Version 5.70.0
* CiviCampaign: Version 5.70.0
* CiviContribute: Version 5.70.0
* CiviEvent: Version 5.70.0
* CiviMail: Version 5.70.0
* CiviMember: Version 5.70.0
* CiviReport: Version 5.70.0
* CKEditor4: Version 5.70.0
* Financial ACLs: Version 5.70.0
* FlexMailer: Version 5.70.0
* Form Core: Version 5.70.0
* reCAPTCHA: Version 5.70.0
* SearchKit: Version 5.70.0
* Sequential credit notes: Version 5.70.0
* Theme: Greenwich: Version 5.70.0
Thoughts? Is there a missing setting or is this an actual bug?
5.71.0
https://lab.civicrm.org/dev/core/-/issues/4996
Standalone - user documentation for user management functionality
2024-02-23T16:54:58Z
ufundo
Standalone - user documentation for user management functionality
Would be good to write some user documentation for how to use the standaloneusers user management screen.
I think this belongs somewhere here: https://docs.civicrm.org/sysadmin/en/latest/setup/ ?
Would be good to write some user documentation for how to use the standaloneusers user management screen.
I think this belongs somewhere here: https://docs.civicrm.org/sysadmin/en/latest/setup/ ?
https://lab.civicrm.org/dev/core/-/issues/4995
Standalone - JWT for password resets
2024-03-07T22:30:13Z
ufundo
Standalone - JWT for password resets
Switch Standaloneusers password reset mechanism to use JWT, instead of custom format.
PR from @pfigel is here: https://github.com/civicrm/civicrm-core/pull/28505
Switch Standaloneusers password reset mechanism to use JWT, instead of custom format.
PR from @pfigel is here: https://github.com/civicrm/civicrm-core/pull/28505
Patrick Figel
pfigel@greenpeace.org
Patrick Figel
pfigel@greenpeace.org
https://lab.civicrm.org/dev/core/-/issues/4994
Standalone - issues with haveibeenpwned on password setting screen?
2024-03-26T11:33:19Z
ufundo
Standalone - issues with haveibeenpwned on password setting screen?
Rich
Rich
https://lab.civicrm.org/dev/core/-/issues/4993
Standalone - disable CMS user sync on Standalone
2024-03-07T20:40:09Z
ufundo
Standalone - disable CMS user sync on Standalone
The CMS user sync doesn't make sense when using standaloneusers so should be disabled
The CMS user sync doesn't make sense when using standaloneusers so should be disabled
ufundo
ufundo
https://lab.civicrm.org/dev/core/-/issues/4992
Standalone - front-end theming
2024-02-14T10:01:23Z
ufundo
Standalone - front-end theming
@artfulrobot suggests: provide a template for front facing pages. People can edit that file
(manually) to suit. It should not get overwritten on upgrade.
@artfulrobot suggests: provide a template for front facing pages. People can edit that file
(manually) to suit. It should not get overwritten on upgrade.
Rich
Rich
https://lab.civicrm.org/dev/core/-/issues/4991
Standalone SSO - third-party authentication for single sign on, such as Hybri...
2024-02-14T10:01:04Z
ufundo
Standalone SSO - third-party authentication for single sign on, such as HybridAuth or LDAP or SAML
Would be great to build out the standalone users functionality.
Either in Standaloneusers extension or a separate one?
Would be great to build out the standalone users functionality.
Either in Standaloneusers extension or a separate one?
ufundo
ufundo
https://lab.civicrm.org/dev/core/-/issues/4989
5.69.4>5 regression - Multiple currency issues in contribution page workflow
2024-02-13T19:58:40Z
JKingsnorth
5.69.4>5 regression - Multiple currency issues in contribution page workflow
Testing latest master we have multiple issues when setting a contribution page to a non-default currency.
In all the following examples I changed the currency of the contribution page to JPY.
---
1 - 'Confirm' and 'Thank You' pages sh...
Testing latest master we have multiple issues when setting a contribution page to a non-default currency.
In all the following examples I changed the currency of the contribution page to JPY.
---
1 - 'Confirm' and 'Thank You' pages show default instead of contribution page set currency
![image](/uploads/cfd5a92065599d8c937b806e1289e508/image.png)
---
2 - 'currency' variable is not being set correctly in ContributionBase, which could be affecting client side payment processors?
![image](/uploads/bb16b6e00884f747dbf18f0f6aaa22eb/image.png)
'currencyID' uses the form _values, 'currency' is using the default site currency.
5.70.1
https://lab.civicrm.org/dev/core/-/issues/4988
Standalone: doesn't install because of missing session class
2024-03-07T21:23:58Z
Rich
Standalone: doesn't install because of missing session class
Standalone installer (web based) fails because it tries to start session before it's found the standaloneusers/ session class; presumably, before it's booted extensions(possibly?).
Note it is possible to install from civibuild, but the ...
Standalone installer (web based) fails because it tries to start session before it's found the standaloneusers/ session class; presumably, before it's booted extensions(possibly?).
Note it is possible to install from civibuild, but the [other methods](https://docs.civicrm.org/installation/en/latest/standalone/) don't work.
See @clarkac https://chat.civicrm.org/civicrm/pl/neac84z6ztrymendzimmtqa18a
> Fatal error: Uncaught Error:
> Class "Civi\Standalone\SessionHandler" not found in
> .../web/core/CRM/Utils/System/Standalone.php
>
> followed by a stack trace followed by:
> thrown in .../web/core/CRM/Utils/System/Standalone.php on line 556
ufundo
ufundo
https://lab.civicrm.org/dev/core/-/issues/4987
standalone: agree distribution format(s)
2024-03-08T23:55:45Z
Rich
standalone: agree distribution format(s)
Options:
**OPTION 1** Encourage composer-template
**OPTION 2** Encourage tar-ball (with current structure)
**OPTION 3** Encourage tar-ball (with composer-like structure)
(And is it one of those options -- or two of those options)
Mo...
Options:
**OPTION 1** Encourage composer-template
**OPTION 2** Encourage tar-ball (with current structure)
**OPTION 3** Encourage tar-ball (with composer-like structure)
(And is it one of those options -- or two of those options)
Moved from [chat](https://chat.civicrm.org/civicrm/pl/4pwoodpzufd4z8x5wqguwhprbw) to save an unwieldy thread therein.
@totten
> i guess in theory # 1+# 3 sounds better than # 1+ # 2. but
>
> 1. even drupal.org appears to be following a structure like # 1+# 2
> 2. the workflow of "download+extract full tarball for composer-project" is a little weird for upgrades. (you need to delete+reset some folders -- but not other folders)
> 3. i'm not entirely sure how to reconcile # 3 with the regular RC workflow. i'm sure it can be sorted; but it's more of a conversation
>
@demerit (sorry, don't know your handle here)
> tarball tarball tarball
...
@wmortada
> For initial installation, having a tarball that a user can just download and install is preferable because it is easier and lowers the barrier to entry. But is this going to make upgrades more tricky for them? What could we do to make upgrades easier in this scenario?
@artfulrobot
> composer rules out hosting where you dont have shell access. Personally I'm cool with that, because you kinda need shell access to do things properly. Ftp for fun, shell for serious. (What a t shirt slogan!).
>
> I dont like messy things like unpack this tarball, replace directories a, b, c swap out file d.
>
> But I also don't love composer esp when it requires scripts to run. I tend to have my php as not owned by www-data, so the scripts won't run as www-data. Also in staging, where the httpd is in a container, I like to be able to manage the codebase from outside the container, but this will probably use a different php version. I'm happy to change my ways, though
>
> Other projects I work with:
>
> Nextcloud: provides a fairly solid upgrade script, even a web ui for upgrades, though they encourage CLI invocation to avoid timeouts. Files owned by www-data so the code writes the code. The CLI call to upgrade handles everything: checks, downloads, checksum checks, backups, moving files, running db migrations. It's solid and reliable, and there's a 'repair' command, in case something goes wrong (eg you tried your luck on the web ui method...)
>
> Roundcube mail: provides an upgrade script as part of the new release. So you download tar, extract to tmp/ run a script from there like install-to.php /path/to/installation/dir/
>
> I sometimes deploy by git too. I guess I could composer offline, commit, push, pull. I sometimes find composer flaky. There's one package that won't download or such. And it's slow (a zillion http requests) and can't be run offline.
>
> But it let's you add bits to your site, e.g. if you have civi as part of a bigger project. Which is nice.
>
> Tarballs are nice. Can be signed. Single download. Works offline.
>
> Barrier to entry: hmmm. Idk tbh. You need CLI access at mo, and as long as there's a reliable few commands to run that can be copy pasted it makes no difference?
>
> I'd quite like to be able to upgrade by git pull! Is that any more realistic in standalone? Probably red herring :blowfish:
>
> Let's not do this though...
> curl https://civicrn.org/gimmestandalone | sudo bash
@clarkac
> Please don't do anything that rules out hosting without shell access. That would discourage people from getting started with Civi, as I did and I've helped around 15 charities to get Civi - all hosted without shell access. I'm sure there are many in amongst the 4,000 D7 sites that don't have shell access.
>
> # 2 on the list is similar to what I do with upgrades with D7 - after backing up, delete the CiviCRM code folder and unpack the tarballs into it. That's so easy, and adding some more to that would be no problem
https://lab.civicrm.org/dev/core/-/issues/4986
Montreal Sprint Topics
2024-02-28T23:28:14Z
colemanw
Montreal Sprint Topics
Brainstorming ideas for the Montreal Sprint
- Afform testing. Build on [Dave D's extension](https://lab.civicrm.org/extensions/afformminktests)
- Accessibility improvements: priorities may include
- accordion overhaul (#3294 / [dev/...
Brainstorming ideas for the Montreal Sprint
- Afform testing. Build on [Dave D's extension](https://lab.civicrm.org/extensions/afformminktests)
- Accessibility improvements: priorities may include
- accordion overhaul (#3294 / [dev/user-interface#67](https://lab.civicrm.org/dev/user-interface/-/issues/67))
- accordions: review [#29533](https://github.com/civicrm/civicrm-core/pull/29533)
- accordions: JS fixes for [#29448](https://github.com/civicrm/civicrm-core/pull/29448)
- select2 upgrade/replacement (#3292)
- ensure all fields have labels (see [testing by mthompson](https://chat.civicrm.org/civicrm/pl/un7ajre7mbyc3fis4qebnczpse) on MM)
- ensure tabs are accessible
- ensure pop-ups (dialogs, notifications) are accessible
- ensure date fields are accessible
- ensure [validation errors](https://chat.civicrm.org/civicrm/pl/seqg55bm4fn58eaybqaz5e7kcr) use best practices
- Improve loading of SK/FormBuilder content client-side (bundle requests to minimize Civi bootstrap cycles)
- Placing fields in a form that are not saved to Civi (but are recorded in `civicrm_afform_submission`)
- UX improvements to FormBuilder
- Keyboard navigation of edit-in-place SK displays (and other afforms?) -- and accessibility more broadly?
- Making FormBuilder field placement more flexible (independent of container)
- Use the Queue system for SearchKit exports
- [Open AdminUI PRs](https://github.com/civicrm/civicrm-core/pulls?q=adminui+OR+admin_ui+OR+%22admin+ui%22+is%3Apr+is%3Aopen)
- [Open Afform/SK/FB PRs](https://github.com/civicrm/civicrm-core/pulls?q=afform+OR+searchkit+OR%22search+kit%22+OR+formbuilder+OR+%22form+builder%22+is%3Apr+is%3Aopen+)
https://lab.civicrm.org/dev/core/-/issues/4985
Custom radio/checkbox fields - maximum options per line - alignment lost
2024-03-15T18:05:43Z
samuelsov
Custom radio/checkbox fields - maximum options per line - alignment lost
Regression following on #1821.
This is what we used to have (html table so everything is aligned):
![screen1](/uploads/afc5f71950f200da120187746e43f222/screen1.png)
This is what we have now:
![screen2](/uploads/c202f5aa0fccf732d96090...
Regression following on #1821.
This is what we used to have (html table so everything is aligned):
![screen1](/uploads/afc5f71950f200da120187746e43f222/screen1.png)
This is what we have now:
![screen2](/uploads/c202f5aa0fccf732d96090fd2d385138/screen2.png)
Currently, it's almost impossible to fix it using css.
https://lab.civicrm.org/dev/core/-/issues/4984
Display issue on membership view for relationships
2024-02-14T09:55:26Z
yashodha
Display issue on membership view for relationships
## Steps to replicate :
* Create a membership type configured with a relationship in both directions.
![Screenshot 2024-02-08 204424.png](/uploads/d4e47bd30b2673291f1e8c5bfe4346aa/Screenshot_2024-02-08_204424.png)
* Create a relations...
## Steps to replicate :
* Create a membership type configured with a relationship in both directions.
![Screenshot 2024-02-08 204424.png](/uploads/d4e47bd30b2673291f1e8c5bfe4346aa/Screenshot_2024-02-08_204424.png)
* Create a relationship between contacts that have this relationship "Shares home"
* Create a primary membership on one of them.
* On membership view screen, we can't see the related contact
![Screenshot 2024-02-08 205130.png](/uploads/63407ba8348abd8a2259ad59702c608b/Screenshot_2024-02-08_205130.png)
This should show like (fixed)
![Screenshot 2024-02-08 205008.png](/uploads/fde582a5808cf50f49f8d3fa80cf865c/Screenshot_2024-02-08_205008.png)
I can confirm this is not working on dmaster as well.
yashodha
yashodha
https://lab.civicrm.org/dev/core/-/issues/4983
FormBuilder - allow injection of js files to afform forms
2024-02-14T09:54:42Z
seamuslee
FormBuilder - allow injection of js files to afform forms
As part of JMA's geotargeted petition extension we have some javascript that we inject on the front end https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L58. The purpose of...
As part of JMA's geotargeted petition extension we have some javascript that we inject on the front end https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L58. The purpose of the Javascript is to do a dynamic lookup based on address information entered and then add checkboxes onto the form of "your local representatives that we will be contacting"
Is there a way to be able to do this within the GUI of form builder or similar to make it easier to always ensure that the js is loaded rather than just based on a specific block being on the form
@JoeMurray @Edselopez @colemanw
https://lab.civicrm.org/dev/core/-/issues/4982
Form builder - Extension provided entity settings
2024-02-14T09:53:44Z
seamuslee
Form builder - Extension provided entity settings
JMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter ...
JMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter angular hook https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L76 however this means that even on non petition related form builder forms they will show up.
This is about seeing if there is a better way to achieve this and or see if we can get them put onto the specific settings page for say GeotargetedPetition Entity.
@JoeMurray @Edselopez @colemanw