Added queue clearing

[Codencode]

JavaScript events considered:

• updateCart
• changedCheckoutStep
• updatedProduct
• updateProductList
• clickQuickView

Questions	Answers
Description?	see PrestaShop/PrestaShop#37661
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes #37661
Sponsor company	@Codencode
How to test?	see PrestaShop/PrestaShop#37661

---

Additional context

renderPurchaseEvent() was already documented to receive an array, and all current callers in this repository pass an array.

This change makes that contract explicit in the method signature and removes the redundant runtime check.

As a consequence, any external caller passing a non-array value will now get a TypeError instead of the method silently returning.

[Hlavtox]

Is this necessary? I think it should be automatic when you are extending ModuleFrontController.

[Codencode]

No, it's not necessary; I added it to make the type explicit, i.e., "Ps_Googleanalytics", so that there are no warnings in the editor.
However, if you consider it "redundant", I can remove it.

[Hlavtox]

Just remove this please, your IDE complains because it lacks the context of a parent class. :-)

[Codencode]

I removed it.
Thanks!

[Hlavtox]

Block to prevent accidental merge, I want to check and test it. 👍

[Codencode]

@Hlavtox,
I have also prepared the code to handle the update of the product list (e.g., on the category page when filtering).
I could upload this code to this PR or create another PR, so you can review everything when you have time.
What do you think?

[kreare-priv]

awesome, waiting for merge

[Codencode]

@Hlavtox, have you had a chance to review this PR?

Also, if it's okay, I could create a second PR with the changes related to updating the product list (e.g., on the category page when filtering).

Thanks, and sorry for bothering you.

[Hlavtox]

One comment but I think its good.

ping @kpodemski for check

[Hlavtox]

Just remove this please, your IDE complains because it lacks the context of a parent class. :-)

[Codencode]

