[Skip to main content](#vessel-content)

☰ Documentation

#  HikaShop 6.7 change log

Details    Written by: Administrator    Category: [Global informations](/support/documentation/hikashop/global-informations)     Published: 25 October 2026     Hits: 58

All the HikaShop 6.7 releases. The latest version and the list of all the versions are on the [HikaShop Change Log](/support/documentation/56-hikashop-changelog.html) page.

### HikaShop 6.7.1

**Release date : October, 20 2026**

#### Improvements (4)

- The web cron of hikashop.com is set up from the Cron tab of the HikaShop configuration itself: "Show the web cron" displays whether it runs, its frequency, its next and last run and its last report, and you can switch it on or off and change its frequency there. A website not yet attached to your subscription gets a link to attach it on hikashop.com. Before, the "Create/Edit your Cron task" button opened a page of hikashop.com in a popup, which browsers refused to display or which asked you to log in on hikashop.com without keeping the login.
- The Bambora (Beanstream) payment plugin now sends the customer to the Shift4 payment page (checkout.bam.shift4api.net), the new address of the Bambora hosted checkout. The former address stops working on December 31, 2026, so update before that date. Your Bambora account, merchant id and hash key stay the same.
- On Joomla, when HikaShop was updated without its install script running to its end, as an update made by a remote site manager or files uploaded by FTP can leave it, the first page loading HikaShop now finishes the update of the database. Before, the tables stayed as they were and the frontend pages failed with an "Unknown column" error, such as "Unknown column b.product\_hidden\_languages" on the product listings after an update to 6.7.0, until the "Check database" button of the configuration was used.
- The shipping methods of the checkout now refresh when a guest, or a customer registering during the checkout, changes the country, state, city or postal code of the address in the registration form, as they already did for the address of a logged in customer, and they follow the "Same address for shipping" checkbox. Before, they only refreshed once the registration was submitted. It needs the "Dynamic address refresh" setting of the shipping block of the checkout, which is on by default.

#### Bug fixes (25)

- The "None" choice of the lists in the settings of the Google Products plugin now reads "None". Before, it showed HIKASHOP\_NONE.
- Security hardening in several areas, updating is recommended.
- The payment plugins which check each notification of their payment service with a secret key, a password or a hash (Alipay, AtosSIPS, Beanstream, BluePaid, Borgun, CardSave, ePay, Monetico, Moneybookers, Ogone, PayGate, PayPal Advanced, PayU India, PostFinance, Servired and others) now refuse every notification while that setting is empty on the payment method, so no order can be confirmed by a message that cannot be verified. Before, the empty setting was used as the secret.
- The Authorize.Net payment plugin now refuses every notification while neither a signature key nor an MD5 hash is set on the payment method, and tells you by email. Before, the notification was checked against a value anyone could compute from the login id of the account, so it could confirm an unpaid order.
- With the Bambora (Beanstream) payment plugin, a notification announcing an amount different from the order total is now refused and written to the log, and the order keeps its status. Before, it moved the order to your invalid status, which could cancel an order which was already paid.
- The CardSave and PostFinance payment plugins now leave the order as it is and email the merchant when a notification carries an amount or a currency that differs from the order. Before, they cancelled the order. The PostFinance, Monetico and AtosSIPS plugins also now check the amount and the currency of the notification against the order, which some of them did not do.
- A PostFinance notification which is not signed, or whose signature is wrong, now only warns the merchant by email. Before, it cancelled the pending order it named.
- In a report with the Table display, a "Taxes" row now gives all the taxes of the orders: those of the products, the shipping and the payment fee, minus the tax taken off by the coupon, so that it matches the order totals and the sales with and without taxes. A "Sales" row without taxes nor shipping but with the coupon now deducts the coupon once per order and without its tax. Before, the "Taxes" row only added the taxes of the products before the coupon, and that "Sales" row deducted the coupon with its tax once per product of the order.
- A row of a report with the Table display now counts the orders of every status when "All" is selected in its order statuses. Before, such a row always gave 0.
- A HikaShop content module showing categories, with the brands category (or one brand) as its main category, now lists the brands. Before, since the main category setting accepts several categories (6.6.0), such a module listed the categories of the root of the shop instead (product category, taxation category, order status...).
- The suggestions of a text filter shown on a product page (a filter module in the header, for example) now list the products of the whole shop, as on the other pages, and so do those of a filter module sending its search to another menu item when it is shown on a category listing. Before, on a product page they only listed the products of the category whose id happened to be the id of the product shown, so most products could no longer be suggested there, and on a category listing they only listed the products of that category while the search itself looked in the whole menu item.
- A product suggestion of a text filter (the "cards" style) now opens the product at the first click, however long the mouse button is held, and pressing Enter in a text filter set to "Submit on click" now applies the typed text at the first press, also on the product listing itself and when the suggestions had not appeared yet. Before, holding the button a little sent the search instead of opening the product, or closed the suggestions without opening it, and Enter could do nothing visible or open the suggestions, so a second click or a second Enter was needed.
- On Joomla 6.2 and newer, the checkout opened without a menu item in its address, such as /component/hikashop/checkout reached from an old add to cart link, now redirects to the menu item set in "Force a menu on the checkout". Before, it ended on a 500 error "A key is required" as soon as the cart had a product. The same check now protects the language associations of HikaShop's pages.
- A text filter set to "Submit on click" in the filters shown above a product listing now keeps what the customer types, the cursor and the suggestions while the listing refreshes as they type, and a text filter of a filter module now refreshes the listing even when the listing shows the same filter above its products. Before, the field of the listing was rebuilt after the first letter, the following letters and the suggestions were lost, and the module did not refresh the listing in that case.
- In a filter module whose Filter button is hidden, pressing Enter in a text filter while its suggestions are open now applies the typed text and opens the results, like the button would. Before, Enter only closed the suggestions and nothing was searched.
- The name of an Australia Post v2 service in the order emails, the order pages and the backend now follows the language override of its key followed by \_NAME (for example AUS\_PARCEL\_REGULAR\_NAME), the same key as on the checkout. Before, those pages always showed the plugin's English name, such as "Parcel Post (your own packaging)", whatever the overrides.
- A listing with a price filter and a filter whose conditions contain a sub-query, such as a dates filter, now shows the products. Before, the price filter's query changed every WHERE of the filter's SQL, including the ones of the sub-query, and the page ended on a "Subquery returns more than 1 row" error.
- The "Back" and "Check database" buttons of the page showing the result of the database check now work. Before, clicking them did nothing.
- After an update of HikaShop, the translations of the shop are downloaded for the new version as soon as a HikaShop page of the backend is opened. Before, they were only downloaded at the next login, so emails and settings kept showing the new texts in English until then.
- With the "Generate WebP images" (or AVIF) setting on, two images with the same name and different extensions, such as c1.jpg on one product and c1.png on another, now each get their own WebP and AVIF copy, named after the whole name of the image (c1.jpg.webp, c1.png.webp). Before, both used the same c1.webp copy, so the two products showed the same picture, the one of the image whose thumbnails were made last.
- Saving a variant, or the product while a variant is open, at the moment its description editor (JCE, for example) is still loading now keeps the description of the variant. Before, the description could be replaced by the word "undefined", which then showed on the product page instead of the description.
- An account created at the checkout, from the registration form or from the page offered after a guest checkout now gets a customer of its own in HikaShop. Before, it took over the guest orders placed with the same email address, and the orders of a deleted account which had that address, so whoever registered with someone else's email address saw those orders and their addresses.
- The account created from the page offered after a guest checkout now gets the order of that page, and it waits for the confirmation of its email address when the Joomla user activation asks for one. Before, it was active at once and the order stayed on the guest customer.
- A guest order opened, paid or cancelled without the link of its email now goes to the login page. Before, the page showed an error.
- With WebMCP turned on in the UCP plugin, the commerce endpoints now only accept the browser requests made from a page of the shop by the visitor themselves, and still ask the API key from everything else. Before, turning WebMCP on also let other clients use them without the API key. Updating is recommended if you use WebMCP.

### HikaShop 6.7.0

**Release date : October, 10 2026**

#### New features (58)

- The translation popup of a product has a new "Hide in this language" checkbox. A product hidden in a language is left out of the product listings and the Joomla Smart Search results in that language, cannot be added to the cart there and its page answers "Product not found" (404); a product already in a cart is not shown while the customer browses in that language and comes back in the others. Before, a product was shown in every language of the website.
- The PayPal Checkout payment plugin now uses the new version of PayPal's JavaScript SDK (v6) on the payment page, for the express checkout buttons and for the Pay Later messages. The credit card form, Google Pay, Apple Pay and the local payment methods (Bancontact, iDEAL, eps, Przelewy24, BLIK, Multibanco, Trustly, MyBank, SEPA) are still offered, and new local methods can be offered: Satispay, Bizum, TWINT, Wero, Verkkopankki, Klarna, Scalapay, Floa, Paysafecard and Skrill, once PayPal has activated them on your account. Each local method only shows to the customers PayPal accepts it for. The "Slogan" setting is gone, as the new PayPal buttons have none, and Mercado Pago is no longer offered.
- The one page checkout of a product page menu item can now keep a cart of its own, with the new "Cart used" setting of its "One page checkout" tab. With "Its own cart", the default, the page sells only the product it displays, and what the customer orders there stays apart from the cart they filled elsewhere on your shop, which is still there after the order. With "The cart of the shop", the product of the page goes into that cart and the customer orders everything it contains.
- When a customer creates an account on the login block of the checkout and your shop activates new accounts without an activation email, the block now confirms that the account was created and invites the customer to continue with the order. Before, the registration form simply disappeared, leaving the customer to guess whether it had worked.
- A mass action can now run at the times you choose with its new Scheduled trigger: every N minutes, hours, days, weeks or months, at a time of day, on some days of the week or on a day of the month. Two mass actions can run every day at 2:00 and at 3:00.
- Under a Scheduled trigger, the mass action form shows its next run, and warns when the HikaShop cron has never run, has stopped, or runs too rarely for the time chosen, with a link to the cron settings.
- Mass actions can now work on the discounts and coupons: filter them on their columns, on the products, categories and customers they are restricted to or on the orders which used them, then display, export, import, update or delete them.
- The listing of the discounts and coupons has the Actions button of the other listings, and the buttons of the mass actions on discounts saved with "Actions as a button".
- A mass action on the orders or the customers can now create a coupon for each of them, copied from a coupon of the shop, with a code made from a pattern, restricted to that customer and valid for a number of days. A "Send an email" action after it can give the code to the customer with the tag {coupon.discount\_code}.
- The "send an email" action of a mass action can now send one email to each element instead of one email for the whole set, with its new "Send one email" setting. An email sent for the whole set behaves as before.
- The address *element.email* in the To field of the "send an email" action (*user.user\_email* works as well) sends each email to the customer the element belongs to: the customer of the order, the customer themselves, or the owner of the address. The subject and the message are written for each element in turn, so tags such as {order\_number} carry the value of the element the email is about.
- An email sent by a mass action to a customer is written in their language: the language of the order, else the language of their account on the website, else the default language of the website.
- On the orders, the "send an email" action can send one of the order emails of the shop instead of its own: the order status notification, the order notification or the order creation notification, built and translated as HikaShop builds them, and sent to the customer of each order. Its own email can use any email template of the shop, chosen on the action.
- Each email a mass action sends to the customer of an order adds a line to the history of that order, naming the email and the mass action.
- On the orders, "Send one email" can be set to "For each matching order line": each customer receives one email for each product of their order that the filters match, the variants of a product in the same email, and the columns of that line such as {order\_product\_name} can be used in the subject and the message, so the instructions of the product bought can be sent after each order.
- A mass action has a new "Only once per element" setting. With it on, the mass action runs its actions on an order, a product or a customer only the first time it matches, and remembers what it has handled, so a mass action scheduled every day stops doing the same thing to the same elements on every run. The edit form counts what has been handled and offers to forget it, which makes the mass action run on those elements again.
- Together, "Only once per element" and the "send an email" action make a follow-up email: filter the orders on the product they contain, on their status and on their date, write the message once, and each customer receives it once. The Limitations block warns when a mass action sending emails one by one has a limit above 100.
- A mass action on the categories, the customers, the orders or the addresses can now import a CSV file, as one on the products already could: the "Import from a CSV file" filter finds the rows the file names, by the name key of a category, the email address of a customer, the number of an order or the id of an address, keeps them or the other rows, and with "Save" writes the columns of the file to them.
- With "Create", a line of a CSV file naming an order or a customer which does not exist creates it, as a line naming a product already did: the order gets its number, its status and its currency from the shop when the file does not give them, and the customer is created without an account on the website. Categories and addresses are only updated.
- A mass action on the orders can now filter on the categories of the products the order contains, as one on the products already could. A product bought in one of its variants counts in the categories of the main product, which is where its categories are set.
- A mass action can now filter on a "Date picker" custom field with a value such as "now" or "-2 days", as it already could on the dates HikaShop stores itself, like the creation date of a product. It works on the date picker fields of your products, your orders, your customers and your addresses.
- For example, a date picker field lets a mass action hide products on a date of your choosing: add the field to your products, fill it on the products concerned, and run a mass action every day which unpublishes the products whose date has passed.
- A filter of a mass action which reaches a table holding several rows for one element, the products of an order, the addresses of a customer, the prices of a product, now carries a row number. Two filters carrying the same number have to be true for one and the same row, and two filters carrying different numbers may each be true for a different row. Left alone it says row 1, which is what every mass action saved until now meant.
- The email edit page has a new Design tile: the template with a live thumbnail, the hero displayed above the content (none, the title and lead sentence, the progress of the order as steps, a picture you upload, or a headline and a paragraph you write), and the blocks displayed after the content. The hero and the blocks work with every template, the old ones included.
- The blocks of the Design tile of an email can be reordered by dragging, each with a gear to set what it shows for the whole shop.
- The pen button next to the template selector now opens the template in two tabs: its settings (colors, fonts, corner radius, width, color of the social icons) with a preview of the email which follows the values as you change them, and its code.
- Saving a template from the pen button writes your copy of it, kept through the updates of HikaShop, and the page says whether you are looking at the shipped file or at your copy. A reset button deletes the copy after a confirmation, and a "Save as" field creates a template of your own from it.
- A "Choose a template" button next to the template selector of each email opens a gallery of the templates: each card is a live preview of that email with one of the templates, with your logo, your colors and your latest order or user, so you see what your customer would get before you pick one.
- The social plugin has a new "Follow us" tab where you can enter the pages of your shop on Facebook, Instagram, X, Pinterest, LinkedIn, YouTube, TikTok, Mastodon and Bluesky. The new email templates display them in their footer, with their icons.
- Two new email templates, "clean" and "bold", can be selected for each email of the Emails page. They adapt to the screen of a phone, follow the dark mode of the reader, and display the logo of the "Your logo URL" setting of the configuration.
- The "bold" email template places a hero above the content: the title and the lead sentence of the email with a button to the order, the progress of the order as steps, or a picture, chosen in the settings block at the top of the template file, where the colors and the fonts are also set.
- "clean" is the email template of every email on a new install of HikaShop; the shops which already have HikaShop keep their template until they select a new one.
- The emails can insert blocks with a {BLOCK:name} tag: boxes with the email address, the phone and the address of the shop, products related to the ones ordered, a promotional message with a button, and the social networks of the shop. The order emails come with the contact and related products blocks after the order details, and extensions can offer their own blocks.
- The Google Products plugin can now also generate a product reviews feed, so the ratings and comments your customers leave on your products are sent to Google Merchant Center and displayed with your products on Google Shopping. It is turned on by entering a file path in the new "Product reviews XML file path" setting, and the file is written on every cron pass next to your product feed, with a button to download it and check its content.
- The product reviews feed of the Google Products plugin covers the same products as your product feed and carries the same identifiers, so Google matches each review to the right product. A review left by a customer who bought the product is sent as a verified purchase, checked against your orders review by review, whether or not your shop restricts reviews to buyers.
- Only the reviews which have both a rating and a text are sent in the product reviews feed, as Google requires both, and Google starts displaying product ratings once your feed contains at least 50 reviews.
- The withdrawal requests of your customers can now be handled from start to finish in HikaShop. Orders > Withdrawals shows, for each request, what the products asked back are worth, the day it reached you and the day the refund is due, with the late ones in red and a filter to see only those.
- Opening a withdrawal request gives you a status to set, a text for the customer which is sent with your decision, notes of your own which are never sent, and a button which returns the quantities asked back to the stock of your products. The refund stays where the money is, on your gateway, and the order keeps its total and its invoice.
- Saving a new status on a withdrawal request now emails the customer, with the text following your decision, accepted, refused, or refund sent, and carrying what you wrote for them, under a "Why" heading when you refuse. A tick box on the request lets you save a status without writing to the customer.
- The Customers listing can now show what each customer has spent and sort them by it, with two new columns, "Total spent" and "Total spent without tax", available through the columns button at the top of the listing and hidden until you ask for them.
- The "Total spent" columns of the Customers listing count the orders in the statuses ticked in the Statistics column of the Order Statuses page, the same list your dashboard counts, and follow your orders on their own: an order confirmed adds to them and an order refunded or cancelled takes itself back off. Amounts are in the currency of your shop, converted with the rate of the day each order was placed.
- On a shop which already has orders, run Configuration > Check database once for the "Total spent" figures to be worked out for every customer.
- The UCP plugin now speaks the 2026-08-25 version of the Universal Commerce Protocol, the version behind Google's Universal Cart and the current AI shopping agents: the discovery profile, the checkout responses and the errors follow the new formats. The plugin tests folder has a conformance harness validating every answer against the official UCP schemas.
- The catalog of the UCP plugin has search, lookup and product endpoints, with the variants and options of the products; a shipping choice and a discount code go through the fulfillment and discount extensions, and each payment method able to hand the buyer a hosted checkout page is offered to the agents as a payment handler.
- The UCP plugin now authenticates the AI platforms by the signature of their requests (HTTP Message Signatures with the keys they publish in their profile, with a "Trusted platform profiles" setting to restrict them), and signs its own answers with a key it generates and publishes in the discovery profile.
- The UCP plugin exposes the orders placed through UCP to the platform that placed them, and sends a signed webhook with the order to that platform each time the status of the order changes.
- The UCP plugin now offers the cart capability of the protocol: AI agents can build a basket without payment (create, read, replace, cancel), get estimated totals for it, and turn it into a checkout session later; the same basket stays readable while the checkout goes on.
- The UCP plugin supports the AP2 mandates of the Agent Payments Protocol, the payment layer of Google's Universal Cart: with a platform that uses them, each checkout answer is signed by the shop and an order is only created against a checkout mandate the platform issued for that exact checkout after the customer consented.
- The UCP plugin handles 3-D Secure with the AI platforms through the payment authentication extension of the protocol: a card payment that needs a challenge (or a device data collection step) is accepted, and the platform is given a page of your store to display to the customer, which loads the gateway's step and reports back once your store has settled the payment. A platform without the extension still receives a link to hand the customer over.
- A plugin can now change the user groups the shop reads when it filters your products and your categories by access, through the new onHikashopAclGroups event. The Domains plugin uses it to keep the products of one domain name off the others on a shop served on several of them.
- A plugin can now decide which cart HikaShop loads for the visitor, through the new onBeforeCartIdLoad event. The Domains plugin uses it to give each domain a cart of its own, where HikaShop otherwise finds the cart from the session of the visitor and from their account.
- A plugin can now add its own content inside the main image of the product page, through the new galleryMain display area of the product image layout. The 3D product display plugin uses it to display a 3D model of your product in the image gallery, in the place the photo would take.
- An extension can now put a table of its own next to the results of a mass action, so that its columns can be displayed and exported with them, by registering where the rows are and which column holds the element they belong to. The HikaSerial columns plugin, which adds the serials of an order, is now that one registration.
- The custom fields area of the product, variant, category and customer edit forms now has an "Add a new field" button. It opens the form of a new custom field in a popup, for the table of that form, and once the field is saved its input shows in the form right away, ready to be filled, without leaving the page or losing what was typed in it.
- Customers can now save their card with the PayPal Checkout payment plugin: a "Save this card for my next purchases" box under the card form, then their saved cards above it on their next payments, with 3D Secure when the bank asks for it. A new "Payment methods" page in the customer account, shown once one is saved, lists the cards and PayPal accounts PayPal keeps for them, and removes them. PayPal keeps the cards; the website only stores PayPal's reference with the brand, last digits and expiry date. The new "Customers can save their cards" setting is off by default.
- The customers, orders and products of the connector API can now carry information and settings of other extensions, described so that a client of the API can display the information and edit the settings like your custom fields without knowing the extension behind them. The documentation of the connector API explains how an extension adds them.
- A customer read through the connector API now lists their paid downloads: each file with its order, the downloads left and the end of the download period, flagged when the period has elapsed or no download is left. The connector API can also find a customer from their exact email address, for a helpdesk matching a message to its sender.
- A payment plugin can now say how its payment provider knows the payment of an order, and other plugins can ask for it, for instance to let an accounting platform match the money it receives to the invoice: the PayPal Checkout plugin gives its PayPal order, the PayPlug plugin its PayPlug payment, also for the orders paid before this version, and the bank transfer plugin the order number the customer puts in the label of the transfer. For developers: hikashopPaymentPlugin::getPaymentReference() in a payment plugin, read with the getPaymentReference() method of the order class.

#### Improvements (85)

- The Servired (Redsys) payment plugin now sends Redsys the billing and shipping addresses, the email and the phone of the customer in the format PSD2 asks for (DS\_MERCHANT\_EMV3DS), so that the bank of the card can more often let the payment through without asking the customer to confirm it, and it can be used in any currency Redsys knows, the currencies the terminal accepts being listed in the new "Currencies" setting of the payment method (EUR for a new payment method, EUR and USD for the payment methods you already have). Before, only EUR and USD could be used and Redsys received no customer data.
- The Servired (Redsys) payment plugin now refunds the payment through Redsys when you move a paid order to the refunded status, cancels it when you move it to a cancelled status, and can take payments as preauthorizations, only charged when the order gets a payment capture status (shipped by default) and released when it is cancelled before. Each answer of Redsys is written in the history of the order, and a refund Redsys refuses leaves the status unchanged with its reason. New payment methods have the refunds on and the preauthorization off; the payment methods you already have keep both off until you change their "Refunds and cancellations from the backend" and "Preauthorization" settings. Before, refunds and cancellations had to be made in the Redsys administration portal and payments were always charged at once.
- The Servired (Redsys) payment plugin now also confirms an order when the customer comes back from Redsys, from the signed parameters Redsys adds to the return address once "Parámetros en las URLs" is enabled in the Redsys administration portal, so a payment is not left unconfirmed when the notification of Redsys cannot reach the shop (a firewall, a CDN). The settings of the payment method say which Redsys options to enable. Before, only the notification of Redsys could confirm the order.
- The Servired (Redsys) payment plugin can now sign its payments with Redsys's newer HMAC\_SHA512\_V2 signature, chosen with the new "Signature version" setting: new payment methods use it, and the payment methods you already have keep HMAC\_SHA256\_V1 until you change the setting. Notifications are accepted with either signature. Before, only HMAC\_SHA256\_V1 was available.
- Product listings now load their badges with one database query for the whole page, and look the category of each product up once when they build its links, instead of repeating both queries for every product: listings with many products display faster.
- The settings of the PayPal Checkout payment method now list its payment methods in one table, grouped (PayPal, cards and wallets, local payment methods, pay later) with the countries and currencies each one works with, instead of two lists of funding sources to enable and to disable. A "Check availability" button asks PayPal which methods a customer would be offered. The Merchant ID is no longer typed: it is filled in by the connection with PayPal, or from the first payment.
- A filter module collapsed behind its button can now be displayed several times on the same page, in several sections of a page builder for instance: the button of each copy opens the filters right under it. Before, every button opened the filters of the first copy of the module on the page.
- A product page menu item with the one page checkout now sells every product it is opened on, not only the product selected in it. A link to another product through that menu item, such as the links of a HikaShop module whose "Menu" setting is that menu item, opens that product with its own checkout under it, so one menu item can serve a whole category of gift certificates instead of one menu item for each of them.
- A card refused by the bank on the PayPal Checkout payment plugin now tells the customer what to do about it when the reason allows: the card has expired, it does not have enough funds, the security code or the number was refused, or too many payments were attempted. A reason only the bank of the customer can settle keeps a neutral message.
- A card payment refused by the bank on the PayPal Checkout payment plugin is now handled. When the bank refused because it wants a strong authentication, the card is sent again with the 3D Secure authentication forced, so the customer confirms the payment with their bank instead of losing their order. Any other refusal displays its reason and lets the customer pay again with another card, and the reason PayPal gives is written in the history of the order, so you can read why a payment failed without turning the debug mode on. Until now the customer was thanked for their purchase although no money had been taken, and the order was then moved to the cancelled status, because PayPal reports such an order as completed and only marks the refusal on the payment itself.
- Eleven payment plugins now carry the name their gateway is sold under today, with the old name in brackets so you still recognise it: Worldline (Ogone), Verifone (Paybox), Skrill (Moneybookers), Elavon Converge (Virtual Merchant), Windcave (Payment Express) and its PxPay plugin, Teya (Borgun), PayGate (Payfast), Worldnet (Payroc), CardSave (Worldpay) and Worldline Sips (ATOS SIPS 2.0). Before, the list of payment methods used names some of these companies dropped years ago.
- The payment plugins whose gateway has closed are removed when HikaShop updates, and are no longer installed on new shops: Atos SIPS of the first generation, HSBC ePayments, Payza, First Data Global Gateway, Be2bill and MIGS. Each one tells you on screen why it went, and which plugin to use instead where there is one. Before, a shop could offer a payment method that had no gateway left to talk to.
- USPS and FedEx shipping now comes from the plugins that speak the current APIs, and the old "usps" and "fedex" plugins are removed when HikaShop updates: USPS retired Web Tools on the 25th of January 2026 and FedEx retired its SOAP web services on the 1st of June 2026, so neither old plugin could quote a rate. The "FedEx 2" plugin is included with HikaShop; the USPS plugin is on our marketplace.
- New shops no longer install the legacy UPS, Monetico and PayPlug plugins, which speak APIs their providers have replaced, while the shops that already use them keep them working. The "UPS 2", "Monetico" and "PayPlug 2" plugins are the ones to use.
- The "Every days", "Every weeks" and other period triggers of the mass actions now keep their time from one run to the next. Before, each run started when the previous one had run, so with a cron called every 15 minutes a daily mass action started up to 15 minutes later every day.
- The forms of the mass action triggers, filters and actions are laid out the same way: a label for each field, the field, and a short hint under it.
- The message of the "send an email" action of a mass action is a large field with an "Insert a tag" list offering the columns of the element, of its order line and of a coupon created before it, and the action shows its fields only for the choices they apply to.
- Display the results and the export of a mass action name the table of each box of columns, and a search field finds a column in all of them.
- Update the values offers its kinds of value in words, a whole number, a decimal number, a text or a calculation, and explains how to write a calculation.
- Deleting the elements warns that they cannot be restored, and the SQL query and PHP code actions say what they can use and that only a Super User may save them.
- A single "Sort by" filter chooses the column and the direction of a mass action. The Ordering and Ordering direction filters of the mass actions saved before still show and run.
- The limit of a mass action reads as a sentence, "Take 500 elements, starting after the first 0".
- The row list of a column filter is named and explained, and shown only once two filters look at the rows of the same table.
- Send an HTTP request shows the fields of its authentication and its body only when they apply, and its long explanations, like those of the HTTP trigger, fold under each field. The warning about a public endpoint shows as soon as public is chosen.
- The import from a CSV file filter lays out which elements it keeps, the file and its checks in labelled rows.
- The create a coupon action always copies a coupon of the shop, and says so when the shop has none.
- The Actions popup of the listings opens wider, at 1300 pixels, and no longer offers the cancel operation action, which only means something in a trigger.
- The styles of the mass actions are in a stylesheet of their own, loaded only on the pages using them, so a backend CSS setting pointing to a copy of an older backend\_default.css keeps the new forms styled.
- The HikaShop mass action system plugin, which Joomla and WordPress load on every page, now only holds what has to run on every page: the scheduled mass actions, and recognising a request addressed to the MCP server or to one of the HTTP endpoints of your mass actions, whose addresses it keeps in the cache. The edit form, the editing of the results and the endpoints are loaded when they are used.
- Every filter and every action of the mass actions of HikaShop is now written once for all the tables, in the registers a plugin extends through onMassactionTypeLoad, onMassactionActionLoad and onMassactionTriggerLoad. A table declares how its column filters run, which columns hold a date, what its export adds, the events of its rows that can trigger a mass action (events) and how a cell of the results listing is saved (cells).
- The mass action events onMassactionTableTriggersLoad, onSaveEditionSquareMassAction, onLoadResultMassActionAfterEdition and onReloadPageMassActionAfterEdition are no longer sent, and the filter classes are now named hikashopMassactionFilter...Helper, in helpers/massaction/filter.
- The product, category, order, customer and address mass action plugins no longer answer the per-table events such as onProcessOrderMassFilterorderColumn or onProcessProductMassActionexportCsv: a plugin which called one of them to reuse a filter or an action of HikaShop should ask the register instead. A filter or an action nobody registered is still sent to those events, so a plugin adding its own keeps working.
- HikaShop is ready for PHP 8.6. That version deprecates ending a constructor with a return, which twenty nine classes of HikaShop and of its payment and shipping plugins did, and a shop running it with the notices displayed would have had them printed on its pages. Nothing changes for the PHP versions you run today.
- An order which has a withdrawal request now says so at the top of its page, with a link to the request, and every step of the request is written in the history of the order: the request itself when the customer makes it, your decision, and the return to stock.
- The reason a customer gives for their withdrawal is no longer writable in the backend: it is their statement, and the only writable field of the screen used to overwrite it. The two new fields, the reason given to the customer and your own notes, are where you write instead.
- A withdrawal request now says how the person asking proved who they were: from their account, where HikaShop checked the order belongs to them, or through the withdrawal form, where they gave the order number and the email address of the order.
- A new configuration setting holds the number of days you have to refund a withdrawal, 14 by default, which is what the due date of each request is counted from. It is separate from the withdrawal window, which is the time your customer has to ask.
- On WordPress, a plugin can offer a setting whose choices it works out itself, as the PDF invoice plugin now does for its fonts; the settings page showed a text box for such a setting.
- The canonical URL a product page names is now the address of the product itself, under the menu item pinned to it or to its closest parent category, rather than the address of the page it happened to be generated on, as the category listings already did.
- A product reachable from several menu items used to produce a different canonical URL under each of them, and with the setting on "Use canonical URL and generate it if missing" whichever page was displayed first had its address saved on the product and served to everyone afterwards.
- On a multilingual shop each language now names its own canonical URL, written as a translation of the "Canonical URL" field the first time that language displays the page, in your translation system or in Falang depending on which one your website uses. The first language to display a page used to decide the address every other language named.
- Emptying the "Canonical URL" field of a product or a category removes its translations along with it, from the edit page or with the "Update canonical" mass action, so emptying the field is still all you have to do when your menus change.
- A menu item of the "Products listing" type names a canonical URL of its own now, built from the category it is pinned to and from the menu item covering that category. It could only use one that a category listing page had already saved, so on a shop where none had been saved it named no address at all.
- Each page of a listing names its own address as its canonical URL, for the categories and for the products, and both when the two are paginated at once. The second and every later page of products under a categories listing named the first page, so the products only shown further down were not indexed.
- A category listing fills in its canonical URL on its own now, under the "Force canonical URLs on listings" setting which already did it for the products. The address it names is the category's own, with the menu item pinned to that category or to its closest parent, so a listing browsed from two different menu items still names a single page.
- A product page which has no canonical URL of its own now names the address of the product rather than the address the visitor arrived at, so a link written by hand or an address invented by a crawler no longer has the page name itself.
- The "Cancel Order" button is now also on the order page of your customer account, next to the invoice and the contact buttons. It asks for a confirmation, does the same thing as the one in the Actions menu of the orders listing, and is displayed for the statuses of the "Cancellable" column of the Order Statuses page, as before.
- The product feed of the Google Products plugin now carries the weight of the products weighed in decagrams or in tonnes, converted to a unit Google accepts. Those products were sent without a weight at all, which Google reports as a missing shipping weight.
- The weight of your products is now part of the structured data of your product pages, so Google reads it with the rest of the product and Merchant Center stops reporting it as missing. A product weighed in milligrams, decagrams, tonnes or troy ounces is converted to kilograms.
- In the structured data of the product pages, a product with no weight is sent without one, as before, and each variant carries its own weight, falling back to the weight of the main product when it has none of its own.
- The preview card of the products listing of your backend now tells you at a glance which of your characteristic values can still be bought: each value is written in green when every variant using it is on sale, in red and crossed out when none of them is, and in orange when only some of them are. A variant counts as on sale when it is published, in stock, and within its sale dates.
- The Smart Search plugin of HikaShop now names your products in the language of your website: the "Search by Type" list of the advanced search of Joomla displays "Products", and "Produits" in French, where it displayed "Product" in English whatever the language. Any other wording can be set with a language override on the PLG\_FINDER\_QUERY\_FILTER\_BRANCH\_P\_PRODUCT key, and the vendors of HikaMarket are named the same way.
- A plugin of HikaShop can now put its stylesheets and its scripts in the media folder of the website, which is where Joomla asks an extension to put them, and have them work on WordPress as well. The 3D product display plugin is the first to need this.
- On WordPress, the installer of the plugins now copies the whole folders a plugin declares, the address a plugin builds to its media folder points at a folder which exists, and a plugin asking HikaShop for its own translations is displayed with its text instead of its key names.
- The hero of an email is only offered for the templates which have a place to put one. A template written before the hero existed, one you wrote yourself, or one that comes with an add-on such as HikaMarket, has no such place, and the choice was displayed without having any effect.
- The text version of the emails is now built from the HTML version when the email is sent, for the email clients which do not display HTML, instead of being maintained as a separate file. The text editor of the email edit page is replaced by a preview of that text; a text version written by hand for an email is still used when it exists.
- The text version of an email draws the summary of the order as a real table: the columns are as wide as what they hold, separated by pipes and underlined under their titles, and a product name too long for its column is wrapped inside it. The addresses of the products are left out of the table, since they would take more room than the table itself.
- Everywhere else in the text version of an email, the cells of a row are separated by tabs, headings and paragraphs are on their own lines, list items start with a dash, links are followed by their address, and nothing is left of the parts which only make sense in HTML.
- The HTML version of an email on the email edit page is presented in two tabs, the view builder and the code, and the view builder lists every block of the new order emails.
- The list of the available tags of the email edit page opens in a window of its own, where every tag is readable at once; clicking one copies it, closes the window and puts the cursor back in the editor so you can paste it.
- The rules of the stylesheet of an email are now also written on the elements themselves before the email is sent, for the email clients which drop the stylesheet, such as the Gmail application when it reads a mailbox which is not a Google one. The stylesheet stays for the others, and a template you wrote yourself benefits from it too.
- The order emails (order creation, order status, order notification, payment notification and admin notification) and the three emails of the withdrawal requests have been rewritten: larger text, the content in a white card, the product thumbnails placed next to the product names instead of floating above them, and addresses which keep their label with them on a phone. They render with the templates you already have as well as with the new ones.
- The stylesheet of an email template is now written in the head of the email, so Gmail applies it. Gmail ignores a stylesheet placed in the body, where the templates put it until now, so the colors, the buttons and the responsive rules were lost for the customers reading their emails in Gmail.
- The line the inbox displays under the subject of an email is now the lead sentence of that email, such as "We are pleased to confirm the creation of your order No. 1234", instead of "If you don't see this email properly, click here to see your order details". That link moved to the footer of the email with the new templates.
- The emails carry the language they are written in, for the screen readers and the email clients which use it.
- The payment log file of HikaShop now says why the "payment notification" email was not sent when it is not: the "Payment notifications email address" setting is empty, which is the most common reason, a payment plugin asked for no notification, or the email could not be built for the order. Nothing is written unless the "Payment log file" setting names a file.
- The payment log file also says when an email is not sent because it is unpublished, whether in the System > Emails page or by a plugin of your site. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- The two settings of the filter edition form both named "Category" 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. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- On the affiliate program page, the main information of the partner, the activation of their account, the email address where they are paid and their currency, is now at the bottom of the page, under their affiliate link tools and your banners. A partner who has not activated the program yet still finds it at the top. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- When the PayPal Checkout payment page cannot load the script of PayPal, the message it displays now also names the Content-Security-Policy of your website as a possible cause, where it only pointed at the cookie consent and javascript optimization extensions of the browser.
- The order summary and the credit card form of the PayPal Checkout payment page now follow the colors of your template, their titles included, instead of being drawn on a fixed light grey panel which stood out as a white block on a dark template. On a light template, the page looks the same as before.
- The title of the quantity column of the cart of the checkout stays on one line, where a template cutting long words could split it over two lines on one product and not on another.
- The trees of the backend (the category explorer, the access levels, the category selection popups) are drawn with vector graphics instead of small images, so they stay sharp on high resolution screens, follow the dark mode, and their controls are real buttons for the keyboard and screen readers. Each shape is drawn once per page, so a shop with a deep category tree does not pay for the drawing on every row.
- The "Geographic sales" map of the dashboard now places an order without a shipping address, like the orders of downloads and other virtual products, in the country of its billing address. It used to leave these orders out, so a shop selling only virtual products saw an empty map.
- The withdrawal form can now show a captcha to the customers who are not logged in, with the new "Use in withdrawal forms" setting of the HikaShop ReCaptcha plugin and of the HikaShop captcha integration plugin. The captcha is checked before the order number and the email address, so the form can no longer be used to try order numbers one after the other.
- The blocks of the withdrawal form (title, button, order, products, email address, order number, reason) can now be moved and hidden by drag and drop in the view editor, as on the other forms of the frontend.
- A download whose period has elapsed, or whose number of downloads is used up, is now marked with an orange label on the order page and on the downloads page of the customer, instead of a plain line of text easy to miss next to the file name.
- When you create a menu item, the menu item types of the legacy checkout no longer appear, and its code is removed: no shop could reach it since HikaShop 4.4.0. Menu items and links made for it, with task=step or layout=step for example, still open the current checkout.
- The terms and conditions article and its popup size, the image of the products in the cart and the address selector of the checkout are now set only in the blocks of the checkout workflow, and the delete button of the cart page is always displayed. They also came from settings of the configuration hidden since the legacy checkout: when HikaShop updates, a value you had changed there is copied into the blocks that used it, then these settings are removed.
- The payment page of the PayPal Checkout payment plugin now tells the customer when the order starts a subscription: how often it renews, the date of the next charge, and that the PayPal account or the card used will be charged automatically for each renewal until the subscription is cancelled. It also only offers the payment methods which can be charged again, PayPal and cards, leaving out Pay Later, Google Pay, Apple Pay and the local payment methods. The page looked like the one of a single payment before.
- The geolocation plugin's bundled IP2Location.io library was updated to its latest version.
- The QuickBooks Online Accounting plugin now ships version 6.3.1 of the quickbooks/v3-php-sdk library it bundles, instead of 6.0.3.
- The "Import from HikaShop" screen now lets you choose what to import: configuration, custom fields, zones and taxes, shipping and payment methods, the catalog (categories, products, variants, prices, images and files), users and addresses, coupons and limits, orders. You can bring only the catalog into a shop already set up, without replacing its settings or adding its shipping and payment methods again. Before, the import always brought everything, configuration included.
- On a phone or a small screen, the products of an order in the backend are now shown as cards, one per product, with the image, the name and the code at the top, the unit price, the quantity, the price and the other columns each with its label, then the action buttons. Before, the table went past the edge of the screen and the product name and unit price columns were hidden.
- The HikaBitcoin payment plugin is removed when HikaShop updates, and HikaShop tells you so once. It used the first API of BitPay, which no longer gives keys for it, and it could not confirm the orders paid with it. It had not been part of the HikaShop installation packages for years.

#### Bug fixes (164)

- The payment notifications and the order lists of the Community Builder and JomSocial plugins now name the order statuses from the Order Statuses page, custom statuses included, translated as everywhere else in HikaShop. Before, they used the old order status categories, which missed the statuses created since HikaShop 3, and on a site using Falang the payment notification could stop on the SQL error "1064 ... near ')' at line 1", leaving the paid order in "created" and showing the error to the customer coming back from the payment page.
- The Google Products plugin now links each product of its feeds to the address its page gives as canonical, the one search engines index, when the product has no canonical URL of its own and the "Force canonical URLs" setting is on. Before, such a product was linked as index.php?option=com\_hikashop&ctrl=product&task=show&cid=...
- The Google Products plugin now writes a product's description in the feed as the text a shopper reads: the styles and scripts a description holds are left out, its HTML entities decoded and its spacing tidied. Before, the CSS of a description's style block came first in the feed, ahead of its text.
- When no notification plugin handles the add to wishlist, the customer is now sent to their wishlists, under the current menu item. Before, they were sent to a product listing with no menu item (/component/hikashop/product/listing), an address written on every page that search engines could crawl.
- The Servired (Redsys) payment plugin now opens the Redsys payment page in the language of the customer, lets a customer pay again an order whose first payment attempt failed or was abandoned, and only confirms an order when the notification comes from the merchant code and terminal of the payment method with the amount and currency of the order, without changing an order already paid. Before, the payment page was always in English, Redsys refused a second attempt on the same order (SIS0051), the amount and the terminal of a notification were not checked, a late refusal could cancel a paid order, and the "card + iUpay" choice, a service closed since, was offered instead of Google Pay and Apple Pay.
- With Joomla's "Strict routing" option of the System - SEF plugin, a shop page opened with ad or campaign tracking parameters (utm\_source, gclid, gbraid, wbraid, fbclid, msclkid, \_gl, srsltid...) now keeps them in the query string, and cookie values never end up in the address. Before, the page was redirected to an address where each parameter became a part of the path (/utm\_source-facebook), so the tracking data was lost and some of these addresses answered a 404, and on servers where PHP's request\_order is empty the cookies, the session cookie included, were added to that address too.
- On a product page reached from a category listing menu item, the categories of the breadcrumb now link to that menu item, and when the product is in several categories the breadcrumb follows the one under the menu item's main category. Before, since 6.6.0, they linked to the first category listing menu item of the website, which could show another listing or none, and the breadcrumb could show the path of a category outside the menu item.
- In the breadcrumb of a product page, a category now links to the products listing menu item set to show it, or to the one of its parent category, when there is no closer category listing menu item, and each category of the path gets its own menu item. Before, they all linked to the first category listing menu item of the website, which could show another listing or none.
- The admin payment notification email now carries the detailed message a payment plugin built for it, the hash mismatch details of the Authorize.net plugin included, for a plugin which calls modifyOrder on an order which already has an id: the offline credit card, the purchase order, Authorize.net, Cardsave, MIGS, FirstData, iVeri, iPay DNA, eWay, eSelect, PayJunction, PayPal Pro, PayTR, Innovative Gateway and the Stripe Connect marketplace plugin. Before, only the generic order status change text was sent and the plugin's message was silently dropped.
- The Authorize.net payment plugin's debug log, when a notification's hash does not match, now also writes the hash it calculated, next to the string it was calculated from. Before, the calculated hash could only be read from the admin notification email, which the previous bug could also prevent from carrying it.
- The "Create order" button of a cart in the backend now keeps the automatic coupon of the customer when that coupon is restricted to some user groups or customers: the coupon is checked for the customer of the cart. Before, it was checked for the administrator creating the order, so the order was often created without the discount the customer saw on the checkout.
- The filter module refreshes the products and filters again each time a filter is changed or reset when your template overrides the filter layout of the module with a copy made before HikaShop 6.6.0. Before, only the first change worked and the following ones, the reset button included, did nothing.
- The link to an order in the emails, for instance in the status email sent when a payment is confirmed, now opens the orders page of your menu, or else the customer area, whatever the options of that menu item. Before, a link sent while the payment service notified your shop opened the first HikaShop page of your menu, often a product listing.
- On Joomla, the PayPal window of PayPal Checkout now reaches PayPal's pages from the payment page and from the express checkout button. It could stay stuck on its loading page, because the security headers Joomla sends by default (Cross-Origin-Opener-Policy set to same-origin) cut the link between the shop and the PayPal window: these pages now send same-origin-allow-popups instead.
- Google Pay and Apple Pay payments with the PayPal Checkout payment plugin now go through when the plugin captures the payments. PayPal refused them with a validation error, because the order was created with an instruction to complete itself on approval, which PayPal only accepts for the local bank payment methods.
- A PayPal Checkout payment which PayPal has not settled yet (an eCheck, or a payment under review) now puts the order in the pending status of the payment method. The order was confirmed as if the money had been received.
- Capturing a payment authorized with the PayPal Checkout payment plugin, by changing the status of the order, now reauthorizes it first when the authorization has expired, and no longer displays the error "Authorization date format unknown" at each capture.
- The check of the pending PayPal Checkout payments (iDEAL, Bancontact and the other local bank payment methods) done by the HikaShop cron task now confirms the orders once PayPal has received the money. The check stopped before asking PayPal, so these orders stayed pending until you confirmed them yourself.
- On WordPress, the links which give a guest customer access to their order, in the order emails and after the payment, now open the order every time. The order key in these links could contain characters such as # or &, which cut the link short, so the order could not be found. New orders now get a key made of letters and digits only, on Joomla as on WordPress, and the key of an older order is written safely in its links.
- The Bluepaid payment method now confirms the order when Bluepaid notifies a successful payment. Since PHP 8, the notification stopped with an error and the order stayed in its created status.
- After paying with Teya (Borgun), the customer is now taken to the thank you page, or back to the checkout with the reason when the payment failed. Before, the order was updated but the customer saw an error page.
- The iPayDNA payment method now tells the customer when it does not accept the currency of the cart. Before, the checkout stopped with an error.
- The User group plugin now removes the guest checkout when the cart contains a product which adds the buyer to a user group, since a guest has no account to add. Before, the check never found such a product, and guests could buy it.
- The page of an email in the email history now lists its attachments, such as the invoice sent with an order.
- A full return sent to TaxCloud now gives each product its own TIC code, as a partial return already did. Before, every product of a full return was sent with the default TIC of the plugin.
- The Pinterest button of the HikaShop Social plugin now shares the canonical address of the product, as the other buttons do. Before, it always shared the address of the current page.
- The payment notification emails of Ogone, CardSave and PxPay now name the order status or the answer of the gateway, and the CardSave error message sent back to the gateway is complete. Before, these were left empty.
- The ePay payment method now confirms the order when ePay notifies a successful payment. Since PHP 8, the notification stopped with an error and the order stayed in its created status.
- The Skrill payment method now takes the customer to the Skrill payment page and confirms the order when Skrill notifies the payment. Since PHP 8, both stopped with an error. The "Logo" and "Hide login" settings of the payment method are now also sent to Skrill: before, the logo was never sent and the Skrill login was always hidden.
- The PayPal express button of the PayPal Checkout payment method now stays on the checkout and in the cart module when they are refreshed after a change of the cart, an add to cart from a module for instance. Before, both buttons disappeared until the page was reloaded, because each refresh loaded the PayPal library again.
- The "Proceed to checkout" button of the cart module now opens the checkout of the cart on a product page with the one page checkout, and after an add to cart from a link through such a page. Before, it went back to the product page, since that menu item displays its own checkout instead.
- The one page checkout of a product page now orders the product of the page when the customer already has something in their cart. On 6.6.0, the checkout under the product listed only what was already in the cart, and a customer who did not touch the quantity of the product ordered the rest of their cart without it.
- The one page checkout of a product page now stays on its own menu item when the "Force a menu on the checkout" setting of the configuration is used. Before, its order button sent the customer to the menu item of that setting, which does not know the checkout of the product page.
- A YouTube, Vimeo or Dailymotion video added to the images of a product now plays on the product page when the "Force size" option of the images is off and the main image is larger than the video thumbnail. Before, only the thumbnail was shown there, with a broken image address.
- The Yes and No switches of the backend work again on Joomla 6 when the "Behaviour - Backward Compatibility 6" plugin is disabled, as on a fresh Joomla 6 website: the "Notify customer" switch of the window that opens when you change the status of an order from the orders listing, for example, can be clicked again. The script they depend on was only loaded while that plugin was enabled, so clicking them changed nothing.
- The PayPal Checkout payment page displays its payment buttons again on the shops where the cart module shows the PayPal express button. That button, like the Pay Later message, loaded a second copy of the PayPal script on the payment page, which removed the buttons of the page so that only the credit card form remained. They now use the script of the payment page, and the express button is no longer displayed there since the order already exists.
- The eye button of the password fields in the login block of the checkout now shows the password after the block has reloaded, for example after a failed login or a registration error, as it does when the page opens. It did nothing once the block had reloaded on Joomla 4 and above.
- An order paid with the Authorize.Net payment plugin in SIM mode is now confirmed when the address of the customer contains an accent or another special character. Such an order was refused with the message "Invalid notification." and moved to the cancelled status although Authorize.Net had approved the payment, because Authorize.Net builds its security hash on another character encoding than the one it sends the address back in. The plugin also writes the data it received to the payment log again when the debug mode is on, which a wrong order of the instructions had stopped it from doing.
- The "Load more" link of a product listing set to load its products as the visitor scrolls now keeps the filter values holding a special character, an accent or a space. They were put in the address of the link as they were, so such a value cut the address short and the next products came back unfiltered.
- The payment plugins now check the certificate of the payment platform before sending it a card number or trusting its answer, using the certificates your Joomla or WordPress installation already keeps up to date. Before, seventeen of them skipped that check: Authorize.Net, PayPal Express, PayPal Pro, PayPal Advanced, Ogone, eWAY, Moneris eSELECTplus, iVeri, Payment Express, PxPay, CardSave, First Data, iPayDNA, MIGS, PayGate, Virtual Merchant and Worldnet TPS, and so did the Australia Post, UPS and USPS shipping plugins. On the rare server whose certificates are all broken, the constant HIKASHOP\_CA\_BUNDLE in your configuration file can name a certificate bundle.
- The emojis written on your shop are now saved as they are: in the answer you write to a product review, in the comment a customer writes, in the name of a product or in one of your emails. They used to be replaced by a "?" while the same emoji went through in a Joomla article, because the tables of HikaShop were created with the 3 byte version of UTF8 of MySQL, which has no room for them. The update and the "Check database" button of the configuration now move the tables of HikaShop to utf8mb4, and report the ones your MySQL server refuses to convert with the query to run yourself. The emojis already turned into a "?" before that are lost and have to be written again.
- The cron of HikaShop now removes the old carts on every one of its runs. It used to also obey the "Frequency of the check for the carts" setting of the Advanced tab of your configuration, which is there to avoid running that cleaning on every page of your backend, so a cron passing shortly before that delay was over cleaned nothing and a shop whose cron and delay were close to each other, an hour for instance, only cleaned one run out of two. The pages of your backend still follow that setting as before. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- The guest checkout now goes through when a customer orders again with an email address they already used on your shop, instead of returning them to the address step without any message. On the shops whose customers table still carried the old unique index on the email address alone, which HikaShop replaced in 6.5.0 so that a guest and a registered customer can share one address, saving the returning guest did nothing at all and the checkout stopped there in silence. The database check now repairs that index, and since it also runs while you update, an affected shop is put right on its own. Should the details of a guest fail to be saved for any other reason, the checkout now displays an error rather than nothing.
- The cart, the checkout and the account pages now stay in the language the visitor is reading on WordPress with Polylang or WPML, as do the addresses of your products and categories in that language. HikaShop linked to the pages of the default language of the website, so a visit started in German finished in English as soon as the customer clicked on the cart, and the pages translated in these plugins answered nothing.
- A robot that follows an "Add to cart" link is less likely to leave a cart behind in your database. Such a request carries no cookie at all, since a robot keeps none, while a customer who browsed your shop before clicking always carries one, so HikaShop now gives that request a cookie and asks it to come back once before writing anything. A browser does that on its own, so your customers notice nothing, including one arriving straight from a link in a newsletter, while a robot which does not follow that redirection leaves nothing behind. A visitor whose browser keeps no cookie is not prevented from ordering: coming back without one, they are served exactly as before. The carts already in your database are removed by the "Cart retaining period" setting of the Advanced tab of your configuration.
- The edit form of a mass action now shows its filter when it holds a single filter saved in the first position, as a mass action created by a script or an import can. The filter was not displayed, so saving the mass action from the form removed it.
- The Actions popup of the products listing now opens at the width set for the actions popups, like those of the orders, the categories and the customers. It opened at 640 pixels, too narrow for the columns of the export and the display of results.
- A path of a CSV file which is not absolute, such as media/com\_hikashop/upload/products.csv, in the import from a CSV file filter of a mass action is now read from the folder of the website, both by the "Verify the file" button and when the mass action runs. The button showed an error page instead, and the import looked for the file in the folder the request ran from, which in the backend is the administrator folder.
- A message without HTML written in the send an email action of a mass action now keeps its line breaks. The email is HTML, so the lines ran together into one paragraph.
- A value containing a quote or a closing textarea tag, saved in a mass action form such as the subject or the message of send an email, the limit or the export path, is now shown as it was saved. It was cut short at the quote, and the closing tag broke the rest of the form.
- A value edited in the results of a mass action which cannot be saved, such as a coupon code already used by another coupon, now shows why in the cell, in words when another element already uses the value, and keeps the stored value. The cell showed a whole error page instead.
- Removing the last trigger, filter or action of a mass action and saving now removes it. The save kept the one stored before, so it came back when the mass action was opened again.
- The delete button of an argument already saved on the MCP trigger of a mass action now removes it. It looked for a row under another name and did nothing.
- On WordPress, a mass action filtering on a column of the account a customer has on the website, such as its email address or its username, now works: the column was written the way Joomla names it, which HikaShop translates for WordPress, but the translation missed a column written between backquotes, so the database refused it and the filter found nothing.
- On WordPress, each email HikaShop sends now goes to its own recipients only. The mailer was shared by all the emails sent while a page loads, and kept every address it had been given, so an email went to everyone who received an earlier one: the notification to the shop owner after an order also went to the customer, and a mass action sending an email to each customer sent each one to all the customers before it.
- On WordPress, a mass action on the customers filtering on a column which the table of the WordPress users also has, such as the email address, now works. The column was not named with its table, which the database refused as ambiguous, so the filter found nothing and its counter stayed empty.
- A mass action displaying or exporting categories now leaves out the ROOT category on Joomla, as it already did on WordPress: the check which skips it compared the parent of the category with a string, which the database of Joomla hands over as a number.
- On WordPress, the order emails are now written in the language of the order, and the emails a mass action sends to each customer in the language of the customer, as on Joomla: HikaShop looked for its translations in a folder per language, which only Joomla has, so every email went out in the language of the website.
- A mass action on the categories filtering on a column of the categories, or of their parent, now keeps to the product categories whether it runs from a scheduled task, the Process button or when a category is saved, unless it also has a "Category type" filter, which then decides alone; run from a scheduled task or the Process button, it also reached the manufacturers, the order statuses and the tax categories.
- Editing the cell of a product which no longer exists in the results of a mass action now leaves it alone; the save stopped with an error.
- Changing the status of an order in a cell of the results of a mass action with the notification box ticked now saves the status and records the notification in the history of the order; the save stopped with an error.
- The "Run PHP code", "Run a MySQL query" and "Send an HTTP request" actions of a mass action are now reserved to the Super Users even when the HikaShop mass action system plugin is disabled; with that plugin disabled, any user allowed to edit mass actions could configure them.
- On WordPress, the checkout now goes on to the next step when the customer logs in or registers in it. Before, the first click on the "Next" button after logging in reloaded the checkout on the same step with a message about the security token of the page.
- On WordPress with PHP 8, the blocks of the checkout now refresh when the customer logs in or saves an address in them. Before, the refresh could stop on a PHP error coming from a HikaShop system plugin, and the checkout did not move on.
- The "Import from a CSV file" filter of a mass action now imports a file with a related or an options column; such a file stopped the mass action with an error and nothing was imported. The options are saved as options, in the order of the file, where they were saved as related products.
- The "Import from a CSV file" filter of a mass action now reads a currency written as its id in the price currency column; it only understood a currency code, and a price with an id was saved without a currency.
- The "change the user group" action of a mass action on the customers now only changes the customers who have an account on the website; it also added a user group to an account that does not exist for each customer without one.
- Editing the whole weight unit column of the results of a mass action now opens the list of units to apply to every row; it stopped with an error page instead.
- The number of elements a mass action filter selects now updates as soon as you pick the characteristic of a "Characteristic" filter on the products; picking one stopped the counter with a javascript error and it showed nothing until another setting of the filter was changed.
- The "send an email" action of a mass action edition form now starts with its own settings. It opened with the sentence "Delete the filtered elements", which belongs to the delete action and was left over from it.
- A mass action on the products filtering on a characteristic now selects the same products whether it runs from the database or on a list of products, for instance from a save event, and honours the comparison you chose in both cases. Run on a list it kept no product at all, and where it did compare, it only ever asked whether the two were the same.
- The "canonical URL" action of a mass action on the products now runs on every product selected. When a filter had been applied to a list of products rather than to the database, the action stopped before doing anything.
- A mass action deleting products now deletes every product it selected, however many there are. Beyond 500 products it deleted the first 500 and left all the others without a word, where the other tables have always deleted everything selected.
- The "total purchases" filter of a mass action on the orders now runs the actions on every order of the customers it selects, and its counter says that number; it used to run them on one order per customer. It answers the same thing whichever way the mass action is started, where running it on a list of orders, for instance from a save event, used to keep nothing at all for two of its three questions and to compare the total of the one order it was looking at for the third. And a total which is not a number, such as a word typed by mistake, is now refused with a message and selects nothing, instead of ending on a database error.
- The "customers that have / do not have" filter now answers the same thing whether the mass action runs from the database or on a list of customers, where running it on a list kept every one of them. "Does not have an order in that status" also selects the customers who have no order at all, which it did not before.
- The "user with access level" filter of a mass action works on the addresses, says how many elements it selects on the categories, and no longer answers the wrong thing in three cases. On the addresses it ended on a database error and the mass action did nothing at all. On the categories its counter printed the name of a text instead of the number. A group nobody belongs to used to be ignored, so the mass action ran on everything instead of on nothing. And "not visible to that group", run on a list of products or categories rather than from the database, kept the items everybody may see, which the database branch has always dropped, since an item visible to everybody is visible to that group too.
- A mass action on the categories filtering on the parent category now reads that parent whichever way it is started. Run on a list of categories rather than from the database, it used to look for an entry of the parent chain which is never there, so the comparison was made against nothing.
- Three filters of a mass action on the products now do what they say. "Related products" and "Options" select the products which really have a related product, or an option, answering the comparison, where they used to keep every product of the shop. "Price" compares the prices of each product when the mass action runs on a list of products rather than from the database, where it compared nothing at all and wrote a PHP warning for each product. And a category filter asking for nothing in a column now selects the products which are in no category, where it selected every variant, a variant being in the categories of the product it is a variant of.
- A mass action on the orders now answers the same thing whether it runs from the database or on a list of orders it was handed, for the filters which cross to another table. Two filters on the products of the order mean one product line satisfying both, which is what running from the database already meant; asking for nothing in a column of the billing or shipping address selects the orders which have no such address; and a filter on the customer's Joomla or WordPress account whose value is the number 0 is no longer dropped.
- A mass action on the customers which filters on a column of their addresses and asks for nothing in it now answers the same thing however it is started: the customers with no such address. It answered that when it ran from the database and kept no customer at all when it ran on a list, for instance from a save event, because it was then comparing a column of an address it had loaded.
- A mass action on the addresses can now filter on the Joomla or WordPress account of the customer the address belongs to. The comparisons offered under "User column" which name a column of the account, its email address, whether it is blocked, the day it registered, matched no address at all, whichever way the mass action was started. A filter whose value is the number 0 is no longer ignored either: it used to be dropped when the mass action ran from the database and applied when it ran on a list of addresses, so the same mass action did two different things.
- When you change the customer of an order in the back end, or create an order for a customer there, the order now takes the language the customer chose for the front end in their account, or the default language of your website when they did not choose one. Before, it kept the language of the administration of the person doing the change, so the emails and the invoice of that order could be sent to the customer in a language they do not use.
- A comparison which is not one of those the form offers now selects nothing, whichever way the mass action runs. It was refused in the query and accepted when the mass action ran over elements it had been given, where it fell back on a plain equality, so the same filter answered differently depending on how it had been started.
- A search pattern which is not a valid pattern now selects nothing and says so, instead of ending the mass action. In the query the database refused the statement, which stopped everything; over a set of elements it raised a PHP warning for each of them.
- What a mass action refuses to do is now said where it is read. A column it may not write, a file it may not open, a value it cannot make sense of: each of those is reported to the merchant instead of being written into a report nobody reads.
- Filtering on a group, and the action which adds or removes one, now work on WordPress. Both asked for the name of the role behind the group number they had been given, through a function which was never written, so on WordPress they ended in a fatal error the moment they ran.
- The filters of a mass action can no longer be made to write the query themselves. The name of the column and the comparison went into the statement as they had been saved, so somebody allowed to write a mass action could reach the whole database through one. A column is now a column name and a comparison is one of the sixteen the form offers.
- The "change the value of a column" action, and a cell edited in the results, no longer write the columns of the CMS user account beyond the name, the blocked flag and whether they receive the administrator emails. They used to write any of them, the password included, which let somebody allowed to write a mass action give themselves an account they were not allowed to create. The action also refuses the columns where writing is not editing the shop: the credentials, the customer a row belongs to, the totals and taxes HikaShop computes, and the settings kept as a serialised value.
- An export of a mass action is now written in one of the two folders the shop uses for uploads, with an extension of csv, xls, xlsx or txt. The path was used as it was saved, so an absolute path, or one climbing out of the folder, wrote the file anywhere the web server could write.
- The "in the CSV file" filter, and the page which lists the columns of that file, now only read a csv or txt file in one of those same folders. They opened whatever path they were given and showed its first line.
- The counter which tells you how many elements a filter selects now asks for the token of the form and for the right to write a mass action. It had neither, so another website could have an administrator's browser run a filter on your shop while they were logged in.
- The values shown in the results of a mass action are now escaped. They come from the shop's own data, a good deal of which is written by customers, so a value carrying a piece of markup was rendered as markup in the backend of whoever displayed the results.
- A cell of an exported spreadsheet which starts with =, + or @ is no longer read as a formula when the file is opened. The CSV export had guarded against that for years; the xls and xlsx exports had not.
- The setting which makes the HTTP address of a mass action public now says what that means: anyone who knows the address can run the mass action, with no key and no account.
- The "send an HTTP request" action of a mass action no longer ends in an error. It handed its response to a debugging tool which is not part of HikaShop, so the request went out and the mass action then stopped on a fatal error: the elements after the first one were never sent, the actions after it never ran, and the merchant saw an error page instead of a result.
- The "change the value of a column" action of a mass action on addresses can now write a custom field. The name of the column was cut at the underscore and its first part used as the name of a table, so a custom field called anything but address\_something was written to a table which does not exist and the database refused the whole statement, for every address selected.
- An action which follows a "change the value of a column" in a mass action on addresses or on categories now sees the new value. The action wrote the value into the database but not into the element it had in hand, so a "display the results" placed after it showed the old value, an email carrying a tag sent the old value, and a warning was raised for every element.
- The delete action of a mass action on categories no longer fails when everything selected is a built-in category. It leaves the root, the product, manufacturer and tax categories and the order statuses alone, and when nothing else remained it still asked the database to delete an empty list, which was refused with an error the merchant saw. It now does nothing, quietly.
- A mass action which answers an HTTP address now answers as soon as it is saved. The list of those addresses was kept in a cache for a quarter of an hour, whatever the cache setting of the website said, so a merchant who had just created or changed one got a page not found from it with nothing to explain why. Saving, publishing or deleting a mass action now refreshes that list.
- A mass action whose filters group the results now runs. The two parts of the query were written in the wrong order, which the database refused, so the mass action did nothing at all.
- The number of results shown while writing a mass action now agrees with what the mass action does. On the filters which group their results, the total purchases of a customer and the price of a product among them, it counted the first group instead of the elements: a filter on orders whose customer has bought more than two items said "3 results" where the mass action then ran on 37 orders.
- A sort direction which is neither ascending nor descending no longer stops a mass action. It went into the query as it was saved, the database refused the statement, and the mass action did nothing at all with nothing to say why. The same goes for a column to sort on which is not a column.
- The text filters of a mass action now give the same answer whether the mass action runs over the whole shop or over elements it is given, when it is fired by the save of an order for instance. The value typed by the merchant was read as a regular expression in the second case, so a product name containing a bracket or a plus sign matched the wrong things or nothing at all, and the LIKE comparison looked for the value anywhere rather than comparing the whole value as the database does.
- The withdrawal window of the configuration now only takes a number of days. The field accepted any text, and a value which was not a number counted as zero days, so the withdrawal button disappeared from every order without a word. Text can no longer be typed or pasted into it, and a value already saved which is not a number falls back on the 14 days of the directive.
- Reloading the payment page no longer places the order a second time. On a shop where the cart is emptied when the order is confirmed rather than when it is created, which is how most payment gateways are set up, a customer who refreshed the page carrying the payment buttons, because the window of their bank had frozen for instance, was given a second order made of the same cart, and you received two order notifications for one purchase. The page now displays the order which is already waiting for its payment, and if the payment arrived while the page was open, the thank you page instead, so the customer cannot pay twice either. A customer who changes their cart, or their payment method, and orders again still gets a new order.
- Three fields of your shop now tell an assistive technology, and the AI agents which read your pages, what they are for: the search box of a filter, the two ends of a price slider, and the currency selector. None of them carried a name of its own, so the "Agentic Browsing" checks of PageSpeed Insights reported them as unlabelled. Nothing changes visually, and the name each one takes is the one already shown beside it.
- A product displayed outside of a listing, in a module on another page of your website for instance, now links to the menu item covering the closest parent category of its own category when no menu item is dedicated to that category. It used to fall back to the first listing menu item of the website in that language, so a product in a sub category without a menu item of its own was linked through a listing which had nothing to do with it. The links to such a category do the same.
- Your language override files are no longer rewritten on every page of your shop. The mechanism which renames the entry of a translation when the text it was made for is edited was also running for a field being filled in for the first time, where there is nothing to rename, and it rewrote the override file of every language of your website to leave them exactly as they were. Shops with the canonical URLs generated automatically were doing this on every visit of a product or a category page.
- The listings link to the menu item of a category again when one is dedicated to it. Since 6.6.0 the main category of a menu item can name several categories, and every menu item saved since that upgrade stores its category in a form the rest of the shop still read as a single one, so a menu item pointing at exactly one category was no longer recognised as the page of that category. The subcategory tiles of a listing then pointed at the address HikaShop builds itself instead of the address of the menu item, and a category unpublished on purpose but reachable through its own menu item answered "Category not found" through those links. A menu item whose main category was emptied showed the same error instead of the categories of the shop. Menu items saved before 6.6.0 kept working, which is why only the ones created or edited since then were affected.
- The small cross which removes the value of a filter works again on the listings whose menu item selects several categories. The address the filters block is refreshed with carried the word "Array" in place of the category of the page, so the answer to that refresh held no filters block at all and nothing was put back on your page: the value stayed displayed next to the cross and no further click could remove it, while the products listing itself was correctly refreshed without the filter. Such a listing also displays its filters properly now: a filter restricted to one of the categories of the menu item was left out unless the restriction was on one of their parent categories, and each of the selected categories now brings its own filters, when the page is opened as well as after each refresh. The listings whose menu item selects a single category were not concerned.
- The Order Statuses page now shows the statuses the withdrawal button is really offered on. Its Withdrawable column showed only "delivered" as ticked on a shop which had never set that column, while the button was in fact offered on confirmed, shipped and delivered orders, so the page told you one thing and your customers got another. The three are now shown, which is also what a shop upgrading from before the feature is given, and a shop which has set that column keeps its own choice.
- The withdrawal button no longer disappears on an order whose reference date was never filled in. The withdrawal window is counted from the date of the event the status refers to, the invoice for a confirmed order and the shipping date for a shipped one, and an order which never went through that step, a confirmed order on a shop which issues no invoice for instance, has no such date; the button was then left out with nothing said about it. The date of the order is used instead, so the window is counted from a real date, and an order older than the withdrawal period is still refused.
- The download of a product file no longer carries the text another extension of your website wrote before it. A plugin whose file has a blank line after its last PHP tag prints that line as soon as the file is loaded, and it ended up at the very beginning of the file you download, which is enough to make a PDF or a ZIP unreadable. Everything pending is now dropped before the file is sent, and the CSV and spreadsheet exports of your backend are protected the same way.
- The translation page of Falang no longer ends on a PHP error when no product of your shop belongs to a category. The category filter of that page builds its list from the products which are in a category, and the empty list was not handled, so the page stopped on the shops whose products have no category yet. Filtering on a category which has since lost all of its products no longer ends on a database error either.
- A custom field of the "link" type now keeps its text and its address through the saves of the element it is on. Every save added a pair of quotation marks around the text, so a link named Documentation ended up displayed as """"Documentation"""" after a few saves, and the edit form showed those quotes in its Text box. A link pointing at a page of your own website, entered as /accessories/cables for instance, also lost its address the second time the element was saved, and an address entered without any text was displayed on your website as a link named "https" instead of the address itself. A value which already carries extra quotation marks is cleaned the next time you save the element it is on.
- The link to the order in the emails your customers receive is now a complete web address everywhere it is used. HikaShop built it without the address of your website in front of it and added that address afterwards, but only to the links of the HTML version of the email, so the same link printed in the plain text version, which some email applications display instead, could not be opened. It also reaches the emails of HikaMarket and any email template of your own which prints that link outside of a link tag.
- The PayPal Checkout payment method asks PayPal for the 3D Secure authentication of a card payment when its "Enable 3D Secure" setting has never been touched, as its own settings screen has always shown. The setting was read as if it were on "No" while the screen displayed the first choice, so a payment method saved before this setting existed, or simply never opened, sent no authentication request at all. A card payment presented without authentication is refused by most European banks, which left the customer with a declined payment and the merchant with an order stuck as created. A method explicitly set to "No" is unchanged.
- An email sent by a mass action is now displayed with the template of the emails of your shop. The text written in the "send an email" action of a mass action replaced the whole email once it had been built, template included, so it reached your customer as bare text on a white page while every other email of the shop carried your colours, your logo and your footer. That text is now placed inside the template like the content of any other email, which also means it is turned into a readable text version for the email clients which do not display HTML.
- The code editors of the email edit page, of the template settings and of the view edit page do not mark the PHP tags of the file as errors anymore on WordPress. WordPress checks the content of its code editor against the rules of HTML when it is not told what the file is written in, and HTML knows nothing of <?php, so a red cross was displayed next to the first line and next to every line where the code goes back to PHP. The editors now say they hold PHP, which also colors the code properly, and the editor of the CSS files of the shop says it holds CSS. Joomla was not concerned, as its editor checks nothing.
- The small cross which removes the value of a filter now really empties it on the shops which use search engine friendly URLs. On a text filter, the search field displayed a piece of the address of the page instead, such as .html?tmpl=raw, which could not be removed, so your visitor could not make a new search without reloading the page themselves. The address of the page to come back to was sent as it was to the block which refreshes the filters, and Joomla, when it rewrites such an address in its search engine friendly form, moves it into the path of the URL, where the parameters that address carries itself end up replacing the value of the filter. It is now sent encoded, so nothing it contains can be read as a parameter of the request. Only the filters whose "Deletable filter" setting is turned on were concerned, since the cross is the only thing which displays them.
- The product page image carousel does not fill your error log with PHP notices anymore when its pagination is turned on with a style which is neither dots, numbers nor thumbnails. The size of the pagination slides was only set for those three styles and left undefined otherwise, while the page always tried to write it into its CSS, so it now defaults to a valid size in every case.
- Changing the status of orders with the Actions button of the orders listing, or with a mass action, does not send the status notification email to your customers anymore when the "Send notification email" box is left unticked. The value which says whether that email is wanted was empty in that case, and the compatibility layer which hands the parameters of an event to the plugins took an empty value for a missing one and replaced it with an internal object, which the shop then read as a yes. Changing the status of a single order from its own page was never concerned, as that form sends a no rather than nothing. Any shop with a payment method installed was concerned, since the payment plugins are called when an order is updated.
- An integration which declares its own hikashopBridgeController class before HikaShop is loaded, in order to add its code to every controller of the shop, works again. On 6.5.2, the controllers of HikaShop stopped extending that class, so such an integration was simply never called anymore, without any error. Extensions which extend that class instead of replacing it, HikaMarket among them, were not concerned.
- The title of the order summary of the PayPal Checkout payment page is translated properly again on a shop which is not in English. It was displayed with the word your backend uses for the display order of a listing, "Ordre" in French, "Reihenfolge" in German, "Ordinamento" in Italian, instead of the word for a purchase, so the block looked untranslated to your customers. In English both words are the same, which is why it went unnoticed.
- The PayPal Checkout payment page shows its payment buttons and its credit card form again on the shops which never touched the list of the funding sources to disable of their PayPal method. On 6.6.0, a setting which a payment method had never saved started being filled with the value its plugin declares beside it, and for a setting offered as a list of choices that value is the list of the choices themselves, not a default. PayPal was therefore asked for its script with the labels of its payment means in place of their codes, answered with an error instead of the script, and the page then told the customer that something in their browser was blocking PayPal, while nothing in their browser was involved. Any payment method whose settings include a list, a set of checkboxes or a set of radio buttons was concerned in the same way. The PayPal method now also leaves out a funding source which is not one of those PayPal knows, rather than letting the whole page fail because of it.
- The entry registration form can be submitted again on the shops whose "Allow several entries" setting is turned off. That setting only controls whether a visitor can register several people at once, but it was also hiding the button which validates the form, so the form was displayed with no way to go to the checkout and no entry could be recorded at all.
- A products listing whose menu item has a main category selected does not repeat the whole category path in the breadcrumb anymore. On 6.6.0, the main category started being saved as a list, because a menu item can now name several categories, and the listing read that list as a single number, which gave the root of your category tree instead of the category chosen. The breadcrumb then started its path at the top of the tree and added every level down to the page, next to the path your menu already displays. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- The breadcrumb of a category page is displayed again on the shops whose menu item has a single main category selected. On 6.6.0, that setting started being saved as a list, because it can now name several categories, and the breadcrumb, which reads it to know where the path it displays should start, understood any list as several categories and gave up on the path entirely. A menu item which really names several categories still displays only the path of the menu itself, since there is no single category path in that case. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- A checkout split in several steps does not stay on its first step anymore. On 6.6.0, validating a step sent the customer to the next one and the page displayed the first step again, so the checkout could never be finished. Shops whose checkout has all of its blocks on a single step, which is how HikaShop is configured out of the box, were not affected. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- A device paired with the HikaShop application can now change your shop, and not only read it. The pairing gave the device the right to read your shop but not to write to it, so the application displayed your orders and your products correctly and then answered "forbidden" on every change: a status, a product, an address, a mass action. Devices paired before this fix stay read only and have to be paired again, which takes a moment on the System>App Devices page. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- 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. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- 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. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- When the menu item of a products listing has several main categories selected, a product page opened from that listing displays again instead of stopping on a database error. The breadcrumb of the product now stops at whichever of those categories the product is under, and shows the whole path when it is under none of them.
- The PayPal Checkout payment page displays its payment buttons again on the shops which selected the same funding source both in the list of the sources to enable and in the list of the sources to disable. On 6.6.0, a source named in both lists is removed from the enabled ones, and when it was the only one enabled, PayPal was asked for its script with an empty list of sources, which PayPal answers with an error instead of the script. No button could then be displayed, and the page told the customer to disable whatever was blocking PayPal in their browser, while nothing in their browser was involved. Shops whose only disabled source was Sofort, which HikaShop removes from the list since PayPal stopped offering it, were in the same situation. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- The published or unpublished status icons of the backend listings were displayed in white, and thus hard to see, on Joomla 5 and 6.
- The columns of the products of the orders (item1\_order\_product\_price, item1\_order\_product\_quantity, etc) were missing from the CSV export of the mass actions on the orders since the 6.6.0.
- Updating a HikaShop shipping or payment plugin from the Extensions: Update page of Joomla failed with a "Class hikashopShippingPlugin not found" error.
- On PHP 8.5, a deprecation notice about FILTER\_SANITIZE\_STRING could appear when the translation overrides were read or when a user note was created.
- On WordPress, the UCP plugin could not be used by an AI platform: the address it published for its endpoints left out the index.php its permalinks need, creating a checkout failed, the MCP endpoint answered that it needed a more recent HikaShop, and every answer carried the 404 status WordPress sets on an address none of its pages match.
- Updating HikaShop now leaves the SagePay payment plugin of our marketplace installed. The update to 6.6.0 deleted it, displaying "The plugin SagePay has been removed", and the SagePay payment method of the checkout then created the orders without sending the customer to pay. A shop in that case gets it back by installing that plugin again: its settings are kept with the payment method.
- On WordPress, the checkout now goes on to the next step when its workflow has several steps. Before, the "Next" button displayed the first step again without any message, even when everything was filled properly, so the customer could not reach the payment.
- On WordPress, the checkout keeps working when a step is refused, for example because a field of the address is empty: the choice between login, registration and guest, and the terms and conditions checkbox, still respond on the page which displays the error messages. Before, that page had its javascript broken, and the form displayed could even differ from the choice selected.
- On WordPress, clicking on the "Next" button of the checkout without filling the login or registration form now asks the customer to fill it. Before, the page ended on a PHP error.
- The edit form of a product no longer displays a deprecation notice about strlen() above its empty WYSIWYG or textarea custom fields, since PHP 8.1 on a site displaying its errors.
- On WordPress, the withdrawal form now records the request of the customer and confirms it. Sending the form ended on a critical error page.
- On WordPress, saving a custom field from its edit page in the backend now works. It ended on a critical error page.
- Subscription renewals paid with a PayPal account saved by the PayPal Checkout payment plugin are now charged. PayPal refused every renewal charge, because the plugin did not send the request identifier PayPal requires for a payment made with a saved account, so the scheduled orders of the Recurring Orders plugin stayed unpaid.
- The PayPal Checkout payment plugin now adds its payment references to what the checkout stored on an order, as the other payment plugins do. It replaced them, so a subscription order lost its recurring flag once paid.
- A subscription paid by card with the PayPal Checkout payment plugin is now renewed by charging the same card. The card was charged for the first order only and never kept, so every renewal failed.
- On WordPress, the product selectors of the backend, for instance the Product field of a discount or coupon, now list the products of a category when you open it, and the ones matching what you type. They stayed empty, because WordPress wrapped the list in a full admin page. It was also added to the 6.6.0 package after that version was released, so a shop which downloaded it since then already has it.
- The FedEx 2 shipping plugin's bundled Guzzle and Guzzle PSR-7 libraries, which it uses to call the FedEx API for rates, are updated to the versions fixing their published security advisories (cookie and proxy header handling, open redirects). The plugin only uses them to reach FedEx's own address over HTTPS, so your shop was not exposed through it, but the libraries are kept current.
- At the end of an "Import from HikaShop", only the imported custom fields get their categories and products remapped to the imported ones. Before, the custom fields the shop already had were remapped too and could end up limited to other categories or products.
- On the order page of the backend, a product without weight now has an empty weight cell when another product of the order has a weight. Before, a PHP deprecation notice could be displayed in that cell.
- On a phone, the emails using the default, alternative, admin or user notification templates and their color copies now fit the width of the screen. The templates forced them to 450 pixels wide on screens between 331 and 480 pixels, so the email scrolled sideways on most phones.
- An email written in the language of the customer now reads in the direction of that language: the order emails of a customer who ordered in Arabic or Hebrew are laid out right to left even when they are sent from a back end in English, by a payment notification or by a scheduled task, and an English email sent from a back end in Arabic is laid out left to right. The direction followed the language of the page which sent the email.
- With the "Send details of order" setting of the PayPal Checkout payment plugin turned off, PayPal now shows the order's amount without taxes and its taxes as they are on the order. Before, the taxes of the shipping and payment fees were counted twice when the order had a taxed shipping or payment fee (and a coupon's tax was taken off twice), so PayPal showed a lower amount and higher taxes, even though the total was right.
- The order summary shown beside the buttons of the PayPal Checkout payment plugin now adds up to the order total: with prices shown with taxes, its products, shipping, payment fee and coupon are given with their taxes; with prices shown without taxes, they are given without them and followed by a line with the taxes of the order. Before, the products were given with their taxes and a line of taxes was added under them, and the taxes of the shipping and payment fees were counted twice, so an order of 51.47 could show 40.27 + 12.40 shipping + 6.72 taxes.
- The Pay Later message of the PayPal Checkout payment plugin set at the top of the product listings is now displayed when the product comparison is turned off, and always with the Starter and Essential editions. Before, the message was only output at that position when the comparison was turned on, so nothing showed on the product listings.
- The Pay Later message of the PayPal Checkout payment plugin on the cart of the checkout now follows its own "Pay Later Messaging on checkout cart" setting. Before, the checkout used the setting of the product listings, so the message showed where the listings setting said and could not be turned off on the checkout alone.
- A text in curly brackets starting with "product" and without a product id, like "{product name}" in an article or a forum post, is now left as it is by the HikaShop product tag insertion plugin. Before, the page displayed a database error (1064) instead of its content.
- A visitor without a session, like a search engine robot, opening the address that saves a product vote now gets an answer at once. Before, the page redirected to itself endlessly (Joomla's "session expired" redirect), and search engines reported a redirect error for it.
- A text filter with a minimum length now ignores the search when all its words are shorter than that length, and keeps the words exactly as long as the minimum length. Before, such a search gave an SQL error on the listing, and the words exactly as long as the minimum length were skipped.
- On the product edit page with the form customization, the buttons at the top of the block placed under a hidden "Description" or "Images and files" block, like the "+" adding a characteristic in the "Specifications" block, can be clicked again. Before, the hidden block covered the top of the blocks under it and these clicks did nothing.
- On the orders listing, the invoice number of an order is again shown under its order number. Since 6.6.0, both numbers were shown side by side on the second line of the cell, under an empty line.

[](#top)