← Wróć do Withdrawv1.6.0 (16 wydań)

Historia zmian Withdraw

Historia zmian dostępnej wtyczki Withdraw: aktualizacje, poprawki i rozwój funkcji dla WooCommerce.

v1.6.0

Fixed: the form intro and the model withdrawal text shipped as English sentences in a config file and were printed to the customer word for word. A config default cannot be translated, so every non-English shop showed its customers English until an admin noticed and rewrote it by hand. Both are now generated and translatable.
New: the model withdrawal form (Annex I.B) is built from your own details, the seller name, the WooCommerce store address, the email and the phone, in the language of the site. Leave the setting empty to use it; anything you type still wins.
New: seller name, email and phone settings for those texts. Empty falls back to the site title and the admin email, so the form always names somebody. The screen warns when the WooCommerce store address is empty, because without it there is no geographical address to state.
New: a `[withdraw_instructions]` shortcode rendering the model instructions on withdrawal (Annex I.A) for your terms or returns page, generated from the same details and from your withdrawal period, so it cannot drift out of step with what the form enforces. Attributes `heading="no"` and `form="no"` trim it. The `withdraw/model_instructions` filter is there for the service-contract and digital-content paragraphs a particular catalogue needs.
The return-cost sentence appears in those instructions only once you have set the rule. It is the very notice Article 6(1)(i) requires before the contract, so generating it by default would create the notice a shop then relies on.
On update, an intro or model text left exactly as it shipped is cleared so the generated wording takes over. Anything you edited, including a hand translation, is matched exactly and kept.

v1.5.0

Fixed: the request log stopped at the newest 100 rows with no way past them, so on a busy shop older declarations were unreachable from wp-admin. It now pages 25 at a time, and a bookmarked page that no longer exists lands on the last one instead of an empty table.
Fixed: the log accepted a search argument that nothing ever passed to it. There is now a search box, matching on customer email or order number, and it works together with the status filter.
New: a detail screen per request, reached from the ID column. It shows what the list could not: the reason the customer gave, the declaration they confirmed, both timestamps and your own refund deadline. The access token stays off the page, because it is a credential rather than a record.
New: a note field next to the status control, and a rejection now requires one. "Your withdrawal request could not be accepted" with no reason gives the customer nothing to act on and leaves you no record of why you refused. The note is printed in the email, for every status, so it also works as "your parcel arrived, the refund goes out on Tuesday".
Fixed: re-saving a status without retyping the note no longer wipes it, and editing the note alone no longer sends the customer a second identical message.
The status counts on the filter links are now real numbers rather than plain labels.

v1.4.0

New: every message the plugin sends is now a WooCommerce email. They use your store template, logo and footer, and each one has its own entry under WooCommerce, Settings, Emails where it can be reworded, restyled or switched off on its own. Seven of them: the declaration acknowledgement, the shop notification, one per request status, and the guest access link.
New: the shop notification keeps its own recipient field. Left empty it uses the notification address already set under WooCommerce, Withdrawal, so nothing moves for a shop that never opens the emails screen.
New: the acknowledgement stores the declaration as the customer confirmed it and repeats back those exact words, rather than rebuilding the sentence when the mail is sent. A later translation, a renamed product or a reworded template can no longer change what a past customer is told they declared.
New: the acceptance message carries the Article 14(1) information. Where to send the goods back, taken from a new return address field or from your WooCommerce store address, the deadline counted from the day the customer declared rather than from the day you accepted, and who bears the direct cost of the return.
New: a setting for who pays to send the goods back. It says nothing until you choose, because Article 14(1) only lets you charge the customer if you told them so before the sale, and a default that assumed otherwise would have the plugin make a claim on your behalf that may not hold.
New: the request log shows your own Article 13(1) deadline, 14 days from the day the customer told you they were withdrawing, and marks it in red once it has passed. It counts from the declaration, not from your acceptance, which is the clock the law actually puts you on.
Changed: the acceptance message no longer says the 14 days run from that message. They run from the declaration, so a shop that took a week to accept was quietly giving the customer a week too long.

v1.3.0

Fixed: saving a request's status twice sent the customer a second identical email, and a status outside the allowed list still mailed them the generic "being reviewed" message for a write the database had refused. Both introduced with the status emails in 1.0.8.
New: Article 16(m) consent for digital content, off by default. When switched on, a cart holding a downloadable product gets one optional, unticked checkbox at checkout carrying both halves of the statement: the request to begin supply immediately and the acknowledgement that the right of withdrawal is lost once supply has begun. It renders on the classic checkout and on the block checkout, and the block version hides itself on carts with no downloadable item.
New: the consent is recorded on the order with the moment it was given, the exact wording shown at the time, and the products that were downloadable when the order was placed, so editing the wording later cannot rewrite what an earlier customer agreed to. Nothing is written unless the order really holds a downloadable item, whatever the checkout posted.
New: the consent is confirmed back to the customer on the order screen and in the order email. Article 16(m) only excludes the right if the trader also gave that confirmation, so it is part of the feature rather than an option.
New: an order screen panel showing whether consent was given, declined or never offered, in which words, and whether each covered product has actually been downloaded, which is what decides whether the exclusion applies at all.
New: once supply has begun for a consented item, that item is dropped from the withdrawal form and refused on the server, not merely hidden. If every item in the order is covered, the order is refused with its own reason. WooCommerce cannot see downloads it did not serve, so files delivered by email or an external portal always read as not begun and stay withdrawable; the `withdraw/digital_supply_begun` filter is there for those shops.
New: an optional emailed one-time link for guest access, off by default. Turned on, the lookup step mails a single-use token to the billing address on the order rather than opening the form, answers identically whether the order exists or not, and rate limits requests per address and per IP. Only the hash of a token is stored, tokens expire after an hour, and one is spent when a declaration is actually submitted. Leave it off and the form behaves exactly as it did.
New: on the keyed flow the form no longer emits an order or address field the customer could edit, so whoever holds a link cannot redirect the acknowledgement email somewhere else, and a link stops working if the shop changes the order's billing address after sending it.
Fixed: the panel shown after requesting a link printed a nonce that nothing ever verified, on a button that did not send a second link. The nonce is gone and the button says what it does.
Fixed: the rate limiter restarted its window on every attempt, so it never drained while attempts kept coming. Anyone who knew a customer's billing address could have kept that address over the cap indefinitely, silently, because the flow answers the same either way. The window is now fixed.

