Module · LNK Estimated Delivery

LNK Estimated Delivery: estimated delivery date by carrier and by zone

LNK Estimated Delivery is a delivery time module for PrestaShop. It shows an estimated delivery date, for example "Estimated delivery between Tuesday 9 and Thursday 11 June". The date is calculated from your preparation time, the chosen carrier, the delivery zone, your business days and your shipping cut-off time. Weekends and public holidays are excluded automatically, every year. A customer who orders on a Friday evening reads a precise date instead of "delivered within 3 to 5 days".

  • Version 2.1.0 · PrestaShop 1.7.6 to 8.x
  • Version 2.9.0 · PrestaShop 9
  • PrestaShop 1.7.6 to 9.x
  • PHP 7.1 to 8.4
  • No override

Key points

  • Delivery date calculated per carrier and per zone.
  • Business days and public holidays for ten countries, movable feasts calculated.
  • Cut-off time per carrier, read in the shop's time zone.
  • Four layouts: badge, timeline, countdown, plain text.
  • Four independent placements: product page, checkout, order pages, PDFs.
  • The actual lead time of each carrier at the delivery step.
  • Order tracking with actual dates, then estimated ones.
  • Appearance fully adjustable in the back office.
  • Compatible with page builders (Creative Elements and similar).
  • No core override, no call to an external service.
  • PrestaShop 1.7, 8 and 9, native Symfony back office on 9.
  • Translated into French, ready for any other language.

Delivery time calculated from your own lead times

Most shops show a fixed sentence written in the theme. That sentence ignores the day of the order and public holidays such as 15 August. It announces the same delay for Corsica and for central Paris.

The module relies on the information you know:

  • the time needed to prepare an order, per carrier;
  • the transit time, per carrier and per zone;
  • the time at which you stop shipping for the day;
  • your working days and your closing days.

From these it works out a date with the calculation you would make by hand, redone every time a page is displayed.

Delivery date on the product page

Customers compare offers on the product page, and the delivery time is part of that comparison. The module sits there from installation, on the standard PrestaShop hook.

Four layouts are available in the back office:

  • inline badge, a discreet line with the truck icon;
  • timeline card, with the order, preparation, shipping and delivery dates;
  • countdown, for example "Order within 02:14:37 for same-day shipping";
  • plain text, without a frame, for a minimal theme.

Preparation and transit time per carrier at checkout

At the delivery step of checkout, the module shows the date under each carrier, with its own preparation time and its own transit time. Most modules leave this spot unused.

The customer then compares two prices and two dates. This is the step where they choose the more expensive option or abandon their cart.

Business days and public holidays per shipping country

The calculation runs in business days. You tick your working days and the module skips the others. It also skips public holidays, with a calendar per shipping country:

  • France, Belgium, Luxembourg, Switzerland, Germany, Spain, Italy, Portugal, the Netherlands, the United Kingdom;
  • or no calendar, if you prefer to enter your own dates.

Movable feasts (Easter, Ascension, Pentecost, Corpus Christi) are calculated every year. They stay correct in 2030 as in 2026, without a module update. For the United Kingdom, public holidays falling on a weekend are moved automatically, following local practice.

Your exceptional closures (summer holidays, stocktaking, bridge days) are added in one line.

Order cut-off time and shipping cut-off

Each carrier has its own cut-off time. An order placed after that time ships on the next business day. With a 2 pm cut-off, the displayed date updates itself at 2:01 pm.

With the "countdown" layout, the customer sees the time left. If the cut-off passes while they are on the page, the block shows the new date without reloading. The server calculates both states in advance and the browser switches from one to the other, so the displayed date is always accurate.

The cut-off time is read in your shop's time zone. The server's and the visitor's time zones play no part in the calculation, so hosting set to UTC shifts nothing.

Order tracking for the customer

After the order, the module shows a tracking timeline on the confirmation page and in the order details. It covers the order, preparation, shipping and delivery steps.

Completed steps carry the actual dates, read from the order history. Upcoming steps carry the estimated date, calculated from the order date. That date stays the same from one visit to the next and does not move back when the customer refreshes the page.

