New Product Badge for WooCommerce: safe setup, failure cases, and rollback

Direct answer

To show a New badge on recently published WooCommerce products, compare the already loaded published product's existing publication timestamp with one bounded 1 to 90 day window. Render one escaped, noninteractive plain-text label on documented native WooCommerce hooks. Render nothing for drafts, future dates, invalid settings, missing products, or expired products. Do not change dates, scan the catalog, schedule a daily job, or save a second "new" status.

StoreFixKit's New Product Badge for WooCommerce follows that model. Free supplies one label and one store-wide day window. Pro adds category day windows, individual product day overrides, and explicit exclusions.

"New" needs one source of truth

A product can have several dates:

• publication date;
• modified date;
• import date;
• inventory arrival date;
• first sale date;
• date a category was assigned;
• date an administrator manually marked it.

Mixing them creates surprising badges.

For a simple storefront label, publication date is the clearest default because WordPress already stores it and WooCommerce already knows the current product. The plugin should read that timestamp, not copy it into another table or product field.

WordPress exposes the post timestamp through its own APIs, including get_post_timestamp(). A focused plugin can use the existing published value and WordPress time instead of implementing another calendar.

Do not use modified date unless that is the product

Editing a typo, changing stock, updating an image, or adjusting SEO metadata can change a modified timestamp. That does not make an old product newly launched.

Using modified date by default can cause:

• old products to regain a New badge after routine maintenance;
• bulk imports to reset many products;
• stock or price updates to appear as launches;
• caches and feeds to disagree with the storefront;
• merchants to lose trust in the label.

A separate "Recently updated" plugin could intentionally use modified date. It would be a different promise.

A daily cron job is unnecessary

The badge decision is a comparison:

current WordPress time - publication time <= selected day window

The storefront is rendered at a known current time, so there is no need to visit every product at midnight and remove a flag.

A scheduled scan would add:

• background load;
• missed-run recovery;
• batch limits;
• locks;
• product writes;
• timezone edge cases;
• cleanup and rollback work.

Reading the current product's date avoids all of that. When the window expires, the next uncached render simply produces no badge.

Use native placement hooks, not DOM injection

WooCommerce's classic product loop exposes woocommerce_before_shop_loop_item_title, where core also places the sale flash and thumbnail. WooCommerce's template hooks also expose woocommerce_before_single_product_summary on the single-product page.

A small badge can render through those PHP hooks without:

• waiting for JavaScript;
• searching the DOM;
• copying a product template;
• wrapping the entire product card;
• watching page mutations;
• loading an icon library.

This does not guarantee every builder or block uses the same hooks. It gives the plugin a documented boundary.

Blocks reveal the real compatibility question

A broad badge suite can have many editors, display conditions, assets, and placement systems. Public support reports describe a blank page while opening a New badge, a product chooser with no options, and badges not appearing in a Product Category block.

These reports do not prove one shared bug. They identify three release questions:

1. Does the plugin need a JavaScript badge editor for one label?
2. Does it need to search the whole product catalog for ordinary operation?
3. Does the target block preserve the native hook used by the badge?

For a one-job New badge, the first two answers can be no. The third must be tested on the actual block or documented as an external boundary.

The badge is not sale, stock, or legal status

A New label should not:

• change sale state or a sale schedule;
• imply a discount;
• claim stock availability;
• change visibility;
• change schema or a merchant feed;
• create an order or shipping promise;
• certify freshness, compliance, or manufacturing date.

It is a small editorial cue based on publication time.

That distinction also affects placement. The badge can sit near the product image or summary, but it should not cover a price, sale flash, stock warning, variation selector, or Add to cart control.

Keep the label short and noninteractive

Useful labels include:

• New
• Just added
• New arrival
• Recently added

A 40-character plain-text limit is ample. The label should not be a link, button, tooltip dependency, animation, shortcode, or remote image.

Plain text reduces XSS and layout risk. It also gives assistive technology a straightforward text node rather than an icon whose meaning exists only in color.

