DEV Community: WebKoding

WooCommerce cache serving the wrong country’s price

WebKoding — Fri, 06 Nov 2026 07:00:00 +0000

The dangerous failure of a cached WooCommerce shop is not a slow page. It is a fast one that carries the previous visitor’s country: a Portuguese customer sees the German price on the product page, then a different total in the cart. Here is a test that catches it before launch — two browser profiles, a fixed order of requests, and the cache header at every layer.

What you are actually looking for

A load test tells you whether the shop survives traffic. It tells you nothing about whether the traffic saw the right numbers. When a page cache sits in front of a shop whose prices depend on the customer’s location, the first visitor to a URL decides what everyone after them sees until the entry expires. If that visitor was in Germany, the page is now the German page — 19% VAT baked into every price — and it is served, quickly and with a cache HIT, to the next visitor from Portugal, who owes 23%.

The customer only finds out in the cart. The cart is never cached, so WooCommerce computes it fresh, with the real location, and the total no longer matches the price they clicked. That is the support ticket you get: “the price changed when I added it to the basket.” The cache did exactly what caches do. It just was not told that the page varied.

If you have not yet decided how to structure the cache, read caching a WooCommerce shop when the price depends on the customer’s country first. This article assumes you have built one of those and want to know whether it works.

The setup: two profiles, not two tabs

Use two separate browser profiles, one standing in for each country. Not two tabs, and not one normal window plus one incognito window — the point is that neither profile has the other’s cookies, and a WooCommerce session cookie in particular changes how most cache plugins behave. Many of them bypass the cache the moment they see a wp_woocommerce_session_ cookie, which means a test run from a browser that has ever added something to a cart is testing the uncached path and will pass no matter what.

The country signal has to arrive the way it arrives in production. If your cache is keyed on the CDN’s country header, or WooCommerce geolocates from the IP address, then a cookie or a query string that tells staging “pretend I am in Portugal” tests a different system from the one you are shipping. Use a VPN exit in each country, or two small servers, one in each. If that is not available, inject the override at the same point production reads the country — the CDN header, not a WordPress filter — so every layer below it sees exactly what it would see for a real visitor.

Do it on staging with the same cache configuration as production. A test against a staging site with the cache plugin disabled tells you your tax rules are right, which you already knew.

The sequence, and why the order matters

Purge the cache at every layer — plugin, server, CDN.
In the Germany profile, open a product URL. This warms the cache. Note the displayed price and the cache status of the response (it should be a MISS).
In the Portugal profile, open the same URL. Note the price and the cache status. If it is a HIT and the price is the German one, you have found the failure.
Purge again. Repeat with the order reversed: Portugal first, then Germany.
Compare each displayed price with what your configured tax rules say it should be. Not with the other profile — with the rule. Both profiles showing the same number is a failure if the rates differ; both showing different numbers is still a failure if one of them is wrong.

Reversing the order is not thoroughness for its own sake. A cache that is not keyed on country but whose default location happens to be Germany will pass the Germany-first run — the German page is the right page, and the Portuguese visitor’s leak is what you catch on step 3. But some setups have a second cache, keyed on something like the base country, that only misbehaves when the warming visitor is not in the default location. Running both orders costs two minutes and covers both.

Read the cache status at every layer, not just the last one

A typical stack has three caches in a row, and each reports separately. Open the browser’s network panel, select the document request, and read the response headers:

Cloudflare: cf-cache-status — HIT, MISS, DYNAMIC (not eligible for caching), BYPASS or EXPIRED.
LiteSpeed: x-litespeed-cache — hit or miss. With ESI in use, the page can be a hit while the price fragment is served separately.
Varnish: usually X-Cache and X-Cache-Hits, though the exact header names depend on the VCL the host wrote.
WP Rocket and similar plugins: no header — look at the very end of the page source for the plugin’s HTML comment, which includes the time the cached copy was generated.
Any of them: an Age header greater than zero means somebody upstream served a stored copy.

The layers can disagree, and the disagreement is the diagnosis. Cloudflare says DYNAMIC and the price is still wrong: the leak is in the plugin or the server cache. Plugin comment says the copy is fresh, Cloudflare says HIT: the plugin is doing the right thing and the CDN is serving the previous country over the top of it. And if you have configured a Vary or a cache key on country, the second profile’s first request must be a MISS. A HIT there means the key is not being applied to this URL.

Not only the product page

The product page is where people look, so it is where the exclusions and the workarounds tend to have been applied. The other pages that print prices are separate cache entries with their own rules, and it is common for the product page to be handled correctly while the pages that lead to it are not. Repeat the same two-profile sequence for:

The home page, if it shows featured or recent products with prices.
The shop page and at least one category archive.
Search results.
A product page’s related-products and upsell blocks — these are part of the same cached document, but their prices come from a different code path than the main product’s.
Any page with a mini-cart in the header that shows a subtotal.

If you are on the JavaScript-fetch approach, where the page is cached once and the prices are filled in by a request per page, check that the endpoint itself is not being cached at the CDN. It is a GET request to a URL that does not change, which is exactly what a CDN caches by default. The symptom is identical to a leaked page, and the page will look innocent because the placeholders are there.

Change country mid-session, then walk to the cart

The tests so far cover a visitor who arrives from one country and stays there. Two transitions break differently.

First, a country change within one session. In one profile, browse a product, then change the country — at the checkout address fields, or through whatever switcher the shop provides — and go back to the product page. WooCommerce now has an address on the session and will tax the cart accordingly. Whether the product page follows depends on whether the cache was told that this visitor is now someone else. If the page still shows the old country’s price, the visitor has one price on the page and another in the cart, and it is the cache, not the tax engine, that is lying.

Second, the walk from browsing to the cart. Add the product from the cached page, open the cart, proceed to checkout. Every step after the first is uncached and computed against the real location. Compare the line-item price at each step with the price the product page showed. Any change between the product page and the cart is a leak that the earlier tests missed — most often because the product page was served before the session existed and the cart was computed after it did.

WooCommerce ships its own partial answer to this, the “Geolocate (with page caching support)” option under default customer location, which redirects the visitor to the same URL with a hash of their location as a query string so that each country gets its own cache entry. It works if every layer honours query strings in the cache key and nobody has configured the CDN to strip them — which is another thing this test reveals.