Customers follow their order themselves, which saves you part of the "where is my order?" e-mails.

Delivery date on the invoice and delivery slip

The PDFs include a line with the estimated date, replaced by the actual date once the order is delivered. This spot is switched on or off like the others.

Appearance set in the back office, no CSS

The back office sets the accent colour, text colour, background, border, corner radius, spacing, font size, font weight, alignment, icon and full width.

The preview on the configuration page is rendered by the server, with the front-office templates and your default carrier. It shows exactly what the customer will see.

No file is written to disk. Settings are passed as CSS variables set on the block. The module therefore works properly in multistore, and a CDN cannot serve an outdated look.

Compatible with PrestaShop 1.7, 8 and 9

Two packages of the same module, one per PrestaShop branch:

Branch Module version PHP Back office
9.0 → 9.x 2.9.0 8.1 → 8.4 native Symfony controller
1.7.6 → 8.x 2.1.0 (separate package) 7.1 → 8.1 classic controller

On PrestaShop 9, the configuration page is a native Symfony controller, with the Twig template and the layout of the new back office. The 2.9.0 package only installs on PrestaShop 9; no Symfony file ships to 1.7 and 8 shops.

Before each release, every listed version is installed, configured, displayed and then uninstalled in our integration matrix.

Module without PrestaShop core overrides

This module installs no override. It has no override/ folder and hooks only into the points provided by PrestaShop.

For an agency, this rules out several problems:

  • conflicts with another module overriding the same class;
  • orphan files after a PrestaShop update;
  • an override/ folder to purge before a migration.

Léger et rapide

Figures measured on the shipped module, gzip-compressed (level 9). On the front: a 2,034-byte stylesheet (2.0 KB) and two scripts, no jQuery. The countdown one (1,144 bytes, 1.1 KB) only loads when that presentation is chosen, on the product page or at checkout; otherwise no page loads a single byte of it. The one that places the date under each carrier (978 bytes) only loads in the checkout. The estimate is computed by the server and written into the page HTML: no external call, no CDN.

Frequently asked questions

Is this module compatible with my PrestaShop version?

Yes, from PrestaShop 1.7.6 to PrestaShop 9, in two packages: 2.9.0 for PrestaShop 9 and 2.1.0 for 1.7.6 to 8.x. On PrestaShop 9, the configuration page is a native Symfony controller, with the layout of the new back office. Before each release, every version is installed, configured and uninstalled in our integration matrix.

Does the module contain a core override?

No override. This module does not modify the PrestaShop core and has no override/ folder. It therefore cannot conflict with any other module, and a PrestaShop update leaves no orphan file behind.

Do I need to modify my theme or touch the code?

In the standard case, no. The module sits on the PrestaShop hooks, on the product page and at checkout. If you want the date in a spot your theme does not expose, write to us: we add the hook for you, free of charge. It takes about fifteen minutes.

Does the module call the carriers' APIs?

No, by design. The module calculates the date from your own preparation and transit times. It needs no API key, no quota and no third-party subscription. Above all, it makes no network call while a product page is displayed, so a slow external service cannot slow it down.

Does this module slow down my shop?

No. The calculation is date arithmetic, with no network request and no disk write. Lead times are read once per page and kept in memory. Two small scripts only: the countdown one, loaded only if a "countdown" layout is active somewhere, and the one that places the date under each carrier (under 1 KB), loaded only in the checkout.

Do public holidays need updating every year?

No. Fixed holidays are in the calendar. Movable ones (Easter, Ascension, Pentecost, Corpus Christi) are calculated from the date of Easter in the current year. They will still be correct in 2030, without a module update. You only add your own closures, such as holidays, stocktaking or a bridge day.

I do not ship from France.

Ten national calendars are provided: France, Belgium, Luxembourg, Switzerland, Germany, Spain, Italy, Portugal, the Netherlands, the United Kingdom. The British calendar moves public holidays falling on a weekend to the Monday, following local practice. For a country not listed, choose "none" and enter your public holidays. The rest of the module works the same way.

