CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-11-09T23:56:48Zhttps://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/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/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/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}
```