Keep the load test separate

Once the prices are right, load-test — but as a separate exercise, with the host’s permission, and against a representative mix. Fetching the home page ten thousand times measures the CDN, not the shop: after the first request every one of them is a HIT and never reaches PHP. A real day on an EU shop is a mix of countries, which under a per-country cache means a lower hit rate than a single-country test will ever show, plus carts and checkouts, which are never cached at all. That is the traffic that has to fit on the server.

The two tests answer different questions and are easy to conflate because both come back with a number. One is “is the number right,” the other is “how fast does it arrive.” A fast wrong price fails the first and passes the second, and it is the first that costs you a customer.

The checklist

Two browser profiles, country signal delivered the way production delivers it, cache configured as in production.
Product URL: warm in A, open in B, compare each to the tax rule. Purge, reverse, repeat.
Read the cache status at every layer — CDN, server, plugin — on every request.
Same sequence for the home page, the shop page, one category, search, and the related-products block.
If prices are fetched by JavaScript, confirm the endpoint is not cached at the CDN.
Change the country in one session and revisit the product page.
Add to cart from a cached page and compare the price at every step to checkout.
Load test afterwards, separately, with a browsing-and-cart mix.

Building a WooCommerce store for the EU? WebKoding makes self-hosted WooCommerce plugins — including SplitVAT for products that carry more than one VAT rate — bought once, no subscriptions. Browse the plugins →

Originally published on webkodingtheme.com. I build self-hosted WordPress and WooCommerce plugins at WebKoding.

“Past-due actions found; something may be wrong” — the fix

WebKoding — Tue, 03 Nov 2026 07:00:00 +0000

The notice means jobs WooCommerce queued more than a day ago still have not run. Nothing is corrupt; the runner that should process them is not being started. Here is what the queue is, why it stalls, how to drain it, and how to keep it from filling again.

What exactly triggers the notice

Action Scheduler: 1,240 past-due actions found; something may be wrong. Read documentation »

Action Scheduler is the job queue inside WooCommerce. Anything that should happen later or in the background — sending a webhook, running an import in chunks, generating analytics, a subscription renewal, an abandoned-cart email from a plugin — is written to the queue as a “pending action” with a date. A runner is supposed to pick up due actions every minute and execute them.

The notice is printed on admin pages when at least one pending action has a scheduled date more than 24 hours in the past. That is the whole test: pending, and overdue by a day. It is checked at most every six hours, which is why the number on the notice can lag behind what the list shows. It says nothing about why the actions did not run; it only says the runner has not got to them.

Click the past-due actions link, or go to WooCommerce → Status → Scheduled Actions and filter by Past-due. The hook names in that list tell you what is not happening on your shop right now: woocommerce_deliver_webhook_async means webhooks are not being delivered, wc-admin_import_orders means Analytics is behind, and so on.

How the runner is supposed to start

Action Scheduler registers a WP-Cron event, action_scheduler_run_queue, on a one-minute schedule. Each run processes a batch of up to 25 actions and stops after 30 seconds, then the next minute’s run continues. Only one batch runs at a time. There is also an async runner that fires a background request when an admin page loads and actions are due, which is why a stalled queue often lurches forward when somebody logs in.

WP-Cron is not a real cron. It runs when a visitor requests a page, on that visitor’s request. So the entire mechanism depends on two things: page views arriving regularly, and each of those page views being allowed to spawn the cron request. When either fails, the queue fills and the notice appears.

The five causes, in the order to check them

DISABLE_WP_CRON is set in wp-config.php and no system cron replaced it. Hosts and caching guides recommend the constant; the second half of the advice — “and add a real cron job” — is the part that gets skipped. Nothing runs, ever, except on admin page loads.
The site gets too little traffic to trigger WP-Cron. A B2B shop with thirty visits a day gets thirty chances a day to run a 30-second batch. A queue that receives more work than that never catches up.
Page cache serves every page without touching PHP. If Cloudflare, Varnish or a full-page cache plugin serves the whole site from cache, WP-Cron is never spawned by visitors at all; only uncached requests count.
The cron request cannot reach the site. WP-Cron works by the site making an HTTP request to its own wp-cron.php. A firewall, HTTP authentication on a staging site, a wrong siteurl, or DNS that resolves the domain to a different server from inside the box all break that loopback silently. WooCommerce → Status → System status → WordPress environment shows a WP-Cron loopback test.
The batch keeps dying before it finishes. A single action that fatals or hits the PHP memory limit takes the batch down with it, and the same action is picked up first next time. The queue looks stalled while the runner is actually being killed once a minute. Check the error log, and look for one hook name at the top of the past-due list with a very old date.

Draining the queue

Once the cause is fixed, the backlog still has to run. A few hundred actions will clear on their own within an hour of a working cron. Thousands will not, because the runner only gets 30 seconds a minute and other work keeps arriving. Run it from the command line, where it has no time limit:

# Process everything that is due, 100 at a time, until the queue is empty
wp action-scheduler run --batch-size=100

# Only the webhook deliveries, if that is what matters right now
wp action-scheduler run --hooks=woocommerce_deliver_webhook_async

Before you drain, decide whether every one of those actions should still happen. Twelve hundred abandoned-cart emails from three weeks ago should not go out today. Filter the list by hook, and for hooks whose actions are no longer wanted, use Cancel on the list rather than running them. Cancelled actions are kept for the log and then removed by the cleaner.

If the actionscheduler_actions table itself has grown to millions of rows, the queue will be slow even when it works, because every query scans it. The cleaner removes completed actions after a month and failed ones after three; a long-broken queue can accumulate far more than that. wp action-scheduler clean, or deleting rows with status complete or canceled older than a month, brings it back.

Keeping it from filling again: a real cron

The durable fix is the same for every cause: stop depending on visitors. Disable WP-Cron’s visitor trigger and have the server call it on a schedule instead.

# wp-config.php
define( 'DISABLE_WP_CRON', true );

# crontab -e  (every minute, as the web user)
* * * * * cd /var/www/shop && wp cron event run --due-now >/dev/null 2>&1

