PHP 8.2 - Fix deprecated dynamic properties

Many of the errors are about creating dynamic properties in RulesReactionRule. Adding #[\AllowDynamicProperties] to this class would fix these.

Uploading a patch where the dynamic properties are created. I have tried to add some obvious missing properties (to the tests and to the RulesUIController) and then used the #[\AllowDynamicProperties] in the RulesPlugin class. This class should be a base for all other classes like the RulesReactionRule, which emitted the most deprecation warnings.

PHP documentation states this about the setting a #[AllowDynamicProperties] on a class:

This means setting dynamic properties on stdClass objects or any classes that extend stdClass does not emit dynamic property deprecation notices.

So this is one possible approach (probably the most safe and straightforward). The second possible approach is to declare missing properties (most likely in the RulesPlugin class), e.g. something like this:

abstract class RulesPlugin extends RulesExtendable {
  ...
  public $access_exposed;
  public $active;
  public $tags = array();
  public $dependencies = array();
  public $plugin = NULL;
  public $module = NULL;
  public $data;

Not sure which approach will be preferred by @TR, but will see.

Adding also a noop patch to see the PHP 8.2 errors before this change, so that we are not fixing something that is not a problem (I was checking the errors only locally, so better to have it confirmed by DrupalCI).

I am not sure if the module tests will use a dev version of the Entity module, so we will see if it will be clean of deprecations removed by this fix: 📌 PHP 8.2 - Fix deprecated dynamic properties Fixed

The tests seems to use the Entity 7.x-1.10, so the results could or could not be much relevant, see:

22:20:20 Lock file operations: 3 installs, 0 updates, 0 removals
22:20:20   - Locking drupal/entity (1.10.0)
22:20:20   - Locking drupal/entity_token (1.10.0)
22:20:20   - Locking drupal/rules (dev-2.x 1b5a030)
22:20:20 Writing lock file

To be sure, I think we would need to either do a new release of the Entity module, or update Rules to use Entity 7.x-1.x-dev in testing. Then we can check if my changes are needed at all (e.g. if these deprecations were caused by the Rules module, or Entity module). Thanks!

The changes here are probably needed because the errors reported are about properties in Rules classes.

Part of this fix should be updating the selection of automated testing platforms.

I have never been able to figure out how to force DrupalCI to test against a -dev dependency in Drupal 7. (This used to work, before switch to composer.) There is no documentation addressing this, and my questions about how to do this (in various issue queues and on Slack) have gone unanswered for years.

Dependencies and test dependencies are specified in rules.info in D7. Changing the .info file in a patch doesn't affect anything because DrupalCI installs the module before patching the files, so to change the dependencies for a test you must commit a new version of the .info file first. You can see I tried several variations of that recently, even though I have done this many times before and didn't expect it to work. And it didn't work - entity 1.10 is always used even when I tell it to use -dev. I don't know what syntax will force the dev - specifying 7.x-1.x doesn't work, specifying 7.x-1.x-dev doesn't work. Maybe specifying >7.x-1.10, I haven't tried that recently. But making wild guesses then committing the .info file and waiting to see what the test does is not a productive strategy and I'm tired of experimenting like this.

Entity 7.x-1.x-dev only has one commit above 7.x-1.10, and I would prefer to test against that -dev and possibly commit a few more issues before making a new release of Entity. So if you know the secret way to force DrupalCI to use the -dev version of Entity for Rules testing, I would like to hear it.

I don't know any way of doing that.

The errors are almost entirely about properties in RulesReactionRule and RulesActionSet, so committing fixes to those will fix most of them.

I have not tried this by myself, but have seen @MegaChriz experimenting with this in the past.

The uc_extra_fields_pane module seems to be using the uc_addresses 7.x-1.x-dev version in the testing, see: https://dispatcher.drupalci.org/job/drupal_d7/262584/console

22:24:10   - Installing drupal/uc_addresses (1.0.0-beta1): Extracting archive
22:24:10   - Installing drupal/uc_extra_fields_pane (dev-1.x e4a24f3): Cloning e4a24f3a86 from cache
...
22:24:12 Adding testing (require-dev) dependencies.
22:24:12 Composer Command: sudo -u www-data /usr/local/bin/composer require 'drupal/uc_addresses:1.x-dev' --prefer-stable --no-progress --prefer-dist --no-suggest --no-interaction --working-dir /var/www/html
22:24:12 sudo -u www-data /usr/local/bin/composer require 'drupal/uc_addresses:1.x-dev' --prefer-stable --no-progress --prefer-dist --no-suggest --no-interaction --working-dir /var/www/html
22:24:12 ./composer.json has been updated
22:24:12 Running composer update drupal/uc_addresses
22:24:12 Loading composer repositories with package information
22:24:12 Updating dependencies
22:24:12 Lock file operations: 0 installs, 1 update, 0 removals
22:24:12   - Upgrading drupal/uc_addresses (1.0.0-beta1 => dev-1.x cbdc512)
22:24:12 Writing lock file
22:24:12 Installing dependencies from lock file (including require-dev)
22:24:12 Package operations: 0 installs, 1 update, 0 removals
22:24:12   - Syncing drupal/uc_addresses (dev-1.x cbdc512) into cache
22:24:13   - Removing drupal/uc_addresses (1.0.0-beta1)
22:24:13   - Installing drupal/uc_addresses (dev-1.x cbdc512): Cloning cbdc512316 from cache

It looks like that the .info file cannot force usage of the dev version now, but the composer.json probably could: https://git.drupalcode.org/project/uc_extra_fields_pane/-/commit/e4a24f3a863bf2486f86628eae6bea3dc1eb2280

Fix above looks good thank you very much @poker10 and @LiamMorland

Committed.

Thank you @TR :)

@TR, could we please also have a tagged release for 7.x-2.14 ?

Automatically closed - issue fixed for 2 weeks with no activity.