Returino – Formular de retur for WooCommerce
| 开发者 | nord95 |
|---|---|
| 更新时间 | 2026年7月14日 02:26 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
Returino adds a public 2-step withdrawal / return-request form to your WooCommerce store, built for Romania's OUG 18/2026 requirements on digitising the withdrawal process (an online-accessible form and a durable-medium confirmation). The withdrawal right itself — the 14-day period, the exceptions and the refund — is governed by OUG 34/2014, which OUG 18/2026 amends rather than replaces.
The customer identifies their own order (order number + billing email), selects exactly which products to return — partial returns, not just the whole order — and receives a durable-medium email confirmation with the exact details of the request.
Key features:
- Public 2-step form, without leaving your site — no external platform and no customer account required.
- Partial returns: the customer picks exactly which products and quantities to return, not the whole cart.
- Strict server-side validation — products and quantities are read straight from the order, not from what the customer's browser submits.
- IBAN requested only when it's actually needed (cash on delivery, bank transfer) — card payments are refunded automatically to the card, with no IBAN prompt.
- The return reason is optional — the customer can submit the request without filling one in.
- Rejection reasons: define a list of preset reasons, then on rejection pick one or type it on the spot — the (mandatory) reason is sent in the customer's email, shown on the request in My Account and on the admin request panel, and added as an order note.
- Per-category rules: exclude certain categories from returns (the legal exceptions to the right of withdrawal — art. 16 of OUG 34/2014) or grant them a longer window — never under 14 days. Ineligible products are clearly marked on the form.
- One active request per order: while one is in progress the customer can't open another; after it's resolved they can come back for the remaining items, and a rejection allows a fresh attempt.
- Instant durable-medium email confirmation with the customer's name, order number, exact products and the exact date/time of the request — useful for any consumer-protection (ANPC) checks.
- The form page is created automatically on activation (if one doesn't already exist) — nothing to set up by hand.
- Dedicated "Returino" admin menu with all requests, real columns (Order, Client, Status, Items, Request date) and a status filter.
- A clear approve/reject panel on each request — one click, without confusing "Publish"-style terminology.
- Optional email notifications: to the admin on a new request, to the customer on approval/rejection — on top of the legal confirmation, which is always active.
- Direct integration into the WooCommerce order screen (HPOS-compatible) — see at a glance whether an order has linked return requests.
- A "My return requests" tab in the customer's My Account, for logged-in customers.
- WooCommerce active (declared explicitly via
Requires Plugins).
安装:
- Instalează și activează pluginul (Plugins → Add New, sau upload manual).
- Asigură-te că WooCommerce e instalat și activ.
- La prima intrare în admin după activare, pluginul creează automat o pagină cu formularul de retur (dacă nu găsește deja una cu shortcode-ul
[returino_return_form]) și îți arată un notice cu link către ea — adaug-o în meniul din footer sau altă zonă vizibilă a site-ului. - Dacă preferi altă pagină, o alegi din dropdown-ul „Pagina de retur” din Returino → Setări. Shortcode-ul trebuie pus direct în conținutul paginii — nu printr-un widget sau page builder, altfel stilurile/scripturile nu se încarcă automat.
- Cererile de retur apar în meniul Returino din admin.
常见问题:
Unde trebuie pus shortcode-ul ca să funcționeze corect?
Direct în conținutul unei pagini (bloc Shortcode sau editor clasic). Adăugat prin widget sau page builder, formularul poate tot apărea, dar stilurile/scripturile nu se încarcă automat.
Motivul returului e obligatoriu?
Nu, e opțional. Clientul poate trimite cererea fără să completeze un motiv.
Cere IBAN de la toți clienții?
Nu. IBAN e cerut doar pentru comenzi plătite ramburs sau prin transfer bancar. La plata cu cardul, câmpul nici nu apare — rambursarea se face automat pe card.
Cum aprob sau resping o cerere de retur?
Deschizi cererea din Returino → Toate Retururile. În panoul „Stare cerere de retur” din dreapta ai trei butoane: „Marchează în procesare”, „Aprobă cererea”, „Respinge cererea” — un click, fără reîncărcare de pagină. Aprobarea/respingerea trimite automat emailul corespunzător clientului (dacă e activat în Setări) și adaugă o notă pe comandă.
Ce se întâmplă dacă un produs din comandă a fost șters ulterior?
Formularul afișează o imagine placeholder și numele produsului salvat pe linia comenzii — nu depinde de produsul mai existând în catalog.
E compatibil cu High-Performance Order Storage (HPOS)?
Da, compatibilitate declarată explicit; meta box-ul de pe ecranul comenzii funcționează atât cu tabelele custom de comenzi, cât și cu stocarea clasică bazată pe postări.
Site-ul e în spatele unui proxy/CDN (Cloudflare) și formularul se blochează pentru toți vizitatorii?
Limitarea de încercări la căutarea comenzii (10 căutări eșuate / 15 minute) se bazează implicit pe adresa IP a conexiunii (REMOTE_ADDR). În spatele unui proxy invers sau CDN precum Cloudflare, această adresă poate fi cea a proxy-ului, nu a vizitatorului — caz în care toți vizitatorii ajung să împartă aceeași limită.
Dacă site-ul tău chiar rulează în spatele unui astfel de proxy, poți suprascrie sursa IP-ului cu un filtru (ex. într-un plugin de site sau functions.php):
add_filter( 'returino_rate_limit_ip', function ( $ip, $server ) { return $server['HTTP_CF_CONNECTING_IP'] ?? $ip; }, 10, 2 );
Folosește acest filtru doar dacă site-ul chiar e în spatele acelui proxy — altfel, orice vizitator îl poate ocoli trimițând el însuși acel antet.
更新日志:
1.2.6
- Changed: plugin user-facing strings now use English as the source language (WordPress i18n standard). Sites set to English show English text; Romanian and other locales load from translation files.
- Added: bundled Romanian translation (ro_RO) in languages/, including .po and .mo files, so ro_RO sites keep the same Romanian UI as before.
- Removed: duplicate get_admin_labels(); status labels are unified through get_statuses() (Pending, Processing, Approved, Rejected).
- New: rejection reasons. Merchants can define a list of preset reasons in Settings, and rejecting a request now requires a reason — pick a preset or type one on the spot. The reason is sent in the customer's rejection email, shown on the request in My Account and on the admin request panel, and added to the linked order note. Works from both the request edit screen and the quick actions on the WooCommerce order screen.
- New: per-category withdrawal rules. Exclude specific product categories from returns (the legal exceptions to the right of withdrawal — art. 16 of OUG 34/2014: personalised, sealed-then-unsealed, perishable goods, etc.) or grant them a longer window than the standard one (never shorter than 14 days). Ineligible products are shown disabled with an explanation on the form, and the rule is re-enforced server-side so it can't be bypassed.
- New: one active request per order. While a request is pending or being processed, the customer can't open a second one for the same order — they see its status in My Account instead. Once it's resolved they can submit again: approved quantities are deducted (a line can't be returned more times than it was purchased), while a rejection frees the item up for another attempt.
- Change: the minimum configurable withdrawal period is now 14 days, the statutory minimum under OUG 34/2014 — a longer window can still be set, a shorter one can't.
- Change: the "Powered by Returino" credit in the confirmation email and on the public form now links to returino.com (UTM-tagged), so store owners can attribute the traffic. The email keeps its raster mark, which remains the most reliable choice across email clients.
- Fixed a legal-source error: the withdrawal exceptions (personalised, sealed-then-unsealed, perishable goods, etc.) are defined in OUG 34/2014, art. 16 — not OUG 18/2026, which only mandates the digital process (button, form, durable-medium confirmation). Corrected throughout the description and any user-facing text that misattributed them.
- Admin menu icon is now the Returino mark instead of a generic dashicon.
- Updated the plugin directory banner artwork. No code changes.
- Updated the readme's Description/Installation/FAQ to match the 1.2.0/ 1.2.1 changes — Installation no longer tells you to create the return page by hand (it's created automatically), and there's a new FAQ entry on how to approve/reject a request.
- Renamed the "Credit Returino" setting to "Logo Returino" with a clearer description of what the checkbox does.
- Replaced the classic editor's native "Publish" box for return requests with a dedicated "Stare cerere de retur" panel — no more "Publish"/ "Published" terminology that meant nothing here. Shows the current status plainly and three one-click actions (Mark as processing / Approve / Reject), applied instantly over AJAX. Approving or rejecting still triggers the existing order note and customer email automatically, same as before.
- Admin return-request list reworked: real columns (Order, Client, Status, Items, Confirmation email, Request date) instead of the generic title/date WordPress gives a CPT by default. Removed the "Add New" button (requests only ever come from the customer form), the "Mine" view and the "All dates" dropdown (neither meaningful here), and added a Status filter dropdown.
- New request titles no longer include the customer's name (now meta + its own column only) — keeps it out of revisions and global admin search. Existing request titles are left as they are.
- A return-form page is now created automatically if one doesn't already exist (searches for a page already using the shortcode first, so nothing is duplicated). Configurable from Returino → Settings; shows a one-time notice pointing at the page so it can be linked from the site's navigation, as OUG 18/2026 requires the process to be clearly visible, not just technically present.
- Added optional (on by default) email notifications: to the store admin on a new request, and to the customer when a request is approved or rejected. These are in addition to the mandatory durable-medium confirmation, which still cannot be disabled. Each tracks its own sent/failed delivery status via wp_mail_failed, same as the confirmation email.
- Fixed a critical bug (WordPress core #24415): custom post statuses need
both
show_in_admin_all_listandprotectedset to appear in the admin list's "All" view — only the first was set, so the list table's "All (N)" count and the actual rows shown disagreed, and return requests could go unnoticed. Addedprotected => true(keptpublic => false— requests are still never queryable from the front end). - One-time migration moves any request still stuck on the native "Published" status (residue from the bug fixed in 1.0.9) back to Pending, and logs a note on its linked order. Runs on admin_init and self-disables after running once; trashed requests are left untouched.
- Fixed the order-lookup rate limiter to key off a validated IP address
instead of trusting REMOTE_ADDR blindly — sites behind a reverse
proxy/CDN (e.g. Cloudflare) could otherwise have every visitor share
one throttling bucket, turning the anti-enumeration protection into an
accidental site-wide lockout. Added a
returino_rate_limit_ipfilter for sites that need to supply the real visitor IP (see FAQ). A successful lookup now also clears that visitor's failed-attempt count. - Renamed the wp_ajax_oug18_ AJAX action/nonce names to
wp_ajax_returino_ (code only, no stored data affected — the
_oug18_*post meta keys are unchanged).
- Renamed the plugin to "Returino – Formular de retur for WooCommerce" (previously "Returino for WooCommerce") for better discoverability when searching in wp-admin.
- The "Powered by Returino" credit on the public form is now opt-in and disabled by default (Returino → Settings) — previously it showed automatically. Existing installs will stop showing it until enabled.
- Added per-IP throttling on order lookup (max 10 failed attempts / 15 minutes) against order-number enumeration.
- Unified the order-lookup error message so it no longer reveals whether the order number or the email was the wrong part.
- Renamed the internal "oug18-" prefix (markup/CSS/JS) to "returino-".
- Added a server-side guard (wp_insert_post_data) so a return request can never be saved with a status other than our own four, regardless of which admin UI path is used (Quick Edit, bulk edit, REST API, etc.) — the previous fix only covered the classic per-post editor.
- Fixed a bug where opening/saving a return request in wp-admin silently reset its status to "Published" (the classic edit screen didn't recognize our custom statuses), making it disappear from the order screen and the customer's My Account tab. The custom statuses are now registered in that screen's status dropdown.
- Small performance improvements.
- Added subtle Returino branding to the email footer and the form.
- IBAN is now only required for payment methods that can't be refunded automatically (cash on delivery, bank transfer). Card/wallet payments skip the IBAN field entirely, both in the form and in validation.
- Track each confirmation email's delivery status (sent/failed), captured via wp_mail_failed, and show it on every return request in admin.
- "Resend confirmation" button — resends the exact original content, not a rebuilt one.
- "Send test email" tool on the settings screen.
- Confirmation content is now saved in the database independent of email delivery, and shown to the logged-in customer under My Account → "Cererile mele de retur" — a durable-medium safety net that doesn't depend on the email actually arriving.
- Dashboard/list notice and an admin-menu count bubble for failed confirmation emails, so failures surface without relying on email.
- Renamed to Returino for WooCommerce to avoid confusion with an unrelated, unaffiliated existing company of the previous name.
- Replaced generic "woo"/"wc" prefixes (namespace, constants, CPT slug, statuses, shortcode tag) with a distinct "returino" prefix.
- Removed the GitHub-based update checker in favor of native wordpress.org updates.
- Text domain aligned with the plugin slug.
- Meta box on the WooCommerce order screen showing linked return requests.
- Automatic order note whenever a request's status changes.
- Explicit HPOS compatibility declaration.
- Initial release: custom post type + statuses, 2-step front-end form, AJAX validation, confirmation email, admin meta box, Returino menu.