# Or, without WP-CLI, request the file directly
* * * * * curl -s https://shop.example/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Every minute is right, not every five: Action Scheduler’s own schedule is per minute, and a runner that is called less often simply does less work. On a busy shop, add a second entry that runs wp action-scheduler run directly so the queue is not limited to WP-Cron’s 30-second batches at all.

The checklist

WooCommerce → Status → Scheduled Actions → Past-due: which hooks, how old is the oldest.
wp-config.php: is DISABLE_WP_CRON set, and if so, is there a system cron actually calling the site?
WooCommerce → Status: does the WP-Cron loopback check pass?
Full-page cache: does any request reach PHP without a logged-in user?
Error log: is one action fataling and killing every batch?
Drain with wp action-scheduler run; cancel what should no longer happen.
Install a per-minute system cron so it does not happen again.

What was lost while the queue was stalled

Most queued work is harmless to run late. Webhooks are the exception. An order.created webhook delivered three days after the order is a fulfilment system, a CRM or an accounting tool that learned about the sale three days late — or, if the webhook had already been switched off after failed deliveries, never learned at all. Action Scheduler keeps one line per attempt; it does not tell you which orders the other system is still missing.

HookPilot keeps the delivery log — Every webhook attempt with its response, retries with backoff, and a resend button for the orders that went out late or not at all — so a stalled queue is a delay, not a gap. HookPilot →

Originally published on webkodingtheme.com. I build self-hosted WordPress and WooCommerce plugins at WebKoding.

Your WooCommerce webhook is not firing. Here is the order to check things in.

WebKoding — Fri, 30 Oct 2026 07:00:00 +0000

A webhook that stops is rarely broken in the way it looks broken. WooCommerce fires it, something at the other end times out, WooCommerce marks the webhook disabled after five failures, and from then on nothing happens at all — silently, with no email and nothing on any screen you normally look at. Most of the time the integration was fine and the receiver was asleep.

First: WooCommerce disabled it and did not tell you

WooCommerce counts consecutive delivery failures. After five it sets the webhook’s status to disabled and stops trying. This is sensible — it stops a dead endpoint generating traffic forever — but nothing announces it. Go to WooCommerce → Settings → Advanced → Webhooks and look at the status column before you debug anything else. If it says Disabled, that is your answer, and re-enabling it does not resend what was missed.

Second: was it ever actually sent?

WooCommerce delivers webhooks through the scheduled-action queue, not during the request that triggered them. So the order completes, the customer sees their thank-you page, and the delivery is a separate job that runs afterwards. If Action Scheduler is stuck — a common state on shops with a large backlog, or where WP-Cron never runs because the site gets no traffic — the webhook is not failing. It is queued, and queued looks exactly like nothing happening.

Check WooCommerce → Status → Scheduled Actions, filter to Pending, and look for actions named woocommerce_deliver_webhook_async. A pile of them with dates in the past is a cron problem, not a webhook problem, and the fix is a real system cron hitting wp-cron.php rather than anything to do with the integration.

Third: what the other end actually said

WooCommerce treats any response outside 2xx as a failure, and it keeps only the last delivery per webhook. That is enough to tell you the endpoint returned 500 once; it is not enough to tell you it has been returning 500 all week, or that it returned 200 for nine orders and timed out on the tenth. The pattern is the diagnosis, and the pattern is what WooCommerce throws away.

A timeout is worth separating from a rejection. Five seconds is the default, and a receiver that does real work before replying — writing to a CRM, calling another API — will exceed it under load while being perfectly healthy. Those deliveries are lost, the order is fine, and nothing in the shop indicates a gap.

Retrying, rather than hoping

The behaviour you want is unglamorous: when a delivery fails, try again after a minute, then after a few minutes, then after an hour, and keep the whole history so you can see whether it eventually landed. That is what every payment provider does to you, and it is what a shop sending its own orders somewhere should do too.

HookPilot does the retrying and keeps the log — Every attempt with its response code and body, backoff between retries, and a webhook that stays on rather than being switched off behind your back. HookPilot →

Before you blame the plugin at the other end

Two things account for most reports. A staging site cloned from production keeps the same webhooks and starts delivering real orders to somebody’s live endpoint — check that first if deliveries doubled. And a security plugin or a host’s firewall will block outbound POSTs to an address it does not recognise, which looks identical to the receiver being down, except the receiver never saw a request at all.

Originally published on webkodingtheme.com. I build self-hosted WordPress and WooCommerce plugins at WebKoding.

EU Digital Product Passport in WooCommerce: Implementing ESPR Compliance with Structured Data and QR Codes

WebKoding — Wed, 06 May 2026 19:06:59 +0000

The EU's Ecodesign for Sustainable Products Regulation (ESPR) mandates Digital Product Passports (DPP) for most physical goods sold in Europe starting 2026–2030 (phased by category). If you run a WooCommerce store shipping to EU customers, your products will need machine-readable passports containing lifecycle data, materials, repairability scores, and recycling instructions — all accessible via a physical carrier (QR code, RFID, or datamatrix).

This article walks through how we built a self-hosted WooCommerce plugin to generate DPP-compliant structured data and printable QR codes — no third-party SaaS, no ongoing fees.

What Is a Digital Product Passport?

A DPP is a structured data record attached to a physical product containing:

Product identity: GTIN/EAN, model, manufacturer, batch/serial
Materials & substances: Bill of materials, hazardous substances (SVHC list)
Repairability: Spare parts availability, repair manual links, disassembly score
Environmental footprint: Carbon footprint (kg CO₂e), energy efficiency class
End-of-life: Recycling instructions, collection points, recyclate content %
Compliance documents: CE declaration, REACH compliance, test reports

The data must be accessible via a carrier (QR code printed on product/packaging) pointing to a URL that returns structured data in a machine-readable format (JSON-LD recommended by the EU).

1. The Data Model — WooCommerce Product Meta

We store DPP data as WooCommerce product meta, mapped to the EU DPP data model:

<?php
declare(strict_types=1);

class SP_DPP_Data_Model {

