HikaShop 6.5 change log

Details: Written by: Administrator; Category: Global informations; Published: 25 October 2026; Hits: 44

All the HikaShop 6.5 releases. The latest version and the list of all the versions are on the HikaShop Change Log page.

HikaShop 6.5.2

Release date : July, 20 2026

Improvements (1)

The HikaShop to HikaShop migration now brings your customers' user groups over from the old shop. Any user group that does not exist yet on the new site is recreated with the same name and the same place in the group hierarchy, and each imported customer is assigned to the same groups as before, instead of everyone being added to the Registered group. The access levels and the permissions attached to the groups are specific to each site and are not migrated, so you would review those separately if you use custom ones.

Bug fixes (11)

The button that inserts a product tag into your content, used to add a HikaShop product to a Joomla article or module, no longer breaks the JCE editor. The button handed its information to the editor in a form that JCE could not read, so JCE failed to load on those edit screens with a "Call to undefined method" error. It now works with JCE the same way it already worked with the other editors.
The frontend no longer fails with a "Call to an undefined function parse_ini_file()" error on shops that use the multilingual translations without Falang. To display the translations of your products and categories, HikaShop reads the language override files it stores for each language, and it did so with a PHP function that a few hosting providers disable for security reasons, which stopped those pages from loading. HikaShop now detects when that function is not available and reads the files another way, so the translated pages display normally again on these servers.
The product and category listings no longer fail with a "Layout ... not found" error when they are opened through an address that has no HikaShop menu item of its own, for example a direct or bookmarked link. In that case the listing used the layout of whichever menu item Joomla fell back to, and when that was a menu using a layout name that HikaShop does not have (typically the "blog" layout of a Joomla articles page set as the site home page), the listing could not be displayed. The listing now falls back to its default layout in that situation and displays normally. Listings opened through their own HikaShop menu item were not affected.
The HikaShop to HikaShop migration no longer sends an account creation email to each customer while it imports the users from your old shop. Because the users were created through the standard Joomla user creation, Joomla sent its "new account" notification for every imported customer, which could add up to thousands of emails and, on some servers, stop the migration once the hosting email limit was reached. The users are now created without triggering these notifications, so the migration stays silent and runs through to the end.
The product comparison page shows all the selected products again, instead of only the first one, on sites that have the search engine friendly URLs turned on. When several products were sent to the comparison, their identifiers were joined together in the address with a dash, which is also the character that separates the different parts of a search engine friendly URL, so only the first identifier could be read back and only that product was compared. The identifiers are now joined with a comma, so the whole selection is compared as expected. Shops without the search engine friendly URLs were not affected.
The frontend product search now finds your products by their translated name or description on shops that use the multilingual translations without Falang. When a visitor searched from a text search filter while browsing in a language other than the shop's default one, the search only looked at the original text of your products, so a product could be found by its default language wording or its code but not by the translated wording your visitors actually see on the page. HikaShop now also searches the translations you entered for the language being browsed, so a search for a translated product name or description returns the matching products as expected. Shops using Falang for their translations, and searches made in the default language, were not affected.
On shops that hide the product id from their addresses and use the multilingual translations, the first product of a category no longer returns a 404 error in a translated language when it has the same name as its category. HikaShop builds the translated address of a product from its translated name, so a product named like its category ended up with the same address as the category, and the two collided. HikaShop now automatically gives such a translated product address a distinct value, so the product page opens normally. Shops that keep the id in their addresses, and products whose name differs from their category, were not affected.
On the product edit page, a block that you create yourself under the form customization can now be repositioned like the built-in ones. The new block was missing its up and down move arrows and, because it was not recorded in the block order, it went back to the bottom of the form every time you saved. Such a block now receives its move arrows straight away and keeps the position you give it after saving. The built-in blocks were not affected.
Creating or saving a filter no longer fails with a "1054 Unknown column 'autocomplete' in 'field list'" database error. The autocomplete options that were added to the text filters were mistakenly written as columns of the filter table when saving, which does not exist, so the save was rejected. These options are now stored correctly with the rest of the filter settings and filters save normally again.
On Joomla 6, some HikaShop system plugins no longer break the module rendering of template frameworks such as T3, which could make the frontend layout, colors and sidebars display incorrectly. HikaShop loads a set of legacy class names so that older third-party plugins keep working, and on Joomla 6 it did so in a way that loaded Joomla's module helper too early, which prevented the template framework from applying its own module display. HikaShop now loads these legacy names only when needed and no longer registers them when Joomla's own Backward Compatibility plugin already provides them, so the template framework keeps control of the module display.
We fixed a medium severity open redirect vulnerability in the currency switcher, where a specially crafted link using a doubly encoded address could send a visitor to an external website after changing the currency. The address the visitor is sent back to is now decoded and validated before the redirection, so only addresses on your own site are allowed.

HikaShop 6.5.1

Release date : July, 11 2026

Bug fixes (51)

