ErreD EU Order Withdrawal for WooCommerce -- WordPress 插件

开发者	draison recessodigitale
更新时间	2026年10月16日 23:15
PHP版本:	8.2 及以上
WordPress版本:	7.1
版权:	GPLv2 or later
版权网址:	版权信息

0.9.0 A store selling both goods and services can now count each one's withdrawal period from the right moment, and a multilingual store's translations finally follow the withdrawal settings of the product they translate.

New: "Withdrawal period starts from", on every product and product category, next to the withdrawal status. Goods are counted from delivery, services and digital content from the purchase. Until now this was a single setting for the whole store, so a shop selling, say, T-shirts and course enrolments had to pick one, and one of the two always got the wrong deadline. A product you leave alone inherits from its category, then from the store-wide setting, so nothing changes until you choose. If a product sits in two categories that disagree, delivery wins: it is never earlier than the purchase, so a contradictory setting can cost you a few days but never cost the customer their right.
New: when an order mixes the two, each item gets its own deadline. The withdrawal form shows each item's date next to it instead of one date for the whole order, which could not have been true for both. In strict mode, an item whose period has ended can no longer be selected while the rest of the order stays withdrawable; before, one deadline decided for every item at once.
New: the request detail on the withdrawal requests screen lists each withdrawn item's period, what it is counted from, and whether the request was sent within it, after it but within your extra days, after it, or before the period started (a customer may withdraw before delivery). It is worked out from the order and your product settings as they are now, and says so: a guide for your decision, not part of the receipt. It stays available after the order has been refunded or cancelled.
Fix: on sites translated with WPML or Polylang, a translated product or category ignored the withdrawal status set on the original. Its exclusion, its product-page notice and its checkout consent silently disappeared in every other language, so a product you had excluded could be withdrawn from in translation. Translations now follow the original, as does the new "Withdrawal period starts from"; a value set on the translation itself still wins, for an exception that genuinely differs by market, and the product editor of a translation shows which value it is inheriting. Present since per-product statuses were introduced in 0.3.0.
Fix: within a single page load, an order whose status changed could still be described as it was before the change. WooCommerce sends the "order completed" email in the same request that completes the order, so the withdrawal paragraph in that email could miss the delivery date it had just been given. The result is now recalculated whenever an order is saved.
Changed: the withdrawal paragraph in your order emails and the acknowledgement of receipt now name the right starting point for the items concerned, and both starting points when an order mixes them. The acknowledgement for a store counting from the conclusion of the contract used to tell the customer their period ran "for goods" from the conclusion of the contract; it now says what it means.
Fix: "Delete all data on uninstall" left the withdrawal status set on products and categories behind in the database. It now removes it, together with the new setting. Present since per-product statuses were introduced in 0.3.0.
For developers: two new filters, recesso_dig_original_product_id and recesso_dig_original_category_id, let another multilingual plugin declare a translation's original. The admin request detail returns item_periods. The eligibility REST endpoint returns line_windows, each item's own period. The existing window_starts_at and window_ends_at now summarise the items — earliest start, latest end, and no end while an item's period has not started. On an order whose items share one period, which is every order until you use the new setting, they are unchanged.

0.8.1 A customer pasting their order number the way WooCommerce prints it could never get a withdrawal link, and was never told why.

