Global informations

Details

Written by: Administrator

Category: Global informations

Published: 25 October 2026

Hits: 53

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

HikaShop 6.3.0

Release date : February, 1 2026

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

Bug fixes (26)

• The new dashboard edit mechanism could generate an error upon update when using the legacy dashboard.
• We've fixed a fatal error which could happen in some cases during cron tasks.
• Fixed blank page issue on user profile pages with complex HTML structures (e.g., EasyLayouts templates) caused by PCRE backtracking limits in the HikaShop user synchronization plugin
• On product pages on multilingual websites, in some cases, the Joomla language switcher could lead to a 404 error when not using the translation system of HikaShop.
• The delete icons wouldn't be red anymore in the backend of hikashop.
• We fixed a potential error in the backend with the use of the toolbar system of Joomla.
• Fixed the product description block width expansion button not working in the backend product edition page following changes in the previous version of HikaShop.
• The payment of won auctions wouldn't work properly in some cases due to a faulty security check in HikaShop.
• We've fixed a warning linked to HikaAuction in some rare cases.
• Fix taxes calculation not triggering when the unit price is updated from the quantity change of the product edit / add popup in the order details page.
• We fixed the HikaShop dashboard module layout in the backend in some cases.
• We fixed the dashboard layout in the backend in some cases.
• We've fixed undefined property warning when editing mass actions with saved triggers/filters/actions which could appear in some cases.
• When trying to access an inexistant order in the backend, HikaShop would display PHP errors instead of redirecting to the orders listing.
• The toggles on listings could display a warning in some cases.
• We fixed the display of social network buttons on the product details page.
• We've fix some CSS display issue following the new CSS grid system added in HikaShop 6.2.0
• When a coupon with a shipping discount (like free shipping) is applied to an order where shipping is taxed, the tax display was not being updated correctly even though the total was calculated correctly.
• The new CSS grid created a backward issue in some cases with custom CSS styles.
• We've fixed the PayPal Checkout messages for the cart and the product details page.
• We've fixed several issues with language files.
• New products with a quantity set to 0 would have their quantity changed to unlimited automatically.
• The payment of won auctions wouldn't work properly in some cases due to a faulty security check in HikaShop.
• The Whatsapp share button would display based on the telegram display setting in the HikaShop Social Networks plugin.
• We fixed the display of the "mini cart" / "mini wishlist" option for languages other than English in the cart module settings.
• The "product" button in Joomla articles, which opens a popup to configure content tags didn't work following changes in the previous version of HikaShop.

Improvements (14)

• We've improved the view builder for the frontend product / listing and the category / listing view files.
• We've drastically improved the perfomances of the product CSV import system in HikaShop. It should run at least 30% faster. We also made it more robust.
• The Google Products plugin now checks the access level of the categories of the products so that if no category of a product is accessible based on the "user group" setting of the Google Products plugin, the product will be skipped.
• We've updated the list of currencies.
• We've worked on the currency edit form so that it is now easier to setup the price display for each one thanks to an interactive configuration interface.
• The pagination is now reset on the orders listing when the payment method is selected for filtering.
• HikaShop will now hide the pagination area of products listings on the frontend when it is not necessary.
• The Smart search integration plugin now takes into account the access level of categories of products being indexed.
• We've worked on the style of the view builder system so that it offers a cleaner interface.
• We've added auto scroll to the elements in the view builder so that when you drag & drop an element, the code scrolls automatically to the corresponding code.
• We've improved the rendering of the video player on the frontend product page. It will allow for a smoother experience by preloading the player when the page is loaded.
• We've improved the handling of videos so that they will properly display even if allow_url_fopen is disabled on the hosting environment.
• We've improved the display of the quantity input field so that even if frontend templates add a padding to the input fields, the quantity input field will still display properly.
• We've unified the logic for price_site_id handling between listing and product pages to ensure consistency in price selection.

New features (13)

• There is now a button "Generate copies" on the shipping methods listing and edit pages so that you can easily generate a lot of copies of a shipping method.
• When the "Display view files" setting is activated, there is now an edit icon next to the view file name. When clicking on the icon, you'll get a popup with the view edit form, saving you a lot of time as you don't have to search for the view file in the backend to edit it.
• You now have access to the translation interface when editing a filter for easy translation of the name of the filter.
• We've added an "Address form layout" setting to the HikaShop configuration. You can now easily configure your address form on the frontend with a drag & drop interface. Thanks to this, you can build nice looking layouts. The system comes with a default one which you can just activate to get a good start.
• We've added an import tool to be able to import data from WooCommerce.
• We've added a migration tool to migrate your shop from J2Store / J2Commerce to HikaShop.
• We've added export and import buttons to the shipping methods and payment methods listings in the backend in order to make it easier to migrate and generate methods.
• It is now possible to import sub zones via CSV. This will greatly help when you need to add a large number of states, countries at once or if you need to create a new zone with a lot of sub zones.
• User Points plugin: Added support for defining points earned per product via a custom field.
• User Points payment plugin: Added support for defining point cost per product via a custom field.
• We've added a "cancel operation" action to mass actions. This action will only work when the mass action is called via a "before" trigger. For example, suppose you want to make sure that all the products have a weight and dimensions when being configured in the backend, you can add a mass action with triggers "before a product is created" and vbefore a product is updated", filters on the columns product_weight, product_width, product_length and product_height being equal to zero, and an action "cancel operation". This can also be used to check user information during registration, checks on orders being created on the frontend, forbid the deletion of elements, etc. This action has an option "error message" so that you can display the error message you want to the user when the operation is cancelled.
• The content tags now support the different ways to display discounted prices.
• We've added the possibility to match the columns of the CSV with the possible columns in HikaShop in the product import tool.

Details

Written by: Administrator

Category: Global informations

Published: 25 October 2026

Hits: 46

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

HikaShop 6.4.1

Release date : April, 17 2026

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

Bug fixes (54)

