Problem/Motivation

The plan is to use the google analytics counter module to show the view count of some belonging to a certain content type.
So i followed the documentation that is being provided (https://www.drupal.org/docs/contributed-modules/google-analytics-counter)
Now after following the steps and doing the necessary configurations when i am running cron i am getting this error

Warning: Trying to access array offset on value of type null in Drupal\Core\Cron->processQueue() (line 264 of core/lib/Drupal/Core/Cron.php).

So i checked out the code and what i figured out is when the cron is run, and the worker is google analytics counter the pluginid,plugindefintion, and the configuration is not getting passed and hence $lease_time = $worker->getPluginDefinition()['cron']['time']; this is receiving null value, and the cron run is stopped abruptly and it's throwing error/warning mentioned above.

Steps to reproduce

1. Download and enable the module google analytics counter
2. Implement the necessary configurations (https://www.drupal.org/docs/contributed-modules/google-analytics-counter)
3. Run Cron

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

sandipta created an issue. See original summary.

sandipta’s picture

Issue summary: View changes
simonbaese’s picture

StatusFileSize
new1.54 KB

I saw your thread on reddit and took a quick look at this issue. The problem is that the plugin GoogleAnalyticsCounterQueueBase is not "constructed" correctly. It extends the QueueWorkerBase, but also overwrites the constructor (without calling the parent constructor) and create methods. In the comment, it said that dependency injection is not required, although services are used in the plugin and the ContainerFactoryPluginInterface is also used. This should be reworked in another issue.

For now I can only provide a simple patch, because I am traveling. Also, I was not able to do extensive testing, so please let me know if it works.

sandipta’s picture

Sure. I will test it out and will let you know.

vivek panicker’s picture

Nice spot there @simonbaese.

I got inspiration from your idea to create this patch.

@sandipta please review this patch since it is not tested and see if it helps resolve your issue.

sandipta’s picture

Definitely, I'll test it out and will let you know. Thanks for the patch. @Vivek Panicker

simonbaese’s picture

@Vivek Panicker The __construct() and create() call in GoogleAnalyticsCounterQueueBase is not necessary since it extends the QueueWorkerBase which extends the PluginBase.

The PluginBase constructor does everything needed to instantiate the plugin for the moment.

Since no dependency injection is used at the moment the `create()` method required by the ContainerFactoryPluginInterface is not necessary (should change in the context of another issue as mentioned above).

Please see previous patch.

kaszarobert’s picture

Title: Google Analytics Counter module resulting in cron run failure » Google Analytics Counter module resulting in cron run failure on Drupal 10
Version: 4.0.0 » 4.0.x-dev
Status: Active » Fixed
Issue tags: -google analytics, -Bug report, -cron error

I committed patch #3. Thanks for reporting and finding out this problem.

I was developing branch 4.0.x on a Drupal 9 site and never tried it on Drupal 10. On Drupal 9 everything works fine and since I don't use deprecated Drupal API calls, then I expected that it should work on D10, too. It seems I was terribly wrong. Something about plugins are not the same in D10. TBH, I don't know why was this strange empty constructor there in the first place, this is leftover code from an older release by previous maintainers that I missed to review when working with it. Anyway, please check out the newest release, it should work now.

vivek panicker’s picture

Thanks for the explanation @simonbaese.

@kaszarobert I think we should have an issue then to properly apply depdendency injection in the class files.

kaszarobert’s picture

sandipta’s picture

Status: Fixed » Closed (fixed)

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