[boo-code]

Questions	Answers
Description?	HookDisplayFooterProduct::run() reads the product Smarty variable and passes it straight to ProductWrapper::prepareItemFromProduct(), which consumes it with array keys ($product['id_product'], $product['name'], …). That variable is normally a ProductLazyArray (array-accessible), but some themes/modules assign a raw Product object to it, producing a fatal error Cannot use object of type Product as array on the product page (reported on 5.0.3 / PS 8.2.4). This PR guards the hook: if the product is not array-accessible, it skips tracking instead of breaking the page. ProductLazyArray implements ArrayAccess, so the normal flow is unaffected.
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes #179.
How to test?	On a product page where the product Smarty variable is a raw Product object, before this PR the page fatals with Cannot use object of type Product as array (ProductWrapper.php line ~136). Deterministic check: prepareItemFromProduct(new Product(1)) throws that error; with the guard, HookDisplayFooterProduct::run() returns without a fatal. With the standard ProductLazyArray (which implements ArrayAccess), tracking continues to work as before.
Sponsor company

[ps-jarvis]

Hello @boo-code!

This is your first pull request on ps_googleanalytics repository of the PrestaShop project.

Thank you, and welcome to this Open Source community!

[Hlavtox]

@boo-code I am don't have a great feeling from this change. I think we should not add checks for bad modules overwriting system variables..

Cc @kpodemski @Codencode

[kpodemski]

To me the change is totally fine, and I'm always recommending to check whether the input data is what we expect.

[boo-code]

Thanks @Hlavtox, that is a fair principle and I do not want this to become a pattern of guarding against every misbehaving module either. Let me explain why I think this specific case is worth it, and offer a middle ground.

The distinction I would draw: product here is not this module's own state, it is a shared Smarty template variable that the hook reads but does not set. It is populated by the theme, core, or another module, so from this hook's point of view its type is genuinely external input crossing a trust boundary, not a value we control. The guard validates input at that boundary rather than compensating for one known-buggy module.

The failure modes are also very asymmetric. Without the guard, a third party assigning a raw Product object produces an uncaught fatal that takes down the whole product page (issue #179 is exactly this, on a live shop), not just GA tracking. With the guard, the only consequence is that GA tracking is skipped for that one request. Degrading the analytics is proportionate; crashing the storefront is not.

It is also deliberately minimal and does not touch the normal path: ProductLazyArray implements ArrayAccess, so the standard flow is unaffected and only the anomalous type returns early.

On your underlying concern, that we should not silently mask a bad module: I agree, and I am happy to add a debug-level log when the guard trips, so the misconfiguration stays visible and diagnosable instead of being swallowed. If you would prefer that, I will push it; otherwise I am glad to leave the guard as it is. Either way, thanks for the careful read.

[Codencode]

Indeed, I also think it's better to avoid the page crashing.

[alicjacichocka-bitbag]

QA OK ✅

Tested on: PrestaShop 9.2.x d1106c4 (9.2.1), Docker, PHP 8.1.33, debug mode, theme Classic, ps_googleanalytics 6.0.0.
For "before", I used classes/Hook/HookDisplayFooterProduct.php from dev 64a6b1c. For "after", I used the same file from the PR head 025cf42, which is the only file the PR changes. The rest of the module is the same as dev. I cleared the cache after each switch.
I set a test GA_ACCOUNT_ID (G-QA181TEST) so that the events are rendered in the page source.

Setup (to reproduce #179): a small QA module hooked on displayFooterProduct before ps_googleanalytics assigns new Product($id_product, true, $id_lang) to the product Smarty variable. This is what a theme or module that assigns a raw Product object does. A second QA module hooked after ps_googleanalytics puts the original ProductLazyArray back, so that the rest of the template is not affected. Both modules are active only with ?qa_raw_product=1.

Steps:

1. Open the Clothes category, then the "Hummingbird printed t-shirt" product page (normal case).
2. Open the same product page with ?qa_raw_product=1 (raw Product object).

	Before	After
Product page, normal case (ProductLazyArray)	view_item + select_item	same, and the payload is identical before and after ✅
Product page with a raw Product object	fatal error Cannot use object of type Product as array in ProductWrapper.php:136 (the same stack trace as in #179), and the page doesn't render	the page renders normally. There is no view_item/select_item for this page, because tracking is skipped as described in the PR ✅

Other checks:

• Deterministic check from "How to test", run from PHP: prepareItemFromProduct(new Product(1)) still throws the error before and after, as expected, because the PR doesn't change the wrapper. HookDisplayFooterProduct::run() with a raw Product in the product variable throws the fatal error before. After, it returns NULL without an error ✅
• HookDisplayFooterProduct is the only hook of the module that reads the product template variable. The cart hooks (actionCartUpdateQuantityBefore, actionObjectProductInCartDeleteBefore) build their own product arrays, so they are not affected.
• The PR checks (PHPStan on 8.2.x / 9.0.3 / 9.1.x / develop, PHP-CS-Fixer, syntax) are green.

before_after_product_object_fatal.mp4

[Codencode]

@alicjacichocka-bitbag
Thanks for the QA and for confirming everything works as expected!

Can I add the QA ✔️ label to this PR?

[ps-jarvis]

PR merged, well done!

Message to @PrestaShop/committers: do not forget to milestone it before the merge.