• Contacting the store about an order from the frontend no longer silently fails on WordPress, and after sending the contact request the customer is now taken back to the order page with a confirmation message instead of a blank page. A clear error message is also displayed if the email cannot be sent.
• The tax type (individual / company with VAT number) and the post-code restriction of tax plans were resolved from the shipping address even when the cart had no product that needed shipping, which could strip the VAT exemption of a B2B customer whose billing address carried the valid VAT ID but whose auto-selected or previously saved shipping address did not. The address type used for these two tax lookups now follows the same need-shipping gate already used for the zone extraction, so the billing address is used when the cart is virtual-only.
• The checkout could fall into a redirect loop back to the first step when a cart marker changed during step submission (typically when product prices change because the user just registered and now belongs to a different ACL with different prices), because the $checkout_itemid variable was left undefined when the show method was called from submitstep, producing URLs with an empty Itemid parameter.
• The customer account sidebar is now displayed on the cart show page and the affiliate program page, matching the order listing and address listing pages.
• On WordPress, the cpanel subpage links (cart, affiliate, etc.) now stay on the account page instead of redirecting to controller-specific pages, so the sidebar remains visible.
• The WordPress toolbar compatibility class had empty stub methods for save, apply, cancel, new, delete, edit, publish, unpublish, custom, and back buttons, so toolbar buttons were not rendered on WordPress backend pages. They now properly append buttons to the toolbar.
• The array_unique call on item field category IDs in the product class was missing the assignment, so the deduplication of category IDs was never applied when checking item field category restrictions with sub-categories.
• The PayPal Checkout plugin could produce an AMOUNT_MISMATCH error when discounts resulted in fractional cent amounts, because the discount in the payment breakdown was rounded independently from the order total. The discount is now computed from the rounded order total to guarantee consistency with PayPal's validation.
• PHP 8.3 deprecation warning "Using null as an array key" in getCurrentUserAddress when no user is logged in on the frontend.
• On WordPress, payment plugin end pages (PayPal Checkout buttons, Stripe redirect, etc.) were not displayed after order creation because the showPage method did not account for the plg_ prefix in WordPress extension folder names. The checkout showed "Thank you for your purchase" instead of the payment form.
• The terms and conditions label on the checkout page was not properly translated when set to a translation key, because the variable holding the param name was overwritten with the uppercase value before writing the translation result back.
• The Actions button and mass action toolbar buttons on the product, order, category and user listing pages were visible to non-Super Admin backend users who would then get a permission error when trying to use them. Since mass actions can execute MySQL and PHP code, the buttons are now hidden for users without the core.admin permission on com_hikashop.
• The JHTML select.genericlist WordPress shim was generating a duplicate id attribute when the caller passed an id inside the attribs string instead of using the idtag parameter, causing getElementById lookups to fail.
• The JHTML select.option WordPress shim was not setting the disable property when the value was false, causing "Undefined property" warnings in code that checks the property (e.g. HikaMarket's plugin restriction form).
• The JHTML select.genericlist WordPress shim was not handling plain associative arrays (key-value string pairs) which Joomla supports natively, causing options to be skipped in dropdowns built that way.
• The WordPress frontend routing was intercepting POST form submissions from other components (e.g. com_hikamarket, com_hikaauction) instead of letting their own handlers process them.
• The JRoute WordPress bridge was not handling URLs for non-HikaShop components (e.g. com_hikamarket, com_hikaauction), causing broken links in plugins that generate frontend or backend URLs for those extensions.
• Missing divider() method in the WordPress toolbar bridge class could cause a fatal error on backend pages using toolbar dividers.
• PHP 8.2 deprecation warning "Creation of dynamic property" on the massaction product plugin when deleting products.
• The view override diff viewer in the backend was not readable in dark mode because the diff colors (red/green backgrounds, line numbers, borders) were hardcoded for light mode only.
• The shipping and payment methods listing page in the backend could cause a blank screen or run out of memory when many plugin instances with large configuration data were present, because pagination was removed in 6.4.0. Pagination has been restored while properly accounting for single-instance plugins in the total count.
• File and image uploads via custom item fields on the product page were not saved with the order because the hidden inputs returned by the upload AJAX response were missing the form attribute needed to link them to the product form after the 6.4.0 form restructuring.
• The previous/next product navigation arrows on the product page were no longer displayed for products with variants because the category lookup was using the default variant ID instead of the main product ID.
• Google Rich Results flagged invalid carousels on product listing and carousel pages where prices were not displayed, because the ItemList/ListItem structured data was output without the required product offer information. The structured data is now only included when prices are shown.
• The register button on the registration form was not wrapped in a grid container, causing it to not align with the other form fields when using the grid layout system.
• The breadcrumb on the product page was generating category links using the product menu item instead of the appropriate category listing menu item, resulting in URLs without the correct menu prefix.
• The System > Plugins page in the HikaShop backend was listing non-HikaShop system plugins (Joomla core plugins like HTTP Headers, Page Cache, etc.). The query now only includes HikaShop-related system plugins.
• PHP warnings "Attempt to read property params on array" on the System > Plugins page for the geolocation, remarketing, analytics, and recaptcha plugins when their params were not properly initialized as a Registry object.
• Adding a product with variants to the cart from the product page would always add quantity 1 regardless of the quantity entered, and custom item fields were not included. This was caused by the form restructuring in 6.4.0 where the form no longer wraps the entire product page, leaving quantity, product_id, and custom field inputs disconnected from the form used by the add-to-cart AJAX call.
• The order status dropdown on the backend orders listing was no longer displayed, and order statuses were shown untranslated. This was caused by the import button feature overwriting an internal variable used to detect popup context.
• Embedding images in emails could fail with "Could not access file" when the email template used relative image URLs (e.g. media/com_hikashop/images/mail/header.png) instead of absolute URLs. The embed function now resolves relative paths to absolute file paths.
• Google Rich Results flagged products without prices on category listing and carousel pages as missing required "offers" field, because the templates used schema.org/Product instead of schema.org/ListItem for each item in the ItemList structured data.
• The aggregateRating in the JSON-LD structured data on the product page was missing the bestRating property, and empty product descriptions were output as empty strings instead of being omitted.
• On WordPress, the element-invisible CSS class used for screen-reader accessible labels was not applied in the backend because the rule was only scoped for the frontend wrapper.
• The breadcrumb on the product page was showing the default variant name instead of the main product name when the product had variants.
• We fixed a fatal error "Cannot redeclare" on WordPress when uploading a new version of the HikaShop plugin while the previous version is still active. WordPress loads both copies during the upgrade process, causing function redeclaration errors. We added a double-load guard and function_exists() checks to prevent this.
• We fixed an issue on WordPress where switching between editions (e.g. installing Starter over Business or vice versa) would not update the edition level in the database, causing features from the previous edition to remain active or the configuration page to crash.
• We fixed an issue in the iVeri payment plugin where hardcoded placeholder URLs (127.0.0.1) were used for the callback URLs instead of the actual site URL.
• We fixed an issue on WordPress where installing a HikaShop package with a different ZIP folder name (e.g. com_hikashop_starter) over an existing installation could create a duplicate plugin folder instead of upgrading, causing fatal errors.
• We fixed an issue on WordPress where the Payment Methods and Shipping Methods links in the HikaShop menu bar would highlight the Plugins menu item in the WordPress sidebar instead of the correct Payment or Shipping menu item.
• We fixed the wrong translation key ONLY_FROM_BUSINESS used in the plugin edit form access level area; it should be ONLY_FROM_HIKASHOP_BUSINESS.
• We fixed PHP 8.1 deprecation warnings when passing null values to json_decode() and explode() in the checkout workflow type.
• We fixed PHP 8 warnings "Undefined array key" for 'name' and 'params' in the checkout workflow editor when step data didn't contain these keys.
• We fixed PHP 8 warnings "Trying to access array offset on null" in the field class when the categories parameter was null, which could happen during order deletion and cause a visual gap on WordPress.
• We fixed the cancel button on the plugin edit page redirecting to the generic Plugins page instead of the correct Payment or Shipping page on WordPress.
• We fixed the missing plugin upload interface on WordPress when accessing the "Install Plugin" page. The install template was never created despite the controller, view function, language keys, and menu entry all being in place.
• We fixed the plugin installer on WordPress using a WordPress-specific nonce instead of HikaShop's standard JSession token check, causing "Security check failed" errors when uploading plugins.
• We fixed a fatal error during order creation when the selected payment method type does not correspond to an installed payment plugin. The order creation now gracefully skips the payment plugin confirmation step when the plugin cannot be loaded.
• We fixed a fatal error "Call to a member function get() on null" when saving a variant with a zone-restricted price, because the zone class was not loaded in the variant editing view.
• Selecting an image from a subfolder in the gallery popup on the product edit page would not add the image to the product. The path traversal security fix was rejecting gallery paths starting with a slash and stripping the subfolder component with basename().
• HikaShop popups were not visible when opened while scrolled down on a page and Joomla's "Increased Contrast" accessibility option was enabled. The CSS filter on the body element broke position:fixed positioning, causing the popup to appear above the visible area. The popup system now detects the filter and compensates by adjusting the positioning to the current scroll offset.
• HikaShop popups had a large gap at the top on small screens (e.g. tablets, embedded displays) because of a hardcoded 160px top padding on the popup container. The popup layout now uses flexbox centering with auto margins so that small popups are vertically centered on large screens and fully visible on small screens.
• We fixed an intermittent "Invalid notification" error with the Authorize.net SIM payment plugin caused by invisible Unicode control characters (bidirectional formatting markers) in customer address fields. These characters could be pasted from mobile apps or web pages and would cause the SHA-512 hash validation to fail. The plugin now strips Unicode control and formatting characters from all address fields before sending them to Authorize.net.
• Fixed file downloads returning "File not found" for product files stored at absolute paths within the Joomla root directory. The path traversal security check added in 6.4.0 was too restrictive, only allowing files inside the secure upload folder instead of also allowing files anywhere under JPATH_ROOT like the previous version did.

Improvements (32)

• The order contact page now honors the title set by the view (menu heading or titles rewritten by extensions such as HikaMarket for sub-order contacts), instead of always falling back to "Order: <number>" when an order was loaded.
• The WordPress URL routing now uses a filterable controller-to-page mapping (hikashop_wp_ctrl_page_map) instead of a hardcoded switch, allowing extensions like HikaSerial, HikaMarket, and HikaAuction to register their own controllers. Unknown controllers now stay on the current page instead of redirecting to the shop page.
• The WordPress database compatibility layer now detects any alias used for the users table in SQL queries (not just "juser") and rewrites Joomla column names (name, username, email, block) to their WordPress equivalents (display_name, user_login, user_email, user_status). In SELECT clauses, rewritten columns use AS aliases so PHP code reading $row->username still works. Queries using alias.* are expanded to explicit column lists with proper aliases. This fixes queries from extensions like HikaSerial that use different aliases or select all columns.
• Added a JCrypt / Joomla\CMS\Crypt\Crypt compatibility shim for WordPress, providing genRandomBytes, timingSafeCompare, and safe_strlen using PHP 7+ native functions. This allows extensions that use Joomla's crypt utilities to work on WordPress.
• The "Round prices during calculations" setting now has a third option: "Yes, without rounding increment". This rounds prices during calculations using the currency's decimal places (for payment gateway compatibility) but applies the rounding increment (e.g. 500 yen, 0.05 CHF) only at display time, avoiding per-item accumulation errors with large increments.
• The order auto-cancel plugin now has a configurable "Order statuses to cancel" setting, allowing administrators to select which order statuses should be targeted for automatic cancellation (e.g. both "Created" and "Pending"), instead of only targeting the "Created" status.
• The order auto-cancel plugin now has separate settings for the cron run frequency and the order age threshold before cancellation, instead of a single setting controlling both. Cancelled orders also get a history entry indicating the automatic cancellation reason.
• Added a new "delay" Joomla form field type for HikaShop plugin settings, displaying a numeric input with a time unit dropdown (hours, days, weeks, months) instead of requiring raw seconds input.
• The PayPal Checkout plugin no longer depends on the deprecated paypal/paypal-checkout-sdk PHP library (67 files, 603KB). All API calls now use a lightweight built-in API class with direct curl calls, reducing the plugin size and eliminating external dependency management.
• The image gallery browse popup now remembers the last browsed folder in the user session, so reopening the popup loads the previously selected folder instead of starting from the root.
• The customer account cpanel now triggers the onBeforeFrontendOrderListing event when loading the last orders widget, allowing plugins to filter orders from the cpanel the same way they can on the order listing page.
• Price cells in order tables and email templates no longer wrap the currency symbol to a new line in locales where the symbol appears after the number (e.g. German). Added white-space:nowrap to price cells in the frontend and backend order views, invoice, and all order email templates.
• When changing the customer on a backend order, the address selector dropdown now also shows unpublished addresses in a separate group labeled "Old addresses" for registered users or "Previous orders addresses" for guests, so that addresses from previous orders are always accessible even if the customer deleted them from their account.
• The datepicker custom field type now supports wildcard characters (*) in the year position of the excluded dates setting. You can use patterns like 4/5/* to exclude April 5th every year instead of having to add a new entry for each year.
• The datepicker custom field type now supports wildcard characters (*) in any position of the excluded dates setting. You can use patterns like */2/* to exclude all of February every year, */2/2026 to exclude February 2026 only, or 4/*/* to exclude all of April every year.
• Added a marketplace card at the bottom of the Payment Methods, Shipping Methods, and Plugins listing pages, with contextual links to browse and request plugins on the HikaShop marketplace.
• The UCP plugin now uses opaque random session tokens in checkout session IDs instead of sequential database IDs, making session URLs unguessable.
• The UCP plugin now supports multiple API keys via a repeatable subform field, allowing each client (AI platform, agent) to have its own key.
• Improved error handling in the UCP plugin checkout completion flow to properly handle payment processing failures.
• On WordPress, after uploading and installing a HikaShop plugin, the user is now redirected to the plugin edit page (or the new method creation page for payment/shipping plugins) instead of the plugins listing.
• On WordPress, plugin upgrades now merge new files over the existing installation instead of deleting the entire folder first. This preserves user-installed HikaShop extensions in back/extensions/ and uploaded files that would otherwise be lost during upgrades.
• Updated the license declaration in the WordPress readme.txt and plugin header to GPLv3 to match the license used across the codebase.
• Added an "External Services" section to the WordPress readme.txt documenting connections to hikashop.com (help documentation, language files) and payment/shipping gateway APIs, in preparation for WordPress.org plugin directory submission.
• On WordPress, the Starter edition now relies on the WordPress.org update system instead of the custom HikaShop update checker. The "Check now" button is hidden on WordPress, while the upgrade buttons to Essential/Business remain available.
• The direct file access protection header now checks for both _JEXEC and ABSPATH, ensuring compatibility with both Joomla and WordPress environments.
• Removed the bundled jquery.min.js file from all editions as it is no longer needed. Joomla 3+ provides jQuery natively, and WordPress uses its own copy.
• Comments are now preserved in the wordpress/ PHP files during packaging to keep translators comments required by the WordPress.org Plugin Check tool.
• The PayPal Checkout payment page now displays an order summary alongside the payment buttons in a two-column layout, showing product lines, totals, and addresses so that customers can review their order before paying.
• When the price calculation plugin modifies a product's price and the product has grouped options in the checkout cart, the base price displayed next to the product name now shows the original price before the calculation instead of the calculated total. This prevents confusion when the calculated add-ons are also listed separately below.
• Auto-discovered module blocks in the WordPress Gutenberg editor now render list and radio XML field types as dropdown selects instead of plain text inputs, matching the expected behavior for fields with predefined options.
• Improved WCAG accessibility for the datepicker custom field: added aria-live region on range date display so screen readers announce date selections and night count, added aria-label and aria-haspopup on popup datepicker inputs, added aria-label on the calendar icon button, and added role="application" on inline and range calendar containers.
• Shipping plugins can now validate addresses on save via the onBeforeAddressCreate and onBeforeAddressUpdate events, which now also import hikashopshipping plugins in addition to hikashop plugins.

New features (14)

• The PayPal Checkout plugin now supports payment method vaulting for recurring payments. When used with a recurring orders plugin, the customer is redirected to PayPal to approve saving their payment method. The vault token is stored on the customer account and can be used for merchant-initiated charges on subsequent orders via the onOrderAuthorizationRenew hook. This is also compatible with HikaSerial's recurring subscriptions and replaces the need for the older PayPal Recurring payment plugin (which used the deprecated NVP/IPN API).
• Added an ordering column to zones so that administrators can control the display order of countries and states in dropdown menus. Zones with a non-zero ordering value are sorted first (ascending), followed by the remaining zones in alphabetical order. The ordering can be set via the zone edit form or via the ordering column on the zones listing page.
• The shipping block on the checkout now has a "Dynamic address refresh" setting (enabled by default). When the shipping and address blocks are on the same checkout step, shipping methods automatically refresh as the user edits address fields (country, state, city, postal code, street) without requiring the address to be saved first. The feature detects whether the user is editing a shipping address or a billing address with the "same address" option checked, and handles the country-to-state dropdown cascade properly.
• The UCP plugin now supports the W3C WebMCP standard (navigator.modelContext). When enabled, HikaShop registers commerce tools (search products, create/update/complete checkout, list payment methods) that browser-based AI agents can discover and call directly. The tools call the existing UCP REST endpoints using the visitor's browser session for authentication, so no API key is exposed in the frontend.
• Added hasMerchantReturnPolicy structured data support in the Google Products plugin. You can now configure your return policy type (finite window, unlimited, not permitted), return window in days, applicable countries, return fees, and return policy page URL. The return policy is included in the JSON-LD on product pages and in the OpenAI shopping feed. A per-product override field setting allows referencing a product custom field to use a different return policy type for specific products (e.g. non-returnable personalized items).
• Added shippingDetails structured data to the JSON-LD on product pages, generated from the existing shipping setting in the Google Products plugin. Each configured shipping rule (country, region, rate, handling time, transit time) is output as an OfferShippingDetails object in the offer, enabling Google Merchant listings shipping details. Per-product shipping overrides via custom fields are now supported in JSON-LD, using the same resolution pattern as the Google Merchant XML feed.
• Added two new plugin events for the product page structured data (JSON-LD): onHikashopMicrodataProductInfo to modify the JSON-LD object before injection, and onHikashopMicrodataExtraObjects to add extra JSON-LD blocks. This allows plugins to enrich the microdata for specific product types such as hotels or events.
• The WordPress bridge now auto-discovers external modules (mod_*) installed in the extensions directory and automatically generates WordPress widgets and Gutenberg blocks from their XML manifests, without requiring any WordPress-specific code in the module.
• The WordPress plugin installer now supports uploading module ZIP packages (type="module") in addition to plugins.
• Added an EC-CUBE v4.1 migration tool to import taxes, categories, products (with variants and prices), product images, customers, addresses, orders, and order items from an EC-CUBE database into HikaShop.
• The datepicker custom field type now supports a range mode for check-in / check-out date selection. When enabled, the field renders as a single inline calendar with two-month display where the user clicks once for the start date and again for the end date, with visual range highlighting. Configurable options include minimum and maximum number of nights, and whether the last day is excluded from booking (hotel convention). All existing exclusion rules (forbidden weekdays, excluded dates, wildcard patterns, future/past restrictions, waiting days) are enforced against every day in the selected range.
• The filter system now supports plugin-provided filter types and filter data types. Plugins can register new filter display types via the onFilterTypeDisplay event and new data types via the onFilterDataLoad event, following the same extensibility pattern as the custom field system. The factory methods _getFilterTypeClass and _getFilterDataClass handle class loading, with onInitFilterTypeClass as a fallback event for plugins providing multiple filter types.
• The advanced date picker plugin now provides two new filter display types: a single date picker filter and a date range picker filter. The single date picker supports inline or popup mode, multi-month display, optional margin days with a customer-facing checkbox, and dynamic display restricting selectable dates to those present in the product set. The range date picker renders a single inline calendar with two-click range selection and visual range highlighting, reusing the existing range datepicker component. Both types read date constraints (future/past only, waiting days) from the custom field definition and support filtering on both product custom fields and item custom fields.
• When a filter on the product listing targets a custom item field (e.g. a booking date picker), the selected filter value is automatically passed to the product page via the product link, pre-filling the corresponding item field so that the customer does not have to re-select the same value.

HikaShop 6.4.0

Release date : March, 6 2026

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

Bug fixes (40)

• We fixed an issue where zone-restricted prices were not properly filtered on product listings, causing the wrong price to be displayed. The zone restriction was only applied on the product detail page and cart but not on product listings.
• We fixed an issue where embedding images in emails would fail when the image URL used a different scheme (http vs https) or www prefix than the site URL configured in Joomla, resulting in a "Could not access file" error preventing the email from being sent.
• We fixed a PHP warning "Undefined property: stdClass::$payment_price" on the payment methods listing page when a payment method had no price set.
• We fixed an issue where importing a CSV with tax-inclusive prices would overwrite the tax category of variants from "like parent product" to the default tax category, resulting in incorrect tax category assignments and potentially wrong price conversions.
• We fixed an issue in the mass action system where filtering on price columns could result in duplicate rows in the results when products had multiple prices.
• The mass action CSV export now correctly calculates the taxed price for product variants which inherit their tax category from their parent product.
• We fixed an issue where Google Search Console would only detect the main variant of a product instead of all variants, because inline microdata on the product page conflicted with the JSON-LD structured data. We removed all inline microdata (itemprop/itemscope) from product page templates and vote templates so that the JSON-LD is the sole source of structured data.
• We rewrote the JSON-LD structured data generation on the product page to properly use ProductGroup with hasVariant for products with variants, so that Google detects all variants individually with their own prices, stock status, images, and characteristics.
• We fixed the JSON-LD structured data so that it works without requiring the Google Products plugin to be configured, using sensible defaults when the plugin is absent.
• We fixed an issue where the product description in the JSON-LD structured data could exceed Google's 5000-character limit when the product had long content (tables, FAQs, full copy), causing Google Search Console "description too long" errors for ProductGroup and Product entries. The description is now truncated to 5000 characters.
• We fixed the inverted ItemList schema markup in the product listing and carousel templates where individual product items were incorrectly marked as ItemList and the container was marked as itemListElement.
• We fixed a MySQL query error during the update / install process due to a typo with the modifications made for the currencies default settings in HikaShop 6.3.0.
• We've fixed an issue where plugins relying on the HikaShop cron could get seen as uninstalled by Joomla in some cases during cron tasks, following a previous fix with the saving of plugin settings during cron tasks.
• When products were configured with several prices restricted to different conditions, the correct price was not always loaded due to an improvement in the previous version.
• The activation link would not work properly on Joomla 6.
• We've fixed several issues with Google Pay in the PayPal Checkout payment plugin that could prevent the Google Pay button from appearing or payments from being captured properly.
• We've fixed several issues with Apple Pay in the PayPal Checkout payment plugin, including a TypeError on non-Apple devices and missing billing contact information.
• We've fixed the 3DSecure settings and information display on the PayPal Checkout payment plugin.
• We fixed a false duplicate alias error when saving products with variants. The alias uniqueness check was matching against variant rows which share the parent product alias, causing a false positive.
• We fixed an issue which could lead to the interface customization of the product edit page messing with the description HTML editor which wouldn't display correctly.
• The category explorer would not display properly when being folded in the backend products and categories listing pages following changes to the CSS grid system in a previous release.
• The saving of a view override on the backend could result in the page being displayed without the backend template.
• We've fixed missing CSS and JS for the address layout builder.
• We fixed a warning on the dashboard with "table" widgets.
• We fixed a SQL error on dashboard map widgets with MariaDB strict mode.
• We fixed PHP errors in the map widget template.
• We've fixed a layout issue on the backend customer edit form when the affiliate system is activated.
• We've fixed the width of the weight unit selector for the variant edit form in the backend.
• We've fixed a backward compatibility issue with HikaSerial's dashboard.
• We fixed a warning in HikaShop Essential on the cron task tab of the HikaShop configuration.
• We fixed a warning with the default layout of the product page.
• We fixed a PHP warning which could happen on the category listing page when an image file couldn't be read properly.
• We fixed a PHP warning which could happen when generating thumbnails and checking sizes for invalid or unreadable image files.
• We fixed an issue where generated thumbnails could fail to display because the thumbnail folder path used scaled image dimensions instead of the configured thumbnail dimensions.
• Modules under the product page could have the translated canonical URL of another language in some cases.
• We fixed a warning which could appear in some rare cases on the checkout with the previous version of HikaShop.
• We fixed a deprecated message with custom fields in some rare case on PHP 8.4.
• We've fixed several issues with the vote system: JavaScript crash on some pages, tooltip HTML breaking the page DOM, vote stats returning zeros on comment-only submissions, and various other JavaScript bugs.
• We fixed the affiliate commission not being calculated when using the category restriction feature.
• We fixed the Joomla 4+ plugin compatibility layer so that it correctly handles typed Joomla events with no named arguments (such as GetKeyEvent or SetCachingEvent). Previously, the argument mapping would crash when the event object had no arguments to extract. The layer also now uses the addResult() method instead of the deprecated setArgument() for returning results, as required by Joomla 6.

Improvements (42)

• The Google Products plugin now automatically adds the native_commerce attribute to all products in the feed when the UCP plugin is enabled, making them eligible for Google's UCP-powered checkout.
• The product_sort_price field is now automatically recalculated on the product detail page when it doesn't match the current public price, so that price-based sorting in product listings stays accurate without requiring a manual recalculation.
• The product condition in the JSON-LD structured data now uses the product-level setting with a fallback to the Google Products plugin default, instead of always defaulting to NewCondition.
• We improved the handling of review authors in the JSON-LD structured data by resolving the username from the database when the vote pseudo is empty, and skipping reviews without an identifiable author, as required by Google.
• Language files are now automatically updated when a new version of HikaShop is installed. On each admin session, HikaShop checks if the installed language files are outdated and downloads the latest versions from the server. On WordPress, the wordpress.ini translation files are also updated automatically.
• The default product page image size for new installs has been increased from 100x100 to 300x300 pixels.
• The "Simplified breadcrumbs" setting now has a third "Auto" mode which automatically builds the full breadcrumb path (Home > Category > Product) using the product's main category, while keeping clean URLs without the category_pathway parameter. This new mode is now the default for new installs.
• We've improved the address form layout configuration interface so that the behavior of the tool when drag&dropping fields around is smoother.
• We've added a weight and a volume column to the orders listing in the backend.
• We've added shipping price and payment fee columns to the backend order listing (hidden by default).
• We improved the display of microdata for the price with the reversed and tabular layouts of the product page.
• We've improved the decoding of serialized data.
• We've improved the look of the tabs in the tabular product page layout.
• We've improved the display of the drawer mode for the HikaShop cart module.
• HikaShop now properly supports child templates for view overrides.
• We've improved the support for newer versions of jQuery.
• The product page layouts have been modified to not have a form HTML element around the whole page. This allows for greater flexibility with customization, allowing you to add elements with forms, like modules, inside the product page layout.
• The IP address resolver in HikaShop now supports CloudFlare, Sucuri, Incapsula / Imperva and Nginx reverse proxy in order to improve capturing the correct IP address for customers.
• We've improved the loading of filters configured to use fields so that when the field is removed, the filter doesn't generate an error.
• The view override "diff" mechanism has been restyled and reworked so that it is more useful and looks correct.
• When a mass action is manually processed in the backend, there is now a result message.
• We've optimized the backend vote listing by batch-loading product names and user info.
• We've added CSRF token validation to vote AJAX requests.
• The Google Products plugin now skips products with zero price to avoid Google Merchant Center rejection.
• We've improved the contact form error handling when email sending fails.
• We've added duplicate withdrawal request detection to prevent users from submitting multiple withdrawal requests for the same order.
• Plugins of the group "hikashop" not supporting multiple instances are now listed in the System>Plugins menu.
• We improved the thumbnail generation performance by skipping regeneration when a valid thumbnail already exists and the source image has not changed.
• The image helper now preserves ICC color profiles when resizing JPEG images with GD, preventing the color shifts that occurred because GD strips ICC data during processing. The ICC profile is extracted before resizing and re-injected into the output file afterward.
• The PayPal Express payment plugin now blocks known bots from initiating orders via the PayPal Express button.
• The PayPal Express payment plugin now prevents duplicate order creation when the PayPal Express button is clicked multiple times, by detecting if a pending order already exists for the same cart.
• When linking directly to a product variant via URL, the characteristics are now automatically pre-selected even when the "Characteristics dynamic display" setting is enabled.
• When Joomla's page cache is enabled, cached pages now vary by currency so that visitors with different currencies (e.g. via geolocation or the language-to-currency plugin) see the correct prices instead of the currency from the first cached visit. :: https://www.hikashop.com/forum/5-support-en-francais-french-support-/910178-la-devise-affichee-ne-tient-pas-compte-de-l-ip-si-le-cache-est-active.html#370789
• We improved WCAG 2.2 accessibility compliance across the frontend and backend: added visible focus indicators on dropdown and button elements, added scope="col" to data table headers, added visually hidden labels to search inputs and select-all checkboxes, added screen-reader-only text for star ratings, replaced clickable table cells with proper button elements for the useful/useless vote actions, and added thead/tbody structure to the product comparison table.
• We further improved WCAG 2.2 accessibility: added focus styles alongside hover on product/category name links and checkout cart rows, added visible focus indicator on backend namebox inputs, added Enter/Home/End keyboard support to dropdown menus, added accessible text to the icon-only empty cart link, added a visually hidden legend to checkout fieldsets, and added screen-reader text for out-of-stock product variants.
• We added screen-reader accessible text and aria-hidden on decorative icons across multiple frontend and backend views: login form forgot password/username links, order listing show/hide product buttons, product carousel prev/next buttons, discount selection search/reset buttons, address layout field controls, and product edit block controls.
• We added role="alert" to error and warning messages so screen readers announce them, and added aria-live="polite" to the cart module so cart updates are announced to assistive technology users.
• We replaced non-semantic clickable spans and divs with proper button elements for the filter toggle, product image prev/next navigation, and backend product block controls (width/columns/toggle), improving keyboard accessibility (WCAG 2.1.1). We also added accessible text to the product image prev/next buttons.
• We added aria-describedby error spans to form fields (address, registration, custom item, contact, and order fields) so that screen readers can announce per-field validation errors. Fields now set aria-invalid when validation fails and display the specific error message next to the input (WCAG 3.3.1).
• We improved accessibility of vex popup dialogs: added role="dialog", aria-modal, and aria-label attributes, implemented focus trapping so keyboard users cannot Tab out of the dialog, made the close button keyboard-accessible, and focus is now restored to the trigger element when the dialog closes (WCAG 2.4.3).
• We added keyboard move buttons (up, down, previous/next position) to the view builder blocks as an alternative to drag-and-drop reordering, so that keyboard-only users can rearrange blocks without a mouse. All action buttons now appear on hover/focus for a cleaner interface (WCAG 2.5.7).
• We added keyboard alternatives to all drag-and-drop interfaces in the backend: move buttons on product edit form blocks and grip handles with arrow keys on block fields, move buttons on dashboard configuration rows and widgets, and move buttons on address layout builder fields. Controls appear on hover or keyboard focus. We also fixed a pre-existing bug where mouse-resizing address layout fields could not increase their width (WCAG 2.5.7).

New features (14)

• HikaShop now works on WordPress. You can use the same install zip file on WordPress' "Add plugin" upload form and then activate it. HikaShop will work basically the same as on WordPress. With a few changes here and there to adapt to how WordPress works.
• We've added a UCP (Universal Commerce Protocol) plugin to HikaShop. Once configured and enabled, it allows AIs to purchase on your store for their users.
• The Google Products plugin can now generate an OpenAI / ChatGPT Shopping product feed in JSON format alongside the existing Google Shopping XML feed. It includes all required and recommended fields such as reviews, star ratings, variant attributes, store country, target countries, return policy and eligibility flags. The JSON feed is saved to a publicly accessible file that OpenAI can crawl, and is automatically regenerated by the cron alongside the Google feed.
• We've added 5 new and modern layouts for the product page on top of the "default", "reversed" and "tabular" layouts.
• The customization capabilities of the product edit page have been improved in the backend. Now, each block can be resized and options inside each block can be split into 1, 2 or 3 columns.
• Custom fields of the table "product" now have a new display setting you can activate so that they get displayed in their own tab in the tabular layout of the product page.
• There is now a "translatable" flag which can be added by payment and shipping plugin developers in the pluginConfig array in order to make text options translatable by the user. The "information" setting of the Bank transfer, Check, Credit card, Purchase Order and Western Union payment plugins can now be translated easily via the available translation interface.
• We've added an "import" button to the backend orders listing to be able to easily import orders to HikaShop.
• The tag {VAR:order.order_geolocation_country_code} is now available in order emails in HikaShop Business in order to provide the country code retrieved by the geolocation plugin based on the IP of the customer.
• There is now a "+" icon for the images option of payment and shipping methods so that you can easily add extra images.
• We've added a new migration tool from one website with HikaShop to another one. With it, you can migrate from one Joomla to another, one WordPress to another, from a Joomla to a WordPress or from a WordPress to a Joomla.
• On the HikaShop configuration page, below the version number, we've added a "Check updates" button and buttons to upgrade to Essential / Business if you're on the Starter / Essential edition and you've purchased an upgrade.
• HikaShop constants can now be overridden from a system plugin, before HikaShop is being loaded.
• We've added include/exclude toggle and multi-select support for warehouse restriction on shipping methods.

Details

Written by: Administrator

Category: Global informations

Published: 25 October 2026

Hits: 55

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.

Details

Written by: Administrator

Category: Global informations

Published: 25 October 2026

Hits: 48

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

HikaShop 6.6.0

Release date : August, 29 2026

New features (12)

• On WordPress 7.1 and above, HikaShop registers what it can do with the Abilities API that WordPress now provides, the registry an AI assistant reads through the REST API or through MCP to find out what a site is able to do. Every command of the HikaShop command line is offered there under the same name, so an assistant can list your products, read an order, check what is running low or change a stock level without you writing any glue. Everything an assistant could undo is offered to it; what it could not is registered but kept out of what it is shown until you turn it on, which is the five operations HikaShop already treats as dangerous on the command line, where they ask you to confirm: deleting a product, a customer, a category or a discount, and running a mass action. Whoever asks must be able to administer the site, and each ability then asks for the same access level of your HikaShop configuration as the backend screen it corresponds to: reading your orders answers to the order view level, changing one to the order manage level, deleting a product to the product delete level, and so on. An assistant acting for someone therefore reaches exactly as far as that person reaches in your backend, and no further. Nothing is exposed on a site running an earlier WordPress, or on Joomla, which has no equivalent registry.
• The PayPal Checkout express button displayed on the cart of your checkout can now be placed above the cart rather than under it. The setting which used to turn it on and off now asks where you want it, and shops which had it turned on keep it under the cart as before. Placing it above is useful when your checkout displays the payment methods right before the cart, since the button then sits with the other ways of paying rather than after the totals.
• The affiliate program page your partners see on your website has been rebuilt. It used to show the same handful of totals since the day they joined, with no way to tell whether this month was better than the last one. It now opens on a dashboard: your partner picks a period, today, this week, this month or this year, and everything on the page follows it. The commission earned, the clicks, the sales and the leads of that period are each shown next to the same length of time immediately before, so the direction is visible at a glance, with the conversion rate as well when you let your partners see the advanced statistics. Under them are graphs of the commission over time split between clicks, leads and sales, of the clicks, and of the payments you have made them, then their best referring sites and their best banners. The totals since they joined are still on the page, below, where the amount you already owe them is told apart from the amount that is payable. Their clicks, leads and sales open as real pages of their account rather than in a popup, so they can be read on a phone and linked to. The page also gives your partners the tools they were missing: their affiliate link to your shop ready to copy, a field where they paste any page of your shop and get their link to it, a QR code for it, and a copy button on the HTML of every banner you offer instead of a box of code to select by hand. Nothing needs to be configured. If you wrote your own CSS for the previous page and want it back, the hidden setting "affiliate_legacy" can be set to 1 in the hikashop_config table of your database.
• On WordPress, your shop can now have more than one language. HikaShop reads the list of languages from the multilingual plugin your site uses, either Polylang or WPML, and lets you translate the names, the descriptions and your own custom fields of your products and your categories, exactly as on Joomla. Nothing needs to be configured: install the multilingual plugin you prefer, add your languages to it, and the translation tabs appear in HikaShop. Until now a WordPress shop was always treated as having a single language, whatever plugin was installed, and the translations you could type were never displayed. Your translations belong to HikaShop and are stored by HikaShop, so moving from one multilingual plugin to another, or removing one, does not lose them ; they are also kept outside the plugin folder, so that updating HikaShop cannot delete them. The mobile application can translate your content on a WordPress shop too, since it goes through the same place.
• HikaShop can now be managed from a command line, so that your shop can be driven from a terminal, a cron entry or a deployment script without opening your backend. It uses the command line each platform already provides: the Joomla console on a Joomla site, with commands such as "php cli/joomla.php hikashop:product:list", and WP-CLI on a WordPress one, where the same command is written "wp hikashop product list". Nothing travels over the network, since the commands run inside your own site on the machine it is installed on, so there is no key to create and nothing to open to the outside. You can list, read, create, change and delete your products, your orders, your customers, your categories and your coupons, set a stock level or a price, change the status of an order and notify the customer, and run the mass actions you already use in your backend. Commands that look after the shop itself are there too: run the scheduled tasks, read and change a configuration setting, empty the caches, and bring your database up to date after restoring a backup. Each command prints a readable table by default and can print JSON, CSV, or just the ids or the count instead, so its output can be piped into another program, and it returns a different exit code depending on whether the record was missing, the request was wrong or the account was not allowed, which is what a script needs to react. A command acts as the account you name, so the access levels of your site and of the HikaShop configuration decide what it may do, and your change log records who made the change. Anything the commands do not cover directly is still reachable, since the whole Connector API can be called the same way. The commands for your products, orders, customers, categories, coupons and mass actions come with the Connector plugin of the Business edition, while the commands for the configuration, the caches and the database are available in every edition ; running the cron this way needs the Essential or the Business edition, as the cron itself does.
• The "Product page" menu item type can now carry the whole checkout on the page itself, so that a customer orders without ever leaving the product. A new "One page checkout" tab on the menu item turns it on and gives you the list of checkout blocks displayed under the product, with the same drag and drop editor as the checkout of your configuration, but for this page only: the checkout of the rest of your shop is not affected. The page opens with the product already counted in, showing its price, its taxes, its shipping cost and its total, without anything being written in your database until the customer actually orders something, so a visitor who only looks at the page does not leave an abandoned cart behind. Changing the quantity, the options or the custom fields of the product updates the totals, the shipping methods and the payment methods on the spot, without reloading the page, and there is no "Add to cart" button to press. Your customers are identified as guests, with their email address and their delivery address asked directly on the page, unless they are already logged in, in which case nothing is asked of them. The order button, whose text you can change, creates the order and sends the customer to the payment as usual. This is available in the Essential and Business editions.
• HikaShop Business now has a mobile application, which lets you run your shop from your phone or your tablet, and from any browser. It is free, and you connect it to your site by scanning a QR code: the new "App Devices" page of the System menu of your backend creates a single use pairing code, and the application exchanges it for its own key, so your password is never typed into it. Each device that you connect is then listed on that page with the date it was last used, and can be revoked on its own, which is what you do when a phone is lost or when an employee leaves. From the application you follow your sales on a dashboard, receive a notification when an order arrives or when a product runs low on stock, and go through your orders to read them, filter them, change their status, edit their addresses, their products and their shipping and payment fees, or create an order by hand. You also manage your catalogue there: your products with their images, their prices, their variants, their characteristics and your own custom fields, your categories, your customers with their addresses, and your discounts and coupons. A barcode can be scanned with the camera of your device, or with a barcode reader, to find a product and correct its stock without looking it up. The mass actions that you set to be displayed on a listing of your backend also appear in the application, so your own bulk operations are available from your phone. Several shops can be connected to the same application and you switch between them from the menu. What each person is allowed to see and to change is decided by the access levels of your Joomla or WordPress site and by the Access levels tab of the HikaShop configuration, so you can connect a device for an employee and limit it to what they need. The application is not needed to run your shop and changes nothing on your site until you pair a device with it.
• Your categories can now be imported from a CSV or XML file, with a new "Import" button on the categories listing of your backend. It opens the same wizard as the import of the orders: the first step takes your file, or the content of a CSV pasted in the page, and asks under which category the new categories should be created, whether the categories which are not on your site yet should be created at all, and whether the images given by an address should be downloaded. The second step displays the columns of your file with their first values and matches them with the columns of HikaShop for you. A category of your file is recognized by its id, by its namekey or by its name, so a file exported through a mass action can be filled in a spreadsheet and loaded back to update the descriptions, the SEO texts, the access levels, the images and your own category fields in one go. A file can also describe a whole tree at once: a row can name its parent category instead of giving its id, and the rows are saved in the order needed even when a category is listed before its parent. This works for the manufacturers and the other category trees as well, since the type of the imported categories follows the category you selected as their parent.
• When your customers filter a product listing by a characteristic, for example by a color, the image of each product now automatically changes to the image of the variant that matches the selected value. A product that has a red and a blue variant shows its red image when the red color is selected in the filter, so your customers can see which variant is available without opening each product page. This happens when a single value is selected in the filter and the matching variant has its own image ; products that do not have a matching variant, or whose matching variant has no image of its own, simply keep their main image as before. Only the image is changed, the price, the stock and the add to cart still refer to the main product.
• You can now link directly to a specific variant of a product by adding its characteristic value to the product page address. A link ending with ?hikashop_char=red opens the product page with the red variant already selected, showing its image and its price, and you can combine several values, for example ?hikashop_char=red,l for the red large variant. Each value can be given either by its name (its alias) or by its id, which is convenient to send a customer a link to the exact variant you want to highlight. In addition, when a product listing is filtered by a characteristic, the links to the products now carry the selected value automatically, so a customer who filtered by the red color and then clicks a product lands directly on its red variant. If the value does not match any variant, the product page simply opens on its usual default variant.
• Your discounts and coupons can now exclude specific products, categories and user groups, in addition to the existing options that limit them to certain products, categories or user groups. Three new "Excluded products", "Excluded categories" and "Excluded user groups" settings are available in the restrictions of each discount and coupon. An automatic discount is not applied to a product that is among its excluded products or in one of its excluded categories, and is not applied at all to a customer who belongs to one of its excluded user groups, while every other product and customer keeps receiving it. This makes it easy, for example, to set a discount on your whole shop except one category or a few products. A coupon that would apply to an excluded product, an excluded category or an excluded user group is refused with an explanatory message. The excluded categories can optionally include their sub categories, and all three settings are left empty by default, so your existing discounts and coupons keep working exactly as before.
• Your shop can now be served on several domain names, with one vendor per domain, thanks to the new "Domains" system plugin. HikaShop provides what that plugin needs on its side: when a domain is restricted to a vendor, its product listings, its category and manufacturer listings, its product pages and its RSS feed only show that vendor, and the links HikaShop builds stay inside the menu the domain belongs to instead of pointing at a menu item of another domain. Two new triggers, "onHikashopMenuItemsFilter" and "onBeforeProductFeedLoad", carry this and are available to any plugin. The plugin adds the domain field to your HikaMarket vendors by itself, so nothing has to be installed or updated on the HikaMarket side. Nothing changes on a shop served on a single domain, as these triggers do nothing when no plugin listens to them.

Improvements (45)

• The filter edition form had two settings both named "Category", one saying in which categories the filter is displayed and one, for a filter on categories, saying which category the filter reads its choices from. They are now named "Displayed in the categories" and "Parent category of the values", and the second one has an explanation next to it as the first one already had.
• The translations of your shop now keep themselves up to date without saying anything, and the message which used to ask you to do it by hand is gone. HikaShop already downloaded the languages of your site again when they were older than the version you run, once per session, but it did so silently while the configuration page kept telling you that your language file was not up to date, and the link it offered opened an editor which downloaded nothing until you pressed Save on it. A message is now displayed only when the download really could not be done, which is when your server cannot reach hikashop.com or when it cannot write in your language folder, and it says which of the two happened, for which language, with a link to try again. That link now does the whole thing on the server, so nothing is loaded from our website into your backend anymore. This also puts an end to the message appearing in the days after a release: a translation is published a little after the version it belongs to, so HikaShop installs the most recent one it has and stays quiet about the texts which are still in English, instead of asking you for something no click could give.
• The MCP server that exposes your mass actions and your agentic checkout to AI assistants is now HikaShop's own, and it speaks the current version of the protocol. It used to be built on an external library that was already a full revision behind: that revision removed the opening handshake and the notion of a session, which is what the library is built around, so following it meant waiting for the library to be redesigned. HikaShop now answers both the current protocol and the older ones, choosing on each request which the assistant is speaking, so a recent assistant and an older one both work against the same address without you configuring anything. The endpoint also refuses a request coming from another website in a browser, which the protocol has required for a while and which the library never applied to us. On top of that the install package loses about 1 MB and a thousand files, since the twenty-two libraries that came with the external one are no longer shipped. The mass actions you expose, and the way you declare them, do not change.
• The graphs of HikaShop now draw themselves when they appear instead of being there all at once: a curve is traced from left to right, columns and the bars of a ranking rise from zero, a pie is filled clockwise, the needle of a gauge swings up to its value and slightly past it before settling, or is lifted and let fall back when it reads zero and has nowhere to travel, and the countries of the map take their colour one after the other, the busiest first. This concerns the graphs of your backend dashboard, those of your reports, the chart of the values of a custom field and the graphs of the affiliate page your partners see. The figures are not touched, only the moment each part of the drawing arrives. A visitor whose system is set to reduce animations, and a browser which does not play them, get the finished graph straight away as before.
• A report can now be displayed as bars. The bar chart existed but was never offered when building a report, so it could only be reached by editing the database. It sits next to Line and Area in the list of display types.
• The menu of the customer account now follows the page as your customers scroll, so they can move from their orders to their addresses or their affiliate program without scrolling back to the top first. On a short screen the menu scrolls on its own rather than losing its last entries.
• Your affiliate banners now record which of them a visitor arrived from, so your partners can see which banner works and so can you. The links HikaShop builds for each banner carry its reference, and the affiliate page lists the clicks of each one. A link a partner copied before this change carries no reference, and those clicks are grouped under "Direct link" rather than being lost.
• Every graph HikaShop draws is now drawn by HikaShop itself instead of by the Google Charts service: the graphs and the map of your backend dashboard, the widgets of your reports, the graph of a report while you build it, the chart of the values of a custom field, and the new graphs of the affiliate page. Nothing is requested from Google anywhere in HikaShop anymore, which removes a third party from your administration and from the consent question which came with it. The graphs gained the figures of the point your mouse is on, they follow the dark mode of your backend, and the numbers behind each drawing can now be read by a screen reader. The map is drawn from country outlines shipped with HikaShop, so it also works on a server with no access to the outside.
• The Google Merchant feed can now be written more than once, so that a shop served on several domain names has one feed per domain: the same feed settings, but each file holding the products of that domain and carrying its addresses. The feed of your shop keeps its name and its schedule, the others are written next to it with the domain added to the file name, and only your shop's feed is sent to your Google account, since there is one account in the settings. Nothing changes on a shop with a single domain.
• The smart search index now records which vendor sells each product, so a search can be restricted to one vendor. It also fixes a related oversight on multilingual shops: the copy of a product made for each language started from an empty set of tags, so anything the product had been tagged with beyond its type and its language was lost, and only the type and the language survived indexing.
• The checkout workflow editor, used by the Checkout tab of your configuration to arrange the blocks of your checkout, has been redesigned. The steps and the blocks are now displayed as cards with clearer spacing, and the icons to delete a block, to delete a step and to move a block have been redrawn so that they stay sharp on every screen. The buttons which delete a block or a step now turn red when you point at them, to tell them apart from the buttons which only move things around.
• The number of nights of a date range custom field, and the message reporting how many shipping methods were generated, are now written in the singular or in the plural like the other messages. The number of nights changes while your customer is choosing the dates, without the page being reloaded, so the forms of your language are given to the page and the one matching the number is picked as the dates change.
• The messages which give a number of things are now written in the singular or in the plural depending on that number, instead of always using the plural or hedging with a "(s)". This concerns about thirty messages, among them the number of records deleted or restored in your backend, the number of results a mass action is about to work on, the number of items of the cart module, the number of downloads left on a file, the number of packages of a shipping rate, the number of categories, orders, discounts, zones and methods created by the imports, the number of nights of a date range, and the points of the user points plugin. Languages which need more than the two forms of English can give the form of their grammar for each number, and a language which has not been updated yet keeps its current wording, so nothing changes for it until its translation is completed.
• The "Export a csv file" action of the mass actions can now output the columns in the order you choose and with the header names you want. Once you have selected the columns to export, they appear in a list below where you can drag them into the order your label printer, your carrier portal or your spreadsheet expects, and give each one a custom header instead of the raw database column name. The columns can be arranged in any order, even mixing fields that come from different tables, like a delivery name followed by an address and a phone number. Your existing mass actions keep exporting exactly as before until you change the order or the labels of their columns.
• A mass action on your categories can now export the image of each category, like a mass action on your products already exports the images of your products. The columns of the images are proposed among the columns to export once the "Export a csv file" action is selected, so an export of your categories can carry their images and be loaded back with them through the import of the categories.
• The import of the sub zones of a zone and the import of the payment and shipping methods now work like the import of the orders and of the discounts. Their file can be a CSV or an XML file, its charset is detected, the columns of your file are matched automatically with the columns of HikaShop instead of having to be selected one by one, and the first rows of your file are displayed next to each column so that you can check the matching before importing. On the sub zones, no column was ever matched automatically, so an import launched without touching the selectors imported nothing.
• The import of the orders and the import of the discounts and coupons, available with the "Import" button of their listing, now read the files exported by a spreadsheet more faithfully. A value written between quotation marks keeps its line breaks and its own quotation marks, so a text on several lines is loaded as one value instead of being cut into several rows. A new "File charset" setting was also added on the first step of these imports, which lets you tell in which charset your file was saved when it is not UTF-8, the charset being detected automatically when you leave that setting on "Automatic", so the accented characters of a file saved by Excel are no longer replaced by strange characters.
• The "Main category" setting of the category and product menus and modules now accepts several categories instead of only one. A products listing built this way shows the products of all the selected categories together, so you can, for example, present the products of a few chosen categories on a single page. A category listing gains in addition a new "Display the selected categories themselves" choice in its "Sub elements filter" setting, which shows the categories you picked as they are instead of their sub-categories, letting you build a "Featured categories" block that lists a few categories chosen anywhere in your tree, in the order you arranged them. Selecting a single category keeps the previous behavior, so your existing menus and modules are unchanged.
• The old carts are now removed by the cron of HikaShop. Until now, the carts left untouched for longer than the "Cart retaining period" of the Advanced tab of the configuration were only removed while a page of the HikaShop backend was displayed, so a shop whose backend is rarely opened kept accumulating them. The cron now does that cleaning too and reports the number of carts it removed, and it empties a backlog of old carts over a few runs instead of removing a single batch per check. An empty "Cart retaining period" now also keeps the carts instead of removing all of them, and the wishlists of your customers are still never removed.
• The NETS payment plugin is not included in HikaShop anymore. It integrated the Netaxept platform, which Nexi has replaced by Nexi Checkout, and a Nexi Checkout payment plugin is now available on our marketplace for it. If you already use the NETS payment plugin on your website, it stays installed and keeps working as before, so your existing payment methods and orders are not affected.
• The pages of your shop are now protected from the page caches. A page cache keeps the page built for one visitor and serves it to the next ones, so your customers could receive a page carrying the cart and the security token of another visitor, and their order then failed with an "Invalid Token" message. HikaShop now tells the page cache of Joomla not to store the pages of your shop which display a cart or which need the token of the visitor, while your product and category pages keep being cached as before. This is done by the "HikaShop user synchronization" plugin, which is already installed on your site. Those pages also ask the LiteSpeed cache of your server not to store them, and your dashboard now warns you when the page cache of Joomla or the LiteSpeed Cache plugin is enabled without the pages of HikaShop being protected from it. If you use another caching system, like Varnish, Cloudflare or a caching extension, exclude your cart and checkout pages from it, or configure it to bypass the cache for the visitors who have the hikashop_cart_id cookie.
• On the checkout, the button that validates the address form is now shown with the same highlighted style as the other main buttons of the checkout (like the "Next" button and the "Add a new address" button), instead of the plain style it used to share with the "Cancel" button next to it. On guest checkouts especially, some customers did not notice they still had to validate their address before the shipping and payment options appeared, so this button now clearly stands out as the main action of that step.
• The category menus and category modules can now display your whole category tree instead of stopping after two levels. The "Sub-categories" setting has two new choices. "All sub categories (all levels)" lists each category with all of its sub-categories nested underneath it, as deep as your category tree goes, so a third or fourth level of categories is shown too. "All sub categories, collapsible (all levels)" shows the same full tree but folded, so that clicking a category reveals its sub-categories and clicking again hides them, at every level, with the branch of the category you are currently browsing opened automatically. The previous choices keep displaying two levels as before, so nothing changes on your shop until you select one of the new options. The "Number of sub categories" setting still applies and then limits how many categories are shown at each level.
• You can now add a price unit label to your products. A new "Price unit label" setting on the product edit page lets you type a short text, for example " / kg" or " per litre", that is displayed after the price on your product listings and pages, in place of the default " each" wording. This is useful when some products in a shop are sold by weight or length while others are sold by the unit, so that your customers can immediately see what the price refers to. The label is left empty by default, in which case the usual behavior is kept, and variants inherit the label of their main product when they do not have one of their own. The label is also displayed when the "advanced price display" of your menu item is turned on, and, if your shop is translated in several languages, you can enter the name of a translation of your shop instead of a text so that the label follows the language of your visitor.
• A new "Fill image name from the uploaded file name" option has been added to the Images section of the configuration. When you turn it off, the images you upload no longer keep the uploaded file name as their name, so the product name is automatically used as the image alt text on the frontend, which is better for your search engine referencing. You can still set the name and the description of each image manually. The option is turned on by default so nothing changes on your shop until you decide to use it.
• The addresses of your listings now favor your own menu items over the hidden menu item that HikaShop creates for its modules. When a category module has no menu item assigned to it, HikaShop creates a hidden menu item so that it can still build the addresses of the links of that module. That hidden menu item was then considered like any other one, so it could be selected before your own menu items when HikaShop had to pick one to build a link, and some of your listings displayed addresses containing "hikashop-menu-for-module-12". Your own menu items now always come first, and that hidden menu item is only used as a last resort, when no other menu item of your site is able to build the address.
• The Modern, Gallery, Sticky, Full width and Showcase layouts of the product page now keep their arrangement of the images on shops whose template or custom CSS also styles that area of the product page. These layouts place the strip of small images in a narrow column next to the main image, but their style rules had the same level of precedence as the CSS of a site, so a rule of your own making that strip take the whole width, which is how the default layout arranges it, took priority and left no room for the main image, which was then displayed with a width of zero pixels and thus looked missing. This mostly showed on the products that have several images, for example one image per variant. The rules of these five layouts now take precedence over the CSS usually written for the product page. Nothing changes on the shops that were not affected, the five layouts look exactly the same as before.
• The translation editor of the Languages section of the configuration now protects your language file. When the text you save cannot be read as a language file, for example when a quote is missing on one line or when the browser only sent a part of the content, nothing is written any more and the line to correct is displayed: such a file makes every text of your shop display as its key instead. Saving also removes the copies Joomla keeps of the previous version of the file, so the strings you just saved are used right away.
• Several elements of your shop are now easier to use with a keyboard and with a screen reader. The frames displaying the payment page of Authorize.net and of PayPal Integral Evolution, and the documentation and update pages of your backend, now carry a title, so that a screen reader announces what the frame contains instead of reading it as an unnamed region. The username and password fields of the checkout login form no longer force their own position in the keyboard order, which used to send the visitor to them before the rest of the page whatever the order of your checkout.
• The listings of your backend can now be used with a screen reader. The icons which publish or unpublish a record, and which turn a setting of a row on or off, only said their state through their colour and their shape, so they were announced as an empty link; they now say whether the value is enabled or disabled and that activating them changes it. The checkbox which selects every row of a listing, the small field which sets the position of a row, and the button of the search box are named too, instead of being read as an unlabelled field or an empty button. The two arrows which open and close a branch of a category tree, in the product listing, in the access levels and in the image gallery, say whether they expand or collapse it. The dropdown which changes the status of an order, on each line of the order listing, and the other category dropdowns of your backend now say what they list. On the shop itself, the quantity field now says that it is a quantity, wherever it appears: on a product page, on a product listing, in the cart and during the checkout. Nothing changes visually.
• Each setting of the HikaShop configuration is now tied to its own caption. Clicking the name of a setting puts the cursor in its field or opens its dropdown, as it does everywhere else in your backend, and a screen reader now says which setting it is reading instead of announcing an unnamed field. This covers the Main, Display, Features, Checkout, Advanced, Languages and Cron tabs. Along the way, the "Checkout SEF name" field, which shared its identifier with the "Product show SEF name" field above it, received its own.
• Several captions in your backend and on your shop pointed at a field which did not exist, so clicking them did nothing and a screen reader read the field as unnamed: the password of the registration form, the state of every address form, the condition and the sale dates of a product, the name of a new block, and the status of an order. They now point at the field they name. The two handles of the price slider of your filters say which end of the range they move, so that they can be used with a keyboard by someone who does not see the slider. The image of a product in the order pages and in the customer account carries the name of the product, so the link around it is no longer read as an unnamed link. The buttons which upload or pick an image or a file, the link to the customer of an order, and the edit and delete links of the address book are named as well: they show an icon only, and what named them for a sighted person was a tooltip or a text hidden by the stylesheet, neither of which a screen reader reads. The button which saves the order of the rows of a listing is named too, and its tooltip, which was written in English whatever your language, is now translated. The two dates of the period filter of your orders and of your tax rates are tied to their "From" and "to" captions, so clicking those puts the cursor in the field. The grid which decides the order statuses of your shop also says, on each of its buttons, which status and which setting it stands for, instead of offering a screen reader a row of unnamed buttons.
• The small controls of your shop and of your backend are now large enough to be tapped without aiming: the edit and delete buttons of an address, the refresh and delete buttons of the cart, the edit and delete icons of a price or a file, the order and invoice numbers of the order listing, and every branch of a category tree, which were all under the 24 by 24 pixels that a touch screen needs. Nothing moves on the page, the icons keep their size, only the area which answers to a finger or a mouse grows around them. The category tree of the product listing and of the access levels is slightly taller as a result, inside the panel it already scrolls in.
• Several colours of your shop and of your backend were too pale for the text written on them to be read comfortably: the add to cart button and the other green buttons, the coloured labels of the order statuses, the message shown when no shipping method is available, and the unselected choice of the registration method at the checkout. Each keeps its colour and is only deepened enough for its text to stand out, which is also what the accessibility rules ask for.
• More fields of your backend and of your checkout now say what they are to a screen reader. The name, the alias, the page title, the keywords and the description of a category, and its two page layouts, are tied to their captions, as are the two layouts of a product. The width and the height of a product, which shared the caption of its length, say which measurement they hold, and the two dropdowns beside them say that they carry the unit. Each box of an access level tree says which level it ticks, and each choice of the address list of the checkout is read as the address it selects.
• The category list of your shop, when it is displayed as an accordion, now separates the arrow which opens a branch from the name of the category. Clicking the name still opens the category and clicking the arrow still unfolds it, as before, but the arrow is now a button of its own: it can be reached with the keyboard, it says whether the branch is open or closed, and it is large enough to be tapped. The filters of the order, discount, custom field and mass action listings, and the fields of the import wizard, say what they are as well.
• The last unnamed controls of the backend and of the customer area are named too: the width and the height of the two image sizes of the configuration, the unit of a delay, the sub elements filter of the category listing, the link back to the top of the configuration menu, the link to the currency manager, the link to the customer of an order, and the two filters above the orders of a customer. A characteristic without an alias no longer shows an empty link in its listing, and the small mark which says that a value cannot be removed is no longer a link, since it does nothing.
• The small icons of your backend, on the buttons which save, add, edit or delete, are described for a screen reader: alone they say what they do, and beside a caption they are passed over in silence rather than read out twice.
• The variant selection dropdowns on your product pages now carry an accessible name too. When a product has variants, the drop down that lets your customers pick a value, a size or a color for example, had no label linked to it, so screen readers and the accessibility checks of tools like PageSpeed Insights could not tell what it was for. Each dropdown now announces the name of its characteristic, with no visible change on your product pages.
• The product review form and the social sharing buttons of your product pages are now clearer for assistive technologies and for the accessibility checks of tools like PageSpeed Insights. The name and email fields of the review form were only preceded by a plain text, so their label was not linked to the field, and the sharing buttons that show only an icon had no readable name. The fields now carry a real label, the comment area announces its purpose, and each sharing button now has a name based on its network, so a screen reader and an automated browser can tell what they are, and these audits no longer report them. Nothing changes visually on your shop.
• The PayPal Checkout payment page now explains the problem when the PayPal buttons cannot be displayed, instead of showing an empty area. The buttons are drawn by a script loaded from the PayPal website, and a cookie consent extension which blocks the third party scripts of your pages until the visitor consents, or an option of a caching extension or of your template which combines, defers or minifies the javascript of your pages, can prevent that script from running. Your customers were then left on a payment page with no button and no explanation, and the javascript of the rest of the page stopped working. The page now displays a message inviting the visitor to disable such an extension and to reload the page, the rest of the page keeps working, and the reason is written in the console of the browser for you to find. If you are in that situation, add www.paypal.com to the addresses allowed by your cookie consent extension.
• The debug setting of the PayPal Checkout payment method now also brings you what the browser of your customer says on the payment page. The payment buttons are drawn in the browser of each customer by a script coming from PayPal, so when a customer tells you that no payment button appeared, the reason is usually only visible in the console of their browser, which you cannot ask them to open. While the debug setting is on, the payment page watches whether the buttons really appear, and when they do not, it writes in your payment log file what that browser said, together with the browser used, the size of the screen and what the payment area ended up containing, so you can see what happened on the side of that customer and tell us about it. Nothing is written for the customers whose payment page worked, so your log only holds the cases you are looking for. Only the payment page of PayPal Checkout is concerned, and only the customer who is paying can write there. Remember to turn the debug setting back off once your problem is understood.
• Added a trigger which lets a plugin store the files uploaded on your shop somewhere else than on your server, and updated the trigger "onBeforeFileDelete" with a new parameter telling whether the files themselves are kept. These are aimed at developers, and make it possible for a plugin to keep your files on a cloud storage.
• The files uploaded through a custom field of the type "AJAX file" can now be kept outside of your server by a plugin, on a cloud storage for example. Such a file used to be looked for on the disk of your server only, so it could not be delivered to your customer, and the value of the field was emptied when the form was saved. Both now work, and a file which no plugin recognises is still refused, so the address of a file cannot be typed in by hand to reach a file which is not yours. The files stored on your server are unchanged.
• On a mini-cart that uses a configured icon, the cart module now adds a distinct hikashop_small_cart_empty CSS class to the mini-cart link while the cart is empty. Since version 6.5.0 the mini-cart keeps its icon visible when the cart is empty, so a shop that also shows a separate empty cart image ended up displaying both at once, with no way to tell the two states apart in CSS. With this class you can now style the empty mini-cart on its own, for example to hide the filled cart icon while the cart is empty, without having to hide the empty cart itself.

Bug fixes (93)

• The filter edition form does not print PHP deprecation notices anymore when it is opened to create a filter. On PHP 8.4 and above, two of them were displayed in the middle of the options of the form.
• The fields of the filter edition form which had no label of their own, the number of columns, the custom field selector and the values of the filter, are now named for a screen reader, and its two links which acted as buttons, the one adding a value and the one clearing the parent category, are buttons, so they can be used with the keyboard.
• When your affiliate program is set to pay your partners in points instead of money, the points are credited again instead of stopping the page with an error. A partner earning a click fee or a lead fee ran into that error, so the points were never given and the fee stayed on their account. The points given for a sale are also labelled as a partner fee now, where they were labelled as a click fee.
• The Alipay payment method now obeys its "Allow payment notifications" setting, which it ignored: turning it off left Alipay able to confirm your orders anyway. The name of the gateway is shown in that setting instead of a %s, and the "Sandbox", "Server to Server", "Charge And Ship" and "Invalid status" settings have been removed from the method, as the plugin never did anything with them.
• Importing a CSV which updates existing products no longer changes their tax category when the file says nothing about it. The tax category of your shop is meant to fill in for a product being created, but it was applied to the products being updated as well, so a product sold under one tax category came back from the import under another one, the last of your tax categories in the ordering of your tax category listing. A file which does give a tax category, by its name or by its identifier, still applies it, and a product created by the import still receives the tax category of your shop as before.
• Updating HikaShop now always brings the structure of your database up to date. On a site where another extension loads HikaShop before the installation itself runs, which is what a plugin displaying your products outside of HikaShop does, the update skipped that step without saying anything: your files were updated but your tables were not, and a page using a column added by the new version then failed with an "Unknown column" error. If your shop is in that state, the "Check database" button in the toolbar of your HikaShop configuration adds what is missing, and installing the package again does it as well.
• When a CSV of products gives a parent category next to the category of each product, a category is now created under that parent when it is not there yet, even when a category of the same name already exists somewhere else in your catalogue. A catalogue where the same name is used in several branches, for example a "Hand cream" under each of your brands, used to end up with a single category holding the products of all the branches: the products of the second brand were attached to the category of the first one instead of a new one being created under their own parent. Shops with more than four thousand categories were not affected.
• The old Google Analytics plugin is removed from your site when you update. It spoke to Universal Analytics, the service Google shut down, so it had not been reporting anything for a long time, and it had already stopped being part of HikaShop in 5.0.4. It is deleted now, along with the settings it kept, and HikaShop tells you so once. The free Google Analytics 4 plugin of our marketplace is the one to install in its place if you have not done so already.
• Uploading an image or a file on a server whose PHP configuration has the "file_uploads" setting turned off now tells you so, instead of appearing to work and leaving you with an entry showing the default image. PHP discards the file in that case and hands HikaShop an empty request, which HikaShop did not recognise: it recorded an image with no file attached to your product, and answered the browser something the upload area quietly ignored, so nothing appeared until the page was opened again. The upload now stops with a message naming the setting to turn on, and no entry is recorded. Any upload that reaches the server without its file, for whatever reason, is reported the same way rather than passing silently.
• The screen listing the methods of a plugin, which you reach with a direct link to a payment, shipping or system plugin of HikaShop, no longer displays an error page instead of the list. It stopped on recent versions of PHP, which no longer accept the counting the page did there. The listings of the payment methods, of the shipping methods and of the plugins, and the edition of a method, were not affected, so the screen was only met through a bookmark or a link kept from an older version of HikaShop.
• A customer address that has no country or no state set no longer fills your pages with "Using null as an array offset is deprecated" warnings on recent versions of PHP. HikaShop looks the tax zone of an address up by that field, and looked it up even when the address did not carry one, which found nothing and warned about it on every attempt. It now skips the lookup when there is nothing to look up, which is what it already did with the result. The warnings only showed on a site that displays PHP errors, but the pointless database query happened everywhere.
• The commerce tools that the UCP plugin offers to AI assistants over MCP now work. They were declared correctly and an assistant could list them, but none of them ever received what it was called with: creating a checkout arrived with no products, reading or completing one arrived with no session, so every call came back saying the session could not be found. Their answers also left the envelope the assistant expects, arriving as a bare web error with an HTTP error code rather than as the result of the call, which the protocol places above HTTP for exactly that reason. The tools now receive their arguments, answer inside the envelope, and carry the checkout both as structured data and as text, which is what the UCP specification asks of them. Placing an order from an assistant through this plugin therefore works for the first time; the REST side of the plugin was never affected.
• The MCP endpoint of the mass actions no longer answers with two JSON documents at once. HikaShop opens a session by itself for an assistant that sends a request without initializing one first, and the answer to that internal initialization was written to the response ahead of the answer to the request itself, so a strict client saw a malformed reply. Only the answer to the request is sent now.
• The order confirmation email produced a PHP warning when the payment method was a bank transfer, a check or a purchase order and its information text had been left empty in your configuration, which is the case until you fill in your bank details. The email was still sent, but the warning could end up in your logs or, on a site displaying errors, at the top of the page. On WordPress, a second warning came from asking the translation system about an empty key.
• A plugin could not stop a mass action anymore. The mass actions give your plugins a chance to check what is about to happen before it runs, and to cancel it, which is how a plugin refuses a change it knows would break something. The value telling HikaShop to stop was not passed in a way that let the plugin change it, so the mass action always went ahead. Cancelling works again, both before the filters are applied and before the actions are run.
• The database name, the table prefix and the installation path of the WooCommerce and EC-CUBE imports had their text displayed next to them but not attached to the field, so a merchant using a screen reader heard nothing when reaching them, and clicking the text did not put the cursor in the box. They are now properly attached.
• The import page offered VirtueMart, Mijoshop, Redshop and J2Store even on a site where none of them had ever been installed. Selecting one only produced a message saying it could not be found, so the list was mostly made of options which could not do anything. Those four are now displayed only when their tables are actually on your site.
• The WooCommerce and EC-CUBE settings of the import page ignored the dark mode of your backend: they kept a white panel with dark text on it, and their fields stayed white, in the middle of a dark page. They now follow the colours of your backend in both modes.
• The PayPal Checkout express button did not appear on a product page carrying the one page checkout. That page keeps its cart in memory until the customer actually orders, so that a visitor who only looks at the page does not leave an abandoned cart behind, and the button was looking for a cart that had not been written yet. It is now displayed there like on the other pages, and the cart is created when the button is clicked, which is the moment the customer decides to pay.
• The credit card fields of the checkout, displayed by the payment methods which collect the card on your own site, were not all announced to customers using a screen reader. The card owner and the card type had their text displayed next to them but not attached to the field itself, the year of the expiration date had nothing at all, and the label of the card number pointed to a field that did not exist, so clicking it did not put the cursor in the box. Each of those fields is now properly attached to its text, and the month and the year of the expiration date are announced separately.
• The dropdowns of the checkout did not look like the other dropdowns of the page. When the shipping methods, the payment methods or the addresses were set to be displayed as a dropdown rather than as a list of radio buttons, those dropdowns were missing the style of your template, so they appeared smaller and plainer than the country or the state dropdown right next to them. They now carry the same class as the rest of the fields of HikaShop and follow your template like the others.
• The tax zone kept in the session of a customer who logs in was not set anymore, so until that customer opened a page which reads their address again, the taxes of their cart could be computed on the shop's default zone instead of theirs. The address field holds the zone together with the ones which contain it, the country, the tax zone and the continent, and only the first of them is the address's own zone; all four were being read at once, which produced no zone at all. On a server configured to display them, this also printed a warning on the checkout.
• A payment method saved before one of its settings existed, or created outside the payment method form, left the payment plugin reading settings which were not there. Bank transfer, for example, then left the order in its initial status instead of moving it to the status it is configured to use, and printed warnings on the last page of the checkout on a server configured to display them. Every payment method now starts from the values its plugin declares as defaults, and only the settings you actually changed are read from what was saved.
• Installing HikaShop from the command line, with the Joomla console rather than through your backend, left the shop without any of its bundled plugins and modules: no payment method, no shipping method and no HikaShop module could be selected afterwards. The post-installation step stopped early when it could not create the upload folders, which happened on that path because the folders it was given had not been read from the configuration yet. The folders now fall back to their usual place, and a problem with them no longer prevents the plugins, the modules, the menus and the update site from being installed.
• On PHP 8.4 and above, the taxes page of your backend displayed a long list of "Deprecated" notices when your shop had orders whose address carried no country, on servers configured to show such notices. The page itself was correct, but the notices made it unreadable. Those orders are now counted outside the European Union, as they already were, without the notices.
• When the server could not add a product to the cart, the "Add to cart" button did nothing at all: no message, no error, nothing on the page, and your customer had no way of knowing that the product was not added. This only happened when the request itself failed, for example when the database of the shop was missing a column of one of your custom fields, and the failure was written in the console of the browser, where a customer never looks. Such a failure is now reported like a refused add to cart, so the usual notification tells your customer that the product was not added, and your shop no longer redirects to the cart in that case.
• The widgets of the backend dashboard were displayed one under the other, each taking the whole width of the page, instead of three per row. They were laid out with an old grid which the backend no longer carries any rule for, so every widget fell to the full width. The last row was also left unclosed when the number of widgets was not a multiple of three.
• In the Starter edition, the "Sales per country" map of the backend dashboard was displayed instead of the notice explaining that the geolocation map is a feature of the paid editions. The map belongs to the Essential and Business editions and was never meant to be part of the free edition ; a typo in the marker which removes it while the Starter package is built meant that it was kept.
• Fixed a warning displayed in the filter module of your product listings, for a filter saved before the column width setting existed. The filter had no width of its own and the module used it without checking, which showed a message at the top of the module on sites configured to display PHP warnings.
• Fixed a deprecation notice displayed at the top of the page, on PHP 8.1 and newer, when a form containing a custom field was saved and that field had no previous value. Two of the checks that decide whether a required field was filled in were passing that empty value straight to a function which no longer accepts it.
• The address format, which you customize in the Checkout tab of your configuration to decide how the addresses of your customers are displayed in your emails, in the checkout and on the orders, is now kept when you change the template of your site. That format was only stored in the folder of each template installed at the moment you saved it, so a template installed afterwards did not have it, and switching to it silently brought back the format of HikaShop, without the lines you had added. It is now also saved in your configuration and put back automatically in the templates which do not have it, so a new template starts with the format you had. Templates which already have the file are left untouched, and the "Reset the address format" button still resets everything.
• In the checkout workflow editor of the Checkout tab of your configuration, the button which deletes a block was invisible when your backend was displayed in dark mode, so the block could not be removed without switching to the light mode. The step name field and the "Step" title next to it were also misaligned when the editor was displayed outside that page.
• The renewal of the payment authorizations of your orders no longer stops with a fatal error. Once a payment plugin had renewed the authorization of at least one order, the message reporting how many were renewed called a function which does not exist, so the renewal stopped there and the report was never displayed.
• The message giving the quantity left in stock on a product page is now written in the singular or in the plural depending on that quantity, and no longer depending on the "Low stock message threshold" setting of the Display tab of the configuration. A shop whose threshold was set to 5 displayed "3 item in stock" for three items, and a shop which left it at 1 displayed "1 items in stock" when a single item was left. The threshold now only decides when the message is displayed, as its name says. The languages which need more than two forms for a quantity, like Polish, Czech, Slovak, Croatian, Slovenian, Romanian and Arabic, can also give the form of their grammar for each quantity, so their message reads correctly for two items as well as for five.
• A custom field which does not apply to the product or the category being saved can no longer be stored on it. A field restricted to certain categories or to certain products, or which is not displayed on the form being used, is correctly hidden from that form, but its value was still saved when it was submitted anyway, for example by a script or by a page left open while the restrictions of the field were changed. Such a value is now discarded, and the fields which do apply are saved as before.
• The title of a group of display options of a custom field is now translated. When a group of options added by an add-on had a translation for its title, the form of the custom field displayed the name of the translation key instead of the translated title.
• The columns of a file loaded through the import of the orders can be stored in a new custom field again. Choosing "New custom order field" (or the item, user and address ones) for a column of your file stopped the import with a database error, and the field was not created. The field is now created and, which never worked either, the values of that column of your file are stored in it, whether the field belongs to the orders, to the products of the orders, to the customers or to the addresses.
• The list of your payment methods, the list of your shipping methods and the other pages which load these plugins no longer stop on a fatal error when one of the installed plugins contains code that your version of PHP no longer accepts. A single such plugin, for example an old version of a payment plugin left on a server which was later moved to PHP 8, used to take down the whole page and prevent you from reaching any of your methods. HikaShop now detects a plugin which cannot run on your PHP version before loading it, disables that one plugin automatically, tells you which plugin it was so you can update or remove it, and displays the page normally with all your other methods.
• The "Actions" window of the orders, products, customers and categories listings no longer opens with an empty drop down list. The actions of that window come from mass action plugins, and when the "System - HikaShop Mass Action" plugin or the mass action plugin of the type of elements you selected was disabled in the plugins manager of Joomla, the window opened with a list containing no action and nothing explained why. These plugins are now enabled automatically when you open that window, as they already were when you open the Mass actions menu, and the window is then reloaded so that the actions are immediately usable. When such a plugin is not installed on your website and cannot be enabled, the window now displays a message naming the plugin to install instead of an empty list.
• Changing the status of an order from a scheduled task no longer stops with a fatal error. When a task of your site changed an order status, for example a mass action run by the Joomla scheduler, the notification email of that order could not be prepared and the task stopped without finishing its work. The order statuses now change normally in that situation and the emails are sent as usual.
• The advanced date picker custom fields configured with an "Hour for extra day" but without a "Days from now" no longer offer a single day to your customers. Once the hour of the day set in that field was passed, the maximum date your customer could choose was moved to one day from now even though you had set no maximum at all, so only one day remained selectable in the calendar for the rest of the day. The "Hour for extra day" setting now only moves the first day which can be chosen, and it moves the last one as well only when you did set a "Days from now".
• A checkout sent with an invalid security token now brings your customer back to the checkout with an explanation, instead of a blank page displaying only "Invalid Token". That page was a dead end for your customer, who could not know what happened nor what to do, and it happens when the page stayed open for a long time or when it was served from a cache. The checkout is now displayed again with a message inviting them to try again, and that page carries a valid token so their next attempt goes through. The other frontend forms of HikaShop, like the addresses, the order pages and the product notifications, behave the same way.
• The payment notification email is sent again for the payment methods which take the money during the checkout, before the order is created, such as the offline credit card, the purchase order, Authorize.net, cmCIC, MIGS, FirstData, eWay, PayPal Pro or the Stripe Connect plugin of our marketplace. Since 6.4.2, the addresses of the "Payment notification email" setting of your configuration received nothing at all for those methods, while the same methods asking for the payment after the order was created kept working, so a shop using one of them was only warned of a payment by the order notification. The notification is now kept aside while the order is being created and sent as soon as it exists, with the order number and the payment status in it as before.
• We fixed a high severity vulnerability in the Bambora (Beanstream) payment plugin, which allowed someone to have an unpaid order marked as paid on the shops whose payment method had its "Hash method" setting on "None". That choice told the plugin not to sign what it sends to Bambora, and the payment notifications coming back were then accepted without being checked at all, so anyone knowing the id of an order could send such a notification themselves and have that order confirmed. The "None" choice is removed: the payment method now has to be set to MD5 or SHA1 with the hash key of your Bambora account, and a notification which does not carry the matching signature is refused and written to the log of the plugin. The amount of the payment is now compared with the total of the order as well, and a notification announcing a different amount puts the order in your invalid status instead of confirming it. The shops whose payment method was set to MD5 or SHA1 were never concerned. If yours was on "None", open it and select the hash method your Bambora account is configured with, since its notifications are refused until you do.
• A Belgian VAT number of eleven or twelve digits is no longer accepted. A Belgian number holds ten digits, nine on the ones issued before the leading zero was added, and up to two extra digits were tolerated at the end. We went over the format of every country we verify against the structures published by the European Commission on this occasion, and Belgium was the only other one which did not match.
• A VAT number with too many digits is no longer accepted. The check of the numbers of the United Kingdom, of Northern Ireland and of Spain was written in a way which only required the beginning of the number to have the right shape, so anything typed after a valid number was ignored instead of making the number invalid: a British number followed by an extra digit, which is neither the nine digits of a company nor the twelve digits of a branch trader, was taken as valid and the customer was exempted from the VAT. The whole number is now checked. Thanks to Seyi on the HikaShop forum for the report.
• The Plugins page of the System menu no longer displays PHP warnings when some of your plugins are turned off. The page has to load every plugin, turned on or not, to know how to list it, and a plugin which is turned off cannot read its own settings back, which is what the warnings were about. Nothing was wrong with the plugins themselves, and their settings were kept intact.
• The texts of your shop no longer stay in the language of the last notification sent. When a notification had to be sent in a language other than the one of the page, the order of a customer who chose another language for example, HikaShop switched the translations to that language and switched them back afterwards by loading the previous language on top. That only brought back the texts that the previous language actually translates, so every text it leaves to English, and every translation override you had made, kept the wording of the notification for the rest of the page. On a shop whose translation of HikaShop is only partial this showed up as a page, and as the notifications sent after that one, written in a mix of two languages with no logic to it. The translations in use are now put back exactly as they were before the notification.
• A VAT number of the United Kingdom starting with GB is now accepted. Since the United Kingdom left the European Union, only the numbers of the businesses under the Northern Ireland protocol, the ones starting with XI, can be checked against the VIES service of the European Commission, and HikaShop treated every United Kingdom address as one of those. A customer entering their real GB number was told to make it start with XI instead, and was never recognised as a company with a VAT number. Both prefixes are now accepted for the United Kingdom, and a number entered without any prefix is given the one that matches the address, XI for a Northern Ireland post code and GB otherwise. A GB number cannot be checked online through VIES, so it is accepted on its format alone, as already happens when VIES cannot be reached. Checking it for real needs the API of HMRC, which requires each shop to have its own credentials.
• For developers: the onBeforeVATOnlineCheck trigger can now refuse a VAT number. The result of the trigger was handed back to the caller as the list of the answers of the plugins instead of one value, and a list is never empty once a plugin has answered, so a plugin refusing a number was read as accepting it and the number was always considered valid.
• A custom product field set to be displayed in its own tab now really gets its own tab on the tabular layout of the product page. The setting had no effect at all since it was introduced in 6.4.0: the field stayed in the Specifications tab with the others, whatever you did with it. The Specifications tab itself is now only displayed when it has something in it, so moving every custom field of a product to its own tab no longer leaves an empty Specifications tab behind.
• The dimensions and brand area of the product page can be customized again. One of its markers was misspelt, which stopped HikaShop reading the structure of that part of the page, so it could not be reorganised from the customization screen.
• When a payment plugin recorded the reference of a payment on an order, it replaced everything else the checkout had already stored on that order along with it. The information lost this way included the recurring plan of a subscription order, so a payment plugin able to renew a subscription by itself no longer found the period to renew and never charged the customer again after the first payment. The references of the payment are now added to what the order already carries instead of taking its place.
• The "On HTTP request (webhook)" trigger of the mass actions now works as its description says. Three things stood in the way. The address the description announces, yourwebsite.com/your-endpoint, only answered when the URL rewriting of Joomla was turned off: with it on, the endpoint had to be called on yourwebsite.com/index.php/your-endpoint instead, which nothing told you. Both addresses now work either way, and the same applies to the address of the MCP endpoint. The API key was then read from the request in a way that depended on the exact capitalisation the client wrote the header in, so a webhook sending "X-Api-Key" rather than "X-API-KEY" was refused with a wrong key error, and on servers where the header cannot be read that way it was refused whatever it sent. Any capitalisation is now accepted. Finally, a request asking the endpoint to load elements failed with a database error naming a table which does not exist, unless the request happened to carry an ordering parameter, which no webhook sends. That trigger could therefore not read anything at all. It now returns the elements as intended.
• The message telling you that a language file of your translations cannot be read now names the line at fault. It only explained the one mistake HikaShop itself can make, a key which is one of the words PHP reserves, and said nothing about the other invalid lines, which the language override manager of Joomla and your own edits can leave in the same file. The message now carries what PHP reports about the file, with the number of the line, so the line to correct can be found straight away.
• Translating a text which reads "No", "Yes", "On", "Off", "None", "True", "False" or "Null" no longer wipes out every translation of your shop. Those eight words are reserved by PHP in the kind of file translations are stored in, and one of them was enough to make the whole file unreadable, so all the translations it held stopped being applied at once and your pages went back to their original language. HikaShop now stores those texts under a slightly different name, so they can be translated like any other. If this already happened to you, the message which tells you the file cannot be read now names the lines to remove from it, instead of only saying the file is invalid. Your other translations are untouched, and nothing has to be translated again.
• The mcp_bridge.js file shipped with the "System - HikaShop Mass Action" plugin was updated along with the endpoint. It used to open a second connection to your site to listen for messages, and stopped with a "SSE Connection Failed: 405" as soon as the endpoint stopped offering that connection, which it no longer needs to since every answer comes back with the request that asked for it. If you copied that file to connect an assistant or the MCP Inspector to your shop, replace your copy with the one from this version.
• An assistant connecting to the MCP endpoint of the mass actions no longer waits forever for its answer. The protocol has clients announce on every request that they accept both a plain answer and an event stream, and HikaShop read that announcement as a request for a stream, then held the connection open indefinitely waiting for messages that a single request can never produce. Requests now receive their answer straight away. The endpoint serves POST requests only, which is all this protocol asks of it, and answers anything else by naming the method it accepts rather than holding the connection open, so the same wait could no longer be provoked with a plain browser request either.
• The MCP endpoint of the mass actions no longer answers requests when no API key is set in the settings of the "System - HikaShop Mass Action" plugin. The key was only checked once one had been filled in, so a shop that turned the MCP server on without setting a key, which is the state right after installing the plugin, exposed its mass actions to anyone who knew the address of the endpoint. The endpoint now answers that the key is missing and runs nothing until you set one, which is what the description of that setting already announced. The key is also read only from the X-API-KEY header now, and no longer from the address of the request, where it ends up recorded in the logs of your server, and it is compared in a way that does not give it away through the time the comparison takes.
• A HikaShop page no longer stops on the text "MCP Plugin Triggered" when the address of the request carries a debug_mcp parameter. A development leftover in the "System - HikaShop Mass Action" plugin answered that on any page of the site, so anyone adding that parameter to any address got a blank page instead of your shop. The plugin no longer looks at it. In the same pass, the MCP endpoint of the mass actions stopped writing every request it receives into a debug_mcp.log file next to the plugin, a file that grew with no limit and that no setting could turn off; what it recorded now goes to the log file of your HikaShop configuration, and nowhere at all when you have not set one. The errors of that endpoint no longer print the internal message of the failure to the caller either, and go to the same log instead.
• The MCP server of the mass actions works again. Since version 6.5.1, an assistant connecting to the address of your MCP endpoint received a server error instead of the list of your mass actions, with the message "Class phpDocumentor\Reflection\DocBlockFactory not found". Several libraries of the MCP server were left out of the install package because they were believed to be needed only for a mode of that server HikaShop does not use, but the server loads one of them whatever the mode, and stopped as soon as it registered the first mass action. They are included in the package again, so the MCP endpoint answers normally and your mass actions are usable from an assistant. Nothing else was affected, the mass actions themselves and their other triggers kept working all along.
• A customer could end up with two orders for the same purchase, the second one paid and the first one left in the "Created" status forever, without ever noticing anything and without being charged twice. When the last step of the checkout was slow to answer, because the payment, the shipping or a notification service took a few seconds, a checkout block finishing its own request in the meantime submitted the order form a second time. The first order was created by the server and its payment page thrown away by the browser, which had already moved on to the second one. That second submission is now ignored while the order is being placed. Coming back to the checkout with the browser button after an order was placed also left the order button doing nothing at all, and it works again.
• On a shop migrated from Joomla 3, the value of a custom field whose name contains capital letters was not saved anymore when you edited an existing customer, order, address or product. The record was saved without any error message, but that field kept its previous value. Only fields created a long time ago are concerned, since HikaShop has been writing the names of new fields in lower case for years, and creating a new record was saving them correctly. Joomla 4 started dropping from an update any column whose name does not match the one of the table letter for letter, and HikaShop was passing those names in lower case.
• The page which lets your customers add or edit an address from their account displayed an error message instead of the form. The address form of the checkout was not affected, only the one reached from the "Addresses" page of the customer account. This came from the address form layout added in 6.3.0: a leftover instruction referred to a list of custom fields that the new layout no longer builds, and PHP 8 stops on it instead of ignoring it.
• After a payment accepted by PayPal Checkout, your customers now land on the thank you page of your checkout instead of an empty page. The address they were sent back to after the payment notification carried only the id of the order, and that page needs either the customer to still be recognized by the site or the token of the order to be given in the address, so nothing was displayed when the session of the customer did not survive the payment, for example when it expired while the customer was on PayPal. That address now carries the token of the order, as the other PayPal return already did, and only when PayPal confirmed a payment made for that very order. The orders and their payments were correctly recorded in every case, only the page displayed at the end of the checkout was affected, and with it the purchase event sent to Google Analytics from that page.
• The search of your product listings and the text filters again find a reference typed in the middle of a product code. Since the search of HikaShop uses the search index of your database, a search for 4003 only found the products where 4003 began a word, so a product with the code ACB4003 was not found anymore, while a product whose reference 37230-40031 begins with 4003 was. The fallback on the previous way of searching only happened when the search found nothing at all, so a single product like that one was enough to hide all the others. The product codes and the custom fields of your products, which hold references rather than sentences, are now always searched from beginning to end again, so a fragment of a reference finds the same products in your shop as in the products listing of your backend.
• The coupon line of the cart, of the checkout and of the order now shows the amount the coupon really took off the order, instead of its full value, when it is worth more than the products it applies to. A coupon of 80 used on an order of 76,89 was displayed as -80,00 next to a total of 0,00, which did not add up for your customers, and the order was recorded with a discount of 80,00, which overstated the discounts of your reports and of your invoices. It is now displayed and recorded as -76,89, and the taxes recorded with it follow the same proportion. A coupon which is smaller than the order is not concerned and keeps being displayed and recorded as before.
• The taxes of an order are no longer lost when a coupon covers the whole price of the products. Until now, as soon as a coupon brought the total of the products down to zero or below, the tax line disappeared from the cart and from the checkout, and the order was saved without any tax information, so those taxes were missing from the tax report of your backend, while a coupon which left one cent to pay displayed them normally. The taxes which are still due on the products are now kept in that situation, so a coupon applied after the taxes, or a coupon which has no tax of its own, no longer cancels them. A coupon applied before the taxes still lowers the taxes as before, and cancels them entirely when it covers the whole price of the products.
• A product listing using the "Infinite scroll" option no longer displays the same products over and over while scrolling down, on a site using search engine friendly URLs. Joomla renames the pagination parameter of such addresses, and HikaShop was reading the original name, so the page number of each listing loaded while scrolling was lost and the first page was sent back every time, then added below the products already displayed. This was the most visible on the results of a search filter, where all the products fit on one page. The page number is now read whatever the address format, and the block loading the next page is only added to the listing when there are still products to load, instead of on any listing holding more than one product.
• A custom field of the checkbox or the radio type no longer loses its value when a product, a customer or an order is saved again. When one of the choices of the field contained a special character, for example the "&" in "Metal Cutting & Machining", the choice already stored was not shown as ticked when you opened the item again, so saving it once more, even after changing something else, emptied that field unless you ticked the choice by hand every time. These fields now recognise their stored value whatever the special characters it holds, so the right choices are ticked when the item opens and their value is kept across saves. The listings that show the value of such a field also display the label of the choice again instead of a stripped version of it.
• The description editor of the edit pages, for example the one of a payment method or of a shipping method, no longer covers the settings displayed next to it. The row of buttons that the editor adds under itself, like "Article", "Module" or the buttons added by your own extensions, was kept on a single line and stretched the whole area to the width of that line, so the editor laid over the settings on its right, which could then neither be read nor modified. Those buttons now go on as many lines as needed and the editor stays inside its column.
• The product page again displays the name of the product itself instead of the name of its first variant. On a product which has variants, the name shown at the top of the page and in the tab of the browser was the name of the variant selected by default, so it carried the characteristic values of that variant, for example "T-shirt: Red, Small", on every product page opened from a menu item or from a search engine friendly address. The characteristic values are now added to the name only once your customer picks a variant, or when the address of the page points at one specific variant.
• A product used as an option of another product no longer displays PHP warnings on the product page when all of its prices are set with a minimum quantity greater than one. Such an option has no price for a single unit, so its price was read from an empty value, which filled the product page with warnings when the display of the PHP errors is enabled on your server. The option is now simply displayed without a price next to its name, which matches the fact that it does not add anything to the total until that quantity is reached. The same correction was made on the window that lets your customers edit the options of a product already in their cart.
• The categories shown in a category listing that do not have their own image now use their own name as the alt text of their image, instead of all borrowing the name of the last category of the listing. This alt text is what search engines and screen readers read for the image, so it now correctly describes each category.
• HikaShop can now be installed again on a site where a folder of a previous HikaShop is still present. When the folder of the component is already on the site, Joomla treats the installation as an update of that folder and does not run the file which creates the tables of HikaShop, so the installation stopped on a "Table hikashop_config doesn't exist" warning followed by "Error installing component", and no table was created. HikaShop now creates its missing tables itself in that situation and the installation goes through. This typically happened after a site was restored from a backup, or after a first installation was interrupted, since the files of HikaShop remain on the site even when its tables and its entries in the extensions of Joomla have been removed.
• The texts you display around the prices of your product listings no longer run outside of the box of their product. These texts, the ones you add before or after the price through the translation of your shop and the price unit label, were displayed on a single line which could not wrap, so a long text overflowed its product and covered the product next to it. This came from the rule which keeps the currency symbol on the same line as its amount, which was applied to the whole price area instead of the amount alone. The currency symbol still stays with its amount, and the texts around it wrap normally again.
• The prices displayed to a customer who just logged in now follow the address type used for your taxes. When a customer logs in, HikaShop remembers one of their addresses in order to know which taxes apply to the prices displayed in your catalog, and it used to take their default address whatever its type. So, on a shop where the setting "Type of address used for tax" is set to the shipping address, a customer whose default address was a billing address in your country kept seeing the prices of your catalog with the taxes of your country until they selected their shipping address on the checkout. The billing address and the shipping address of your customer are now remembered separately, like the cart already does, and the taxes displayed on your catalog follow the one matching that setting.
• A date custom field of the advanced type no longer offers a single day to your customers. The setting which pushes the first day they can pick to the next one past a given hour was applied even when no last day had been configured, and it then set a last day of its own, so from that hour until midnight the calendar offered one date and nothing beyond it. That setting is now only used when a last selectable day was really configured, on the field itself, on the check made when the form is sent, and on the filters built from that field.
• The price column of the CSV export of your products now uses the decimal separator you chose in the configuration, like the rest of the file. The "CSV decimal separator" setting was applied to every numeric column except that one, which always used a point, so a shop set on the comma exported a file holding 9,99 in one column and 9.99000 in the price column. A spreadsheet opened on such a file treats those two columns differently, and the prices could come back modified when the file was reimported.
• Removing a file or an image now cleans up everything that was made from it. The avif versions of the thumbnails were never deleted, and the webp ones were only deleted while the setting which creates them was still on, so turning it off left them on your server for good. Removing one file from a product also left its translations behind, which deleting the whole product did not.
• A file downloaded by a program which does not identify itself, like some download managers, is no longer damaged. A notice could be written inside the file being sent, so what your customer received was not exactly the file you sell. Downloads from a normal browser were not affected.
• A download link pointing at a file which no longer exists, for instance one kept in an old email after you removed the file from the product, now tells your customer that the file cannot be found instead of showing an error page.
• A download which could not be delivered no longer costs your customer one of their allowed downloads. When a customer clicked a download link but the file could not be sent, for example because the file was missing from the server or because a plugin refused the download, that attempt was still counted against the number of downloads allowed for the order. A customer allowed three downloads could therefore use all three without ever receiving the file, and had to ask you to reset the counter. A download is now only counted when the file is really sent, and a failed attempt is given back to the customer.
• The download limit of the files delivered by a plugin, like the files of HikaSerial, is now multiplied by the quantity bought, as the limit of the files stored on your server already was. A customer who bought three copies of such a product was only allowed the downloads of a single copy.
• The download links of the products bundled inside another product are now included in the order emails and on the order details page, instead of only in the customer account download area. When a product added a downloadable file through the bundle feature, that file appeared in the "Downloads" area of the customer account but was missing from the order confirmation and status emails, so customers who rely on the emails did not receive it. The bundled products carry no quantity of their own on the order, which is why they were left out of the emails. Their download links are now listed under the main product in the emails and on the order page as well, whatever the "Group the options of the products" setting is.
• On Joomla 6, the shop and its add-ons (such as HikaSerial) no longer crash with a fatal error on some pages. HikaShop provides the old Joomla class names that many extensions still rely on, but it was leaving that to Joomla's own compatibility plugin when that plugin was enabled, and that plugin only sets those names up later during the page load, so code that ran earlier could hit a class that did not exist yet. HikaShop now sets up these names itself, early and in every case, keeping the full features of the classes, so the shop and the add-ons load normally again.
• A report added to the dashboard through the dashboard configuration is now displayed. When you added the "Report" widget to a row and selected one of your reports, the widget did not appear at all on the dashboard because it was treated as hidden by default. A widget placed in the dashboard layout is now always displayed, so your report shows up as expected.
• The small thumbnail images under the main product image are no longer stretched. Since the previous update the product images carry their width and height so the browser can reserve their space, but the small thumbnails are sized by their height in the styles, so the added width made them wide and flat. Their width is now kept automatic again so they display at the correct size. If you had adjusted the thumbnail size with your own CSS it keeps working as before.
• On a product with several characteristics displayed as drop down lists, the second drop down no longer shows the values that do not match the first choice when the shop is browsed on a mobile phone. HikaShop used to hide these values, which works on a computer but not in the native drop down of mobile phones, so the visitor could see values that were not selectable. The values that do not match the current selection are now removed from the list instead of only being hidden, so the mobile drop down shows exactly the same choices as on a computer.
• Product images no longer disappear on some servers because of the modern AVIF image format. HikaShop can offer each image in the AVIF format for the browsers that support it, with the usual version kept as a fallback, but on a number of servers the AVIF file ended up unavailable to the browser, either because the image library did not really create it or because the hosting blocks the AVIF files, and the AVIF format leaves no room for a fallback in that case, so the image stayed blank. The "Generate AVIF images" option is now turned off by default, so images display normally after the update, and HikaShop also checks that the AVIF file was really created before offering it. If you want to use the AVIF format you can turn the option back on in the Images section of the configuration, after making sure your server creates and serves these files correctly. If your images disappeared after the previous update and the option is still on, set it to No and empty your thumbnail cache to bring them back.
• On the final page of the PayPal Checkout payment, the "Order" title above the order summary is now translated into the language of your shop instead of always showing the English word. The title used a text entry that did not exist in the translations, so it stayed in English on every language. It now uses the regular translated wording. Shops browsing in English were not affected.
• The PayPal Checkout buttons show again on shops that had selected the same funding source (for example the credit or debit cards) both in the list of funding sources to display and in the list of funding sources to hide in the payment method settings. PayPal refuses to draw its buttons when a funding source is asked to be shown and hidden at the same time, so none of the buttons appeared. HikaShop now keeps such a source hidden and no longer sends the contradiction to PayPal, so the buttons display normally. Shops that did not select the same source in both lists were not affected.
• On the product page, the main image again changes when the visitor moves the mouse over the thumbnails on high resolution (Retina) screens. To stay sharp on those screens the images are served in a higher resolution version, and that higher resolution version kept the first picture on screen, so on Retina screens the main image looked frozen when hovering the other thumbnails while it worked normally on standard screens. Hovering a thumbnail now always updates the main image to that picture.