Item-field validation error in cart->addProduct surfaces at later checkout steps

-- HikaShop version -- : 6.4.1
-- Joomla version -- : 6.1.0
-- PHP version -- : 8.5.5
-- Browser(s) name and version -- : Chromium 130 (Playwright) — also reproduces in any browser; not browser-specific
-- Error-message(debug-mod must be tuned on) -- : no Joomla error log entry — the bug is incorrect message routing, not a PHP error. The customer sees the field's `errormessage` value, e.g. "Please enter the year. If year does not apply, enter the word 'none'."

Hi HikaShop team,

Reporting a small bug in the standard checkout, with a suggested patch.

Bug: when validates a required item-field that's empty, the field's is written to Joomla's session message queue. The customer then sees that alert at a later checkout step (typically Payment), with no cart-row context to indicate where the error came from.

Cause: in line 1845, runs without overriding the field class's default , so calls . The cart's own loop a few lines below already handles error reporting in the right scope — the call is redundant and leaks the message into the session queue.

The Fields-step helper at already does this correctly for order fields by passing as the report mode. The cart's item-field path just needs the same treatment.

Patch (against 6.4.1; is byte-identical to 6.4.0):

Tested locally on Joomla 6.1.0 + HikaShop 6.4.1.

I searched the forum for prior reports of this specific symptom and didn't find one — apologies if I missed it.

Thanks,
Brian

Hello,

Thanks for the report and the very precise diagnosis with the location and the suggested fix.

You are exactly right. In `cart::addProduct()` the call to `$this->fieldClass->checkFieldsData()` was running with the field class's default `report = true` setting, which causes a validation failure to also be enqueued via `JFactory::getApplication()->enqueueMessage()`. That message lives on Joomla's session queue across the post / redirect chain, so it ends up rendered at whichever page is shown next, typically a later checkout step. The cart already builds the error in its own scoped channel right after via `$this->addMessage()` so the session-queue copy was a duplicate fired at the wrong moment.

The change has been included on our end using exactly the pattern you suggested. We save the current `report` value, force it to `'msg'` for the duration of the `checkFieldsData()` call, and restore it afterward, matching what `helpers/checkout/fields.php` already does for `getFilteredInput()`.