[Codencode]

Questions	Answers
Description?	This PR removes a redundant is_array() check in GoogleAnalyticsTools::renderPurchaseEvent(). Both callers initialize $orderProducts as an array and only reassign it using prepareItemListFromProductList(), which always returns an array. Therefore, the check is unnecessary, and PHPStan correctly reports: Call to function is_array() with array will always evaluate to true. Additionally, native parameter and return types have been added to the methods in GoogleAnalyticsTools, taking advantage of the minimum supported PHP version (7.2). The issue is reproducible directly on the current dev branch. The removal of the redundant check does not change the existing behavior.
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?
Related to	#170 (comment)
Sponsor company	Codencode snc
How to test?	Run the PHPStan checks and verify that the develop job passes without reporting: Call to function is_array() with array will always evaluate to true.

[ps-jarvis]

Hello @Codencode!

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

Thank you, and welcome to this Open Source community!

[Hlavtox]

It would be best to add types to the methods. Since the minimum php version is now 7.2, we can. :-)

[Codencode]

@Hlavtox good point, thanks!

I’ve updated GoogleAnalyticsTools to use native parameter and return types across the class.

[boo-code]

QA: validated on dev. This tightens renderPurchaseEvent() to (array $orderProducts, array $orderData, string $callbackUrl): string and drops the now-dead if (!is_array($orderProducts)) return;.

The one regression risk in a signature tightening is a caller that can pass a non-array (which would turn the old silent return into a TypeError). Checked both call sites:

• HookDisplayOrderConfirmation and HookDisplayBackOfficeHeader each initialize $orderProducts = [] and only reassign it from ProductWrapper::prepareItemListFromProductList(...), which returns [] or an array on every path.

So $orderProducts is always an array at both call sites: the removed guard was unreachable, and @return string|void -> : string is behavior-preserving (the void return only happened in the branch being removed). No behavior change; the type-hardening is safe.

[LameuleFR]

The guard was indeed unreachable: both callers start from $orderProducts = [] and only reassign it from prepareItemListFromProductList(), which returns an array on every path. Not blocking: could you update the description so it mentions the native types added by the second commit (and clear the stray F in "Fixed ticket?")?

[Codencode]

@LameuleFR
Thanks for the review!

I've updated the PR description to mention the native types added in the second commit and removed the stray F from the "Fixed ticket?" section.