Problem/Motivation

Deprecated function: Creation of dynamic property Drupal\views_aggregator\Plugin\views\style\Table::$commerce_field_values is deprecated in Drupal\views_aggregator\Plugin\views\style\Table->getCellRaw() (line 679 of modules/contrib/views_aggregator/src/Plugin/views/style/Table.php).

Steps to reproduce

Drupal 10.1.2, PHP 8.2.8

Proposed resolution

Add protected $commerce_field_values to class

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

derekw created an issue. See original summary.

tr’s picture

Version: 2.0.2 » 2.0.x-dev
Category: Bug report » Task

It's a PHP 8.1 thing, so you have to test against PHP 8.1. I triggered a test for you.

The parameter is commented wrong in your patch it should be: @var array

It would also be nice to have a test case that uses this code, so that the tests would show the error. The reasons this hasn't been seen before is because it's in that special case commerce code which isn't tested.

tr’s picture

Also, since you're using the commerce integration, perhaps you can test #3376200: No aggregation total shown if first result is empty (commerce_price fields) ?

tr’s picture

Parent issue: » #3344504: Fix test failures
anybody’s picture

Status: Active » Needs work
anybody’s picture

For details see https://www.php.net/manual/en/migration82.deprecated.php

Eventually it needs

adding the #[\AllowDynamicProperties] attribute to the class (which also applies to all child classes).

if this is required by design.

tr’s picture

Personally I think when there's module-specific exceptions like this being made in the code, it's a giant red flag indicating that something is being done wrong.

Why should some commerce field be treated differently than any other Drupal field? How many modules do we have to make exceptions for?

Either Views Aggregator isn't doing the right thing, or the commerce module isn't constructing their field properly.

Yes, your MR would be the right way to fix things if we want to keep that variable around, but I personally would rather see this module fixed so it doesn't have to make exceptions like that. However I don't personally have the time or desire to set up a commerce site so I can investigate and figure out a proper solution.

anybody’s picture

@tr: Agreed! :)

tr’s picture

Version: 2.0.x-dev » 2.1.x-dev

Yeah, I'm not going to do any of those things I said in #10. I'm just going to add property, add a @todo, and open a new issue to examine the issue of potentially removing commerce-specific code.

tr changed the visibility of the branch 2.0.x to hidden.

tr changed the visibility of the branch 2.1.x to hidden.

  • tr committed 31261137 on 2.1.x
    Issue #3382721 by derekw, tr, anybody: Creation of dynamic property...

  • tr committed d4824342 on 2.1.x
    Revert "Issue #3382721 by derekw, tr, anybody: Creation of dynamic...
tr’s picture

Parent issue: #3344504: Fix test failures »

  • tr committed 080719ae on 2.1.x
    Issue #3382721: Creation of dynamic property Drupal\views_aggregator\...
tr’s picture

Status: Needs work » Fixed

Committed.

  • tr committed 591cf2a1 on 2.0.x
    Issue #3382721: Creation of dynamic property Drupal\views_aggregator\...

Status: Fixed » Closed (fixed)

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