Showing Estimated Delivery Date in PrestaShop 8, Step by Step

PrestaShop 8 doesn’t natively calculate or display an estimated delivery date on the product page. You have to add it yourself, either with theme code or with a module. This post covers how to do it right, which variables to account for, and how to avoid the typical mistakes.

⚠️

PrestaShop doesn’t do this out of the box

There’s no native setting to calculate or show a delivery date. Any store that wants one has to build it: with theme code or with a dedicated module.

Where to show the date

Three reasonable locations, ordered by impact: product page, near the add-to-cart button (highest impact, the non-negotiable minimum), product listing — category or search (improves CTR to the product page, medium impact) and cart/checkout (reinforces the decision during purchase, low but positive impact). Recommendation: start with the product page, extend to listings if it works; cart and checkout are optional extras.

Variables the calculation needs

Calculating the estimated date has to account for:

1. Current server time in the customer’s time zone. Without this, a customer checking at 11pm might see a different date than one checking at 9am the same day.
2. Order cutoff time for same-day shipping (configurable, usually 12:00 or 14:00 for stores with their own warehouse).
3. Warehouse preparation days (0 days if shipped same day, 1-2 days if preparation is required).
4. Current product stock. If available, day 0. If out of stock with a restock date, that date plus preparation.
5. Warehouse and carrier working calendar: business days, national and local holidays, does it deliver on Saturdays?
6. Carrier transit time by destination, determined from postal code or country.

The final date is the sum of these components applied to the specific order. Before implementing, get the concrete values for your own logistics straight: cutoff time (e.g. 14:00), preparation days (0 if in stock, 2 if restocking), working calendar (national holidays plus your warehouse’s local holidays) and transit times by zone (mainland 24-48h, Balearic Islands 48-72h, Canary Islands 72-96h, international depending on country). Without those values defined, any implementation will produce inconsistent dates.

How it’s calculated, in pseudocode

The basic calculation logic:

baseDate = today
if stock available and current time before cutoffTime:
    baseDate = today
if stock available and current time after cutoffTime:
    baseDate = next business day
if stock unavailable with a restock date:
    baseDate = restock date + prepDays

customerZone = detect from postal code or country
transitDays = lookup table by zone

deliveryDate = add transitDays business days to baseDate
show deliveryDate in a friendly format

In PrestaShop 8 this materializes as an override of the product controller that adds a delivery_date variable to the Smarty context, plus a modification to the TPL template that renders it.

Performance and caching

On listings with 30+ products per page, calculating 30 dates on every visit can slow things down. Without caching, calculating the date for each product in the listing adds work to every render, and that cost multiplies by the number of products shown — enough to be noticeable in Core Web Vitals on a large catalog. Three optimizations: caching per visitor session with the zone already detected (the date only changes meaningfully once an hour has passed), lazy calculation (computed the first time it’s rendered, then cached for 5-15 minutes) and invalidation at midnight and on stock changes.

Multilingual copy and honesty

The date format changes by language (“Recíbelo el martes 19 de mayo” in Spanish, “Receive it on Tuesday, May 19” in English, and so on for every active store language) — PrestaShop already has native language management and translatable Smarty templates, so the copy shouldn’t be hardcoded. Two details that improve perception without tipping into artificial pressure: showing the time left until the cutoff (“get it Tuesday if you order in the next 2 hours,” honest urgency grounded in real logistics) and clearly flagging when the timeframe runs longer than usual (“get it in 10-14 days” with an explanation if the product needs restocking) — a surprise on arrival is worse than clear information at the point of purchase.

The shortcut: Zeyvro’s module

Zeyvro’s Delivery Date module for PrestaShop 8 implements the full calculation with BO configuration for cutoff time, preparation days, holidays, per-carrier calendar, multilingual support and caching — shown on the product page, listing and cart from a single configuration point. It pays off in any store with a catalog of meaningful size, where maintaining the calculation by hand in the theme costs real development time — the module is free, so the saving is that development time directly. It doesn’t pay off in a very small store with irregular logistics where dates can’t be promised honestly.

Frequently asked questions

Does PrestaShop 8 calculate the delivery date natively?

No. There’s no native setting for this — you have to add it with theme code (a product controller override plus a TPL template) or with a dedicated module.

What variables need to be considered to calculate the date?

Current time in the customer’s time zone, order cutoff time, warehouse preparation days, product stock, the warehouse and carrier working calendar, and transit time by destination.

How do you keep the calculation from slowing down the product listing?

With per-visitor-session caching, lazy calculation (5-15 minutes) and invalidation at midnight or on stock changes. Without caching, the cost of calculating the date repeats for every product in the listing, which can add up on large catalogs.

Can the date be shown in multiple languages?

Yes. The format changes by language (“get it by Tuesday the 19th” / “recíbelo el martes 19”) using PrestaShop’s native language management and Smarty templates — the copy lives in the module’s or theme’s translation, never hardcoded.

Zeyvro builds PrestaShop 8 modules from a real store in production. Unobfuscated code.