Fix: the order lookup rejected an order number entered with the leading # — which is exactly how WooCommerce shows it in the confirmation email a customer copies from. Because the screen answers identically whether or not an order matched (so nobody can discover which order numbers exist), the customer was told a link had been sent and then waited for one that was never going to arrive. Order numbers now also survive a stray space and a difference in leading zeros. Present since the lookup screen was introduced in 0.5.0. Two references that are genuinely different orders still do not match.
New: the intro paragraph and the two field hints on the lookup screen can now be removed, not only reworded. Emptying the text was never a way to remove a line — it restored the bundled wording — so each now has its own tickbox, and the hint under the order number field became editable at the same time.
New: the withdrawal form tells the customer when their withdrawal period ends, in your site's date format. The date was already worked out and never shown; they were given a duration and left to do the arithmetic. The wording follows your enforcement setting, so the advisory default does not promise a cut-off the plugin will not apply.
New: you can add your own sentence, and a contact link, below the explanation a customer sees when their order cannot be withdrawn from (Order Withdrawal: settings → Order lookup screen). The explanations themselves state the legal position and stay as they are, but they used to end the conversation with no way for the customer to reach you.
Fix: the intro paragraph on the lookup screen had no spacing of its own, so on themes that do not space paragraphs it sat directly on the first field's label.
Fix: on the settings screen, the greyed suggestion inside six fields — the trader details and the two consent texts — was double-escaped, so an apostrophe showed as '. The four trader fields also had no description at all, and the phone field showed nothing greyed with no explanation of why.
The withdrawal acknowledgement and the withdrawal-link email are always sent, whatever the enable switch in WooCommerce → Settings → Emails says. That was already true and deliberate; now each says so in its description on that screen, instead of showing a switch that quietly does nothing. Three code comments claimed these emails were exempted for a different reason that turned out not to hold, and are corrected.

0.8.0 The withdrawal page is now yours to word and to colour, without touching code or waiting for a translation.

New: the four texts on the order lookup screen — page title, intro paragraph, the hint under the email field, and the submit button label — are settings, under WooCommerce → Order Withdrawal: settings → Order lookup screen. Until now they were the only customer-facing copy in the plugin with no field of its own, which meant the first screen many customers see was the one screen a merchant could not reword. Leave a field empty to keep the bundled sentence, which follows each customer's language; your own wording can be translated per language with WPML or Polylang.
New: a colour for the withdrawal page's buttons, under Withdrawal page appearance. Pick any colour and the plugin works out the hover shade and the label colour from it, so the label keeps a WCAG AA contrast ratio whatever you choose — a pale brand colour cannot leave you with white text nobody can read.
New: "Inherit my theme's button style", in the same section, for stores whose theme already styles its buttons the way they want them everywhere. The plugin then stops styling those buttons entirely. It stays off by default: the withdrawal page is an ordinary page, where a theme's button rules are not guaranteed to load, and the shipped styling is what keeps the control from rendering as bare text.
Fix: with "Delete all data on uninstall" enabled, the wording you had written for the dated-service exclusion notice (Art. 16(l)) was left behind in the database instead of being removed. Two rows, no effect on how the site ran, but the setting promises a clean removal and did not deliver one. The plugin's own version marker was left behind for the same reason. Present since 0.6.0, and now covered by a test that checks every setting the plugin writes against the list of what it deletes.

0.7.0 Customers can now follow their withdrawal requests from their account, and a withdrawal page that has been deleted or unpublished no longer fails silently.