    public const FIELDS = [
        // Identity
        'dpp_gtin'                   => 'sanitize_text_field',
        'dpp_manufacturer_name'      => 'sanitize_text_field',
        'dpp_manufacturer_country'   => 'sanitize_text_field',
        'dpp_batch_number'           => 'sanitize_text_field',

        // Materials
        'dpp_main_material'          => 'sanitize_text_field',
        'dpp_recycled_content_pct'   => 'absint',
        'dpp_hazardous_substances'   => 'sanitize_textarea_field',

        // Repairability
        'dpp_repairability_score'    => 'sanitize_text_field',
        'dpp_spare_parts_url'        => 'esc_url_raw',
        'dpp_repair_manual_url'      => 'esc_url_raw',
        'dpp_warranty_years'         => 'absint',

        // Environmental
        'dpp_carbon_footprint_kg'    => 'sanitize_text_field',
        'dpp_energy_class'           => 'sanitize_text_field',
        'dpp_energy_kwh_year'        => 'sanitize_text_field',

        // End of life
        'dpp_recycling_instructions' => 'sanitize_textarea_field',
        'dpp_disassembly_time_min'   => 'absint',
        'dpp_collection_point_url'   => 'esc_url_raw',

        // Compliance
        'dpp_ce_declaration_url'     => 'esc_url_raw',
        'dpp_reach_compliant'        => 'absint',
    ];

    public function save_product_meta( int $product_id ): void {
        if ( ! current_user_can( 'edit_product', $product_id ) ) return;

        if ( ! isset( $_POST['sp_dpp_nonce'] ) || ! wp_verify_nonce(
            sanitize_text_field( wp_unslash( $_POST['sp_dpp_nonce'] ) ),
            'sp_dpp_save_' . $product_id
        ) ) return;

        $product = wc_get_product( $product_id );
        if ( ! $product ) return;

        foreach ( self::FIELDS as $field => $sanitizer ) {
            if ( isset( $_POST[ $field ] ) ) {
                $value = call_user_func( $sanitizer, wp_unslash( $_POST[ $field ] ) );
                $product->update_meta_data( '_' . $field, $value );
            }
        }
        $product->save();
    }

    public function get_passport_data( int $product_id ): array {
        $product = wc_get_product( $product_id );
        if ( ! $product ) return [];

        $data = [];
        foreach ( array_keys( self::FIELDS ) as $field ) {
            $data[ $field ] = $product->get_meta( '_' . $field );
        }
        return $data;
    }
}

2. JSON-LD Passport Endpoint (WP REST API)

The QR code points to a public REST endpoint returning JSON-LD:

<?php
declare(strict_types=1);

class SP_DPP_REST_Controller extends WP_REST_Controller {

    protected $namespace = 'sp-dpp/v1';
    protected $rest_base = 'passport';

    public function register_routes(): void {
        register_rest_route( $this->namespace, '/' . $this->rest_base . '/(?P<product_id>[\d]+)', [
            [
                'methods'             => WP_REST_Server::READABLE,
                'callback'            => [ $this, 'get_passport' ],
                'permission_callback' => '__return_true',  // Public
                'args'                => [
                    'product_id' => [
                        'validate_callback' => fn($v) => is_numeric($v),
                        'sanitize_callback' => 'absint',
                    ],
                ],
            ],
        ] );
    }

    public function get_passport( WP_REST_Request $request ): WP_REST_Response {
        $product_id = $request->get_param( 'product_id' );
        $product    = wc_get_product( $product_id );

        if ( ! $product || ! $product->is_visible() ) {
            return new WP_REST_Response( [ 'error' => 'Product not found' ], 404 );
        }

        $model = new SP_DPP_Data_Model();
        $data  = $model->get_passport_data( $product_id );

        $passport = [
            '@context' => [
                'schema' => 'https://schema.org/',
                'dpp'    => 'https://digital-product-passport.eu/ns#',
            ],
            '@type'       => [ 'schema:Product', 'dpp:DigitalProductPassport' ],
            '@id'         => get_permalink( $product_id ),
            'schema:name' => $product->get_name(),
            'schema:gtin' => $data['dpp_gtin'],
            'dpp:materials' => [
                'dpp:primaryMaterial'    => $data['dpp_main_material'],
                'dpp:recycledContentPct' => (int) $data['dpp_recycled_content_pct'],
                'dpp:hazardousSubstances' => json_decode( $data['dpp_hazardous_substances'] ?: '[]', true ),
            ],
            'dpp:repairability' => [
                'dpp:score'         => $data['dpp_repairability_score'],
                'dpp:sparePartsUrl' => $data['dpp_spare_parts_url'],
                'dpp:repairManual'  => $data['dpp_repair_manual_url'],
                'dpp:warrantyYears' => (int) $data['dpp_warranty_years'],
            ],
            'dpp:environmental' => [
                'dpp:carbonFootprintKg' => (float) $data['dpp_carbon_footprint_kg'],
                'dpp:energyClass'       => $data['dpp_energy_class'],
                'dpp:energyKwhYear'     => (float) $data['dpp_energy_kwh_year'],
            ],
            'dpp:endOfLife' => [
                'dpp:recyclingInstructions' => $data['dpp_recycling_instructions'],
                'dpp:disassemblyTimeMin'    => (int) $data['dpp_disassembly_time_min'],
                'dpp:collectionPointUrl'    => $data['dpp_collection_point_url'],
            ],
            'dpp:compliance' => [
                'dpp:ceDeclarationUrl' => $data['dpp_ce_declaration_url'],
                'dpp:reachCompliant'   => (bool) $data['dpp_reach_compliant'],
            ],
            'dpp:generatedAt' => gmdate( 'c' ),
        ];

        $response = new WP_REST_Response( $passport, 200 );
        $response->header( 'Content-Type', 'application/ld+json' );
        $response->header( 'Cache-Control', 'public, max-age=3600' );
        return $response;
    }
}

Endpoint URL: https://yourstore.com/wp-json/sp-dpp/v1/passport/123

3. QR Code Generation (No External API)

<?php
declare(strict_types=1);

class SP_DPP_QR_Generator {

    public function generate_qr( int $product_id, int $size = 300 ): string {
        $passport_url = rest_url( 'sp-dpp/v1/passport/' . $product_id );

        $cache_key = 'sp_dpp_qr_' . $product_id . '_' . $size;
        $cached    = get_transient( $cache_key );
        if ( $cached ) return $cached;

        require_once SP_DPP_PATH . 'vendor/phpqrcode/qrlib.php';

        ob_start();
        QRcode::png( $passport_url, false, QR_ECLEVEL_M, 10, 2 );
        $raw_png = ob_get_clean();

        $data_uri = 'data:image/png;base64,' . base64_encode( $raw_png );
        set_transient( $cache_key, $data_uri, WEEK_IN_SECONDS );

        return $data_uri;
    }

    public function save_qr_file( int $product_id ): string {
        $upload_dir = wp_upload_dir();
        $dpp_dir    = trailingslashit( $upload_dir['basedir'] ) . 'sp-dpp-qr/';

        if ( ! file_exists( $dpp_dir ) ) {
            wp_mkdir_p( $dpp_dir );
            file_put_contents( $dpp_dir . 'index.php', '<?php // Silence is golden.' );
        }

        $filename = 'dpp-qr-' . $product_id . '.png';
        require_once SP_DPP_PATH . 'vendor/phpqrcode/qrlib.php';
        QRcode::png( rest_url( 'sp-dpp/v1/passport/' . $product_id ), $dpp_dir . $filename, QR_ECLEVEL_M, 10, 2 );

        return trailingslashit( $upload_dir['baseurl'] ) . 'sp-dpp-qr/' . $filename;
    }
}

4. Admin Product Tab

<?php
add_filter( 'woocommerce_product_data_tabs', function( array $tabs ): array {
    $tabs['sp_dpp'] = [
        'label'    => __( 'Digital Passport', 'sp-dpp' ),
        'target'   => 'sp_dpp_product_data',
        'priority' => 85,
    ];
    return $tabs;
} );

add_action( 'woocommerce_product_data_panels', function(): void {
    global $post;
    wp_nonce_field( 'sp_dpp_save_' . $post->ID, 'sp_dpp_nonce' );
    echo '<div id="sp_dpp_product_data" class="panel woocommerce_options_panel">';

    echo '<div class="options_group">';
    woocommerce_wp_text_input([
        'id'          => 'dpp_gtin',
        'label'       => __( 'GTIN / EAN', 'sp-dpp' ),
        'description' => __( 'Global Trade Item Number', 'sp-dpp' ),
        'desc_tip'    => true,
        'value'       => get_post_meta( $post->ID, '_dpp_gtin', true ),
    ]);
    woocommerce_wp_text_input([
        'id'    => 'dpp_repairability_score',
        'label' => __( 'Repairability Score (e.g. 7.5/10)', 'sp-dpp' ),
        'value' => get_post_meta( $post->ID, '_dpp_repairability_score', true ),
    ]);
    woocommerce_wp_text_input([
        'id'    => 'dpp_carbon_footprint_kg',
        'label' => __( 'Carbon Footprint (kg CO₂e)', 'sp-dpp' ),
        'value' => get_post_meta( $post->ID, '_dpp_carbon_footprint_kg', true ),
    ]);
    echo '</div>';

    // QR preview
    $qr  = new SP_DPP_QR_Generator();
    $src = $qr->generate_qr( $post->ID, 200 );
    echo '<div class="options_group">';
    echo '<p><strong>' . esc_html__( 'DPP QR Code', 'sp-dpp' ) . '</strong></p>';
    echo '<img src="' . esc_attr( $src ) . '" width="150" />';
    echo '<p><a href="' . esc_url( rest_url( 'sp-dpp/v1/passport/' . $post->ID ) ) . '" target="_blank">'
        . esc_html__( 'View Passport JSON-LD', 'sp-dpp' ) . '</a></p>';
    echo '</div>';
    echo '</div>';
} );

5. Bulk Import via WooCommerce CSV

<?php
add_filter( 'woocommerce_csv_product_import_mapping_default_columns', function( array $columns ): array {
    return array_merge( $columns, [
        'GTIN'                => 'dpp_gtin',
        'Manufacturer'        => 'dpp_manufacturer_name',
        'Carbon Footprint kg' => 'dpp_carbon_footprint_kg',
        'Recycled Content %'  => 'dpp_recycled_content_pct',
        'Repairability Score' => 'dpp_repairability_score',
        'Energy Class'        => 'dpp_energy_class',
    ] );
} );

add_filter( 'woocommerce_product_import_pre_insert_product_object',
function( WC_Product $product, array $data ): WC_Product {
    foreach ( array_keys( SP_DPP_Data_Model::FIELDS ) as $field ) {
        if ( isset( $data[ $field ] ) ) {
            $product->update_meta_data( '_' . $field, sanitize_text_field( $data[ $field ] ) );
        }
    }
    return $product;
}, 10, 2 );

ESPR Rollout Timeline

Year	Categories
2026	Batteries, textiles, electronics
2027	Furniture, steel, cement, chemicals
2028–2030	All remaining categories

The DPP endpoint must stay accessible for the full product lifecycle — typically 10+ years after sale.

Why Self-Hosted?

DPP SaaS platforms (Circularise, Renoon, Fairly Made) charge €200–500/mo per brand. For most WooCommerce stores, a one-time plugin generating compliant JSON-LD and QR codes covers the full technical requirement without ongoing costs.

The full plugin is on CodeCanyon: EU Digital Product Passport for WooCommerce (ESPR)

Questions about the JSON-LD structure or ESPR data requirements? Drop them in the comments.

Implementing ZATCA Phase 2 E-Invoicing in WooCommerce: UBL XML, XAdES Signing, and Hash Chains

WebKoding — Wed, 06 May 2026 18:51:21 +0000

Saudi Arabia's ZATCA Phase 2 e-invoicing mandate is one of the most technically demanding compliance requirements I've encountered in WooCommerce development. It's not just generating a PDF — it's UBL 2.1 XML, XAdES-BES digital signatures, a cryptographic hash chain, TLV-encoded QR codes, and real-time API submission to government servers.

Here's how I built FatooraPro, a WooCommerce plugin that handles the full ZATCA Phase 2 flow.

What ZATCA Phase 2 Actually Requires

Every invoice must:

