Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-12-08T20:55:07Zhttps://lab.civicrm.org/dev/core/-/issues/3645Eventually google will require OAUTH for bounce processing and may require it...2022-12-08T20:55:07ZDaveDEventually google will require OAUTH for bounce processing and may require it for outbound SMTP through gmail serversAs noted on [stackexchange](https://civicrm.stackexchange.com/questions/34142/sending-mail-via-gmail-google-announce-username-password-authentication-will-b), Google sent out an email outlining plans to require OAUTH and discontinue supp...As noted on [stackexchange](https://civicrm.stackexchange.com/questions/34142/sending-mail-via-gmail-google-announce-username-password-authentication-will-b), Google sent out an email outlining plans to require OAUTH and discontinue support for just username/password.
The way I read it, this is mostly applying to POP/IMAP clients for reading mail, and they are *hinting* that someday they might require it for outbound SMTP, i.e. at Administer - System Settings - Outbound Mail you choose SMTP and have it set to use gmail servers. The relevant quote is
> No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth.
(LSA means less secure apps, which is google-speak for username/password)
They are targeting June 2020 - Feb 2021 for IMAP etc, but as noted above they have not specifically set a date for changes regarding sending outbound emails.
It occurs to me though that bounce processing and the email processor use POP/IMAP. For the email processor you can work around it by just forwarding it to a non-gmail address and polling that, but bounce processing might be harder depending on setup.https://lab.civicrm.org/dev/drupal/-/issues/142D8/D9 - Define composer upgrade test protocol2020-10-22T04:39:49ZtottenD8/D9 - Define composer upgrade test protocolWith composer-based distribution, there's an extra dimension/risk that you don't see in D7/WP/BD distribution -- Civi and Drupal build on some of the same packages (eg `symfony/*`), and they pull in various plugins, and the different tem...With composer-based distribution, there's an extra dimension/risk that you don't see in D7/WP/BD distribution -- Civi and Drupal build on some of the same packages (eg `symfony/*`), and they pull in various plugins, and the different templates have different conventions. It is entirely plausible for problems to sneak into the dependency-graph that are then awkward for system-implementers to resolve.
During the test/review/RC processes, we currently run [upgrade tests to check the DB-update procedure](https://github.com/civicrm/civicrm-upgrade-test/) against a range of older DB versions. This would be a sort of parallel for checking the composer-code-update procedure.
Ideally, as part of the release-cycle, one might run an upgrade-matrix. Example:
| Drupal Template | Drupal Version | CiviCRM Old Version | CiviCRM New Version |
| -- | -- | -- | -- |
| `drupal-composer/drupal-project` | `8.7.0` | `5.27.0` | `5.31.0` |
| `drupal/legacy-project` | `8.8.0` | `5.29.0` | `5.31.0` |
| `drupal/recommended-project` | `8.9.0` | `5.28.0` | `5.31.0` |
| `drupal/recommended-project` | `9.0.0` | `5.29.0` | `5.31.0` |
Of course, there are a huge number of permutations, and we're not gonna test all of them, but it would be appropriate to ensure that several distinct (in each column) do get tested.https://lab.civicrm.org/dev/user-interface/-/issues/10Ability to edit Contribution page "Confirm Contribution" button2023-11-23T07:35:02ZHeatherOliverAbility to edit Contribution page "Confirm Contribution" buttonIt would be useful to be able to control what the submission button says on a Contribution page in the same way that you can control the "Register now" button in events.
"Confirm Contribution" isn't very meaningful. For example:
Member...It would be useful to be able to control what the submission button says on a Contribution page in the same way that you can control the "Register now" button in events.
"Confirm Contribution" isn't very meaningful. For example:
Membership registration, Standard donation page and Campaign donation page you may wish to customise this button.https://lab.civicrm.org/dev/core/-/issues/4952PHP 8.3 Support2024-01-31T22:32:21ZJoeMurrayPHP 8.3 SupportThis is an epic for PHP 8.3 support.
PHP 8.3 was released 2023-11, has active support till 2024-12-8, and security support till 2025-12-08.
Some extra motivation to support 8.3 sooner rather that later is the significant performance im...This is an epic for PHP 8.3 support.
PHP 8.3 was released 2023-11, has active support till 2024-12-8, and security support till 2025-12-08.
Some extra motivation to support 8.3 sooner rather that later is the significant performance improvements it has, up to 55% for D10 over 8.1: https://kinsta.com/blog/php-benchmarks/
Reference: [https://www.php.net/manual/en/migration83.incompatible.php](https://www.php.net/manual/en/migration83.incompatible.php)
See also [thttps://php.watch/versions/8.3](https://php.watch/versions/8.3) and [https://www.php.net/releases/8.3/en.php](https://www.php.net/releases/8.3/en.php).
Here are the breaking changes listed here for reference. Almost all seem like they would be difficult to search for and identify in the codebase. Whack-a-mole from running on edge test servers might be a helpful approach.
- [ ] Uses of traits with static properties: Uses of traits with static properties will now redeclare static properties inherited from the parent class. This will create a separate static property storage for the current class. This is analogous to adding the static property to the class directly without traits.
- [ ] Assigning a negative index to an empty array: Assigning a negative index $n to an empty array will now make sure that the next index is $n+1 instead of 0.
- [ ] Class constant visibility variance check: Class constant visibility variance is now correctly checked when inherited from interfaces.
- [ ] WeakMap entries whose key maps to itself: WeakMap entries whose key maps to itself (possibly transitively) may now be removed during cycle collection if the key is not reachable except by iterating over the WeakMap (reachability via iteration is considered weak). Previously, such entries would never be automatically removed.
- [ ] Date: The DateTime extension has introduced Date extension specific exceptions and errors under the DateError and DateException hierarchies, instead of warnings and generic exceptions. This improves error handling, at the expense of having to check for errors and exceptions.
- [ ] DOM: Calling DOMChildNode::after(), DOMChildNode::before(), DOMChildNode::replaceWith() on a node that has no parent is now a no-op instead of a hierarchy exception, which is the behaviour demanded by the DOM specification.
Using the DOMParentNode and DOMChildNode methods without a document now works instead of throwing a DOM_HIERARCHY_REQUEST_ERR DOMException. This is in line with the behaviour demanded by the DOM specification.
Calling DOMDocument::createAttributeNS() without specifying a prefix would incorrectly create a default namespace, placing the element inside the namespace instead of the attribute. This bug is now fixed.
DOMDocument::createAttributeNS() would previously incorrectly throw a DOM_NAMESPACE_ERRNAMESPACE_ERR DOMException when the prefix was already used for a different URI. It now correctly chooses a different prefix when there's a prefix name conflict.
New methods and properties were added to some DOM classes. If a userland class inherits from these classes and declare a method or property with the same name, the declarations must be compatible. Otherwise, a typical compile error about incompatible declarations will be thrown. See the list of new features and new functions for a list of the newly implemented methods and properties.
- [x] FFI: C functions that have a return type of void now return null instead of returning the following object object(FFI\CData:void) { }
- [ ] Opcache: The opcache.consistency_checks INI directive was removed. This feature was broken with the tracing JIT, as well as with inheritance cache, and has been disabled without a way to enable it since PHP 8.1.18 and PHP 8.2.5. Both the tracing JIT and inheritance cache may modify shm after the script has been persisted by invalidating its checksum. The attempted fix skipped over the modifiable pointers but was rejected due to complexity. For this reason, it was decided to remove the feature instead.
- [ ] Phar: The type of Phar class constants are now declared.
- [ ] Standard: The range() function has had various changes:
A TypeError is now thrown when passing objects, resources, or arrays as the boundary inputs.
A more descriptive ValueError is thrown when passing 0 for $step.
A ValueError is now thrown when using a negative $step for increasing ranges.
If $step is a float that can be interpreted as an int, it is now done so.
A ValueError is now thrown if any argument is infinity or NAN.
An E_WARNING is now emitted if $start or $end is the empty string. The value continues to be cast to the value 0.
An E_WARNING is now emitted if $start or $end has more than one byte, only if it is a non-numeric string.
An E_WARNING is now emitted if $start or $end is cast to an integer because the other boundary input is a number. (e.g. range(5, 'z');).
An E_WARNING is now emitted if $step is a float when trying to generate a range of characters, except if both boundary inputs are numeric strings (e.g. range('5', '9', 0.5); does not produce a warning).
range() now produce a list of characters if one of the boundary inputs is a string digit instead of casting the other input to int (e.g. range('9', 'A');).
```
<?php
range('9', 'A'); // ["9", ":", ";", "<", "=", ">", "?", "@", "A"], as of PHP 8.3.0
range('9', 'A'); // [9, 8, 7, 6, 5, 4, 3, 2, 1, 0], prior to PHP 8.3.0
?>
```
The file() flags error check now catches all invalid flags. Notably FILE_APPEND was previously silently accepted.
- [ ] SNMP: The type of SNMP class constants are now declared.https://lab.civicrm.org/dev/core/-/issues/4745Joomla: Fails to download extension feed2023-11-09T23:56:48ZtottenJoomla: Fails to download extension feedOverview
----------------------------------------
There appears to be a Guzzle conflict when fetching the extension feed on Joomla.
Reproduction steps
----------------------------------------
1. Install CiviCRM on Joomla
1. Navigate to...Overview
----------------------------------------
There appears to be a Guzzle conflict when fetching the extension feed on Joomla.
Reproduction steps
----------------------------------------
1. Install CiviCRM on Joomla
1. Navigate to dashboard
Current behaviour
----------------------------------------
The first pageload fails with:
![Screen_Shot_2023-11-01_at_4.20.15_PM](/uploads/bfab953fd770a8c09af0658b11529f04/Screen_Shot_2023-11-01_at_4.20.15_PM.png)
The NACK is cached for a while, so you won't immediately see the problem again. But we should expect it to recur.
Expected behaviour
----------------------------------------
No crash.
Environment information
----------------------------------------
The "hydra sites" (https://test.civicrm.org/view/Sites/job/hydra-sites/) are clean CMS installations. (They have the Civi source code preloaded -- but the installer hasn't run.) The error was observed on the hydra site for Joomla with CiviCRM `5.67.beta2` circa Nov 1, 2023.
* __Browser:__ Firefox
* __CiviCRM:__ 5.67.beta2
* __PHP:__ 7.4
* __CMS:__ Joomla
* __Database:__ 5.7
* __Web Server:__ Apachehttps://lab.civicrm.org/dev/core/-/issues/1647Make packages and bower_components tokens compataible with the CiviCRM Core R...2022-09-29T17:40:08ZseamusleeMake packages and bower_components tokens compataible with the CiviCRM Core Reources URL settingOne of the things that has been hightlighted by dev/Financial#120 is that since this commit https://github.com/civicrm/civicrm-core/commit/1143a7815b1abbcb7cfc0cab6c754e499d11d064#diff-ff63186dcddd8213d6b992efd57d70a4 from @totten not al...One of the things that has been hightlighted by dev/Financial#120 is that since this commit https://github.com/civicrm/civicrm-core/commit/1143a7815b1abbcb7cfc0cab6c754e499d11d064#diff-ff63186dcddd8213d6b992efd57d70a4 from @totten not all resources urls are treated the same. What that causes is that all bower_components and packages urls now are relative to the CiviCRM Core root path as calculated by getCiviSourceStorage rather than the CiviCRM Core Resources URL setting. Where as assets loaded from the root folder e.g. js/common.js etc would all still continue to respect the setting. This ticket is about unifying them back together in a way that is sensible. Or at least we should update the documentation and other respects to indicate that the setting no longer applies to packages and bower_components urlshttps://lab.civicrm.org/dev/core/-/issues/1571New Contribution form gives fatal error when using ONLY_FULL_GROUP_BY2023-02-07T19:36:18ZDaveDNew Contribution form gives fatal error when using ONLY_FULL_GROUP_BYI'm not sure if this is something that's changed recently but my local setup has had mysql 5.7 with only_full_group_by for a while now so it seems like it would have come up, and I can't be the only one. The related code doesn't seem to ...I'm not sure if this is something that's changed recently but my local setup has had mysql 5.7 with only_full_group_by for a while now so it seems like it would have come up, and I can't be the only one. The related code doesn't seem to have changed though. Maybe it only comes up in a certain configuration.
I can see the PR test sites don't have only_full_group_by so I assume dmaster.demo also doesn't, so I can't easily double-check on those.
```
SELECT
DISTINCT ( price_set_id ) as id, s.title
FROM
civicrm_price_set s
INNER JOIN civicrm_price_field f ON f.price_set_id = s.id
INNER JOIN civicrm_price_field_value v ON v.price_field_id = f.id
WHERE
is_quick_config = 0 AND s.is_active = 1 AND s.extends LIKE '%2%' AND s.financial_type_id IN (3,1,4,2) AND v.financial_type_id IN (3,1,4,2) GROUP BY s.id [nativecode=1055 ** 'f.price_set_id' isn't in GROUP BY]
0 ...\sites\all\modules\civicrm\CRM\Core\Error.php(192): CRM_Core_Error::backtrace("backTrace", TRUE)
1 ...\sites\all\modules\civicrm\vendor\pear\pear-core-minimal\src\PEAR.php(922): CRM_Core_Error::handle(Object(DB_Error))
2 ...\sites\all\modules\civicrm\packages\DB.php(997): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
3 ...\sites\all\modules\civicrm\vendor\pear\pear-core-minimal\src\PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
4 ...\sites\all\modules\civicrm\vendor\pear\pear-core-minimal\src\PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...", "DB_Error", TRUE)
5 ...\sites\all\modules\civicrm\packages\DB\common.php(1925): PEAR->__call("raiseError", (Array:7))
6 ...\sites\all\modules\civicrm\packages\DB\mysqli.php(935): DB_common->raiseError(-1, NULL, NULL, "\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...", "1055 ** 'f.price_set_id' isn't in GROUP BY")
7 ...\sites\all\modules\civicrm\packages\DB\mysqli.php(405): DB_mysqli->mysqliRaiseError()
8 ...\sites\all\modules\civicrm\packages\DB\common.php(1231): DB_mysqli->simpleQuery("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
9 ...\sites\all\modules\civicrm\packages\DB\DataObject.php(2691): DB_common->query("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
10 ...\sites\all\modules\civicrm\packages\DB\DataObject.php(1829): DB_DataObject->_query("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
11 ...\sites\all\modules\civicrm\CRM\Core\DAO.php(421): DB_DataObject->query("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
12 ...\sites\all\modules\civicrm\CRM\Core\DAO.php(1420): CRM_Core_DAO->query("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...", TRUE)
13 ...\sites\all\modules\civicrm\CRM\Price\BAO\PriceSet.php(403): CRM_Core_DAO::executeQuery("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
14 ...\sites\all\modules\civicrm\CRM\Contribute\Form\Contribution.php(716): CRM_Price_BAO_PriceSet::getAssoc(FALSE, "CiviContribute")
15 ...\sites\all\modules\civicrm\CRM\Core\Form.php(595): CRM_Contribute_Form_Contribution->buildQuickForm()
16 ...\sites\all\modules\civicrm\CRM\Core\QuickForm\Action\Display.php(76): CRM_Core_Form->buildForm()
17 ...\sites\all\modules\civicrm\packages\HTML\QuickForm\Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Contribute_Form_Contribution), "display")
18 ...\sites\all\modules\civicrm\packages\HTML\QuickForm\Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution), "display")
19 ...\sites\all\modules\civicrm\CRM\Core\Controller.php(335): HTML_QuickForm_Page->handle("display")
20 ...\sites\all\modules\civicrm\CRM\Contribute\Page\Tab.php(316): CRM_Core_Controller->run()
21 ...\sites\all\modules\civicrm\CRM\Contribute\Page\Tab.php(372): CRM_Contribute_Page_Tab->edit()
22 ...\sites\all\modules\civicrm\CRM\Core\Invoke.php(268): CRM_Contribute_Page_Tab->run((Array:3), NULL)
23 ...\sites\all\modules\civicrm\CRM\Core\Invoke.php(68): CRM_Core_Invoke::runItem((Array:16))
24 ...\sites\all\modules\civicrm\CRM\Core\Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
25 ...\sites\all\modules\civicrm\drupal\civicrm.module(456): CRM_Core_Invoke::invoke((Array:3))
26 ...\includes\menu.inc(527): civicrm_invoke("contribute", "add")
27 ...\index.php(21): menu_execute_active_handler()
28 {main}
```https://lab.civicrm.org/dev/financial/-/issues/39Authorize.net doesn't support MD5 hashing at the end of the month2019-07-02T14:40:29ZJonGoldAuthorize.net doesn't support MD5 hashing at the end of the monthI just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Ex...I just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Exchange.
> Authorize.Net is phasing out the MD5 based transHash element in favor
> of the SHA-256 based transHashSHA2. The setting in the Merchant
> Interface which controls the MD5 Hash option will be removed by the
> end of January 2019, and the transHash element will stop returning
> values at a later date to be determined.
>
> Merchants utilizing this feature will need to work with their web
> developer or solutions provider to verify if they are still utilizing
> MD5 based hash and if still needed to move to SHA-256 hash via
> Signature Key.