New: the My Account "Right of withdrawal" tab lists the requests the customer has sent — when it was sent, the order, the scope, the current status, the note you wrote when you decided it, and the receipt verification code — alongside the orders they can still withdraw from. Previously the tab listed eligible orders only, so sending a request made the order disappear from it and left the customer reading "None of your orders is currently eligible for withdrawal". The acknowledgement and status emails link to the same screen.
New: the receipt PDF is reachable from that tab for as long as the account exists. The link in the acknowledgement email is signed with a token that expires after 60 days, and until now that was the only route to it — a durable medium the consumer can no longer open is not durable.
New: the My Account orders list shows the withdrawal control on an eligible order, and the request's status on an order already withdrawn from. It showed neither before.
New: the Article 14(4)(a) service-start consent can be made mandatory (Withdrawals → Settings → Checkout consents). Off by default, because asking for the service to start inside the withdrawal period is the customer's choice to make; useful where the service always begins inside that window, such as live sessions or bookings.
New: four developer filters for the checkout consents — recesso_dig_consent_render_hook and recesso_dig_consent_render_priority move the checkboxes on the classic checkout (an empty hook suppresses the render), recesso_dig_consent_applies decides per cart whether each consent is asked for, and recesso_dig_consent_required makes either one blocking or optional. All hooks are now documented under "Hooks for developers" below.
New: an "Edit your details" link on the confirmation step, back to the form. Re-submitting replaces the unconfirmed request rather than adding a second one.
Fix: a withdrawal page that was deleted, trashed or unpublished sent every withdrawal link to the shop front page instead — customers arrived with a valid link, no form and no explanation. Links are now suppressed rather than misdirected, and the settings screen and an admin notice say what is wrong with the page. The settings screen also stops describing your home page as the withdrawal form when no page is selected.
Fix: an expired or already-used link submitted from a stale form produced an unstyled "You are not authorized to perform this action" page outside your theme, with no way back. It now explains what happened on the withdrawal page and offers the form that sends a fresh link.
Fix: returning to the confirmation step for a request already sent re-showed the success screen as though the withdrawal had just been recorded. It now says the request is already on record and when it was sent. Reaching the form again for an order already withdrawn from says the same, instead of a bare "a request is already in progress".
Fix: the message screen printed whatever text the address bar carried. It was correctly escaped, so it was never a scripting hole, but it did let a crafted link display wording of someone else's choosing inside your withdrawal page. Only messages this plugin defines can be shown now.
Fix: accessibility of the public form — the consumer declaration told screen readers to announce its own label twice, the order-lookup fields had no description attached, and a validation error was not moved to on re-render.
Two links in the requests screen were built with a helper that HTML-escapes the URL it returns. That is correct when printing a link into a page, and wrong for a URL handed to the admin app as data and set straight onto a button: the browser then sent amp;request instead of request, so the server never saw the parameters and refused. Both are fixed and covered by tests that fail against the old form.
Fix: Export CSV failed with "The link you followed has expired". The export nonce never reached the server. Present since 0.3.0.
Fix: opening a durable-medium receipt from the request detail panel failed with "You are not authorized to perform this action". Present since 0.5.1, and it affected every receipt opened from that panel, whatever the age of the withdrawal. The Download link in the no-JavaScript requests table was never affected by either bug.
A receipt link that cannot be matched to a withdrawal record no longer reports an authorisation failure. Merchants are told the record could not be read and pointed at the requests screen, where a pending database upgrade finishes; everyone else still gets the same generic refusal, so the endpoint cannot be used to discover which requests exist.
A merchant following an old receipt link — from an acknowledgement email, or a bookmark, whose signed token has since expired — is now taken to that request in the admin instead of a permissions error. The file itself still requires a freshly signed link.

0.6.1 Superseded by 0.7.0, which contains these fixes. Never released separately. Two links in the requests screen were built with a helper that HTML-escapes the URL it returns. That is correct when printing a link into a page, and wrong for a URL handed to the admin app as data and set straight onto a button: the browser then sent amp;request instead of request, so the server never saw the parameters and refused. Both are fixed, and both are now covered by tests that fail against the old form. These are the only two places where the plugin builds a URL server-side and hands it to JavaScript.

Fix: Export CSV failed with "The link you followed has expired". The export nonce never reached the server. Present since 0.3.0.
Fix: opening a durable-medium receipt from the request detail panel failed with "You are not authorized to perform this action". Present since 0.5.1, and it affected every receipt opened from that panel, whatever the age of the withdrawal. The Download link in the no-JavaScript requests table was never affected by either bug.
A receipt link that cannot be matched to a withdrawal record no longer reports an authorisation failure. Merchants are told the record could not be read and pointed at the requests screen, where a pending database upgrade finishes; everyone else still gets the same generic refusal, so the endpoint cannot be used to discover which requests exist.
A merchant following an old receipt link — from an acknowledgement email, or a bookmark, whose signed token has since expired — is now taken to that request in the admin instead of a permissions error. The file itself still requires a freshly signed link.

0.6.0

