Changelog

Dolibarr stock flows to Shopify again: updates were refused as soon as a product already had online stock (“changeFromQuantity”). The module now reads the quantity actually recorded at Shopify and sends only the difference, groups updates in batches, and a temporary Shopify outage no longer puts products into permanent failure; products left stuck are re-queued automatically

The module's REST API had been answering with a 500 error since 2.6.0, even with a valid key: fixed and verified over real HTTP on Dolibarr 18 and 24 from the delivered package

The maintenance tools finally open (the tab crashed on opening), and the “Status mapping” tab, which had no effect on your orders, is removed — its old links redirect to “Order configuration”

The Webhooks tab no longer crashes: unticking “Immediate processing” or emptying a numeric field caused a fatal error, and choosing the blank line in “Webhook user” made all your webhooks answer with a 500 error

Saving a store's product category no longer silently erases its order, invoice and quotation tags. To check: open each store sheet, “Categories and tags” tab, and make sure the three tags are filled in

A manual collection is no longer mistaken for an automatic one: its products are attached again, and collections driven by conditions are reported separately on the synchronisation screen

Critical fix: on a Shopify store configured with several locations/warehouses, the stock-only re-sync cycle (when a product's content has not changed since the last push) was systematically rejected by Shopify. An integrator reported 141 errors out of 158 products, with stock staying at its old value on Shopify with no update ever going through. The cause: the reference quantity was compared against a Shopify stock across all locations combined, whereas Shopify actually compares it against the single location configured for your store — invisible on a single-location store, the defect appears as soon as a second location exists. It is now always read at the location actually configured for your store. After updating, re-run a stock sync for the products previously in error

Fix: a product with several variants no longer has all its variants blocked by one variant's issue — if a variant cannot be re-synced on a given cycle, the other variants of the same product, correctly synced, are no longer held back together with it

Fix: a genuine Shopify location configuration problem (location deleted, invalid, or disabled — e.g. an old warehouse closed but not deleted) is now clearly reported in the logs and the sync summary, with the action to take depending on the case. A misconfigured location identifier is also now detected immediately, without waiting for the call to Shopify

Fix: a temporary slowdown imposed by Shopify (rate limiting, normal on a large catalogue) is never confused with this location configuration problem — it keeps following the normal path, with a retry on the next cycle

Fix: an item correctly set with a stock of zero is no longer ever confused with an item whose quantity could not be read — a legitimately null stock at the configured location is now correctly sent to Shopify

Fix: on an installation with several Shopify stores, a product's sync tracking stays correctly isolated per store, with no mixing between stores; the two counters introduced by this version are also now visible directly on the manual sync screen, as dedicated banners

Critical fix, accounting impact: since the 18 September 2026 update (version 2.5.5), a Shopify order carrying an order-wide discount (promo code or automatic discount applied across several items) could be imported with a discount close to double the amount Shopify actually granted. On an order of €2,520.00 excl. VAT discounted by 5% (€126.00 excl. VAT), the import kept €245.70 excl. VAT. The order-wide discount amount is now taken directly from the breakdown Shopify already computes per line item, read only once — double-counting becomes structurally impossible

Fix: a discount targeting only some of your items (e.g. "-10% on sale items") could, in some cases, be calculated on the value of all items in the order rather than only the ones concerned, present since the same 18 September update

Fix: with some third-party discount apps or Shopify Functions that already reflect the order-wide discount in the price Shopify displays, the first fix in this version still counted it a second time. The calculation now reads each discount allocation only once, regardless of how Shopify otherwise displays the line price

Fix: marketplace orders (Nature & Découvertes and similar channels), which do not always state the VAT rate on each item, could have their order-wide discount overestimated by 20%; the module now falls back to your Dolibarr product's VAT rate for this calculation, as it already does for the line itself

Fix: an order with mixed VAT rates (e.g. 5.5% and 20% on the same order) allocated its entire order-wide discount to the highest rate; a discount line is now created per VAT rate actually concerned

A discount announced by Shopify but not found in the line-item breakdown no longer disappears silently: it is now logged for investigation

Fix, accounting impact: a global discount spread across line items was never applied on two import paths — the historical import and the single-order fetch, that is, the path used after a new order notification. A piece of information needed for the decision was not requested from Shopify, so the condition was always false: the order was recorded at full price, with no error and no warning

Fix: the stock of a variant with no matching SKU was never sent to Shopify, and nothing said so. The variant stayed indefinitely at whatever quantity it held when the mismatch appeared — sellable while out of stock, or unsellable while in stock — all the while the report announced a successful synchronisation

Fix: a product whose photos had disappeared on the Shopify side (product deleted then recreated, media removed by hand, backup restore) never got them back. The module relied on a fingerprint of the Dolibarr images to conclude that Shopify already held them, and no purge cleared that fingerprint: the correct procedure, correctly applied, could not work

Fix: "Your licence has expired" was shown when it was in fact our server that had failed to answer. An outage on our side no longer presents itself as a problem on yours

Multicompany fix: on installations where Doli2Shop is configured on an entity other than the first one, no webhook was ever accepted. The entry point always ran in the first entity and could not find the signing secret there: orders, products and shipments stopped coming through, without a single error message, and nothing was kept to be replayed later

Multicompany fix: product photos never reached Shopify. Dolibarr stores documents in a sub-folder named after the entity number, which the module did not recognise — the diagnostic screen reported "no product with at least one photo" while the ERP showed them

Multicompany fix: VAT on imported orders was computed using the company record of the first entity instead of the one the order belongs to

Multicompany fix: default payment mappings (card, bank transfer, cheque, PayPal…) were never created on a secondary entity. They are now seeded per entity, and never overwrite a mapping you have changed

Fix, all installations: a warning claiming a photo was not indexed was written for every product on every synchronisation, including when it was perfectly indexed — and each product was read from disk twice

Fix, all installations: your product photos were duplicated on every notification from Shopify — a mere price or stock change was enough to drop another copy. One customer had four copies of the same image on a single product, three of them created on the same day. A cleanup screen is provided for the duplicates already accumulated: it shows what will be deleted before acting, and never touches a photo you uploaded yourself

Critical fix: on some installations, the Shopify connection had to be re-established manually every day. The default store kept two copies of its credentials and the automatic renewal only updated one of them; since a Shopify token is single-use, the forgotten copy expired. Both copies are now kept in step

Fix: each variant's label was being replaced by the parent product title on every update coming from Shopify, including a simple price or stock change. Labels are now recalculated as they are on creation, and the repair tool finds them again even once they have already been linked

Fix: on the webhooks screen, the save button had no effect — the list of tracked events could not be changed. A page structure defect prevented the form from being submitted

Fix: the product synchronisation screen and the scheduled task were not looking at the same scope. A product filed under a sub-category was synchronised without ever appearing on screen, which reported "no products". Both now share the same definition, and a new go-live date setting lets you exclude orders predating your move to Shopify

Fix: on multi-store installations, the synchronisation screen counters counted each product once per store it was present in. Displayed totals will therefore go down: they are now correct

Fix: the historical order import never reported where it stood — "completed" always stayed no, statistics stayed empty, and changing the start date midway had no effect. The import now reports its progress, and can no longer declare itself complete after a failure

Critical fix: the shipment catch-up scheduled task no longer started at all, leaving no trace whatsoever in Dolibarr — only the server log recorded it. An automatic check now prevents this kind of silent failure from recurring

Fix: two other scheduled tasks failed for a related reason, including the webhook health check — which broke down precisely when recording an incident, that is, when it was most needed

Fix: products with variants produced around thirty warnings on every image synchronisation

Critical fix: viewing one page could disable the buttons on another. The module's internal calls rotated the session security token, and the Health page triggers one per store as soon as it opens: on a three-store installation, merely opening that page was enough for clicks on the Webhooks page to be rejected, silently

Fix: thirty actions across nine administration pages could be rejected with no message and no trace when the security token was refused — including linking a licence number to a store, which could therefore fail without any indication. All of them now display an explicit error

Fix: a synchronisation could switch off the webhooks of other stores

Fix: on the webhooks screen, "Configuration saved" was displayed without the state actually changing. Display and saving were not looking at the same database row: you disabled a webhook, the page confirmed, and nothing moved

Fix: disabling now removes every relevant subscription rather than just the first one found — a twin row can no longer bring back a webhook you have just removed. Enabling reuses an existing subscription instead of creating another one

Inconsistencies inherited from installations predating multi-store support are corrected along the way: a row left "active" with no actual subscription is reset

Fix: with several stores connected, the Webhooks page displayed the selected store but saved against another one — webhooks could not be disabled and the Save button appeared to do nothing. Display and saving now share the same per-store filter, and every error is shown in full instead of an empty message

Critical fix: on hardened installations (anti-CSRF token renewed on every page), every admin action of the module was silently rejected — including the setup wizard. Token checking now matches Dolibarr core, and a rejection is always reported on screen

Critical fix: on Dolibarr 18 to 22, connecting a store returned an HTTP 500 error on the way back from Shopify and the store was lost — the module relied on a core feature only introduced in late 2025

Fix: on strict SQL mode hosting, webhooks were never registered — the timestamps sent by Shopify were rejected by the database. They are now converted and stored in universal time

Fix: variant products imported from Shopify did not create a real Dolibarr variant — the parent/variant link stayed invisible in the interface, and the variant label could remain identical to the parent product's

Fix: importing products with variants failed when the same reference (SKU) is shared across several Shopify products — the module now reuses the existing product instead of failing, and shows the full error reason for any other issue

Fix: order lines coming from bundle/pack apps ("build your own pack") were not created in Dolibarr — billable products grouped in a bundle are now imported correctly (free 0-euro components are still ignored)

Critical fix: Dolibarr stock was never pushed to Shopify (restocking, in-house production, manual corrections) — Shopify stock drifted with each sale, down to false negative values. Every Dolibarr stock movement is now synchronized to Shopify in real time (absolute value, never negative)

Critical fix: more reliable product/stock sync — a disabled variant sometimes remained visible on Shopify, and diverging stock levels (sometimes negative) were no longer silently corrected; errors are now logged and surfaced

Critical fix: a shipment left in draft status after a failure (warehouse/stock) was never caught up automatically — it is now validated and closed by the periodic catch-up job

Display fix: incorrectly encoded accented characters (double encoding) fixed throughout the admin interface

Fix: a store's license status could get stuck on "unknown" — verification is now reliable and never downgrades a default store

Critical fix: some orders were no longer fetched from Shopify (regression introduced in 2.3.0) — order synchronization works normally again

Fix: webhooks registered on an outdated Shopify API version are now automatically re-registered during health checks, for each store

Fix: module activation blocked (blank page) on multi-store installations

Fix: percentage discounts undervalued — the discount was computed on the tax-excluded base then divided a second time by (1 + VAT) as if it were a tax-included amount. Orders with a percentage promo code now match the exact amount shown by Shopify (e.g. 5% = −€151.20 incl. tax, not −€126)

Critical fix: stock not decremented when importing Shopify orders — the warehouse was not passed at invoice validation. All 4 Dolibarr stock decrease rules (order, invoice, shipment, shipment closing) are now covered

Fix: the v2.2.4 permissions migration (module ID change) now runs automatically on activation — user rights are preserved when upgrading from a version older than 2.2.4

Webhooks fix: wrong callback URL (missing /custom/ path) when no explicit configuration was set, and the events retention days setting is now honored by the purge

Critical fix: document API calls returning 404 on subdirectory installations — a leading slash was overriding the subdirectory path (issue #288)

All document access points (product and category images) now correctly honour the installation subdirectory

Fixes Dolibarr installations running in a subdirectory (version 2.2.6 already worked around this via the local SQL fallback)

Critical fix: resilient product image sync — automatic SQL fallback (llx_ecm_files) when the Dolibarr REST API /documents endpoint is unreachable (404, timeout, HTML in body). Product images now correctly synced to Shopify even on restrictive hosting (issue #286)

Critical fix: multi-tenant entity filter added to image SQL query — prevents exposing images from other Dolibarr entities in multi-company installations

Fix: image sort key mismatch (filename vs relativename) — sort by position now actually works

Critical fix: verifToken() function not loaded on some PHP-FPM stacks, blocking Shopify OAuth — 4 module files now explicitly include the compatibility.lib.php polyfill

Critical fix: Dolibarr module ID migration (436950 → 351003, official range allocated to Association P'tite Tête) — automatic SQL migration preserves existing permissions

Critical fix: admin pages (setup, wizard, product sync) referenced a non-existent CSS file — CSS loading and page display now correct

Critical fix: variant stock sync now runs every hour instead of 24h

Fixed webhook products/delete — invalid SQL query corrected

Critical fix: no more duplicate products created on Shopify after purging a product with variants

Improved anti-loop: inter-process sync/webhook protection to prevent deadlocks

Diagnostic false positive fixed: API Documents 404 on non-existent test product is now reported as warning instead of error

Removed ~1,974 lines of dead code

Dolibarr 23 compatibility — systematic audit and corrections

OAuth license link fix

Discounts not applied on services