So one issue I am hitting at the moment is that this is generating bunch of deprecation warnings when trying to run unit tests
Deprecated: Symfony\Component\Config\Resource\ReflectionClassResource implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /home/jenkins/bknix-edge/build/build-1/web/sites/all/modules/civicrm/vendor/symfony/config/Resource/ReflectionClassResource.php on line 20
@totten@DaveD I am wondering if we need to bite the bullet so to speak and update Symfony sooner rather than later as 3.x Symfony won't help here unless there is a way of patching to make this work but that makes me feel concerned as well.
I don't personally have any objections to that. For what it's worth I tried looking at universe for symfony usage, but wasn't able to get a good handle on it, and that's maybe not a useful way to approach it anyway.
I'm not sure if that piece of code is actually problematic -- the underlying implementation of pathGet() and pathSet() should all be fairly direct access (eg $GLOBALS[$part]) rather than batchy/loopy access (eg array_merge($GLOBALS...)). But I may not have a proper test environment.
$ cv ev 'return 123;'123$ cv ev '$getter = Civi\Core\Resolver::singleton()->get("global://civicrm_root?getter"); return $getter();'"/Users/me/bknix/build/dmaster/web/sites/all/modules/civicrm/"
On my local php80+php81, both commands return the expected output. Of course, on php81, both commands produce a ton of unrelated warnings - but I don't think any of them relate to GLOBALS.
The Flexmailer snippet looks more logical, but the differences (tsLocale vs dbLocale) are fairly edgy, and I can't honestly say which is better. Arguably, it becomes moot whenever we make Flexmailer mandatory...
Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php on line 296Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm/CRM/Report/Page/InstanceList.php on line 164Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php on line 296Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php on line 296Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm.php on line 1361Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm.php on line 1362Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php on line 296
and some Warning: Undefined array key "group_by" in /var/www/html/civicrm/wp-content/uploads/civicrm/templates_c/fr_FR/%%F5/F54/F5478576%%Table.tpl.php on line 190
I cannot show reportings
Warning: Undefined array key "group_by" in /var/www/html/XXXX/wp-content/uploads/civicrm/templates_c/fr_FR/%%F5/F54/F5478576%%Table.tpl.php on line 190
Warning: Undefined array key "group_by" in /var/www/html/XXXX/wp-content/uploads/civicrm/templates_c/fr_FR/%%F5/F54/F5478576%%Table.tpl.php on line 190
Warning: Undefined array key "group_by" in /var/www/html/XXXX/wp-content/uploads/civicrm/templates_c/fr_FR/%%F5/F54/F5478576%%Table.tpl.php on line 193
octobre 28th, 2011
In terms of the scope of this ticket, I'd say it's complete in that you can install and run civi on php 8.1. What is still a problem is the enormous number of warnings/deprecations that flood logs and make writing new unit tests difficult, and that someday will be fatal errors. They mostly need to be handled individually so it suggests making new tickets for each one, and they're likely to get missed if all lumped into one ticket. It's just there's sooooo manyyyyy so it will be a lot of tickets and prone to duplicates. It's the kind of thing a sprint would be good for.