@Hlavtox,
I noticed the PHPStan test is failing (https://github.com/PrestaShop/ps_googleanalytics/actions/runs/14990171643/job/42111552847?pr=170) because it reports a missing method. This happens because it doesn't recognize the type of the $module attribute.

Initially, I had added the type declaration in the class definition like this (since my IDE suggested it):

    /**
     * @var Ps_Googleanalytics
     */
    public $module;

But you rightly advised me to remove it (#170 (comment)).
What do you recommend to fix the test issue? Should I perhaps add the type declaration back?

I'd like to fix these issues since I'm preparing videos to demonstrate the functionality - this way we can work toward closing this PR. Thanks!

[Hlavtox]

@Codencode

Open up this file - https://github.com/PrestaShop/ps_googleanalytics/blob/dev/tests/phpstan/phpstan-8.0.neon

And add this to ignoreErrors:

- '#Call to an undefined method Module::getDataHandler\(\).#'

And probably the same for https://github.com/PrestaShop/ps_googleanalytics/blob/dev/tests/phpstan/phpstan-latest.neon, not sure.

Should work 🎉

[Codencode]

@Hlavtox, I also had to modify:

• phpstan-1.7.7.neon
• phpstan-1.7.8.neon

After several attempts, I finally got it working 😄

I think it should be good now.

Thanks a lot!

[Codencode]

@paulnoelcholot, were you able to run the tests in the end?

[Codencode]

ping @PrestaShop/qa-functional

[Codencode]

@Hlavtox @kpodemski, I think testing this change is a bit 'complicated.' I tried my best to explain how to do it and even added some videos. Do you have any suggestions? I'm afraid these changes won't get merged, and that's a shame.

[Touxten]

Hello @Codencode

The CI is fixed can you check conflicts and i ask @PrestaShop/qa-functional for QA by dev

[Codencode]

@Touxten yes, I think it's the best thing, because I couldn't get the test done, probably I wasn't good at making myself understood.

[Touxten]

You must delete the old .neon files and add the errors to the new ones.

[Codencode]

@Touxten I think I did everything, right?

[boo-code]

QA against dev @ 64a6b1c (module 6.0.0) on PrestaShop 9.2.x.

Without this PR the bug is still there. An AJAX add-to-cart writes one row into <prefix>ganalytics_data and sends nothing; the add_to_cart call only reaches a page on the next full render, attributed to that later page. Repro steps without a GA account are on PrestaShop/PrestaShop#37661.

With the four code files applied on top of dev, the server half does what it should. POST /module/ps_googleanalytics/ajax with ajax=1&action=flushQueue returns ["gtag(\"event\", \"add_to_cart\", { ... })"] and the row is gone, with no page navigation in between.

Why it is CONFLICTING. Every conflict is inside tests/php/phpstan/; the four code files merge cleanly. Two commits moved the ground:

• e6823cc (2026-02-22) moved tests/phpstan/ to tests/php/phpstan/ and renamed the per-version configs
• a35abd8b (2026-06-08, Epic #41648) deleted phpstan-1.7.7.neon, phpstan-1.7.8.neon, phpstan-8.0.neon and phpstan-latest.neon

That makes the rebase mechanical:

• drop the edits to those four deleted files
• renderCartpage() is unused is no longer needed - 3b86d3c9 made the method reachable again (classes/Hook/HookDisplayBeforeBodyClosingTag.php:59) instead of ignoring the error
• HookActionValidateOrder::$module is never read is already present in all five current configs
• so the only line still to add is - '#Call to an undefined method Module::getDataHandler\(\).#', into phpstan-8.2.x.neon, phpstan-9.0.3.neon, phpstan-9.1.5.neon, phpstan-9.2.x.neon and phpstan-develop.neon

An alternative that touches no config file at all is to narrow the property at the call site in controllers/front/ajax.php:

/** @var Ps_Googleanalytics $module */
$module = $this->module;
$output = $module->getDataHandler()->readData();
$module->getDataHandler()->deleteData();

I only checked that construct under PHPStan 1.12, and CI here runs ^2.1, so take it as a suggestion rather than a verified result.

One gap in the change itself. hookDisplayHeader() registers views/js/ganalytics.js and defines psGoogleAnalyticsAjaxUrl behind if ($back_office === false) alone, while the rest of the module is gated on the account id (classes/Hook/HookDisplayHeader.php:56). Measured on a shop with the module installed and GA_ACCOUNT_ID empty: no gtag block is rendered, but psGoogleAnalyticsAjaxUrl is still emitted into the page, so updateCart, updateProductList, clickQuickView, updatedProduct and changedCheckoutStep each fire a front-controller request that can only ever return []. updateProductList fires on every facet and pagination click, so on a category page that is one wasted request per interaction. Putting the same Configuration::get('GA_ACCOUNT_ID') check on the new block removes it.

[Codencode]

@boo-code

Thanks for testing this so thoroughly and for the detailed feedback.

I’ve rebased the PR on the latest dev branch and resolved the PHPStan conflicts by keeping the current configuration files.

For the getDataHandler() PHPStan issue, I went with the local type annotation approach you suggested instead of adding the ignore rule to all PHPStan configs.

I also added the GA_ACCOUNT_ID check around the new AJAX/JS registration, so ganalytics.js is no longer loaded and no unnecessary AJAX requests are triggered when Google Analytics is not configured.

There is still one PHPStan failure that seems unrelated to this PR. GoogleAnalyticsTools::renderPurchaseEvent() already declares $orderProducts as an array in its PHPDoc while still checking is_array(), and the same code is currently present on dev. The current develop PHPStan job detects PrestaShop 9.3.0, so this appears to be a newly surfaced issue in the current CI/develop environment rather than a regression introduced by this PR.

Thanks again for the very helpful review.

[Codencode]

@boo-code I opened a separate PR to fix the unrelated PHPStan error detected on the current dev branch: #185

If that PR is approved and merged, I’ll just rebase this PR on the updated dev branch and the remaining PHPStan failure should be resolved here as well.

Does this approach look good to you?

[boo-code]

The split is the right call, and I checked the part of #185 that could bite rather than just the PHPStan line.

Removing the is_array() guard and typing the parameter array is only safe if no caller can reach it with something else. Both callers in the module are the same shape and neither can:

• classes/Hook/HookDisplayOrderConfirmation.php initialises $orderProducts = [] and only ever reassigns it from $productWrapper->prepareItemListFromProductList(...), then passes it straight to renderPurchaseEvent();
• classes/Hook/HookDisplayBackOfficeHeader.php does the identical thing.

So the guard is dead code at both sites, and the declared @param array was already the contract. A code search across the organisation finds only those two callers plus the declaration itself.

The one thing worth a line in #185's description: it is a public method, so third-party code outside the org calling it with a non-array moves from a silent return; to a TypeError. That is the correct behaviour and matches the docblock, but it is a behaviour change rather than a pure cleanup, so it belongs in the description rather than being discovered later.

On the sequencing, no objection: land #185, rebase this one on dev, and the remaining PHPStan failure goes with it.

[Codencode]

@boo-code
Thanks for checking this in detail.

That makes sense. I’ll keep the fix separated in #185 and add a note to the PR description about the behavioral change for external callers passing non-array values.

Once #185 is merged, I’ll rebase #170 on dev so the remaining PHPStan failure should disappear.