Hardened the sorting of the product and order listings.
Hardened the order actions available to customers from their account pages.
Hardened the processing of uploaded files.
When saving a product whose alias is already used by another product, the alias is now really modified automatically to avoid the conflict, with a warning telling you about the change, as originally intended: a typo prevented the mechanism from ever running. Existing products get their product id appended to the alias and new products get an incrementing number.
The checkout page no longer displays "Undefined property ... $address" PHP warnings when a visitor registers a new account during the checkout. The warnings only appeared when the error reporting of the site was set to a strict level and did not affect the address form, which kept working normally, but they are now gone.
Opening a custom field for editing no longer produces a "Cannot access offset of type string on string" error when the field's stored options are empty or malformed in the database (for instance a field created by a third party plugin). The field options are now always treated as an empty list in that case, so the field editor keeps working.
On the product page, the custom item fields of a product with variants are shown again when the variants have no price of their own and inherit the price of the main product. They were hidden in that case because the product was treated as free, even though it is actually sold at the inherited price. This only happened when the "Display the add to cart button for free products" option was turned off. Products whose variants carry their own prices were not affected.
When editing an order in the backend, adding a second tax rate to a product line now keeps that tax on the line and in the order total. Previously, if the name of one of the tax rates contained a comma (for example "Recargo Equivalencia 5,2%"), saving the order dropped that tax and only the other rate was applied, because the list of tax rates assigned to the product was stored as a comma separated text and the comma inside the rate name split it apart. Tax rates whose names do not contain a comma were not affected.
The product listing view switcher now switches the products to a single column when the visitor chooses the list view. Since the product and category listings moved to a CSS grid layout, clicking the list view button kept the products in their usual columns and only rearranged the content inside each product, so the list view looked almost identical to the grid view. Switching to the list view now places one product per row as intended, while the grid view is unchanged.
Updating HikaShop no longer stops with a "Cannot redeclare com_install()" fatal error on sites that also have an older third-party component built on the legacy Joomla 1.5 installer (for example the PayZen com_payzen component). HikaShop kept declaring the old com_install() install function on Joomla 4 and later, where Joomla no longer calls it, and a component that tested for that function the wrong way around then tried to redeclare it and halted the update. HikaShop now declares that legacy function only on the Joomla versions that actually use it (before Joomla 4), so the update goes through. Sites without such a component were not affected.
Recently viewed products are recorded again for products that have variants, so a products module or menu ordered by the "product_last_seen_date" field (the "last products viewed by everyone") and the per-visitor "Recently viewed" listing both fill up correctly. Since the product page was reworked in version 6.4.0, viewing a product that has variants saved the visit on the selected variant instead of on the main product, and listings only show main products, so those views never appeared and the recently viewed lists stayed empty or stale for such products. The visit is now always recorded on the main product. Products without variants were not affected.
A required custom field displayed as radio buttons or checkboxes on the product page now stops the product from being added to the cart until the customer actually makes a choice. Since the product page was reworked in version 6.4.0, when such a field was left empty its first option was sent automatically as the product was added to the cart, so the product went into the cart with that first value and the customer was never required to choose. The field now blocks the add to cart with the usual message asking to fill it in until an option is selected, so an order can no longer be placed with an unintended default value. Fields where the customer did make a selection, and fields displayed as dropdown menus, were not affected.
On product pages whose view has been customized (overridden) before version 6.4.0, the price, name and image now update again when a visitor selects a variant while the characteristics are displayed as radio buttons. Since 6.4.0 the product page is no longer wrapped in a single form, and the default product page view tags the characteristic fields so the script can still find the selected radio button. A product page view that was customized before that change does not have this tag, so on those pages the script could not read the selected characteristic and the displayed price stayed on the default variant (the correct variant was still added to the cart at the correct price). The script now reads the characteristics directly from the product page, so variant selection works whether or not the product page view has been customized. Variants displayed as dropdown menus were not affected.
The "number of items per page" dropdown shown below the product and category listings now has an accessible name, so accessibility and SEO audits such as Google PageSpeed Insights and Lighthouse no longer report it with the "Select element must have an accessible name" warning. The dropdown had no label, so screen readers and audit tools could not tell what it was for; it now carries an "Items per page" label that assistive technologies announce, with no visible change to the page.
A product that uses variants but has none of them published is no longer offered for sale as a free product. When every variant of a product was unpublished, the product lost its variants and was displayed like a simple product with no price, so it still appeared in the shop and could be added to the cart for nothing. Such a product is now shown as out of stock with no "Add to cart" button, and adding it to the cart is refused as well, so unpublishing all of a product's variants takes it off sale as expected. Products that still have at least one published variant are unaffected.
A mass action that runs a custom SQL query or PHP code from an order trigger no longer shows a "requires Super User privileges" error to your customers on the checkout confirmation page. The privilege check was also running while an order was being placed, where the current user is the shopper and not an administrator, so the action was skipped and the error was shown to the customer. The Run PHP code, Run SQL query and Send HTTP request actions are now restricted to Super Users where they are selected, saved and run, instead of when they execute. Order-triggered and scheduled mass actions run normally again, while these powerful actions stay limited to Super Users and are hidden from the action list for other administrators.
Adding a new product that has images now keeps you on the product edit form when a required custom field was left empty, instead of stopping the save with a fatal error page. When the save was refused because of a missing required field, the form was shown again with the uploaded images reduced to plain identifiers, and redisplaying it then failed. The images are now restored as proper entries when the form reappears, so you stay on the form with your data and your images kept, ready to fill in the missing field and save.
The product filters, such as the price slider, no longer disappear after a filter is applied when the filter module refreshes the list without reloading the page (its "Force redirect" option turned off) and another extension or the template has a JavaScript error on the page. After such a refresh HikaShop re-runs the page scripts, and a single failing third-party script used to stop that process and leave the price slider blank until the page was fully reloaded. Each script is now run on its own, so one faulty script can no longer prevent the filters from being redisplayed.
The product filters no longer disappear after a filter is used on sites with search engine friendly URLs turned on, where every filter but the search box vanished until the page was fully reloaded. When the filters refresh in the background without reloading the page, that request could come back as the whole page instead of just the filter block, and HikaShop then replaced each filter with the first block found on the page, which was usually the search filter. HikaShop now always restores the matching filter block, so the price, characteristic and category filters stay visible after filtering. This happened whatever the filters' "Dynamic display" setting, which is why turning that option off did not help.
The product page structured data (the JSON-LD that Google reads for search results) no longer reports customer comments that have no star rating as zero-star reviews, which Google Search Console rejected with a "Rating is outside the specified or default range" error. On shops where ratings and comments can be submitted separately, a comment left without a star rating was output as a review with a rating of 0, and those empty ratings were also pulled into the product's overall rating and review count. The structured data now includes only votes that actually carry a star rating, so the reported average and review count match what the website already shows. Comments without a rating stay visible on the product page exactly as before; they are simply no longer sent to search engines as zero-star reviews.
The FedEx 2 shipping plugin now returns rates for addresses that have no state or province. The plugin read the state code without checking that a state was set, which raised a "zone_code_3 on null" warning and, on United States and Puerto Rico addresses, then sent an empty state to FedEx, which FedEx rejects, so no rate was returned. The plugin now reads the state safely and only sends a state to FedEx when one is present, so an address with just a country and a postcode still gets rates.
The price range slider in the product filters no longer disappears after a filter is used, on shops where the price filter had its "deletable" option turned on. With that option on, selecting a price range replaced the slider with a small removable label, and after clearing the price the slider did not come back until all the filters were reset. A price filter is now always shown as a slider, with its clear button kept beside it, so the slider stays visible whatever filters are applied.
On WordPress, the rich text editor inside forms loaded over AJAX (such as the product variant edition form) can now be switched to the Visual tab without breaking. These forms are rendered outside the normal WordPress admin page, so WordPress did not output the editor TinyMCE configuration and clicking Visual threw a JavaScript error that left the editor unusable. HikaShop now outputs the needed editor configuration inline for these AJAX-loaded forms, while preserving the configuration of any other editors already on the page.
Live shipping rates from the FedEx, UPS and other carrier plugins now appear correctly when the list of shipping methods refreshes automatically as the customer types the address during the checkout. Until now these plugins could not load an address that had not been saved yet, so their rates did not show, and with debugging turned on the FedEx plugin reported an "Attempt to assign property address_country on true" error. The address being entered is now kept available to the carrier plugins so they can request their rates against it during the live refresh.
The price in the product page structured data (the JSON-LD that Google reads for search results and Google Merchant) now follows the shop's "Show taxed prices" display setting when the Google / Meta Products plugin has not been configured. After the structured data was reworked to use JSON-LD as the single source, the price fell back to the pre-tax value on shops that had not set up the Google Products plugin, so Google could show a price without tax while the website showed the tax-included price. When the plugin is not configured, HikaShop now uses the same with-tax or without-tax choice as the prices shown on the site; shops that have configured the plugin keep using its own "Taxed prices" option.
The "Configure display options" popup for HikaShop module blocks (products, cart, and others) in the WordPress block editor now shows the options form with its proper styling and working controls, instead of a bare unstyled list of fields. The popup output the form markup but not the stylesheets and scripts that the options view registers on the page, so the layout picker, the columns and rows grid selector and the styled toggles had no styling and did not work. The popup now outputs those stylesheets and scripts the same way the regular HikaShop admin pages do.
The "Terms and conditions" popup at checkout on WordPress now displays the configured page instead of a PHP warning followed by a "No article defined" message. The popup read the terms from Joomla's article table, which does not exist on WordPress, so nothing was found and the code then tried to read a property of the missing article. On WordPress it now loads the terms from the configured page, and the Joomla-only multilingual article handling is guarded against a missing article, so a deleted or misconfigured terms article no longer raises a warning on either platform.
HikaShop popups on WordPress, such as the cart's "edit product options" popup, now use the active theme's styling instead of appearing unstyled with default fonts, plain radio buttons and Bootstrap-coloured buttons. These component-only popups build a minimal HTML page that enqueued HikaShop's own assets but never triggered the active theme's stylesheet and font loading, so the popup had none of the site's design (and theme-provided touches such as colour swatches did not appear). The popup now fires the standard front-end asset loading, so the active theme styles it exactly like any other page.
Adding a product to the cart on WordPress no longer shows the confirmation notification twice, and other front-end scripts are no longer loaded twice. HikaShop fired its onBeforeCompileHead event in two places on WordPress (once when enqueuing the page assets and again while rendering the page content), so plugins that inject scripts on that event, such as the cart notification plugin, were included twice and registered their handlers twice. The event now fires only once per request, and the document script list is cleared after the scripts are enqueued so the content renderer does not emit them a second time.
Product characteristic options shown as radio buttons (for example colour swatches and size choices) now render with the correct markup and styling on WordPress. The radio-list helper on WordPress output a plain label and input without the Bootstrap form-check structure that Joomla produces, so template styling that targets those classes did not apply, and any HTML inside an option value (such as a colour swatch) was escaped and printed as raw text. The helper now produces the same form-check markup as Joomla and outputs the option labels without escaping, matching Joomla.
Product and category listing filters (the search box, the characteristic checkboxes and the price slider) now actually narrow the results on WordPress instead of only being displayed. The listing applies the selected filters only when the request is flagged as the main front-end component output; Joomla sets that flag when the component renders, but it was never set on WordPress, so submitting a filter reloaded the same full list of products. The flag is now set when HikaShop renders its main page content on WordPress, so the filters narrow the products there exactly as they do on Joomla.
HikaShop no longer stops with a fatal "Class JLoader not found" error when opening the checkout on WordPress. The checkout controller ran a Joomla-only block that resolves multilingual menu-item associations through the Joomla JLoader and MenusHelper classes, which do not exist on WordPress, so the page crashed before the checkout could be displayed. That block now runs only when those Joomla classes are available, so it is skipped on WordPress while continuing to work on Joomla multilingual sites.
Creating a product or category listing menu directly from the Joomla menu manager now applies the default display options set in the configuration (Display tab), in particular the number of columns and items, instead of always opening on a fixed 3 columns by 7 rows layout. Those default options were only used when the menu was created through the HikaShop menu manager; a menu created from the Joomla menu manager ignored them and fell back to a hard-coded 3 columns and 20 items. Both ways of creating a listing now start from the same configured defaults.
HikaShop now uses the Falang translation component only when it is actually installed and enabled, instead of as soon as its database table is present. The integration was switched on by the mere existence of the Falang table, so a site that had uninstalled or disabled Falang but kept its leftover table had HikaShop read and write translations through that stale table instead of using its own translation overrides. HikaShop now also checks that the Falang component is installed and enabled before using it.
The view editor (Display > Views) is now legible in dark mode. The builder cards, the drop zones and the draggable item boxes used hard-coded light colours that did not adapt to the back-end dark theme, which left dark text on dark boxes and a stray light panel. They now use proper dark colours with readable contrast when the back-end dark mode is active; the light mode is unchanged.
The "withdraw from contract" form (EU Directive 2023/2673) no longer sends a customer to the login screen instead of letting them submit. When the form was reached with an order reference (for example by following the withdrawal link from the order confirmation email), or when a guest submitted the standalone form for an order that was not in a withdrawable state or already had a request, HikaShop redirected to the account order listing, which requires a login, so the visitor hit the login page rather than the form or a clear message. Guests are now kept on the withdrawal form: following the link without being logged in shows the standalone form where they identify themselves with their order number and email, and a rejected submission shows the reason (not withdrawable, already requested) on the form instead of the login screen. Logged-in customers are unaffected.
Paybox and PayPlug (v2) payments are no longer charged one cent less than the order total on some amounts. When the order total had cents whose value could not be represented exactly in floating point (for example 270.28 or 128.64), the conversion to the integer amount sent to the gateway was truncated downwards (270.28 became 27027 instead of 27028), so the customer paid one cent short and the order was still validated because the return check used the same truncated value. The amount is now rounded to the nearest cent before being sent and verified, so it always matches the order total.
PayPal Checkout payments can be completed again on shops where the final step failed with an "Unknown error when processing order" message at the end of the PayPal popup, even though the buyer had already approved the payment. PayPal moved its API behind a stricter front-end that returns a generic "400 Bad Request" for the capture, authorize and re-authorize calls HikaShop was sending without a request body, so the payment was never captured. HikaShop now sends an empty JSON object as the body of those calls so PayPal accepts them again. Shops that were not affected keep working exactly as before.
The cart module now honors its "Hide if empty" option again in mini-cart mode with a configured icon. The 6.5.0 change that keeps the cart icon visible when the cart is empty was overriding that option; when "Hide if empty" is set to Hide, the empty mini-cart (icon included) is now hidden again as it was before 6.5.0, and when it is not, the icon stays visible as introduced in 6.5.0.
Creating or saving a product filter (search box) bound to a custom field no longer fails with a misleading "The chosen custom field is not available for this category" warning that also blanked the selected field, on sites that have the advanced date picker filter plugin installed. The date picker filter types render their own field selector in the filter form; while hidden, it shared the same form field name as the main custom-field selector and was not disabled, so it overrode the merchant's choice on save and submitted an empty value. The configuration panels of the inactive filter types are now disabled until their type is selected, so only the active selector is submitted.
The PayPal Checkout "Pay Later" messaging (for example "payer en 4x avec PayPal") shows again on product pages for shops whose currency is not US dollars. The messaging script was loaded without the shop currency, so PayPal evaluated the offer in its default US dollar context, found none and returned no content, leaving the message blank even though Pay Later was available at checkout. The shop currency is now passed when the messaging script is loaded, the same way the checkout buttons already do, so PayPal serves the message in the shop's currency. Shops in US dollars were unaffected.
The product display mode dropdown used by product listing modules and menus (Related products, In the same categories, From the same manufacturer, In the module's parent category, Other clients also bought) no longer drops one of its choices. Two of the choices were stored under the same internal list index, so one of them ("In the module's parent category") was overwritten and never appeared in the dropdown. All five choices are now listed and selectable.
Importing discounts from MijoShop or OpenCart now keeps each coupon's total usage limit instead of importing every coupon as having no limit. The usage quota was mapped twice during the import and the second mapping, a fixed 0, overrode the value read from the source shop, so all imported coupons arrived with their usage limit cleared. The limit from the source shop is now imported correctly.
On multilanguage sites, a product shown through Joomla's tags system no longer triggers a fatal error when its link is built. HikaShop's tag route helper used a language-lookup helper that recent Joomla versions removed from the base route helper class, so generating one of these links stopped the page with an "undefined method" error. HikaShop now provides that language lookup itself, so the link is built correctly with its language code. Single-language sites were not affected.
On the orders listing, the "Change status" mass action now respects the "Send notification email" checkbox when it is left unticked, so the status-change email is no longer sent to your customers against your choice. The checkbox was only tested for being present and not for its value, so the customer notification went out whether the box was ticked or not, in particular when the mass action had been saved. Ticking the box, and changing a single order's status from its own page, worked correctly and are unchanged.
The withdrawal confirmation email sent to the customer (EU Directive 2023/2673) now always lists the withdrawn products with their quantities and the billing and shipping address, the same way the copy sent to the shop already did. Until now that summary was only included when the withdrawal was submitted from the customer's order page, and was left out when the request came through the standalone withdrawal form (order number and email), so those customers received a confirmation without the list of what they had withdrawn.
The checkout no longer stops with a memory exhaustion fatal error ("Allowed memory size of X bytes exhausted") on some sites when a coupon is added to the cart. Since version 6.4.1, the coupon in the cart keeps an internal link back to its cart so that coupon plugins can check the cart content, and HikaShop's internal data duplication routine could enter an endless loop when it received data containing such a mutual link, exhausting the PHP memory. That routine now detects the situation and duplicates the data correctly, whatever plugins are used. Checkouts without a coupon were not affected.
On small screens, the downloads area of the customer account no longer shows the column names printed on top of the values. On narrow displays the downloads table is stacked vertically and each value is labelled with its column name, but the label was drawn at a fixed position without any room reserved for it, so a long product name, or a long column name such as "Limite du nombre de téléchargement" in French, overlapped its neighbour and became unreadable. The column name now has its own space on the left of each line, wrapping over several lines when needed, while the value stays on the right.
On wide or zoomed-out displays, the variant edit form of the backend product page no longer shows large empty gaps in its first row. Two invisible leftover elements of the previous layout were counted as blocks by the CSS grid the page now uses, and were placed right after the "Main options" block, pushing the "Images and files" block to the right and the "Prices" block down to the next row. The blocks of the form are now laid out side by side, like on the main product tab. This was only a display issue, all the fields kept working correctly.
The sub zones list of a zone no longer shows blank rows that cannot be deleted. When a zone that was used as a sub zone of another zone was deleted, its link to the parent zone was left behind in the database and appeared as an empty, undeletable line in the parent's sub zones list. Deleting a zone now also removes every link that tied it to other zones, so these blank lines no longer appear, and any blank line left over from a past deletion can now be removed with its delete button.
In the address form layout editor, the width button of each field (the double arrow icon in its toolbar) now changes the field width when it is clicked, cycling through the widths that fit the row while the other fields of the row adjust to keep it filled. It previously reacted only to being dragged left or right, so a simple click did nothing and the button looked unresponsive. Dragging the icon to resize a field still works as before, and the button can also be operated with the keyboard by giving it focus and pressing Enter or Space.

Improvements (17)

When you save a product whose variants are all unpublished, HikaShop now shows a warning that the product has variants but none of them is published, so it is not available for sale. The save still goes through; the message is only there to flag a state that is easy to reach by accident, for example after unpublishing the last variant of a product. Saving a product that has at least one published variant shows no such warning.
In the backend, the category tree shown beside the category listing now opens by default when the listing has nothing to show, instead of staying folded next to an empty list, which could look as if something was broken (for example when every category is nested under another one, so the top level is empty). Your own choice to open or close the tree is still remembered as before. The manufacturer listing behaves the same way.
When importing products, a column that matches a characteristic, or a custom product field of the dropdown, checkbox or radio type, no longer drops a value that does not exist yet: the missing characteristic value or field option is created automatically and the product is linked to it. A cell can hold either the stored value or the displayed label of an existing option, and it is matched to that option in both cases instead of creating a duplicate. Custom fields whose options are filled from a MySQL query are left untouched.
The install package is smaller. The mass action plugin bundles the MCP server library used by the AI assistant features, and that library was pulling in several code-analysis libraries (phpDocumentor, PHPStan and their dependencies) that are only used for an automatic tool-description mode the plugin does not rely on. Those libraries, about 1.5 MB and 260 files, are no longer included in the package; the mass action features are unchanged.
Packaging maintenance pass on the bundled third-party libraries included in the install package.
The internal order modification method now accepts the historical argument order used by older payment and integration add-ons. A new order modification method introduced for the agentic commerce (UCP) support expected the payment method name in the position where the historical method expected the "notify the customer" flag, so an add-on written for the historical order could change an order status without that flag being honored, and the status email was not sent. The method now detects and accepts both argument orders, so those integrations notify customers as expected.
The view override editor (Display > Views) now shows the path of the override file it edits. When you open a view, the editor displays where the override is stored under your front-end template, or, when no override exists yet, where it will be created when you save your changes, so you can locate the file on the server without having to work the path out by hand. The path is shown relative to the site root and works on both Joomla and WordPress.
Added a "Do not issue an invoice for free orders" setting in the Invoices section of the configuration. When enabled, an order whose total to pay is zero (for example a course fully covered by a coupon or funded by a third party) is processed through its normal statuses but does not consume an invoice number. The behaviour was already in the code; the option is now available in the backend. The option is also honored on the front-end: the "Print invoice" button is no longer offered for these free orders in the customer's order area, and the matching print address is blocked, so a customer can no longer generate an invoice document for an order that has no invoice number. The order page itself stays available as a record. Stopping the PDF invoice from being attached to these orders' emails additionally requires the matching update of the Attach Invoice plugin. With the option off (default), free orders are invoiced exactly as before.
Add-ons can now replace the "Free" label shown for a product that has no price, on a per-product basis, the same way the "Add to cart" button text can already be overridden. A plugin sets a message on the product and the product listing and product page print that message instead of "Free". This is used by HikaAuction so that an auction with no starting price and no bids yet shows its auction status (for example a countdown to the start, or "No bids yet") rather than the misleading "Free". Shops without such an add-on are unaffected and keep showing "Free" for genuinely free products.
The cart drawer module now renders at the full viewport size on templates that put a frosted-glass effect (backdrop-filter) or a transform on a parent of the cart module, such as UIkit and Bootstrap 5 sticky navbars or many custom sticky headers. On such pages, the drawer used to be trapped inside the navbar's box (a thin strip at the top of the page) instead of overlaying the page, because the CSS specification makes any ancestor with transform, filter, perspective or backdrop-filter the reference frame for fixed-positioned descendants. The drawer now detects this case when it opens and compensates with inline offsets so the overlay covers the whole page and the drawer panel slides in from the side of the viewport as expected. Templates that do not use any of these properties on an ancestor of the cart module are not affected and continue to render as before.
Internal modernization for maintainability: HikaShop and its plugins now use the namespaced Joomla classes in their own code instead of the legacy class names (JFactory, JText, and so on). HikaShop already mapped those legacy names to their modern equivalents itself, so the shop kept working the same way (including with Joomla's Backward Compatibility plugin disabled); this change keeps the code aligned with the current Joomla APIs for easier maintenance going forward, with no change to how the shop runs.
PHP 8.4 compatibility: the command-line cron script no longer raises "implicitly nullable parameter" deprecation notices on PHP 8.4. The constructor parameters that default to null are now declared explicitly nullable. Behaviour is unchanged on every supported PHP version.
Joomla 7 compatibility: HikaShop no longer relies on several Joomla functions, a base class and a JavaScript helper that Joomla is removing in its upcoming version 7. HikaShop keeps working once merchants move to Joomla 7, with no change to how the shop behaves on the Joomla and WordPress versions available today.
The FedEx 2 shipping plugin now has a "Group packages" option in the shipping method configuration, like the legacy FedEx plugin and the other carrier plugins. When enabled, the items in the cart are combined into a single package for the FedEx rate request instead of being sent as one package per product, which avoids over-quoting a multi-item cart as several separate boxes. It is off by default, so existing setups are unchanged.
The "Read more" separator in product and category descriptions is now recognized even when it was saved as <hr id="system-readmore"> without the closing slash, instead of the usual <hr id="system-readmore" />. Some editors drop that slash, in particular when a description is translated through a tool such as Falang, and the separator then looked absent: layouts that rely on it (for example the tabular product layout, which splits the description at that point) showed the whole description instead of only the intended part. Descriptions whose separator is stored in the usual form are unchanged.
When a customer clicks the final order button on the last checkout step, the checkout now shows a "Your order is being processed, please wait..." message under the loading spinner. Placing an order can take a few seconds while the payment gateway, shipping carriers and notification services are contacted, and until now only a spinner was shown over the checkout, which could leave the customer wondering whether anything was happening and tempt them to click again or leave the page. The message reassures them that the order is going through. It is translatable and can be adjusted with a language override, and it only appears on the step that actually places the order; moving between earlier checkout steps is unchanged.
Applying a filter on a product listing no longer turns the page blank on sites sitting behind a cache or security proxy that rewrites URLs (such as Sucuri). Filtering refreshes the listing through an Ajax request that asks HikaShop for the listing block alone; when the hosting or the proxy dropped the parameter carrying that request, the server returned the whole page instead, and HikaShop re-ran every script of that page, which could wipe the display until the visitor reloaded. HikaShop now takes only the refreshed listing out of such a response and runs only its own scripts, so the products update in place as expected. Sites not behind such a proxy were not affected.

New features (20)

The PayPal Checkout payment plugin can now display an express checkout button directly on the cart, before the checkout. The customer pays through the PayPal window, where they pick their PayPal address and see the shipping options and the final total, and then lands on the checkout already filled in: no address form to type, just a final confirmation. If the cart changes between the approval and the confirmation, the amount is reconciled with PayPal before the payment is taken, and a higher total always requires a new approval from the customer, so the captured amount can never silently differ. The button can be enabled for the cart page and for the checkout cart in the settings of the PayPal Checkout payment method.
You can now add a block of information to the product pages of a whole category or brand at once. The category and brand edition screen has a new "Information for the product page" rich text field, and whatever you write in it is displayed on the product page of every product of that category or brand. It is meant in particular for the manufacturer and EU responsible person details required by the GPSR regulation, which must be shown on the product page, but it is equally handy for care instructions, warranty notes or any legal mention shared by a range of products. Each product displays the information of its brand and of every category it belongs to, and nothing is shown when the field is left empty.
Products now have a GTIN field on their edition screen, for the product's barcode number (EAN, UPC or ISBN). When you fill it in, the GTIN is automatically added to the structured data of the product page and to the Google Merchant product feed, so search engines and Google Shopping can identify your products without any extra setup. Each variant can carry its own GTIN. The field is optional and empty by default, so nothing changes for products that do not have one.
The filters of the products listings can now display the number of products next to each choice, for example "Red (12)". It can be turned on for each filter with the new "Display product counts" option, for the category, characteristic, manufacturer, custom field, price range and product information filters. The numbers take the other active filters into account, so they always tell the visitor how many products a click will bring up, and they reuse the product set the filters already compute for their dynamic display, so activating them costs only one extra light query per filter.
Text filters can now show autocomplete suggestions as the visitor types: matching product names appear in a dropdown under the filter, backed by the same fulltext index as the product search, and can be picked with the mouse or the keyboard. The suggestions respect the filter's category and the visitor's access rights. It is turned on per filter with the new "Autocomplete suggestions" option of the text filter configuration (on by default).
The text filter autocomplete now offers three suggestion styles, chosen with the new "Autocomplete style" option of the filter: product names (the default), product cards (a thumbnail, the name and the price, where clicking a card goes straight to the product page), or column values (the distinct matching values of the columns the filter searches, each labelled with its column, useful for attribute filters). The suggestions are matched across all the columns the filter is set to search, in priority order (code and name first, then custom fields, then the description) and capped at a few results, so even searching in the description stays fast. The product card is a view file that can be overridden in your template.
The images of the product and category listings are now rendered with lazy loading (images below the fold no longer delay the page display), explicit dimensions (the layout no longer shifts while images load) and a high resolution variant for retina and mobile screens, so thumbnails are not blurry anymore on modern displays. The first image of a listing and the main image of the product page keep loading immediately with a high fetch priority since they are usually the largest element of the page. The image markup is now generated by a single view file (product / image_tag, in the front-end and back-end views) which can be overridden in the site template to customize every image of the shop in one place. Note: template overrides of the listing view files keep their previous markup until they are updated.
In addition to the WebP image variants, HikaShop can now generate AVIF variants of the thumbnails, typically 30 to 50% smaller than WebP for the same visual quality. The option is enabled by default when the server supports AVIF and can be turned off with the new "Generate AVIF images" setting of the configuration, next to the new "Generate high resolution thumbnails" setting which controls the retina variants.
AVIF images can now be uploaded directly as product images, category images and file/image custom field values, the same way as JPEG, PNG and WebP. The "avif" extension is included in the list of allowed image extensions of new installations and HikaShop now reads AVIF sources when generating thumbnails, so an AVIF image is resized and displayed like any other. On an existing shop, add "avif" to the "Images allowed" setting of the configuration to enable it. Generating the thumbnails from AVIF sources requires a server whose image library supports AVIF.
The HikaShop database tables are now converted from the MyISAM storage engine to InnoDB during the update. InnoDB locks rows instead of whole tables when writing, which removes most of the database slowdowns during the checkout on busy stores, and it repairs its tables automatically after a server crash. Tables too big to be converted safely during the update are handled by the database check of the maintenance screen, which finishes the conversion.
The product search of the frontend listings, of the backend products listing and of the search plugin now uses a MySQL fulltext index instead of scanning the whole product table, which makes searching in large catalogs orders of magnitude faster. The results of the frontend listings are also sorted by relevance when a search is active. Searches the index cannot answer (words shorter than the server minimum, languages written without spaces, or text located in the middle of a word) automatically fall back to the previous search mechanism, so no result is lost compared to before. If needed, the previous behavior can be fully restored by adding a product_search_mode entry set to "like" in the hikashop_config table of the database.
Text filters now automatically get a dedicated fulltext index matching the columns they are configured to search in. The index is created when the filter is saved and removed when no filter needs it anymore, so filtering products by text benefits from the same speedup as the product search.
The states of a country can now be reordered by drag and drop. When you edit a country in System > Zones, a drag handle appears next to each of its states in the subzones list: drag the states into the order you want and it is saved automatically. That order is then used everywhere the states are displayed, in particular the state drop down of the checkout address, which previously could only be sorted alphabetically.
The "Category listing SEF name" and "Product show SEF name" settings of the configuration can now both be left empty, for shorter URLs without any prefix before the product or category alias (for example /shop/my-product instead of /shop/product/my-product). In that mode, HikaShop recognizes products and categories directly by their alias or id in the URL, with the product taking precedence when a product and a category share the same alias. When the configuration is saved with both fields empty, HikaShop lists the aliases used by both a product and a category, the aliases matching reserved URL keywords, and the products and categories without an alias, so that you can fix them beforehand, and a warning is displayed when saving a product or category whose alias conflicts. This works on both Joomla and WordPress.
Countries are now grouped by continent in the country selection dropdowns. HikaShop ships with seven built-in continent zones (Europe, North America, South America, Africa, Asia, Middle East and Oceania), each already linked to its countries, so the checkout and address country dropdowns are shown under continent headings, with the customer's detected country listed first for quick selection. The grouping is set per field: on a custom field of the type "Zone" whose zone setting is "Country", a new "Group countries by continent" option turns it on (on by default) or off to go back to a single alphabetical list. The continents are real zones too, so you can pick a whole continent as the zone of a shipping method, tax, discount or payment restriction instead of adding each country one by one. Existing sites receive the continents and their links automatically on update.
Characteristics can now be set to a new "Calendar" type (Business edition), so the values of a variant axis are dates picked from a calendar instead of typed by hand. Each value can be a single date or a date range, using the same advanced date picker as the date custom fields, and the readable date is shown on the product page and in the order. You can then put a filter on that characteristic and your visitors get a date range picker that keeps only the products having a variant whose date falls in the chosen range, which a normal characteristic filter (a list of fixed values) could not do. This is handy for tours, events, rentals and any catalog where each variant is a date.
Products now have per-product settings to control how they behave when offered as an option of another product, on the product edit page. A product without variants gets a "Selected by default as an option" toggle, so it can be pre-selected (ticked) on the product page while the customer can still unselect it. A product with variants gets an "Add a 'No' choice as an option" toggle and, when that is on, a "Default to 'No'" toggle, so the option can be made optional and start unselected instead of on its default variant. Each product is controlled individually, so some options can be pre-selected and others not. Existing products are unchanged.
Added an "Edit the view file" button next to the product page layout setting, both in the configuration (Display tab) and on the product edit page. The button opens the matching layout's view file directly in the Display > Views editor, in a new browser tab, for your default front-end template, so you no longer have to locate the right file by hand when you want to customise that layout. The button follows the layout currently selected in the dropdown, and works on both Joomla and WordPress.
Added a "Return method" setting in the Google Products plugin configuration to declare how customers ship returned items (By mail, At a kiosk, or In store). The selected method is included in the hasMerchantReturnPolicy JSON-LD on every product page and in the textual return policy of the OpenAI / Google Products feed, so Google Merchant Center no longer reports a "Missing field 'returnMethod'" warning on the product listings. The method is automatically omitted when the return policy category is set to "Returns not permitted", to avoid the same contradiction Google flags for return fees in that case.
The back-end listings now show a preview card when you hover a row. On the orders, customers, products, categories and brands listings, moving the mouse over a row displays a small card with the key information about that item, loaded on the fly: for an order its number, status, date, customer, its first products and total; for a customer their shipping address, their most recent orders, total number of orders and total spent; for a product its image, its number of sales, its characteristics with the values used by the variants, and its number of hits; for a category or brand its image, parent and number of products. On the orders listing, hovering the customer shows the customer card rather than the order one. The card is fetched only when you actually hover, so it does not slow down the listing. Any listing whose view has a "tooltip" layout file gets this automatically, and it follows each row link to its own type, so template makers and add-ons can add preview cards to their own listings just by providing that layout. Plugins can also add their own rows to a card through the standard view display event (for instance the affiliate details on a customer, auction data on a product or the sub-orders on an order). The card takes the colors of your backend, light or dark, and the new "Preview cards on backend listings" setting of the Display tab of your configuration turns the cards off for everyone if you prefer your listings without them. Pressing the Escape key also hides the card being displayed.

HikaShop 6.5.0

Release date : May, 26 2026

List of all the files changed between the 6.5.0 and the previous version

Bug fixes (63)

On Joomla 6, the notification popup shown after a product is added to the cart appears reliably again, instead of the add silently falling back to a plain page redirect. Joomla 6 still ships jQuery but no longer registers it as a loadable web asset, so HikaShop's legacy jQuery request silently did nothing; the popup scripts (vex and notify) are jQuery plugins and failed with a "jQuery is not defined" error. HikaShop now loads jQuery through Joomla's Web Asset Manager, in no-conflict mode so it does not clash with other scripts on the page, which also restores the backend admin interface elements that rely on jQuery on Joomla 6. Earlier Joomla versions are unaffected.
Two minor frontend display fixes: the affiliate program page no longer emits a PHP notice when it builds the "please log in first" link for a logged-out visitor (a stray undefined variable was being appended to the login URL; the link itself is unchanged), and the order details page no longer forces a white background on the "Billing address", "Shipping address" and "Product list" fieldset legends, so they inherit the template's own styling instead of always showing a white band.
On orders with multiple tax rates stacked on the same product line (for example Malaysian GST + SST, or any other compound-tax setup), saving the order after editing the shipping fee, the payment fee or the discount in the backend no longer makes one of the tax lines disappear from the order total. The previous fallback that runs when the per-product order_product_tax_info has been lost attributed the entire product tax to a single tax rate looked up from the product's tax category, which zeroed every other rate and the cleanup pass then removed those rows. The fallback now distributes the product tax across all the rates present on the order proportional to each rate's share in the existing order_tax_info, so every line survives the recalculation and the tax breakdown stays balanced. Orders with a single tax rate keep their previous behaviour, and orders whose per-product tax info is intact are not affected at all.
The HikaShop toolbar in the WordPress backend now renders correctly on WordPress 7. The "Check database", "Help" and "Dashboard" buttons no longer look like primary blue-outlined buttons that compete with the green Save buttons, the dashicons inside every toolbar button are no longer pushed below the label, the separator between button groups now stretches to the full button height instead of being a small 20-pixel line, and the "Check database" icon is back to a database glyph that all current dashicons fonts render reliably. Pages on WordPress 6 are unchanged: the new neutral-button styling matches WordPress 6's existing .button default, so the rules are a no-op there.
The "Brand" link rendered on the product page when the "Display the manufacturer" option is on no longer outputs the brand name twice in the URL when a dedicated menu item for that brand exists, and no longer routes to a sibling brand's URL when the linked brand has no dedicated menu item of its own. On a shop with one Joomla menu item per brand (for example /merken/nike and /merken/adidas) the brand link from a Nike product now points at /merken/nike rather than at /merken/nike/nike, because the SEF router now recognises that the resolved menu item already represents the target category and skips appending an extra category segment. On a shop where some brands have a dedicated menu item and some do not, the link for a brand without one no longer borrows another brand's menu as base (which previously produced URLs like /merken/nike/adidas for an Adidas product): menu items pinned to a specific brand are now filtered out as fallback candidates when the target is a different brand, so the link prefers a parent "all brands" menu (or any other ancestor-pinned category menu) when one exists, and only falls back to a neutral category-listing menu when none does. Shops where every brand has its own dedicated menu item are unaffected.
Uploading an image to an "Ajax image" or "Ajax file" custom field on the backend product edit page (and to the equivalent upload widgets on the front-end) no longer logs an "Uncaught ReferenceError: Fancybox is not defined" exception in the browser console after the file finishes uploading. The image entry returned by the server carried an inline script that calls Fancybox to bind the lightbox to the freshly inserted thumbnail; the parent page's Fancybox library was not pulled in via this AJAX response, so the inline bind ran with Fancybox still undefined and threw. The inline script now detects that situation, dynamically loads the Fancybox library once per page (subsequent uploads on the same page reuse the load instead of triggering a new one) and then performs the bind. Pages that already include Fancybox (any product page rendered in full) keep their existing instant-bind behaviour.
The product page JSON-LD that HikaShop emits for Google Merchant listings, and the XML product feed produced by the Google / Meta Products feed plugin, no longer advertise return fees for products whose return policy category is MerchantReturnNotPermitted. Until now, the global "Return fees" setting was written into the hasMerchantReturnPolicy block (and the corresponding feed line) unconditionally, which produced contradictory pairs like "returnPolicyCategory":"MerchantReturnNotPermitted" together with "returnFees":"FreeReturn" on products that opt out of returns via the per-product override custom field; Google Merchant flagged the resulting offer as inconsistent. Products that do accept returns are unaffected and still advertise the configured return fees.
On a category listing or filter module that has a price (or any other slider) filter side by side with another filter, the value set on the slider is no longer reset to its default range when the customer applies another filter on the same page afterwards. The two filters now stack as expected: applying brands after setting a price range keeps both restrictions in place, the same way applying the slider after brands already did. Until now the slider's hidden form field was not carrying its previously-applied range across a re-render, so every subsequent apply submitted an empty value for the slider and the server treated that as the customer clearing the slider.
When a customer posts the very first comment on a product page, the new comment now reliably becomes visible without the customer having to reload the page manually. Until now, on layouts that do not render the comment listing area when the product has zero comments (the tabular product layout suppresses both the Comments tab and the listing container until at least one comment exists), the new comment was saved server-side but the front-end had no element to populate, so the user only saw the success notification and had to reload the page to see their submission. The vote front-end now detects when the listing area is missing right after a successful save, and triggers a full page reload automatically so the freshly-rendered page (which now sees one comment) displays the Comments tab and the new comment. Subsequent comments on the same product still use the smooth AJAX list update because the listing area is then present. A new vote.beforeListRefresh JavaScript event is also fired before the lookup so custom layouts can inject the listing container themselves to skip the reload if they prefer.
Applying the product filter on a category or listing page no longer breaks the filter and listing area after the first apply, with a JavaScript "Identifier '...' has already been declared" error in the browser console (commonly "initColorMode", which is declared by Joomla's Cassiopeia color-scheme switcher). When the filter refreshes the listing it re-runs the inline scripts that came back with the refreshed content; any top-level const/let/class in them that is already declared in the page (a Joomla core script, the template, or another extension) made the browser throw a syntax error that aborted the whole re-injected block, so HikaShop's own filter code never ran and the layout stayed broken until a full page reload. HikaShop now detects which of those declarations are already present and turns only those duplicates into a plain assignment (instead of a second declaration) before running the code, so there is no redeclaration to collide with while every reference still uses the page's existing value. The filter keeps working across successive applies and the fix holds for future Joomla, template and extension changes without needing to special-case each name.
The PHP code action of the mass actions no longer wrongly rejects valid code that simply contains the name of a blocked function as part of a longer word. The security check added to block dangerous functions (exec, system, dl, etc.) was matching those names anywhere in the code as plain text, so for example code using a SOAP "wsdl" file was refused because "wsdl" contains "dl". The check now only triggers on a real call to one of those functions, not on a substring inside another word, a variable or a method name.
On a clean per-category menu URL (for example /shop/payment, with no category id in the URL), the category being viewed is now correctly marked as the current/active one in the category list. Until now the active category was detected only from the category id in the request, so on these menu-resolved listings no entry received the "current active" styling. The current category is now derived from the active menu item's HikaShop settings, following alias menu items to their target.
The "My account" page no longer returns a 500 error on PHP 8 when the logged-in customer's order history contains a guest-checkout order. Loading such an order from the account page reached the guest order-token check with no token available (there is none on the account page), and PHP 8's hash_equals() rejects a null second argument with a TypeError. The check now treats a missing token as an invalid one (access denied) instead of letting it reach hash_equals, which is the intended behaviour. Customers whose orders were all placed while logged in were never affected.
On a product listing menu item scoped to a parent category, navigating to one of its sub-categories no longer drops the sub-category from the breadcrumb. The breadcrumb now shows the full path (for example Home > Marketplace > Payment) instead of stopping at the menu item, while the bare listing page keeps its original shorter breadcrumb. Until now the sub-category was only added to the breadcrumb when the listing was reached without going through a menu item.
The "Bank account information" content shown to customers at the end of the checkout when paying via the Bank transfer payment plugin now displays the translated version when the merchant has filled in translations of that field via HikaShop's multilanguage panel (the flags on the payment method edit form). Until now the translations were saved correctly but never read back at display time, and customers always saw the default-language version regardless of the site language.
Submitting a product review or rating from the front-end no longer fails with a 500 server error when the access mode for reviews is set to "Bought". A leftover regression from the new guest reviews via order token feature was carrying two extra fields into the vote insert (order_token and order_id) that are not columns of the votes table, which made MySQL reject the insert with an "Unknown column" error. The two fields are now stripped from the vote object before persisting, while still being read earlier in the flow for the guest token authentication. Affects both registered customers and guest customers; review submission works again in all modes.
The username field on the checkout login form now displays the same placeholder as the password field next to it. Until now the password field showed a placeholder while the username field was visually empty, which made the two fields look inconsistent in the checkout login step.
An address entered manually when creating a new order from the backend (HikaShop > Orders > New) is now correctly linked to the customer it belongs to. The address still showed up on the order itself, but it was not attached to the customer record, so when creating a second order for the same customer, the address selector in the customer popup came back empty with only the "No address" option.
The "Brand" link on the product page now opens the dedicated brand menu item when you have one (for example a "Brands > De Kreij" menu item set on that brand), instead of sending the customer to an unrelated section of the site. On Joomla 4 and newer the link was systematically using the first HikaShop category-listing menu item in the database regardless of which brand was clicked. The same fix also applies to the category breadcrumbs.
The "Display Both" discount display option (reduced price with strikethrough on the original price) in the HikaShop product picker popup of the Joomla content editor (Article toolbar > HikaShop "Product" button) was silently dropped when building the resulting {product N|...} content tag. The popup's JavaScript only emitted the chosen discount mode for the first three dropdown values (Discount amount, Price before discount, Inherit), so picking "Display Both" produced a tag with no price option at all and the price block was not rendered. The content tag parser was also not recognising a hand-edited |pricedis4 in the tag. Both gaps are now closed: the popup emits |pricedis4 when "Display Both" is selected, and the parser maps it through to the underlying show_discount=4 listing price layout setting.
The product "Display" dropdown on the product edit form (the per-product layout selector) no longer offers show_block_* partials (show_block_custom_main, show_block_characteristic, show_block_dimensions, etc.) as selectable layouts. These files are partials loaded internally by the actual show_*.php layouts via setLayout(); picking one as a product display layout would produce a broken page. They are now excluded from the dropdown alongside show_quantity_* partials.
Fixed a verified-purchaser check on the product page that incorrectly accepted any user as soon as their order contained a non-product line item (shipping fee, payment fee, manual backend addition). HikaShop stores those rows with product_id=0, and the variant-matching SQL clause used product_id IN (0) as its fallback when the reviewed product had no variants, which falsely matched those rows. The fallback is now skipped entirely when the product has no variants.
Fixed two integrity bugs in the verified-purchaser check on the product page that decides whether the review form is shown. The check did not filter by order status (an unconfirmed or refunded order falsely counted as proof of purchase) and a missing pair of parentheses in its variant-matching SQL query made it pass for any logged-in user as soon as another customer had bought one of the product's variants. The check now uses the same shared logic as the comment-submission server-side check, which had already been patched against both bugs in a previous release.
Fixed variant selectors on the product page (size, color, etc.) still listing out-of-stock variants when the "Display out of stock products" setting was set to No, on shops that also had the waitlist or wishlist features enabled. The visibility setting now takes precedence as expected and the out-of-stock variants are correctly hidden from the selectors regardless of waitlist or wishlist state.
Fixed a product page issue where the available values of a variant characteristic (size, color, etc.) were sometimes displayed as multiple separate selection blocks instead of being grouped under a single selector, in cases where the underlying display ordering value of the characteristic was 0.
Fixed the HikaShop "Product" toolbar button in the Joomla content editor opening the HikaShop dashboard instead of the product picker popup when the editor in use is JCE on Joomla 5.4 or later. The popup URL was built with HTML-entity ampersand separators which JCE then re-encoded, breaking the URL parameters; it is now built in a form that both TinyMCE and JCE handle correctly.
Fixed the HikaShop options tabs (Product, Category, Checkout, etc.) on the Joomla menu item edit page rendering with light-mode colours when the backend is set to dark mode. The wrapper div on that page was missing the version marker class that HikaShop's dark stylesheet relies on to scope its overrides; it now matches the marker pattern used by the rest of the HikaShop backend, so the existing dark mode rules also apply on the menu item edit page.
The "Configure Layout" popup opened from the Configuration page (Configuration > Checkout > Address form layout > Configure Layout) now renders with the correct dark colours when the backend is in dark mode. Previously the popup kept its light-mode palette regardless of the dark mode setting, which made several elements (rows container, drop zone, toolbar, button group) hard to read on a dark background.
The dark mode stylesheet's cache-busting URL parameter is now correctly tied to the dark stylesheet's own modification time. It used to be tied to a different stylesheet's modification time by mistake, so updates to the dark mode rules shipped in a HikaShop release stayed invisible in browsers that had cached the previous version of the URL until those caches expired naturally.
The two HikaShop search plugins (which power the HikaShop product and category lookup in JCE Editor's "Insert / Edit Link" dialog) no longer crash with a "Class JPlugin not found" fatal error on Joomla 6 sites. Joomla 6 stopped automatically loading some legacy class names; the plugins now declare the alias they need themselves, so the JCE link picker works again on Joomla 6. Thanks to JanDerhake for the report.
The image uploader popup that opens when a third-party plugin (HikaMarket and similar) places an image-upload field on a frontend form no longer crashes with a 500 error on PHP 8 when the third-party plugin handling that upload is not installed, disabled, or registered under a different plugin group than expected. The popup now opens in an empty state in that case, the way it always did on PHP 7.
The "Delete this block" button on the View Builder now actually deletes the block. Previously the button showed a misleading error saying that the block's markers could not be found in the source, even when the markers were perfectly valid.
Block titles on a customized backend product edit form (Form customization feature) no longer pick up the labels of the block's own action buttons on every save, which used to bury the original title under dozens of repeated copies after a few saves. Existing titles that have already accumulated those copies need a one-time manual cleanup, but new saves will preserve the title correctly.
Saving a backend filter on a custom field no longer rejects the chosen field with a misleading "Caution: the chosen custom field is not available for this category" warning, and no longer silently overwrites the chosen field with another one. Any field that appeared in the dropdown is now accepted on save.
The checkout no longer aborts at the order creation step with a "Raw SQL execution in mass actions requires Super User privileges" error when a registered customer (i.e. logged-in but not a backend super administrator) places an order on a site that has a mass action configured to run on the after-order-create or after-order-update trigger. The super-admin check that was guarding raw SQL and PHP actions at runtime has been moved up to the backend controller entry points where a logged-in user can manually fire a mass action from the edit screen, so trigger-driven and listing-button executions of pre-configured mass actions now run for any user the trigger fires for. The "Use of exec / system / shell_exec / etc. is not allowed in mass action PHP code" defense remains, since it constrains the configured code itself rather than who happens to be online when the trigger fires.
The HikaShop Google / Meta Products feed plugin no longer aborts the cron run with a "Call to a member function loadRenderer() on null" error on Joomla 6 sites that have the Joomla "Load module" content plugin enabled. The feed plugin runs each product description through Joomla's content prepare event so any embedded {loadmodule} / {loadposition} / custom shortcodes get expanded into the feed, but Joomla 6's loadmodule plugin assumes a regular page render context and crashes when the event chain is reached from a cron-triggered code path. The feed plugin now falls back to the raw description for a product when a content plugin throws during preparation, so the feed continues to be generated for the rest of the catalog, and adds a warning to the cron report naming the offending product so the merchant knows which description to clean up.
A category page that lists subcategories above a HikaShop "Display content" module attached to the same menu no longer shows the "No products in this category" message under the subcategories when the attached module happens to point at a category that has no products of its own. The empty-state message inside the attached module is now suppressed when the parent menu is already showing a populated subcategories listing above it, matching the behaviour of the menu's built-in product listing slot. Thanks to MSTACE for the report.
Migrating a shop from one HikaShop installation to another (Products > Import > HikaShop) no longer aborts with a "1062 Duplicate entry" database error during the tax rates step. Some long-running shops accumulate an unusable blank tax rate left over from older versions, which used to clash with the destination's matching blank entry and stop the migration cold. The blank entry is now skipped during the import.
HikaShop no longer emits "str_getcsv: the $escape parameter must be provided as its default value will change" deprecation notices on PHP 8.4 when importing orders, importing zones from CSV, or importing plugin configurations from CSV. The CSV parser arguments are now passed explicitly so the parsing behaviour stays identical across PHP versions.
The "Please fill the field" error displayed when a customer tries to add a product to the cart with a required item field left empty no longer reappears at a later step of the checkout (typically on the payment step or the thanks page). The cart was already displaying the error in the right place next to the product, but a duplicate copy was also being put on Joomla's session message queue, where it lingered until the next page rendered it. Thanks to Genr8r on the HikaShop forum for the report and the diagnosis.
On a multilingual website, clicking the "Load more" button on a translated product listing now keeps showing products in the current language instead of falling back to the default language. The same fix also applies to the AJAX filter refresh on translated listings. Thanks to Sandra for the report.
HikaShop no longer produces a "Function curl_close() is deprecated" notice on PHP 8.5. The calls were harmless (curl_close has been a no-op since PHP 8.0, with the underlying handle cleaned up automatically) but PHP 8.5 now flags every such call. The redundant calls have been removed from HikaShop core and from every HikaShop-maintained payment and shipping plugin that used to make them. No behaviour change on older PHP versions.
On Joomla 6.1 or newer, HikaShop emails that include a customer's address (order creation notifications, order status notifications, payment notifications, etc.) no longer fail with a "Call to a member function getType() on null" error when the email is rendered from a context where Joomla has not prepared a page document, such as a payment gateway notification callback or a scheduled task. Joomla 6 added an unconditional call to the current page document when rendering a view, without checking whether a document is available. HikaShop now provides a fallback document when Joomla does not have one.
HikaShop emails sent from a Joomla command-line script or from a custom Joomla REST API endpoint now render correctly with working links. Previously the email could fail entirely or produce URLs that didn't resolve, because Joomla's link builder is designed for the regular frontend and backend and does not handle the command-line and REST API cases. Thanks to seyi for the report and the diagnosis.
The "Check for updates" button in the HikaShop configuration no longer does nothing when the HikaShop backend is set to a language whose translations contain apostrophes (French and a few others). Clicking the button now correctly checks for an available HikaShop update regardless of the language.
Dropdown custom fields no longer generate a "Using null as an array offset" warning on pages like the backend customer listing and customer edit page when running on PHP 8.1 or newer.
Two PHP 8.4 deprecation warnings are gone: one was a typo in the switch statement of the product variant mass actions and the file download error handling, and the other was an old way of reading HTTP response headers in the remote product file size lookup.
The legacy HikaShop Google remarketing plugin no longer shows a JavaScript alert popup ("You have configured the remarketing plugin of HikaShop with a wrong Adword ID. It should be a number.") to visitors of your shop when the configured Google Ads ID is not a plain number. Modern Google Ads IDs (starting with AW-) are no longer supported by Google's legacy remarketing tag at all; if you use one, configure it in the HikaShop Google Analytics 4 plugin instead. Thanks to daduts for the report.
The customer account sidebar shown on the cart page and on the affiliate program page is no longer displayed when those pages are accessed via a dedicated Joomla menu item of their own (Cart display, Cart listing or Affiliate program), matching how the sidebar already behaved on the order listing and address listing pages.
Several payment methods that were missing their history entry on new orders since version 6.4.0 (offline Credit Card, Purchase Order, Authorize.net, Cardsave, MIGS, FirstData, iVeri, iPay DNA, eWay, eSelect, PayJunction, PayPal Pro, PayTR, Innovative Gateway) now record it again. For the offline Credit Card plugin this means the beginning of the credit card number is once again visible on the order in the backend.
Order emails and other views that include billing or shipping addresses no longer crash when the order is created from a Joomla CLI script or a custom Joomla API application.
The admin payment notification email triggered when a payment gateway confirms a payment is now properly sent for a number of payment methods where it had silently been skipped (Authorize.net, Atos, Amazon Checkout, cmCIC, Collect on Delivery and others). Thanks to webfarol for the diagnosis and the patch.
Outgoing HikaShop emails no longer fail silently when the order has no customer email on file, or when one of the frontend contact forms is submitted with a malformed email address that ends up in the Reply-To field. The Reply-To address is now validated before it is handed to PHPMailer so the email is sent. This applies to order creation admin notifications, the generic outgoing mail, the "Contact the store about an order" form and the "Contact the store about a product" form.
The cart module icon image no longer renders as a broken placeholder after a customer adds a product to the cart on a deep-URL page (e.g. /shop/product/foo). When the icon path saved in the module settings was relative, the AJAX-replaced cart fragment did not carry the document base URL and the browser resolved the path against the current deep URL instead. Relative icon paths are now resolved against the site root before being emitted, so they survive the AJAX update.
The "Share this product" buttons (Twitter, Facebook, LinkedIn, etc.) on the product page now display correctly on templates that apply a global "img { display: block }" reset to all images. The icon image inside each share button now explicitly uses inline-block display so the icon and the brand label sit side by side as intended, regardless of the active template's CSS.
The cart module no longer produces "Undefined property: cart_type" / "Undefined property: cart_id" PHP notices when the cart is empty and the module is configured with a small cart icon (dropdown / hover / drawer mode). The 6.5.0 fix that made the cart icon visible in the empty state stubbed the price and product list but not the cart-type and cart-id properties; both are now stubbed with sensible defaults too, so PHP 8.x deprecation strict mode no longer floods the page with notices.
Saving a filter from the backend filter edit form no longer fails with a "Cannot access offset of type string on string" error on PHP 7.4 or newer, and no longer silently corrupts the "Apply on" value. The form-data ingestion loop was overwriting both the structured filter_options array (used for attribute, title_position, button_align, …) and the serialized filter_data field with flat strings, so the offset writes that follow raised a fatal and the type-specific filter_data normalization branch never fired (which made the Apply on dropdown revert from "Characteristics" to "Price" on the next load). The ingestion loop now skips both fields so the structured initialization downstream works as designed.
A cursor filter (price range slider) saved with the title position set to plain "top" or "bottom" no longer renders as an empty box that throws "Cannot read properties of null (reading 'setAttribute')" in the browser console. The cursor render switch only handled the explicit top_left/top_right/top_center/bottom_left/bottom_right/bottom_center positions and silently skipped the hidden _values input on any other value, which then made the noUiSlider init JS call setAttribute() on a null reference. Plain "top" and "bottom" are now handled, and any unknown value falls back to top-left rather than producing a broken slider.
Saving a filter no longer floods the page with "Undefined array key" PHP notices on PHP 8.x. Many of the filter_options fields (textBoxSize, max_char, min_char, words_skipped, searchProcessing, label_format, cursor_min/max/step/effect/width, input, weight_unit, dimension_unit, button_align, logic, parent_category_id, column_width, defined_limits, …) are conditional on the filter type and filter data, so a given save call legitimately submits only a subset of them. The save routine now reads each of these with a null-coalesce default instead of unguarded array access, so the missing keys produce empty strings rather than notices. A duplicate cursor_width assignment and a redundant @ suppression operator were also removed in the same pass.
Rendering a cursor filter on a page where it has not yet received a value no longer emits "strpos(): Passing null to parameter #1" / "explode(): Passing null to parameter #2" deprecation notices on PHP 8.1 or newer. The cursor display path was passing the raw return value of an inner display() call (which can be null) straight into strpos() and explode(); both call sites now coerce to a string first, with no behaviour change for the populated case.
The FedEx 2 shipping plugin no longer triggers a fatal "strict_types declaration must be the very first statement in the script" PHP error on PHP 8 servers, which could prevent some customers from logging in or browsing the shop as soon as they had an item in their cart. The HikaShop license header that was being prepended to every third-party library file in the plugin pushed the strict_types declaration off the first line of the file, which PHP 8 rejects at parse time. The license header is no longer added to the bundled vendor libraries (which are third-party code with their own copyright). The same fix has also been applied to the bundled libraries of the PayPal Checkout, PayPlug 2, Mass actions and Geolocation plugins, which use the same packaging rule and would have started failing the same way the moment one of their libraries adopted strict_types. The FedEx 2 plugin's bundled libraries (Guzzle HTTP client, Guzzle Promises, Guzzle PSR-7, Symfony deprecation contracts and the WhatArmy FedEx REST library) were also refreshed to their latest releases in the same pass. Thanks to the user who reported the issue on the forum.
HikaMarket vendor-restricted shipping methods no longer disappear from the customer checkout after the 6.5.0 multi-select warehouse picker change. Two regressions were involved. First, on the save side, the new picker posts the warehouse value as an array, but HikaMarket's vendor-restriction encoding (which has long appended a "v<vendor_id>" suffix to the warehouse filter) used a string concatenation, producing a literal "Arrayv5" garbage value on PHP 7 and a TypeError on PHP 8, in both cases corrupting the stored value so the method never matched any cart again at checkout. HikaShop now normalises the warehouse filter back to its canonical comma-separated string form before firing the plugin save hooks, so HikaMarket and any other plugin built against the long-standing string contract keep working. Second, on the read side, the single-shipping-group code path of the checkout (one warehouse plus one non-master vendor) was passing an already-parsed array key into matchWarehouseFilter without an explicit struct argument; the function's null-struct fallback only handled the string shape and was double-wrapping the array, hiding every keyed component (including the vendor) and silently failing the per-letter check. Existing shipping methods that were already corrupted by the save-side bug need to be opened in the back end and saved once for the stored value to be rewritten cleanly.
Opening the email preview or the edit screen of the customer or admin withdrawal notification templates from the back end no longer fails with a PHP 8 fatal "Attempt to assign property cart on false" when no withdrawal has been selected first. The preload script now seeds safe default values for the order, withdrawal and cart objects so the template renders cleanly even with no withdrawal data. Thanks to Alouette00 on the HikaShop forum for the report.

Improvements (11)

Category modules now generate the clean per-category menu URL for each category link, the same way category listing pages already do, instead of falling back to the generic listing route. The resolution also works when the visitor is already on a per-category page (the lookup now also considers the sibling menu items of the active one), not only when on the parent listing. This only has an effect when the "forward to submenus" option is on and the relevant per-category menu items exist.
Category listing pages and category modules that resolve each category link to its dedicated per-category menu item (the "forward to submenus" feature) are now faster. The menu lookup that maps a category to its menu item depends only on the active menu item, which is the same for the whole page, so it is now resolved once per page instead of once per category link rendered. On pages or modules listing many categories this removes a database query and the associated menu parameter parsing for every category beyond the first. The resolved URLs are unchanged.
Three legacy system plugins that used to ship in the HikaShop installation package are no longer re-installed by the HikaShop updater on every update. The VirtueMart fallback redirect plugin (which keeps the URLs of an old VirtueMart shop pointing at the corresponding HikaShop products) is updated to use the modern Joomla 4+ CMSPlugin class instead of the JPlugin class that Joomla 4 removed, so it stops fataling with a "Class JPlugin not found" error on modern Joomla installs while remaining usable for the ongoing migrations that still need it. The "no SSL outside checkout" plugin (a pre-HTTPS-everywhere helper that forced HTTP outside the checkout) and the Redshop fallback redirect plugin (a Redshop-to-HikaShop URL redirect helper for a no-longer-maintained product) are retired and removed from the installation bundle. The HikaShop installer also detects retired bundles left over in administrator/components/com_hikashop/extensions/ from previous installs and removes their files there so they do not get auto-reinstalled on each update. Already-installed Joomla plugins under plugins/system/ are left as-is so merchants who still rely on them can keep them; merchants who want them gone can remove them via Joomla > Extensions > Manage as usual.
For fully-digital orders (no shipping method), the "Withdraw from contract" button now disappears automatically as soon as the customer downloads one of the files attached to a product in the order, when the order is in a status that allows downloads. This matches the EU Directive 2023/2673 rule that the withdrawal right on digital content is lost as soon as the consumer starts the download. Orders with a shipping method are unaffected since their physical part may still be returned, so the existing status + withdrawal-window gate stays in charge there.
The product page structured data (the machine-readable JSON-LD that Google reads to display your products in search and in Google Merchant) and the XML feed generated by the HikaShop Google / Meta Products feed plugin now both advertise a distinct landing page URL for each variant of a product, instead of every variant sharing the main product's URL. Google Merchant expects items that belong to the same variant group to each have their own URL, so this change makes your product listings acceptable by default even when the "Remove products and categories id from URLs" SEF setting is enabled or you have set a fully custom canonical URL on the product.
The "Brand" link shown on a product page (and every other link to a manufacturer listing) now correctly targets a specific brand's Joomla menu item when you have one (for example a dedicated Nike or Starshoes menu item), instead of always pointing at the top-level Brands menu.
The "Check database" action in the HikaShop configuration no longer produces a scary "Illegal mix of collations" MySQL error on shops that were migrated across MySQL versions. HikaShop tries to realign the customer email column automatically, including switching the storage engine to InnoDB when that is what allows the realignment to succeed. When it cannot do it for you, the screen shows a short explanation and the exact SQL to run in PHPMyAdmin instead of the raw MySQL error.
The cart icon configured in the cart module settings is now displayed even when the cart is empty, so visitors always have a clickable trigger in the header to open the mini-cart. The empty-cart trigger uses the same "show price" and "show quantity" options as the non-empty one, so the text shown next to the icon stays consistent between both states (e.g. "The cart is empty" / "1 item for 340,00 €" when both are shown, "0 items" / "1 item" when only the quantity is shown, or "Total : 0,00 €" / "Total : 340,00 €" when only the price is shown).
HikaShop icons (the loading spinner, the print and delete buttons, the menu bars, etc.) now render correctly on third-party templates that did not previously include FontAwesome themselves. Until now, on those templates the icons could appear as blank squares; HikaShop now loads the FontAwesome font on its own pages so the icons always display, regardless of the template you use.
In narrow areas like the cart module in the header, product cards in multi-column grids, and the cart and checkout summary, prices no longer break across two lines in locales where the currency symbol appears after the amount (e.g. "340,00" on the first line and the currency on the next). The 6.4.1 release already fixed this for order summaries and emails; this release extends the same protection to all the other places where prices are displayed in HikaShop.
The available characteristic values shown on each product card in the listing (typically the colour swatches under the product name) are now wrapped in a single .hikashop_product_characteristics_on_listing container in the rendered HTML. This lets a template style them as a horizontal row of swatches with a single CSS rule and ensures the layout is preserved across AJAX filter and pagination refreshes — without any onload JavaScript fix-up needed in the template. Affects the listing_img_title, listing_title, listing_img_desc, listing_img_description, listing_img_pane, listing_fade, listing_hover_x_img_title and the two listing_slider layouts.

New features (5)

HikaShop can now be installed in a single step from a headless, non-interactive context such as the Joomla console "extension:install" command, a CI pipeline or a Docker provisioning script. Until now the bundled plugins and modules were deployed by a second step that relied on the browser following a redirect right after the component install. With no browser to follow that redirect, a command-line install left HikaShop without its plugins and modules. The installer now detects a command-line context and runs the same plugin and module deployment inline, so a command-line install completes on its own. The interactive browser install is unchanged.
The Payfast payment plugin now supports recurring billing in combination with the Recurring Orders plugin. On the first checkout, when the order is part of a recurring schedule, HikaShop posts the Payfast form in tokenization mode so Payfast tokenizes the buyer's card and returns the resulting token in the IPN. On each subsequent renewal scheduled by the Recurring Orders plugin, HikaShop charges the saved token server-side via Payfast's REST subscriptions API, without redirecting the customer through the gateway again. A new "Passphrase" setting was added to the plugin parameters, as Payfast requires it for the subscriptions API. The plugin's existing form and IPN signatures now also include the passphrase when it is set, which is the correct behaviour Payfast expects for merchants who configured one on their dashboard.
Guest customers can now leave a verified-purchaser review or rating on the products of an order they placed via guest checkout. The "Bought" access mode for reviews previously required a Joomla account (which guest customers don't have), so they were blocked even though they had purchased the product. The product links in the order confirmation email, the order status emails, the My Orders page on the front-end and the review reminder email now all carry the order's authentication token, which the comment system accepts as proof of purchase. The reviewer's name and email are pre-filled from the order's billing address. Logged-in customer reviews are unchanged.
You can now import discounts and coupons in bulk from a CSV or XML file, the same way orders can already be imported. A new "Import" button on the Discounts & Coupons listing page in the backend opens a two-step wizard: step one accepts a file upload (or pasted CSV content) and lets you pick whether the file describes Coupons or Discounts; step two shows the columns from your file with a data preview and lets you map each one to the matching HikaShop field, with the most common column names (code, percent, flat, start, end, quota, currency, etc.) auto-matched for you. A discount_type column in your file overrides the type chosen in step one on a per-row basis, so a single file can mix the two. Existing coupons with the same code are updated in place rather than duplicated.
Guests and registered customers with the same email address are now kept as two separate customer records in HikaShop. When a shopper who previously placed guest orders later creates an account using the same email, their existing guest record is promoted to a registered one so all their past orders, addresses and saved preferences follow them into the new account. The customer listing in the backend has a new filter and column to tell guest customers apart from registered ones at a glance.