Checkout consents now work in the WooCommerce Checkout block, not only the classic shortcode checkout. They are registered through WooCommerce's Additional Checkout Fields API, so the checkboxes are rendered, validated and stored by WooCommerce itself — accessible markup and block-theme styling included. Requires WooCommerce 8.9 or newer for the block checkout; the classic checkout is unchanged and works on every supported version.
New option: show each consent only when the cart contains a product classified for it (the digital-content box with art. 16(m) items, the service box with art. 14(4)(a) items), using the "Withdrawal status" already set on the product or category. Off by default, so nothing changes on update; turn it on under Checkout consents.
New "Right of withdrawal" tab in My Account, listing the customer's currently eligible orders with the «recedere dal contratto qui» control for each. Can be switched off under Withdrawal link visibility.
New [recesso_digitale_link] shortcode (attributes: text, class) for footers, widgets and menus, and [recesso_digitale_avviso_esclusione] for product templates built with a page builder (Divi, Elementor, Bricks and similar) whose layouts do not fire the usual WooCommerce hook.
The settings screen is considerably more configurable, and every field now says whether it is mandatory, recommended or optional:
which order statuses offer the withdrawal function (a checkbox list of every registered status, previously fixed to Processing and Completed);
which roles, besides the administrator, may view and manage requests — access is granted and revoked the moment you save, and is never offered to customer-facing roles;
a From name and From address for the plugin's own emails only;
the wording of the accepted, rejected and completed customer emails;
the intro paragraph above the public form (text and on/off);
an optional "bought as a consumer" self-declaration on the form, recorded verbatim in the durable-medium receipt for B2B disputes;
separate title and body for each exclusion notice — digital content (art. 16(m)), dated services (art. 16(l)) and the other art. 16 exceptions — with a {withdrawal_page_link} placeholder.
The requests screen now lists recent unmatched lookups: attempts to request a withdrawal link whose order number and email matched no order, so a mistyped reference is visible instead of vanishing silently. No withdrawal record is created for them, and the submitted address is stored masked.
Fix: a decision taken through the request detail panel's "Set status" dropdown — the main path since 0.5.0 — wrote no order note. Accepting, rejecting, completing and resetting a decision now all appear in the order timeline.
Fix: the "default policy for unconfigured products" setting declared one default and applied another. Both are now "Allow withdrawal", which is what running sites have always used.
Fix: the settings screen and the CSV export required manage_woocommerce while the requests list required the plugin's own capability. All three now use the plugin capability, which the new roles setting controls.
Fix: an opted-in "delete all data on uninstall" left two options behind.
Hardening: an in-place upgrade whose table can no longer take another column (InnoDB "row size too large", possible after several upgrades) now rebuilds the table and completes, instead of leaving a half-applied schema that breaks the requests screen until a manual re-activation.
Every merchant-editable text is now exposed to WPML and Polylang String Translation; the previous configuration file covered only five of them.
Database: one new optional column (consumer_declaration), applied automatically. Receipts issued before this release keep verifying against their stored hash — the receipt payload is versioned, and a request without a self-declaration hashes exactly as it did before.

0.5.10

Compatibility with WordPress 7.1 and WooCommerce 11. Verified against the WordPress 7.1 release candidate with WooCommerce 11.0.1: full integration and end-to-end suites, including the accessibility checks, pass unchanged.
Admin: the requests screen now opts in explicitly to the 40px control size that WordPress 7.1 makes the default, so the status filter, the search field and the action buttons keep their intended alignment on every supported WordPress version instead of changing height silently.
Security: the bundled Dompdf library, used to render the durable-medium receipt, is updated from 3.1.5 to 3.1.6. That release fixes six reported issues, including a local file read and a file-existence disclosure through SVG images embedded as data URIs, and two denial-of-service paths through oversized image bitmaps. This plugin never enabled remote resource loading and its receipt template contains no images, SVG or custom fonts, so exposure was limited; the library is updated regardless.
Admin: the requests bundle is now loaded with the deferred script strategy.
The minimum supported WordPress version is now 6.9, matching the minimum required by the WooCommerce releases this plugin is built against. Nothing in the plugin itself required the change: WooCommerce 11 already refuses to run below WordPress 6.9, so the previous floor of 6.7 could not be satisfied in practice.
No database migration and no changes to the withdrawal flow, the durable-medium receipt or the legal timestamps.