v1.2.0

Fixed: the form asked for the order number and then looked the order up by its database id. On a stock WooCommerce install those are the same value, so nothing looked wrong, but any plugin that renumbers orders breaks the pair: the shop printed a number in its own emails that its own withdrawal form then rejected. The lookup now resolves the displayed number, falling back to the id, with a `withdraw/resolve_order_number` filter for other numbering schemes.
Fixed: the status email addressed the order by its database id rather than the number the customer sees, for the same reason.
New: withdrawals are written into the order's own notes, both when the declaration arrives and when its status changes. The request log is a separate screen nobody has open; whoever opens the order next now sees what happened without knowing this plugin exists.

v1.1.0

New: a separate confirmation step. Choosing items and declaring withdrawal used to be one click. Article 11a(3) requires a confirmation control carrying no wording other than "confirm withdrawal", which only means something if the customer can read the declaration first, so the declaration is now shown back in full on a step of its own before anything is stored.
New: the declaration carries the customer's name, the contract it refers to and their electronic contact details, which is what Article 11a(2) asks a withdrawal statement to contain. The name is prefilled from the order and stored with the request.
New: the acknowledgement email is now a durable record under Article 11a(4). It repeats the declaration in full and states the date and time it was submitted, instead of only saying the request arrived.
New: `[withdraw_link]` shortcode and an optional footer link. Article 11a(1) requires the function to be easily accessible for the whole withdrawal period, and the My Account control only reaches a signed-in customer already looking at that order, so a guest had no way in.
Changed: the control now reads "Withdraw from contract here", the wording Article 11a(1) prescribes, instead of "Withdraw from this order".

v1.0.8

Fixed: a withdrawal could be recorded without the customer ever ticking the declaration. The checkbox carried only the browser's `required` attribute and the server never looked at it, so a request posted without it was stored as a valid declaration. That record is the whole point of the plugin, so it is now refused server-side and nothing is written.
Fixed: the order link in the request log used the classic post editor URL, which does not open an order once HPOS is on, while the plugin declares HPOS compatibility. It now picks the right URL for whichever order storage the shop uses.
Fixed: the confirmation sent to the customer ended with "We will confirm the next steps by email" and no code ever sent that email. Changing a request's status now writes to the customer, and the accepted message carries the 14-day return deadline and the refund method, which is information the trader owes anyway.

v1.0.7

Renamed to Plogins Withdraw so the name leads with the brand rather than a generic word, as the plugin review asked.
Removed the "Tested up to" header from the main PHP file. It belongs in readme.txt only, where it is already declared; in both places the header can override the readme and show a compatibility version that was never intended.

v1.0.6

Translations: refreshed the bundled `plogins-withdraw.pot`, which had fallen behind the code. It was missing five strings from the withdrawal declarations admin screen and the privacy eraser, and still carried the plugin's pre-rename name. That template is what translators work from.
Translations: corrected the Spanish catalogue, which called the right of withdrawal "retiro" throughout. Spanish consumer law calls it *desistimiento*, and the plugin's own description already used that term while its interface did not.

v1.0.5

Tested against WordPress 7.1. Verified by activating this build on a clean 7.1 install with WooCommerce 11.1, not by editing the header.

v1.0.4

New: withdrawal declarations are now covered by the WordPress personal-data tools. A privacy export includes a shopper's declarations, and an erasure request removes them, so a subject access or deletion request can be answered from the standard screen instead of by hand.
Declared compatibility with WooCommerce 10.9.
Copy: replaced long dashes with plain punctuation across the interface.
Housekeeping: the release package no longer carries the translation catalogues, which come from the WordPress.org language packs.

v1.0.3

Corrected the German and Polish translations: "withdrawal" was rendered as "Auszahlung" (payout) in German and "wypłata" (payout) in Polish; both now use the correct right-of-withdrawal terms (Widerruf / odstąpienie od umowy). Also fixed a German grammar slip and standardised the Polish wording.

v1.0.2

Added bundled Polish, German and Spanish translations for the plugin interface.

v1.0.1

First stable release.

v0.1.1

Plugin Check: escaping/sanitisation/i18n/hygiene fixes (table-name identifiers now passed via %i placeholders in prepared statements).

v0.1.0

Initial release: `[withdraw_form]` shortcode (order lookup + full/partial item selection), My Account withdrawal button, configurable withdrawal period and eligible statuses, admin request log with statuses, customer and shop emails, editable model withdrawal text. HPOS + Blocks compatible.

Wróć do Withdraw