HikaShop 6.6 change log

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.