Bug report: "Link" custom field repeatedly adds quotes around label on each prod

-- HikaShop version -- : 6.5.2
-- Joomla version -- : ‎6.1.3
-- PHP version -- : 8.3.31

Hi HikaShop team,

I've encountered a bug regarding the "Link" type custom field on products. Each time the product is opened and saved, HikaShop adds an extra pair of quotation marks around the link's label/text value.

Steps to reproduce:

Go to Display > Custom fields and create a new field for the Product table.

Set its type to Link (e.g., column name: product_series_url).

Open any product in the backend and fill in this field:

URL: /abb/soft-starters/psr

Text / Label: Софтстартеры PSR

Click Save.

Save the product again without changing this field.

Repeat saving several times.

Observed result:
With every save, another layer of double quotes is prepended and appended to the label value. After several saves, it turns into:
"""""""""Софтстартеры PSR"""""""""

It looks like the text string gets re-escaped or improperly parsed each time the form data is processed on save.

Expected result:
The field should retain its original text string (Софтстартеры PSR) regardless of how many times the product is saved.

Could you please look into this and advise on a fix or patch?

Thank you!

Thank you for the quick turnaround and for fixing all three issues so fast! I will download the updated package, install it, and test it out. Appreciate your great support!

Hi Nicolas,

Thank you for the quick fix on the custom field issue!

We updated to the latest package, but now ran into a serious regression regarding the router/SEF URL resolution for category menu items.

1. The main issue: Unpublished category via Joomla menu item gives 404
In previous builds, our workflow allowed us to unpublish a category directly in HikaShop (so it doesn't appear in category listings/grids), while linking to it via a dedicated Joomla menu item (index.php?option=com_hikashop&view=category&layout=listing). In that case, navigating to the Joomla menu item URL still successfully loaded the page.

Now, with the category unpublished in HikaShop:

Accessing the newly created Joomla menu item URL directly returns a 404 error.

However, strangely enough, deeper child URLs (e.g., /owen/izmeriteli-regulyatory/2trm0, where the child sub-category itself is published) still load fine!

Some older categories configured the exact same way somehow still resolve, but newly created menu items with unpublished HikaShop categories fail immediately.

Did you introduce a strict category_published = 1 check in the router or controller when resolving the menu item's target category? Is there a setting or filter to allow direct access via a published Joomla menu item even if the category itself is unpublished in the catalog?

2. Router mismatch between Joomla menu item alias and HikaShop category alias
We also noticed a change in how URLs are rendered inside category listings on the front end:

Previously, if a Joomla menu item existed for a category, HikaShop automatically prioritized the Joomla menu item's alias/path when rendering links inside parent category listings, regardless of whether the internal HikaShop category alias differed.

Now, HikaShop seems to completely bypass the matching Joomla menu item and builds the listing links using its own internal category alias (e.g. rendering /owen/izm from the category alias instead of /owen/izmeriteli-regulyatory defined in the Joomla menu item).

Could you clarify what was changed in the routing logic (router.php or category.php class)? How can we ensure that:

A Joomla menu item pointing to a category remains accessible even if the HikaShop category is unpublished?

Listing links prioritize existing Joomla menu items rather than falling back to raw HikaShop category aliases?

Looking forward to your advice.

Thank you!

P.S.
If a merchant publishes a Joomla menu item explicitly targeting a specific category, the CMS menu item should take full precedence for routing and access. Hard-blocking it with a 404 simply because category_published = 0 completely strips away our flexibility to control public directory listings independently from direct landing URLs.


Previously, category URLs generated in listings strictly followed our Joomla menu structure, keeping the active menu item and the correct breadcrumb trail. Now, this is broken: listings generate raw category alias URLs instead of using the corresponding Joomla menu items, which breaks the breadcrumbs and menu context.

Our SEF Settings (see attached screenshot):

Insert canonical URLs in listings: No, generate URL

Category SEF name: (Empty — left blank intentionally for clean URLs)

Remove product and category IDs from URL: Yes

Simplified breadcrumbs: No

All categories and sub-menu items are published and have existed for a long time. Everything worked as expected on previous versions, but 6.6.0 no longer maps listing links to our Joomla menu items with these settings.

Could you please check what changed in the SEF router regarding Joomla menu item matching in listings?

Thank you!

Hi, I also have found a similar issue:
When selecting a product, it now opens in its own window instead of a new page, therefore I can no longer get the URL easy to send to customers when they are after a certain product, not easy when we have 1,000's of products online.

Rgds

found the issue, and fixed.

Hi HikaShop team,

I have tested and confirmed a breaking bug between previous versions and 6.6.0 regarding Joomla menu items and category URLs in listings.

The root cause:

In earlier versions, saving a HikaShop category listing menu item stored the category parameter in #__menu.params as a string/integer:

"category": "23"

In recent versions, the category selector saves it as an array (even for a single category):

"category": ["23"]

Because of this format change, the code casting in both router.php and view.html.php completely breaks:

In components/com_hikashop/views/category/view.html.php (getLink):

PHP
$params = $category_params->get('hk_category',false);
if($params && isset($params->category))
$parent = $params->category;
...
$submenuCategoryMap[$Itemid][(int)$parent] = (int)$submenu->itemid;
When $parent is ["23"], PHP evaluates (int)$parent to 1!

Because of this, $submenuCategoryMap stores key 1 instead of 23. The listing fails to recognize that a Joomla submenu item exists for category 23 and falls back to generating a raw alias/fallback URL (e.g. /category/p...) instead of the clean menu URL.

In components/com_hikashop/router.php (_HikashopBuildRoute):

PHP
if(isset($catParams->category)) $menuCat = (int)$catParams->category;
if($menuCat > 0 && $menuCat === (int)$query) { ... }
Here again, (int)$catParams->category evaluates to 1, so $menuCat === (int)$query is always false.

Verification:
When I manually edit #__menu.params in the database, change "category": ["23"] back to "category": "23", and clear the Joomla cache, the category URLs and breadcrumbs in listings immediately work correctly as expected. As soon as the menu item is re-saved in the Joomla administrator, it reverts to ["23"] and breaks again.

Could you please either save single category IDs as scalars or add an is_array() check when reading $params->category in view.html.php and router.php?

Thank you!

Regarding the "Main category" field UI change (see screenshot):
Notice how the "Main category" (category) field in the menu item options is now a multi-select tagged input (with the [x] badge) instead of the previous single-select field.

Because this field allows multiple tags, the form handler submits it as an array and stores "category": ["23"] in the database.

What was the rationale behind allowing multiple "Main categories" for a single Joomla menu item? A menu item naturally points to a single node in a site's breadcrumbs and URL structure. Allowing an array here directly breaks the router's ability to map parent categories and submenus because the core code still expects a scalar integer. If multiple main categories are truly supported, the router and view code must unpack the array; otherwise, this field should remain a single-select.