How does it behave with many carriers and zones?

Transit times are loaded in a single query per page, then kept in memory. In the back office, zone details are collapsed per carrier, and a shop with twenty carriers and eight zones stays readable.

What is left if I uninstall the module?

Nothing. Uninstalling removes the module's two tables, its configuration keys, its menu entry and its Symfony configuration. The module never placed a file in the theme or in override/, so it leaves none behind.

Does it work in multistore and multilingual setups?

Yes. The module is translated into French and ready for any other language. In multistore, it generates no CSS file. Appearance settings are passed as CSS variables set on the block, so one shop cannot overwrite another shop's look.

Does the module set cookies?

No. The module sets no cookie or tracker and sends no data to a third party. You have nothing to declare in your consent banner.

Is the delivery date sent to Google as structured data?

No, on purpose. The shippingDetails markup has to be merged into the Product markup your theme already produces. A second, parallel markup would create two competing entities for the same product and blur your rich results. We therefore ruled out this option, which could harm your search rankings without warning.

Release history

4 versions released for PrestaShop

  1. Version 2.9.0 PrestaShop 9

    PrestaShop 9 branch (9.0 to 9.x, PHP 8.1 to 8.4). Shops on PrestaShop 1.7.6 to 8.x have their own package, 2.1.0, with the same features and no Symfony file at all.

    Changes

    • Symfony configuration shipped in place. config/routes.yml and config/services.yml are part of the package: the module no longer copies anything into its own folder on install.
    • Symfony back office only: the tab points straight at the configuration route, and the classic controller is no longer shipped on this branch.
    • French, English and Arabic translations regenerated from the code, accents reviewed.
    • Addresses of the module's CSS and JS files versioned by the fingerprint of their content: after an update, neither a CDN nor the browser serves the old version.
    • Settings page redone: header with the module status, summary pills, Calendar, Carriers, Placements and Appearance panels; month calendar showing what the module counts (working, non-working, closing); exceptional closures as a list; live preview of the four placements (product page, delivery, order, PDF), computed with the current settings before saving.
    • Order tracking (order confirmation and order detail in the customer account): clearer timeline, one dot per step (hollow ahead, filled when done, halo on the current step), line in the accent color up to the current step, date under each step, secondary colors of the theme at 4.5:1 contrast.
    • Upgrading from 2.0.0. No data changes: same tables, same settings, same hooks (a block the merchant moved stays where it is), plus displayAfterCarrier when checkout shows the date under each carrier. The tab is attached to the Symfony route. Proven by tests/upgrade-check.sh: product page estimates identical in French, English and Arabic, settings and lead times unchanged.

    Fixes

    • Date under each carrier, now actually shown at checkout. The core only calls displayCarrierExtraContent for a module carrier, and only on that carrier's module: with ordinary carriers, no date was shown. The module now relies on displayAfterCarrier: one line per carrier, with its date, placed under that carrier's option by a script under 1 KB loaded only at checkout, which follows AJAX reloads; without the script, the list reads below the carrier block. Checked on 1.7.6, 8.1 and 9.2 (Classic, Hummingbird), changing address and carrier.
  2. Version 2.1.0 PrestaShop 1.7.6 to 8.x

    PrestaShop 1.7.6 to 8.x branch (PHP 7.1 to 8.1). Shops on PrestaShop 9 have their own package, 2.9.0, with the same features.

    Changes

    • No Symfony code on this branch: the back office is the classic controller, and the Symfony configuration copy of 2.0.0 is gone.
    • Translations through PrestaShop's legacy system (translations/fr.php, ar.php), the only one 1.7.6 and 1.7.7 load for a module: the module is translated from 1.7.6 on.
    • Tab name with its accents in every language: "LNK Délais de livraison".
    • Addresses of the module's CSS and JS files versioned by the fingerprint of their content: after an update, neither a CDN nor the browser serves the old version.
    • Order tracking (order confirmation and order detail in the customer account): clearer timeline, one dot per step (hollow ahead, filled when done, halo on the current step), line in the accent color up to the current step, date under each step, secondary colors of the theme at 4.5:1 contrast.
    • Settings page redone: header with the module status, summary pills, Calendar, Carriers, Placements and Appearance panels; month calendar showing what the module counts (working, non-working, closing); exceptional closures as a list; live preview of the four placements (product page, delivery, order, PDF), computed with the current settings before saving.
    • Upgrading from 2.0.0. No data changes: same tables, same settings, same hooks, plus displayAfterCarrier when checkout shows the date under each carrier. The tab is set right. Proven by tests/upgrade-check.sh on 1.7.6, 1.7.8 and 8.1: product page estimates identical in French, English and Arabic, settings and lead times unchanged.

    Fixes

    • Date under each carrier, now actually shown at checkout. The core only calls displayCarrierExtraContent for a module carrier, and only on that carrier's module: with ordinary carriers, no date was shown. The module now relies on displayAfterCarrier: one line per carrier, with its date, placed under that carrier's option by a script under 1 KB loaded only at checkout, which follows AJAX reloads; without the script, the list reads below the carrier block. Checked on 1.7.6, 8.1 and 9.2 (Classic, Hummingbird), changing address and carrier.
  3. Version 2.0.0 PrestaShop 1.7.6 to 8.x

    First distributable version. Version 1.0.0 was a custom development for one shop; this version is ported to all three PrestaShop branches and sold.

    New

    • Native Symfony back office for PrestaShop 9 (PrestaShopAdminController + Twig), deployed at installation and only if the version allows it.
    • Public holiday calendars per country: France, Belgium, Luxembourg, Switzerland, Germany, Spain, Italy, Portugal, the Netherlands, the United Kingdom, or none. Holidays falling on a weekend are moved to the Monday for the United Kingdom. The default calendar follows the shop's country.
    • Appearance settings in the back office: accent colour, text colour, background, border, corner radius, spacing, size, font weight, alignment, icon, full width. They travel as CSS variables set on the block; no file is generated.
    • Server-rendered preview on the configuration page, with the real front-office templates: it cannot differ from the actual rendering.
    • Plain text layout, without a frame, for minimal themes.
    • List of suggested hooks per placement, checked as present from 1.7.0 to 9.x.
    • tests/test-estimator.php: 63 checks of the engine, runnable without a shop.
    • Complete documentation: installation, compatibility, hooks, custom hooks, marketplace page, FAQ.

    Changes

    • Public holiday calculation moves from LnkDeliveryEstimator to LnkDeliveryHolidays. LnkDeliveryEstimator::frenchHolidays() and ::easterDate() no longer exist in that form, with no effect on normal use of the module.
    • The single colour of 1.0.0 (LNK_DELEST_COLOR) is carried over into the new appearance settings on update.
    • The countdown script is loaded only if a "countdown" layout is active somewhere.

    Fixes

    • Time zone hard-coded to Europe/Paris. The cut-off time is now read in the shop's time zone. Hosting set to UTC shifted the switchover by one to two hours, and the countdown showed a wrong delay.
    • Expired countdown. The server now renders both states, before and after the cut-off time. The browser only switches from one to the other and recalculates no date: a page served by a full-page cache can no longer show a wrong date.
    • Default carrier deleted or disabled. The module falls back to the first carrier actually available for the zone instead of going silent on every product page.
    • Degenerate configuration. With no business day ticked, the search loop no longer runs 400 times per call: the module renders nothing rather than inventing a date.
    • Hooks unregistered as a side effect. Changing a placement can no longer remove the hooks that carry order tracking or the PDFs.
    • Seeding at installation. Default lead times are inserted in batches; a shop with twenty carriers and eight zones used to trigger 180 queries.
    • Exceptional closures: invalid dates are ignored instead of skewing the calendar.
    • <style> injected into the <head> on every page: removed, the colour goes through a CSS variable on the block.
Show the previous version
  1. Version 1.0.0 PrestaShop 1.7.6 to 8.x

    Initial version, custom development. Not distributed.

Your cart

Your cart is empty.