0.5.9

Fix: the order-lookup form never actually sent the withdrawal-link email. WooCommerce does not autoload its WC_Email base class, so on the front-end request the send bailed out before the email was built. The mailer is now initialised first, so the link is delivered.
Order-lookup: the link is emailed whenever the submitted order number and email match, regardless of the order's current eligibility — a legitimate consumer always gets a response on their own address, and the declaration screen explains any ineligibility (e.g. an expired window) when the link is opened.

0.5.5

Withdrawal page: visiting the page without a signed link (e.g. via the persistent footer link) now shows an order-lookup form instead of a blank page. The consumer enters their order number and the email used on the order, and the plugin emails a secure, signed withdrawal link to that order's address. The link is never rendered inline and the response is always uniform, so orders cannot be enumerated; requests are rate-limited per IP and protected by a honeypot.
New "Withdrawal link request" email (WooCommerce → Settings → Emails) carries the requested link.

0.5.4

Admin: the WooCommerce menu entries and the requests-page heading now default to English ("Order Withdrawal", "Order Withdrawal: settings"); Italian sites keep the previous «Recesso digitale» labels via the bundled it_IT translation.

0.5.3

Uninstall: only the withdrawal page auto-created by the plugin is removed. The page is now identified by a created-by-plugin marker (and must still host the withdrawal shortcode), so a pre-existing page the merchant selected in settings is never deleted.

0.5.2

The withdrawal function is now a single «recedere dal contratto qui» button shown below the order details, available to both guest-checkout customers (order-received page) and logged-in members (My Account order view); the previous duplicate button is gone and the link no longer reports "this withdrawal link is not valid or has expired".
Confirmation step: removed the (unnecessary) product thumbnail and gave the «conferma recesso» button a proper, accessible button style that no longer depends on the theme.
Admin: unconfirmed (abandoned) declarations no longer appear in the requests list or its counts, and a consumer who closed the page before confirming can start a fresh request.
Admin: the menu badge counts all open requests awaiting action (confirmed and acknowledged) and uses the standard WooCommerce/WordPress menu-counter styling.

0.5.1

Packaging: the distribution now bundles the full, human-readable JS/CSS source (assets/) and the build manifests (package.json, package-lock.json) alongside the compiled build/ assets, and the readme documents how to rebuild them and links the public development repository.
Dependency: the bundled Dompdf library is updated from 3.0.0 to 3.1.5.
Hardening: the admin receipt download link now carries a nonce that the download endpoint verifies for the admin path (the consumer link continues to use its signed, rate-limited token).
Hardening: saving a product's withdrawal status now verifies the WooCommerce editor nonce and the edit_product capability explicitly.

0.5.0

New "Withdrawal" column on the WooCommerce orders screen (HPOS and the legacy list) showing each order's current withdrawal decision as a colour-coded badge.
The request detail panel now sets the decision through a single "Set status" dropdown (Pending, Accepted, Rejected, Completed) with a "Save status" button next to "Regenerate receipt". The reason field appears only when rejecting (and stays required); the orders column updates to match.
Hardening: the contract reference stored for a withdrawal is now always derived server-side from the order number, ignoring any client-supplied value on the REST create endpoint.
Hardening: the receipt download endpoint now validates the stored path against an exact directory boundary, preventing a similarly named sibling directory from being treated as the protected store.
Packaging: reproducible production builds (installed from composer.lock) and a direct-access guard added to the generated PHP asset files in the distribution.

0.4.0