Be generated as UBL 2.1 compliant XML
Be digitally signed with XAdES-BES using a ZATCA-issued certificate
Include a TLV-encoded QR code with 8 specific fields
Maintain a hash chain (each invoice's hash references the previous one)
Be submitted to ZATCA's API — either for clearance (B2B) before delivery, or reporting (B2C) within 24 hours

Miss any of these and the invoice is legally invalid.

The Two Invoice Types

Standard Tax Invoice (B2B — Clearance)
Submitted to ZATCA before the invoice is delivered to the buyer. ZATCA must approve it. This means your checkout flow has to wait for an API response, or queue it and hold the invoice.

Simplified Tax Invoice (B2C — Reporting)
Submitted to ZATCA within 24 hours. More lenient — you can generate and deliver the invoice immediately, then report asynchronously.

In WooCommerce, I detect the invoice type based on whether the buyer has a VAT number (B2B) or not (B2C).

UBL 2.1 XML Structure

ZATCA requires a specific XML namespace and field order. Here's a simplified version of what the XML looks like:

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:ProfileID>reporting:1.0</cbc:ProfileID>
  <cbc:ID>INV-2026-001</cbc:ID>
  <cbc:UUID>6f4d3885-0e99-4f13-9c8b-...</cbc:UUID>
  <cbc:IssueDate>2026-05-06</cbc:IssueDate>
  <cbc:IssueTime>14:30:00</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0200000">388</cbc:InvoiceTypeCode>
  <!-- Seller info, buyer info, line items, tax totals... -->
</Invoice>

The InvoiceTypeCode name attribute is a 7-digit bitmask that encodes invoice properties (standard/simplified, credit/debit, etc.).

XAdES-BES Digital Signing

This is where it gets complex. ZATCA requires XAdES-BES (XML Advanced Electronic Signatures, Basic Electronic Signature profile). In PHP:

function sign_invoice( string $xml, string $private_key_pem, string $certificate_pem ): string {
    // 1. Canonicalize the XML (C14N)
    $dom = new DOMDocument();
    $dom->loadXML( $xml );
    $canonical = $dom->C14N( false, false );

    // 2. Hash the canonicalized XML
    $digest = base64_encode( hash( 'sha256', $canonical, true ) );

    // 3. Build SignedInfo element with digest
    $signed_info = $this->build_signed_info( $digest );

    // 4. Sign the SignedInfo with the private key
    openssl_sign( $signed_info, $signature_raw, $private_key_pem, OPENSSL_ALGO_SHA256 );
    $signature_value = base64_encode( $signature_raw );

    // 5. Embed certificate hash and signature into XML
    return $this->embed_signature( $xml, $signature_value, $certificate_pem, $digest );
}

The certificate itself is issued by ZATCA through a 4-step onboarding process: CSR generation → Compliance CSID → Simulation testing → Production CSID.

The Hash Chain (PIH/ICV)

ZATCA requires sequential invoice integrity. Each invoice must contain:

ICV (Invoice Counter Value): sequential integer starting at 1
PIH (Previous Invoice Hash): SHA-256 hash of the previous invoice's XML

This means invoices are cryptographically linked — you can't insert, delete, or modify an old invoice without breaking the chain. In WooCommerce, I store the last hash in a WordPress option and update it atomically after each successful submission:

function get_and_increment_icv(): array {
    // Use DB transaction to prevent race conditions
    global $wpdb;
    $wpdb->query( 'START TRANSACTION' );

    $current_icv  = (int) get_option( 'fatoorapro_icv', 0 );
    $previous_hash = get_option( 'fatoorapro_pih', hash( 'sha256', 'NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2YzNDkyMQ==' ) );

    $new_icv = $current_icv + 1;
    update_option( 'fatoorapro_icv', $new_icv );

    $wpdb->query( 'COMMIT' );

    return [ 'icv' => $new_icv, 'pih' => $previous_hash ];
}

The default PIH for the first invoice is a SHA-256 hash of a specific base64 string defined in ZATCA's spec.

TLV-Encoded QR Code

ZATCA's QR code uses Tag-Length-Value encoding, not a simple URL. It must contain 8 fields:

function generate_tlv_qr( array $data ): string {
    $tlv = '';
    $fields = [
        1 => $data['seller_name'],           // Seller name
        2 => $data['vat_number'],            // VAT registration number  
        3 => $data['timestamp'],             // Invoice timestamp
        4 => $data['total_with_vat'],        // Invoice total with VAT
        5 => $data['vat_amount'],            // VAT amount
        6 => $data['xml_hash'],              // Invoice XML hash (B2B only)
        7 => $data['ecdsa_signature'],       // ECDSA signature (B2B only)
        8 => $data['public_key'],            // Public key (B2B only)
    ];

    foreach ( $fields as $tag => $value ) {
        $encoded = mb_convert_encoding( $value, 'UTF-8' );
        $length  = strlen( $encoded );
        $tlv    .= chr( $tag ) . chr( $length ) . $encoded;
    }

    return base64_encode( $tlv );
}

Async Submission with WP-Cron

B2B clearance requires synchronous submission (blocking). But B2C reporting can be async. I use WP-Cron for retry logic on failures:

function schedule_submission( int $invoice_id ): void {
    wp_schedule_single_event(
        time() + 30, // 30 second delay
        'fatoorapro_submit_invoice',
        [ $invoice_id ]
    );
}

add_action( 'fatoorapro_submit_invoice', function( int $invoice_id ): void {
    $result = submit_to_zatca( $invoice_id );

    if ( ! $result['success'] ) {
        $attempts = (int) get_post_meta( $invoice_id, '_zatca_attempts', true );
        if ( $attempts < 3 ) {
            update_post_meta( $invoice_id, '_zatca_attempts', $attempts + 1 );
            wp_schedule_single_event( time() + 300, 'fatoorapro_submit_invoice', [ $invoice_id ] ); // retry in 5 min
        }
    }
} );

HPOS Compatibility

ZATCA data is stored per-order, so it needs to work with both classic order posts and HPOS. I use WooCommerce's order meta abstraction:

// Works with both post meta and HPOS order tables
$order->update_meta_data( '_zatca_status', 'cleared' );
$order->update_meta_data( '_zatca_uuid', $uuid );
$order->update_meta_data( '_zatca_qr', $qr_code );
$order->save();

The Onboarding Flow

Getting a production certificate from ZATCA requires 4 steps:

CSR generation — create a private key + certificate signing request with your VAT number embedded
Compliance CSID — submit CSR to ZATCA, get a compliance certificate back
Compliance tests — run 6 predefined test invoices against ZATCA's sandbox
Production CSID — exchange compliance certificate for production certificate

I built a 4-step wizard in WP Admin that walks store owners through this. Most of them aren't developers, so the UI has to handle the complexity invisibly.

I packaged all of this into FatooraPro — a complete ZATCA Phase 2 solution for WooCommerce stores in Saudi Arabia: FatooraPro, a ZATCA Phase 2 WooCommerce plugin · FatooraPro on CodeCanyon

Happy to go deeper on any part — the XAdES signing and hash chain were the most challenging pieces.

WooCommerce Only Allows One Tax Rate Per Line Item — Here's How I Solved It

WebKoding — Wed, 06 May 2026 18:30:54 +0000

WooCommerce has a limitation that quietly causes legal compliance issues for thousands of stores across Germany, Austria, France, and other EU countries: you can only assign one tax class per line item.

For most stores this is fine. But if you sell brunch tickets, hotel packages, event passes, or any product that legally requires multiple VAT rates on a single invoice — you have a problem.

The Real-World Problem

Take a brunch ticket priced at €39. In Germany, food is taxed at 7% and beverages at 19%. Since January 1, 2026, the German BMF (Bundesministerium der Finanzen) requires that invoices for such products show the split explicitly:

Item	Net	VAT	Gross
Food portion (80%)	€29.16	7% → €2.04	€31.20
Drinks portion (20%)	€6.55	19% → €1.24	€7.80
Total	€35.71	€3.28	€39.00

Without the split, your invoice is legally non-compliant — the customer overpays VAT by €2.94, and your tax report is wrong. Similar requirements exist in Austria, Switzerland, and France.

Why WooCommerce Can't Do This Natively

WooCommerce's order data model stores tax per line item as a single tax class. There is no native concept of sub-items within a line item — you can't attach two different tax rates to one product without fundamentally changing how the order is stored.

The Approach: Virtual Split Parts in Order Meta

The solution is to store split rules on the product, then at order creation inject virtual line items into order metadata — one per split part — while keeping the customer-facing display as a single product.

Step 1: Product-Level Split Rules

// Stored as product meta: _splitvat_rules
$rules = [
    [
        'label'      => 'Food portion',
        'percentage' => 80,
        'tax_class'  => 'reduced-rate', // 7% in Germany
    ],
    [
        'label'      => 'Drinks portion',
        'percentage' => 20,
        'tax_class'  => 'standard',     // 19% in Germany
    ],
];

Step 2: Hooking Into Order Creation

add_action(
    'woocommerce_checkout_create_order_line_item',
    function( $item, $cart_item_key, $values, $order ) {
        $product = $item->get_product();
        $rules   = get_post_meta( $product->get_id(), '_splitvat_rules', true );

        if ( empty( $rules ) ) {
            return;
        }

        $split_parts = splitvat_calculate_parts( $item->get_total(), $rules );
        $item->add_meta_data( '_splitvat_parts', $split_parts, true );
        $item->add_meta_data( '_splitvat_enabled', true, true );
    },
    10, 4
);

Step 3: Penny-Perfect Rounding

Splitting €39 into 80/20 is clean, but many totals produce floating point rounding errors. The "remainder on last" algorithm fixes this:

function splitvat_calculate_parts( float $total, array $rules ): array {
    $parts      = [];
    $allocated  = 0.0;
    $last_index = count( $rules ) - 1;

    foreach ( $rules as $index => $rule ) {
        if ( $index === $last_index ) {
            $amount = round( $total - $allocated, 2 ); // remainder — no drift
        } else {
            $amount    = round( $total * ( $rule['percentage'] / 100 ), 2 );
            $allocated += $amount;
        }
        $parts[] = array_merge( $rule, [ 'amount' => $amount ] );
    }

    return $parts;
}

This guarantees split parts always sum to exactly the original total.

Step 4: HPOS Compatibility

If you're on WooCommerce High-Performance Order Storage, always use the order abstraction layer — not direct SQL:

// Always use this
$orders = wc_get_orders([
    'status'     => ['completed', 'processing'],
    'meta_query' => [[
        'key'   => '_splitvat_enabled',
        'value' => true,
    ]]
]);

Accounting Export Formats

Different countries need different export formats:

DATEV Buchungsstapel — Germany (direct import into tax advisor software)
BMD/RZL — Austria (Steuercode + Kontenrahmen mapping)
FEC — France (18 mandatory fields, required by tax authorities)
CSV — Universal (Excel, Google Sheets, any tool)

The Key Insight

Orders are immutable records. Do the heavy lifting at checkout, store the computed split in order item meta, and read it back whenever you need it (invoices, exports, reports). Trying to recalculate after the fact is unreliable — prices and tax rates can change.

I packaged all of this into SplitVAT — 13 country presets, 4 export formats, and integrations for the major WooCommerce invoice plugins. If you're dealing with this compliance problem: SplitVAT on CodeCanyon

Happy to go deeper on any part of the implementation.

Dead Stock is Silently Killing Your WooCommerce Store (And How to Find It)

WebKoding — Wed, 25 Mar 2026 07:20:33 +0000

Most WooCommerce store owners focus on what's selling. But the real profit killer is what isn't selling — dead stock.

What is dead stock?

Dead stock is inventory that hasn't sold in 60+ days and has more than a few weeks of stock remaining. It's capital sitting in your warehouse doing nothing — and often getting worse:

Storage costs keep accumulating
Products may expire, go out of fashion, or become obsolete
Cash that could fund better-selling products is locked up
Eventually it becomes a write-off

The detection formula

In StockPulse, I flag a product as dead stock when:

current_stock > minimum_threshold
AND
units_sold_last_60_days = 0
AND
days_of_stock_remaining > 60

Simple, but surprisingly revealing when you run it across your full catalog.

What to do with dead stock

1. Bundle it — pair slow movers with bestsellers. A customer buying a $50 product might add a $10 dead-stock item for $5.

2. Run a clearance sale — even 20-30% margin recovery is better than a full write-off.

3. Return to supplier — if your agreement allows it, especially for newer inventory.

4. Liquidate wholesale — sell in bulk at cost to clear warehouse space.

5. Donate for tax benefit — in some countries, donated inventory generates a tax deduction.

Prevention with reorder discipline

The best cure is prevention. StockPulse's reorder point system means you only reorder what you're actually selling, and in quantities aligned with your real velocity — not gut feeling or "round numbers."

If your daily velocity on a product is 0.3 units/day and your lead time is 14 days, you need a reorder point of about 6 units — not the 50 you ordered "just in case."

See your dead stock in real time

The StockPulse Reports page shows all dead stock products at a glance, sorted by estimated capital tied up. It's often the first time store owners see the full picture — and the numbers are usually surprising.

Try the live demo at https://stockpulse.webkodingtheme.com or grab it on CodeCanyon: https://codecanyon.net/item/stockpulse-inventory-forecast-sales-intelligence-for-woocommerce/62458013

How I Implemented Inventory Forecasting Algorithms in a WordPress Plugin

WebKoding — Wed, 25 Mar 2026 07:17:52 +0000

When building StockPulse, the core challenge was: how do you calculate reliable inventory forecasts when different products have wildly different sales patterns?

Here's a breakdown of the forecasting engine I built.

Three velocity algorithms, automatic selection

The SP_Velocity_Calculator class implements three approaches:

Simple Moving Average (SMA) — baseline, used when less than 90 days of data exists:

$velocity = array_sum($daily_sales) / count($daily_sales);

Weighted Moving Average (WMA) — recent days get higher weight:

$total_weight = ($n * ($n + 1)) / 2;
$weighted_sum = 0;
foreach ($daily_sales as $i => $sales) {
    $weight = $i + 1;
    $weighted_sum += $sales * $weight;
}
$velocity = $weighted_sum / $total_weight;

Exponential Smoothing — alpha=0.3 by default (configurable per product):

$smoothed = $daily_sales[0];
foreach (array_slice($daily_sales, 1) as $actual) {
    $smoothed = ($alpha * $actual) + ((1 - $alpha) * $smoothed);
}
$velocity = $smoothed;

The engine auto-selects: less than 90 days of history → SMA, 90+ days → WMA.

Reorder point formula

public function calculate_reorder_point(
    float $daily_velocity,
    int $lead_time_days
): float {
    $safety_stock = $daily_velocity * ($lead_time_days * 0.25);
    return ($daily_velocity * $lead_time_days) + $safety_stock;
}

The 25% safety buffer accounts for supplier delays and demand spikes.

Seasonal adjustment (prototyped, not shipped)

$seasonal_coefficient = $same_period_last_year / $last_month_average;
$adjusted_velocity = $base_velocity * $seasonal_coefficient;

I prototyped this, but it is not in the released plugin. StockPulse's velocity is a moving average of recent sales and nothing reads last year's orders, so a product that peaks every December will look slow in October. For seasonal lines, set the low-stock threshold with the season in mind.

HPOS compatibility

WooCommerce's High-Performance Order Storage moved orders to custom tables. Instead of querying wp_posts directly:

$orders = wc_get_orders([
    'status'     => ['wc-completed'],
    'date_after' => date('Y-m-d', strtotime('-90 days')),
    'return'     => 'ids',
    'limit'      => -1,
]);

Caching architecture

All calculations are stored in wp_stockpulse_product_cache with a 24-hour TTL, refreshed daily via WP-Cron.

What's next

v1.1 will add purchase order PDF generator and ABC analysis.

Product page: StockPulse, a WooCommerce inventory forecasting plugin
Plugin: https://codecanyon.net/item/stockpulse-inventory-forecast-sales-intelligence-for-woocommerce/62458013
Live demo: https://stockpulse.webkodingtheme.com

I Built a WooCommerce Inventory Forecasting Plugin — Self-Hosted, No Monthly Fees

WebKoding — Wed, 25 Mar 2026 07:13:29 +0000

After months of development, I just launched StockPulse — a WooCommerce plugin that turns your order history into an inventory intelligence system.

The problem I was solving

Running a WooCommerce store means constantly answering questions like:

"How many days of stock do I have left for each product?"
"When should I reorder before I run out?"
"Which products have been sitting in my warehouse for 60+ days with zero sales?"

The existing solutions are either expensive SaaS tools ($49–199/month) or ancient CodeCanyon plugins that haven't been updated since 2017. I wanted something self-hosted, one-time payment, no external API calls.

What StockPulse does

Days of Stock Remaining — calculates how many days your current stock will last based on your actual sales velocity.

Smart Reorder Points — tells you exactly when to reorder, factoring in your supplier lead time plus a 25% safety buffer:

reorder_point = (daily_velocity × lead_time_days) + safety_stock
safety_stock = daily_velocity × (lead_time_days × 0.25)

Dead Stock Detection — flags products with 60+ days of stock and zero recent sales so you can run promotions before they become a write-off.

30/60/90-day demand forecasts — projects future demand using three algorithms (SMA, WMA, Exponential Smoothing) with automatic selection based on data availability.

Email alerts — notifies you when products hit critical stock levels.

CSV export — full data export for deeper analysis.

The tech stack

Built with PHP 7.4+ (OOP, PSR-4 structure), vanilla JS + Chart.js for the admin dashboard, WordPress REST API for data endpoints, and WP-Cron for daily cache refresh.

Fully HPOS-compatible (uses wc_get_orders() — no raw SQL on order tables).

Why self-hosted matters

All calculations happen on your server
No data leaves your store
GDPR compliant by design
No API key to manage, no service to go down

Live demo + CodeCanyon

Product page: StockPulse, a WooCommerce inventory forecasting plugin
Demo: https://stockpulse.webkodingtheme.com
CodeCanyon: https://codecanyon.net/item/stockpulse-inventory-forecast-sales-intelligence-for-woocommerce/62458013

Would love feedback from the WooCommerce/WordPress dev community. What features would you want to see in v1.1?