The final theme still needs contrast and placement testing. No plugin can infer every background, product image, or design system.

Handle time and invalid state conservatively

The plugin should render nothing when:

• the product is not published;
• the publication timestamp is missing or malformed;
• the timestamp is in the future;
• the day window is outside 1 to 90;
• the label is empty or beyond its bound;
• WooCommerce or the product object is unavailable.

It should never guess a date, fall back to modified time, mark every product as new, or write a corrected value during a visitor request.

If a merchant sees a boundary mismatch, compare the product's publication timestamp, site timezone, and current WordPress time before changing code.

Product and category rules need one clear order

Free's store-wide day window solves the ordinary case. Pro can add bounded exceptions:

1. Product Never show New badge wins.
2. A valid individual product day window wins.
3. A valid matching category day window wins.
4. The Free store-wide day window is the fallback.

The visible words still come from the Free label. Pro changes only the date window and scope.

This model avoids copying rules onto every product. Selecting a category changes the decision at render time. It does not scan that category or write a product flag.

Performance and cache behavior

The current product is already present when WooCommerce renders a native card or product page. The decision needs:

• one small settings read;
• the existing publication timestamp;
• one date comparison;
• one tiny static stylesheet on relevant WooCommerce pages.

It needs no:

• custom database table;
• product query;
• catalog scan;
• cron event;
• public remote request;
• frontend JavaScript;
• customer cookie;
• telemetry;
• product write.

A full-page cache can keep a badge visible after the exact expiration time until that cached page expires. This is ordinary cache behavior. A lightweight plugin should not purge pages every minute or create per-product timers. Set cache policy according to how exact the merchandising window must be.

Free remains independent of Pro

The Free label and day window are stored locally and render without StoreFixKit or Stripe.

Pro licensing belongs to authenticated administration and update checks. If Pro is inactive, expired, mismatched, or temporarily unable to reach the license service, category and product rules turn off while Free's store-wide behavior continues.

The New Product Badge documentation includes real screenshots, setup, date semantics, theme boundaries, troubleshooting, rollback, uninstall ownership, and the support evidence checklist.

Beginner launch checklist

Recent product

Use a disposable published product inside the chosen window. Confirm one label appears in the native archive and product page.

Expired product

Use an older published product. Confirm no label renders.

Future and draft products

Preview a scheduled product and a draft. Confirm the public badge path remains silent.

Timezone

Record the WordPress site timezone, product publication timestamp, and current WordPress time around the cutoff.

Native placement

Check shop, category, search, and single-product pages on desktop and mobile. Confirm the label does not overlap images, sale flashes, prices, or controls.

Custom blocks

Test the real Product Collection, category block, quick view, builder card, and headless surface. Record whether each preserves the native hook.

Pro precedence

Test one category rule, one individual product day window, and one exclusion. Confirm exclusion wins.

Rollback and uninstall

Deactivate Pro and confirm Free continues. Deactivate Free and confirm badges disappear without changing products. On staging, uninstall both and verify publication dates, prices, stock, carts, and historical orders remain.

Security and support evidence

Only a WooCommerce manager should save global and category rules. Product overrides require product-edit permission. Every write needs a capability check, nonce, bounded validation, sanitization, and escaped output. WordPress's Common Issues guidance describes these review expectations.

Useful support evidence includes the product ID and status, publication timestamp, site timezone and current WordPress time, Free label and day window, matching category, product override or exclusion, exact URL, plugin and WooCommerce versions, theme/block owner, cache/CDN, expected result, actual result, and screenshots. Remove credentials, customer data, payment details, and full license keys.

FAQ

Does the badge change the product date?

No. It reads the existing publication timestamp only.

Does it run a daily product scan?

No. The current product is checked when WooCommerce renders it.

Why did a Product Collection block omit the badge?

The block may bypass the native hook used by this focused release.

Can it use modified date?

No. This release intentionally uses publication date.

What happens when Pro expires?

The Free label and store-wide day window continue locally. Category windows, product day overrides, and exclusions require an active product-bound license.