Product/category "Withdrawal status" now offers the specific art. 59 / Directive classifications (standard, digital content art. 16(m), service started early art. 14(4)(a), dated accommodation / transport art. 16(l), other art. 16 exception) instead of a plain allow/exclude, and each maps to the right eligibility outcome. Statuses saved by earlier versions keep working.
A one-time welcome notice after activation links straight to the settings and the auto-created withdrawal page.
Reorganised the settings screen into clear sections (General, Withdrawal deadline, Article 16 exclusions, Checkout consents, Model withdrawal form, Excluded products notice, Withdrawal link visibility, Data), added a notification email and a withdrawal-page selector, a "show model form" toggle and an optional trader phone number.
The Annex I.B model withdrawal form was redesigned to match the statutory layout (header block with the trader's details, fillable lines, source attribution and an optional printable view).

0.3.1

Fix: an in-place update now reliably adds the v4 optional columns — the installed schema version is only advanced once the columns actually exist, so the requests admin list and the withdrawal form no longer break until a manual re-activation.
Hardening: the withdrawal declaration never white-screens — a transient persistence failure degrades to a friendly message instead of a fatal error (the legally-required function stays usable).

0.3.0

Art. 59 configuration: per-product and per-category "Right of withdrawal" status (allow / exclude / inherit) in the product and category editors, plus an opt-in "excluded from withdrawal" notice on the product page.
Checkout consents: optional, configurable digital-content (art. 16(m)) and service-start (art. 14(4)(a)) consents, recorded on the order with timestamps and an order note.
Annex I.B model withdrawal form (printable), populated with configurable trader contact details, shown below the public form and via the [recesso_digitale_modulo] shortcode.
Order notes mirror the withdrawal lifecycle; new customer emails on accept/refund/complete and an admin notification (multiple recipients) when a withdrawal is confirmed.
Admin: Accept / Mark completed / Mark refunded actions, an at-a-glance stats summary and a CSV export of requests.
GDPR: personal-data exporter and eraser (anonymises personal data while retaining the legal acknowledgement) and a suggested privacy-policy snippet.
Optional refund IBAN and reason fields on the declaration (carried into the durable receipt), honeypot anti-spam, an optional persistent footer link, an optional strict deadline-enforcement mode with grace days, and a wpml-config.xml for WPML/Polylang.

0.2.0

Redesigned the consumer withdrawal page: products are chosen with checkboxes, each shown with its thumbnail, and a per-product quantity selector appears only when more than one unit was purchased.
The durable-medium acknowledgement email now lists every selected product with its quantity, along with the confirmation email and the declaration timestamp, matching the PDF receipt.
The two-step confirmation («conferma recesso») and the completion screen now itemise exactly which products and quantities are being withdrawn.
Internal: item resolution unified in one shared component used by the receipt, email and on-screen summaries; the tamper-evident receipt hash is unchanged.

0.1.0

Initial development release.
Security-first, HPOS-native withdrawal channel: continuously available function, two-step server-rendered declaration/confirmation flow, signed rate-limited guest access.
Durable medium: acknowledgement email plus a protected, tamper-evident PDF receipt with a write-once legal timestamp (dies a quo), generated asynchronously via Action Scheduler.
Conservative, configurable, fail-closed eligibility engine (window, start trigger, art. 59 exclusions) with filters for integrators.
React admin: list, status filter, free-text search, audit timeline, receipt view/regenerate, process actions, and a menu badge for requests awaiting action.
Optional WooCommerce Subscriptions adapter (withdrawal cancels the subscription).
Merchant-decides model: the 14-day period is advisory (shown to the merchant), the withdrawal function stays available, and the merchant accepts or rejects each request. Rejection requires a reason, recorded in the audit trail and emailed to the consumer.
Accessibility to WCAG 2.2 AA (axe-verified) and a complete it_IT translation.

ErreD EU Order Withdrawal for WooCommerce

标签

下载

详情介绍:

安装:

屏幕截图:

升级注意事项:

常见问题:

更新日志: