{"id":849,"date":"2026-05-12T04:58:19","date_gmt":"2026-05-12T04:58:19","guid":{"rendered":"https:\/\/quickshipd.com\/blog\/?p=849"},"modified":"2026-08-23T18:13:19","modified_gmt":"2026-08-23T18:13:19","slug":"delivery-dates-not-showing-woocommerce","status":"publish","type":"post","link":"https:\/\/quickshipd.com\/blog\/delivery-dates-not-showing-woocommerce\/","title":{"rendered":"Why Aren’t My Delivery Dates Showing Up in WooCommerce?"},"content":{"rendered":"\n

You set up a delivery date plugin<\/a>, configured the settings, and hit save. But the estimates aren’t appearing on your product pages or checkout. This is one of the most common frustrations WooCommerce store owners run into \u2014 and in most cases, the fix is simpler than you think.<\/p>\n\n\n\n

Here are the most likely reasons delivery dates aren’t showing up, and how to fix each one.<\/p>\n\n\n\n

1. The Plugin Isn’t Enabled<\/h2>\n\n\n\n

It sounds obvious, but it’s the most common culprit. Many delivery date plugins have a master on\/off toggle that’s separate from simply activating the plugin in WordPress. If that toggle is off, nothing displays \u2014 regardless of any other settings you’ve configured.<\/p>\n\n\n\n

In QuickShipD, this is the ‘Enable QuickShipD’ toggle at the top of the Delivery tab. Make sure it’s switched on and that you’ve clicked Save Settings.<\/p>\n\n\n\n

2. The Display Location Isn’t Turned On<\/h2>\n\n\n\n

Even when the plugin is enabled, you need to tell it where to show estimates. Most plugins have display controls that are turned off by default for specific pages.<\/p>\n\n\n\n

In QuickShipD’s Display tab, you’ll find individual toggles for Product pages, Shop\/archive pages, Cart page, and Checkout page. If the page where you’re expecting to see the estimate has its toggle off, nothing will appear there. Check each location independently \u2014 they’re controlled separately.<\/p>\n\n\n\n

3. The Delivery Days Are Set to Zero or Left Blank<\/h2>\n\n\n\n

If your minimum and maximum delivery days are both set to zero, or left empty, the plugin has no data to calculate from. The result is either a blank display or no display at all. Go to your Delivery settings and make sure you’ve entered valid numbers \u2014 for example, a minimum of 3 days and a maximum of 5 days.<\/p>\n\n\n\n

4. Theme Compatibility Issues<\/h2>\n\n\n\n

Some WooCommerce themes use heavily customised product page templates that don’t include all the standard WooCommerce hook positions. If a plugin relies on a specific hook to inject its output (like after the price, or before the add-to-cart button), and your theme has removed or moved that hook, the estimate won’t display.<\/p>\n\n\n\n

To test this, temporarily switch to the default Storefront theme and check if the estimates appear. If they do, the issue is with your active theme’s template structure. Contact your theme developer or the plugin’s support team with that information.<\/p>\n\n\n\n

5. A Caching Plugin Is Serving Old Pages<\/h2>\n\n\n\n

If you recently enabled the plugin or changed its settings, your caching plugin might be serving an older version of your product pages that doesn’t include the delivery estimate. Clear your cache completely \u2014 both the server-side cache and any CDN cache and reload the page.<\/p>\n\n\n\n

6. The Product Has Its Estimate Hidden<\/h2>\n\n\n\n

QuickShipD allows you to hide the delivery estimate on a per-product basis. Inside each product’s data panel, under the Shipping tab, there’s a ‘Hide the delivery estimate for this product’ checkbox. If that’s checked for the product you’re testing on, no estimate will appear \u2014 even when the plugin is fully configured everywhere else.<\/p>\n\n\n\n

QUICK DIAGNOSIS CHECKLIST<\/strong>
\u2713 Enable toggle is ON in the Delivery tab
\u2713 Save Settings was clicked
\u2713 Display toggle for your page type is ON
\u2713 Min and Max delivery days are both filled in
\u2713 Cache has been cleared
\u2713 The specific product’s ‘Hide estimate’ checkbox is unchecked<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Work through that checklist in order and you’ll find the issue in almost every case. If the problem persists after all six checks, test with a default WordPress theme to isolate whether it’s a theme conflict.<\/p>\n\n\n\n

Frequently asked questions<\/h2>\n\n\n\n

Why are my delivery dates not showing on the product page?<\/h3>\n\n\n\n

Work down in this order. Confirm the master enable toggle is on and that you clicked Save Settings \u2014 activating a plugin in WordPress is not the same as switching it on. Check the Display tab, because product pages have their own toggle independent of cart and checkout. Confirm your minimum and maximum delivery days hold real numbers rather than zero or blank, since with nothing to add there is nothing to print. Then check the product itself: a per-product \u201chide estimate\u201d checkbox overrides every global setting you have configured.<\/p>\n\n\n\n

If all four are correct, view the page source and search for the plugin’s wrapper class. If the markup is present but nothing is visible on screen, you have a CSS conflict rather than a configuration problem \u2014 usually a theme rule applying display:none<\/code> or a colour that matches the background. That is a completely different fix, and it is worth ruling in or out before you open a support ticket.<\/p>\n\n\n\n

Why do delivery dates show on the product page but not at checkout?<\/h3>\n\n\n\n

Almost always because your store uses the block-based Cart and Checkout rather than the classic shortcode versions. The Cart and Checkout blocks render through the Store API and JavaScript, and they do not fire the classic PHP hooks \u2014 woocommerce_review_order_before_submit<\/code>, woocommerce_cart_totals_before_order_total<\/code> and the rest simply never run. Anything built on those hooks displays perfectly on the product page, which is still a classic template, and then outputs nothing at checkout.<\/p>\n\n\n\n

Nothing appears in your error log, because nothing failed: the hook was never called. To confirm it, edit your Checkout page in the block editor. If you see one large \u201cCheckout\u201d block rather than a

<\/div><\/code> shortcode, that is your answer. From there you either revert those pages to the shortcode versions, or move to a plugin that registers a proper block integration. There is no filter you can add to make a classic hook fire inside a block.<\/p>\n\n\n\n

Why did delivery dates stop showing after I switched themes?<\/h3>\n\n\n\n

Because the estimate is injected at a WooCommerce template hook, and your new theme either omits that hook or has moved it. Themes that ship their own copies of single-product.php<\/code> or the product summary partials frequently drop actions like woocommerce_single_product_summary<\/code>, or reposition them so the output lands somewhere you are not looking. The plugin’s callback is still registered; it is just never called.<\/p>\n\n\n\n

Test it by switching temporarily to Storefront or a default Twenty-something theme. If the dates come back, it is the theme rather than the plugin. Fix it either by choosing a different hook and priority in the plugin’s display settings, one your theme does keep, or by comparing the template overrides in your theme’s woocommerce\/<\/code> folder against WooCommerce’s originals and restoring the missing do_action()<\/code> call.<\/p>\n\n\n\n

Do delivery dates work with a caching plugin?<\/h3>\n\n\n\n

Yes, with one caveat that catches people out. A delivery date is calculated when the page is generated, so a cached page freezes whatever date was correct at that moment. A product page cached on Friday will still be promising Friday’s estimate on Monday.<\/p>\n\n\n\n

Exclude the cart and checkout from caching entirely \u2014 they are per-customer pages and should never be cached in the first place. On product pages, be careful with full-page caching if you display a countdown to your order cutoff, because a frozen countdown is worse than no countdown at all: either render it in JavaScript from the visitor’s clock, or set a cache lifetime short enough that the page cannot outlive the day it was built. And after any settings change, clear the page cache and the CDN cache, or you will spend an hour debugging a page that no longer exists.<\/p>\n\n\n\n

Why is the delivery date wrong by one day?<\/h3>\n\n\n\n

Nearly always a timezone mismatch between your server and your store. WordPress keeps the store timezone under Settings \u2192 General, but PHP on the server has its own, very often UTC. Any code that calls date()<\/code> or new DateTime( 'now' )<\/code> without passing a timezone gets the server’s, not yours. A store set to America\/New_York on a UTC server rolls over to \u201ctomorrow\u201d at 7pm or 8pm local time, so every evening visitor sees a date one day ahead \u2014 and it looks correct all morning, which is why it takes so long to spot.<\/p>\n\n\n\n

In code, the fix is to pass wp_timezone()<\/code> when you construct the date and use date_i18n()<\/code> rather than date()<\/code> for output. If you are using a plugin, first check that Settings \u2192 General is set to a named city such as Europe\/London rather than a raw UTC offset. Offsets do not observe daylight saving, so a store configured as \u201cUTC+1\u201d will be an hour out for half the year and produce exactly the same off-by-one date.<\/p>\n\n\n\n

Related Reading<\/h2>\n\n\n\n