Title: AnyTry – AI Virtual Try-On for WooCommerce
Author: Paweł Piórek
Published: 31 جولای 2026
Last modified: 7 اکتبر 2026
---
جستجوی افزونهها
# AnyTry – AI Virtual Try-On for WooCommerce
توسط [Paweł Piórek](https://profiles.wordpress.org/piezak/)
[دانلود](https://downloads.wordpress.org/plugin/anytry-ai-virtual-try-on-for-woocommerce.1.0.35.zip)
* [جزئیات](https://fa.wordpress.org/plugins/anytry-ai-virtual-try-on-for-woocommerce/#description)
* [نقد و بررسیها](https://fa.wordpress.org/plugins/anytry-ai-virtual-try-on-for-woocommerce/#reviews)
* [نصب](https://fa.wordpress.org/plugins/anytry-ai-virtual-try-on-for-woocommerce/#installation)
* [توسعه](https://fa.wordpress.org/plugins/anytry-ai-virtual-try-on-for-woocommerce/#developers)
[پشتیبانی](https://wordpress.org/support/plugin/anytry-ai-virtual-try-on-for-woocommerce/)
## توضیحات
AnyTry is an AI-powered virtual try-on system that lets your customers see how they’ll
look wearing your products before they buy. The plugin integrates directly with
WooCommerce product pages, adding a “Try On” button that uses cutting-edge generative
AI.
### External services
This plugin connects to the AnyTry API (https://api.anytry.ai) to generate virtual
try-on images using generative AI. Using the plugin requires an AnyTry account (
a free trial is available from the plugin settings screen).
**What the plugin uses the AnyTry API for:**
* **Try-On generation** — submitting the customer photo together with the product
image, following the job’s progress (a real-time stream, with polling as a fallback),
cancelling a job when the customer closes the dialog mid-generation so the reserved
processing is released, and fetching the finished image. Result images are only
ever fetched over HTTPS from `api.anytry.ai` or an `*.anytry.ai` subdomain.
* **AI Size Advisor** — a size recommendation, requested only when the merchant
has enabled the feature and the customer completes the quiz.
* **Account and administration** (operator workflow only; never customer-facing)—
creating the free-trial account on first activation (admin email, WordPress username
and store domain only), sending the activation magic-link email, recovering an
existing API key, single sign-on to the AnyTry Portal, validating the configured
key on the Settings screen and in the background after the key changes or the
plugin is upgraded (retried until the account can be identified; these checks
send only the key, no order or customer data), and loading the figures shown
on the plugin’s own admin Settings screen.
* **Analytics and conversion attribution** — funnel events (button impressions,
generation completes, add-to-cart, checkout start, purchases, refunds), an abandon
event when the customer closes the window mid-generation, and order attribution.**
Gated on analytics consent, which is OFF by default on new installs.**
The Try-On feature works whether or not analytics is enabled. Enable analytics at
WooCommerce AnyTry AI “Send analytics & conversion events”.
**What is sent to the AnyTry API:**
* The customer photo uploaded via the Try-On modal (transmitted only when the customer
explicitly clicks “Try On”).
* The product image URL and product identifier from WooCommerce.
* A random session identifier (no personally identifiable information).
* WooCommerce order ID and product IDs on order completion — **only when analytics
consent is enabled**.
* Optional: height, weight, and usual size values the customer enters in the AI
Size Advisor quiz.
**When the data is sent:**
* Try-On generation: when a customer uploads a photo and clicks “Try On” on a product
page.
* Size Advisor: when a customer completes the AI Size Advisor quiz.
* Conversion events: when an order containing a tried-on product is placed — **
only when analytics consent is enabled**.
**Cookies (server-set, persistent):**
* `anytry_session` cookie (90 days) — stores the random session ID and the list
of product IDs the visitor has tried on, used to attribute orders to try-on sessions
for the conversion dashboard. **Set only when analytics consent is enabled.**
* `anytry_tried` cookie (90 days) — stores a fallback list of tried product IDs
for cases where `anytry_session` is unavailable (third-party cookie blockers,
REST checkout flows). **Set only when analytics consent is enabled.**
* `anytry_legal_accepted_v2` cookie (1 year) — remembers that the customer has
accepted the Try-On legal/age-consent overlay so they are not asked again on
every page. Set ONLY after the customer clicks “Accept” on the legal overlay.
Not used for any analytics or attribution.
**Persistent browser storage (localStorage):**
* `anytry_lang` — the language chosen in the widget, used to restore that choice
on later visits.
* `anytry_legal_accepted_v2` — mirror of the consent cookie above, same purpose,
same trigger. No analytics or attribution use.
* `anytry_tried` — client-side mirror of the `anytry_tried` cookie value, used
when third-party cookies are blocked. **Written only when analytics consent is
enabled.**
* `anytry_tried_products` — same purpose as `anytry_tried` but stored in a structured
per-product map; used by the admin Conversions tab to attribute orders to try-
on sessions. **Written only when analytics consent is enabled.**
* `anytry_canonical_session_id` — a random `sess_*` identifier kept across reloads
so the API can JOIN a try-on generation event to a later purchase event for conversion
attribution. **Persisted only when analytics consent is enabled.** When consent
is off, an ephemeral id is held in memory for the current page only and never
written to localStorage.
* `anytry_active_jobs` — short-lived registry of in-flight try-on jobs (job IDs
+ status), used so the floating “still working…” widget can resume after a page
reload. Cleared when the job finishes or after 24 hours. Not used for any analytics
or attribution.
**Ephemeral per-tab storage (sessionStorage):**
These stores are scoped to the current browser tab. They support the Try-On interface
and, when analytics consent is enabled, retry failed analytics events. A photo stored
here powers the local before/after toggle; when the widget restores an earlier try-
on (for example after a page reload), that stored photo can also be sent with a
Size Advisor request the customer initiates. Quiz answers may likewise be reused
in such a request. The plugin’s other uploaded-photo cache is described under IndexedDB
below.
* `anytry_before_` — the photo the customer uploaded, kept so the “before/
after” toggle works after a result is generated.
* `anytry_result_` and `anytry_result_image` — the generated result image
data URL, used so the same result re-renders instantly when the customer reopens
the modal in the same tab.
* `_anytry_result_cache_order` — job identifiers in cache order, used to evict
older result images when the per-tab image cache reaches its limit.
* `anytry_feedback_state` — whether the customer already rated 👍 / 👎 the current
result.
* `anytry_quiz_user_height`, `anytry_quiz_user_weight`, `anytry_quiz_usual_size`,`
anytry_quiz_skipped` — Size Advisor quiz answers, kept so the customer doesn’t
have to re-enter them while comparing multiple try-ons.
* `anytry_size_recommendation`, `anytry_size_` and `anytry_size__p` — cached Size Advisor responses, which may include estimated
body measurements and recommended sizes, used to restore the recommendation for
the photo and product.
* `anytry_tab_id` — a random identifier used to keep track of which browser tab
owns an active try-on job after a reload.
* `anytry_pending_submit` — a pending request’s random idempotency key and timestamp.
After a reload, a record less than two minutes old can be sent to WordPress to
cancel a submission whose response was lost; the record is then discarded.
* `anytry_sw_blocks_sse` — internal counter the plugin uses to detect a Service
Worker that’s blocking real-time updates, so it can transparently fall back to
the same-origin SSE proxy on the next try-on.
* `anytry_pending_events_v1` — up to 20 failed critical analytics events, including
their product, job and session identifiers. With current analytics consent, the
plugin retries them at the AnyTry API on a later page view in the same tab. A
refusal received by the widget or disabled analytics clears this queue and prevents
new retries on that page.
**Persistent browser storage (IndexedDB):**
These databases cache images in the visitor’s browser. Cached uploaded photos can
be reused and sent to AnyTry when the customer requests another Size Advisor analysis.
Generated results are cached for local display. Clearing the site’s browser data
removes these caches.
* `anytry_cache` object store `photos` — the most recent uploaded photo, so reopening
the modal restores the previous photo selection without a re-pick.
* `anytry_results` object store `images` — the data URL of generated result images
keyed by job ID, so revisiting a recently-generated try-on renders instantly.
**Analytics consent:**
The plugin does NOT send analytics or conversion-attribution events by default.
Enable them at WooCommerce AnyTry AI “Send analytics & conversion events”. The
Try-On image generation itself works whether or not this is enabled — only the conversion-
attribution dashboard in the AnyTry Portal depends on this opt-in.
When analytics is enabled and a tracking token is available, the widget checks the
current merchant setting and the site’s `anytry_allow_session_cookie` consent filter
through WordPress once per page view, before sending or retrying browser analytics.
It reuses that result for the rest of the page. CMP integrations must implement
that filter; the plugin does not automatically detect every consent manager. An
explicit refusal or disabled analytics clears the browser’s attribution cookies,
attribution storage and pending-event queue. A failed or unrecognized consent check
clears the pending-event queue and stops browser analytics for that page, while
preserving existing attribution and session identity. Try-On and Size Advisor remain
available. This does not recall requests already transmitted or erase historical
order records.
**Optional Google Fonts (default OFF):**
By default the plugin uses system-sans typography and makes NO third-party font
request — the AnyTry API is the only external service it contacts. An internal `
anytry_load_google_font` option (OFF by default, with no user-facing control) would,
if enabled, request the Outfit web font from Google Fonts (https://fonts.googleapis.
com) on the storefront and the AnyTry admin Settings page; it stays off in a standard
install.
* Service: Google Fonts (https://fonts.google.com)
* Data sent: visitor IP and User-Agent (standard HTTP request) at the moment a
page that has this option enabled is rendered
* Terms of Service: https://policies.google.com/terms
* Privacy Policy: https://policies.google.com/privacy
Uploaded photos are automatically deleted from the AnyTry servers within 5 minutes
of processing and are not used to train AI models.
This service is provided by AnyTry. By using the plugin, customers agree to the
AnyTry Terms of Service and Privacy Policy:
* Terms of Service: https://anytry.pl/terms
* Privacy Policy: https://anytry.pl/privacy
**Key Features:**
* **Photorealistic Try-On** — Uses generative AI to create realistic images of
customers wearing your products.
* **Data Privacy** — Customer photos are automatically deleted after processing.
No biometric data stored. Try-on tracking data stored on orders (session ID,
tried-product list, attribution job IDs) is included in WooCommerce’s built-in
personal-data Export and Erase tools, so customer data requests cover it.
* **High Performance** — Real-time SSE streaming with a polling fallback; doesn’t
burden your hosting.
* **Responsive Design** — Works perfectly on mobile and desktop devices.
* **Variant Support** — Works with simple and variable products (color/size).
* **AI Size Advisor** — Size recommendations from a short quiz (height and weight
with photo silhouette analysis, or a single “what size do you wear?” question).
* **Eye Advisor** — For glasses and sunglasses, AnyTry checks whether the frame
width fits the face in the customer’s photo and shows a frame-fit verdict on
the try-on result. Runs automatically, no setup.
* **Works across categories** — clothing, jewellery, watches, eyewear, shoes and
accessories.
* **Multilingual** — The shopper widget ships 10 languages (EN, PL, DE, UK, IT,
ES, FR, SV, DA, NB); admin settings are English, with translations delivered
via WordPress.org language packs.
* **HPOS Compatible** — Full support for WooCommerce High-Performance Order Storage.
* **WooCommerce Blocks** — Compatible with the new block-based checkout.
* **Multi-Job Navigation** — Compare results from multiple try-ons with swipe navigation.
**How It Works:**
1. Customer clicks “Try On” on a product page.
2. They upload a photo of themselves.
3. AI generates a photorealistic image of them wearing the product.
4. Optional: AI Size Advisor recommends the best size.
**SaaS Model:** This plugin connects to the [AnyTry API](https://api.anytry.ai)
for AI processing. An API key is required (free trial available). See [Terms of Service](https://anytry.pl/terms)
and [Privacy Policy](https://anytry.pl/privacy).
### Configuration
1. Navigate to WooCommerce > AnyTry AI in the admin panel.
2. Enter your API key or start a free trial.
3. Customize the button appearance (color, text, position).
4. Enable AI Size Advisor (optional).
5. Ensure your products have featured images set (flat-lay or ghost mannequin photos
work best).
### Requirements
* WordPress 6.4 or newer.
* WooCommerce 8.2 or newer.
* PHP 7.4+ (recommended: 8.1+).
* Active internet connection (for API communication).
### Source code & build
The plugin ships its full unminified sources — `src/js/anytry.js`, `src/css/anytry.
css` and `src/css/anytry-admin.css` — alongside the minified runtime in `assets/`.
The two small admin scripts keep their unminified sources in `assets/` next to the
minified files. Minification is done with esbuild on Node.js 18+ via the `minify_wp.
js` build script.
Third-party code: `assets/js/heic2any.min.js` is a prebuilt bundle of heic2any 0.0.4(
MIT) that embeds gifshot (MIT) and libheif (LGPL-3.0-or-later). Full attribution,
licence texts and the corresponding-source offer are in `THIRD-PARTY-NOTICES.txt`
in the plugin folder. It converts iPhone HEIC photos to JPEG in the browser, loads
only when the customer picks an HEIC file, and can be turned off with the “iPhone
HEIC support” toggle in WooCommerce AnyTry AI.
## عکسهای صفحه
[⌊The try-on result — the customer's own photo, wearing the product, generated by
AI. A Before / After toggle sits above it, add-to-cart and save below.⌉⌊The try-
on result — the customer's own photo, wearing the product, generated by AI. A Before/
After toggle sits above it, add-to-cart and save below.⌉[
The try-on result — the customer’s own photo, wearing the product, generated by
AI. A Before / After toggle sits above it, add-to-cart and save below.
[⌊AI Size Advisor — the short quiz runs while the try-on generates, so the size
recommendation is ready together with the result.⌉⌊AI Size Advisor — the short quiz
runs while the try-on generates, so the size recommendation is ready together with
the result.⌉[
AI Size Advisor — the short quiz runs while the try-on generates, so the size recommendation
is ready together with the result.
[⌊WooCommerce product page — the "Try It On" button in the standard product layout,
above Add to cart.⌉⌊WooCommerce product page — the "Try It On" button in the standard
product layout, above Add to cart.⌉[
WooCommerce product page — the “Try It On” button in the standard product layout,
above Add to cart.
[⌊Admin settings — environment health checks, button visibility, and the Size Advisor/
Eye Advisor configuration.⌉⌊Admin settings — environment health checks, button visibility,
and the Size Advisor / Eye Advisor configuration.⌉[
Admin settings — environment health checks, button visibility, and the Size Advisor/
Eye Advisor configuration.
## نصب
1. Download the plugin ZIP file.
2. In WordPress admin, go to Plugins > Add New > Upload Plugin.
3. Select the file and click Install.
4. Activate the plugin.
5. Go to WooCommerce > AnyTry AI to configure your API key.
## سوالات متداول
### Are customer photos safe?
Yes. Photos are transmitted over encrypted connections, processed by AI, and automatically
deleted from the server within 5 minutes. They are not used to train AI models.
### How long does a try-on take?
Most try-ons finish in 15–20 seconds. The plugin does not paste the garment onto
the photo — it generates an entirely new image with generative AI, which is a genuinely
heavy computation. The widget shows a live progress estimate while it works, and
the customer can minimise the window and keep browsing; the finished result is picked
up as soon as it is ready.
### What kind of photos should customers upload?
Best results come from full-body photos with good lighting on a plain background.
### Does this plugin store any data locally?
The plugin stores its WooCommerce configuration options (API key, button style,
size advisor mode, etc.) and a small amount of WooCommerce order metadata for conversion
attribution. No customer photos are ever stored on your site. AI processing and
the analytics reports themselves are handled by the AnyTry cloud service; on your
site the plugin keeps only the bookkeeping records described below, which let it
deliver those reports reliably.
Three small database tables are used for bookkeeping only. One prevents the same
cancellation being reported twice; these records have no age limit. The outbox records
purchase and refund work before it is sent to AnyTry in the background, so temporary
network or server problems can be retried. Delivered purchase and return entries
become eligible for removal 30 days after delivery. Queued purchase and return entries
in the ready phase age out at 90 days from admission once due; failed or quarantined
purchase and return entries become eligible for removal at 90 days from admission.
Return entries are only removed after their refund accounting has been preserved;
if that repair cannot complete, they remain without an age limit. Two kinds are
removed sooner, by default after 14 days from admission: ready purchases while analytics
consent is off, and ready deferred refunds whose readable order shows no AnyTry
activity and has no purchase still owed. Unresolved refund reservations and pending
refund or attribution receipts have no age limit. Staged purchases awaiting production
can also remain without an age limit, including while held for an unknown or different
account; an unreadable order’s staged batch can be retired after 90 days when recovery
runs. The outbox also keeps permanent per-order refund ledgers and ownership records,
introduced in this release: they preserve refund amounts and coverage, order and
refund ids, the owner’s key fingerprint and, when known, account id, without customer
names, contact details or photos. Key-to-account mappings are kept as options containing
key fingerprints, account ids and validation times, without order or customer data;
they remain until uninstall because other orders may still refer to them. An option
also registers purchases that could not be queued: it keeps at most 200 outstanding
orders and sheds the oldest on overflow — except an entry whose ownership could
not yet be recorded (for example during a database outage), which is kept until
it can be, and stops retrying after 24 unsuccessful recovery attempts; account holds
use no attempts and have no age limit. The third table, submit-answer escrow, briefly
keeps hashes, a job id, an encrypted job access token and a small status response
so the answer to one try-on submission can be recovered; it stores no photos and
becomes eligible for hourly cleanup 25 hours after its last update. Cleanup depends
on the background scheduler and database being available. Changing to another API
key of the same AnyTry account changes nothing about ownership or delivery. Purchase
and refund data known to belong to a different account is never sent to the new
account and follows the same retention rule as any undelivered entry of its kind,
including the kinds with no age limit. When account ownership cannot be verified,
history remains held: two known different accounts on one legacy order cannot be
resolved automatically or by CLI assertion, an unmapped legacy key remains held
until mapped, and a read failure before an ownership candidate is verified leaves
unknown provenance that never resolves automatically; an operator may explicitly
assert ownership of genuinely unknown history through the CLI, but cannot override
known conflicting accounts, and during a storage outage the refused-purchase register
may exceed its usual 200-order limit because entries whose ownership cannot be preserved
are retained. All three tables and the key-to-account mappings are removed on uninstall.
The plugin’s WordPress personal-data eraser removes the shopper’s per-order rows,
including permanent refund and ownership records, cancellation records, refused-
purchase references and order metadata, regardless of WooCommerce’s “remove order
data” setting; shared key-to-account mappings are retained until uninstall. One
non-personal marker (a timestamp) is retained per erased order so erased analytics
cannot be silently re-created and re-sent.
### Does this plugin set tracking cookies?
Only when the merchant has enabled analytics consent (default OFF). When enabled,`
anytry_session` and `anytry_tried` cookies persist for 90 days on visitor browsers—
both store a random session ID and a list of product IDs the visitor has tried on,
used to attribute purchases to try-on sessions. See the “External services” section
for full disclosure.
### Is this compatible with HPOS?
Yes. The plugin is fully compatible with WooCommerce High-Performance Order Storage(
HPOS).
## نقد و بررسیها
نقد و بررسیای برای این افزونه یافت نشد.
## توسعه دهندگان و همکاران
“AnyTry – AI Virtual Try-On for WooCommerce” نرم افزار متن باز است. افراد زیر در
این افزونه مشارکت کردهاند.
مشارکت کنندگان
* [ Paweł Piórek ](https://profiles.wordpress.org/piezak/)
“AnyTry – AI Virtual Try-On for WooCommerce” به 1 زبان ترجمه شده است. با تشکر از
[مترجمین](https://translate.wordpress.org/projects/wp-plugins/anytry-ai-virtual-try-on-for-woocommerce/contributors)
برای همکاری و کمکهایشان.
[ترجمه “AnyTry – AI Virtual Try-On for WooCommerce” به زبان شما.](https://translate.wordpress.org/projects/wp-plugins/anytry-ai-virtual-try-on-for-woocommerce)
### علاقه مند به توسعه هستید؟
[کد را مرور کنید](https://plugins.trac.wordpress.org/browser/anytry-ai-virtual-try-on-for-woocommerce/)،
[مخزن SVN](https://plugins.svn.wordpress.org/anytry-ai-virtual-try-on-for-woocommerce/)
را بررسی کنید، یا از طریق [RSS](https://plugins.trac.wordpress.org/log/anytry-ai-virtual-try-on-for-woocommerce/?limit=100&mode=stop_on_copy&format=rss)
در [گزارش توسعه](https://plugins.trac.wordpress.org/log/anytry-ai-virtual-try-on-for-woocommerce/)
مشترک شوید.
## گزارش تغییرات
#### 1.0.35
* Fix: a finished try-on is shown even when the status check falls back to polling
on a site whose server or caching plugin adds long browser caching to REST answers.
Status answers are now marked as not cacheable and every poll uses a fresh address.
* Fix: a new try-on can be started while three finished try-ons are on the list.
Finished try-ons no longer count towards the limit of three at a time; failed
ones still count until the shopper removes them from the list.
* Fix (analytics): after the API key is replaced, for example after rotating it
in the AnyTry portal, the settings page fetches the analytics token that belongs
to the new key, so browser analytics no longer fail silently with the old token.
Opening the AnyTry settings page once repairs a site whose key was rotated earlier.
Only a fingerprint of the key is stored beside the token.
* Fix (settings): the Store API Key field is no longer filled by the browser’s
saved site password, so saving the settings can no longer replace a working key
with that password.
* Fix (reporting): cleanup and retry passes revisit older records even while new
records keep arriving, so recovered storage or order reads can resume delayed
work.
* Fix (reporting): checkout recovery checks all surviving order provenance before
asking AnyTry under the current account, including when the dedicated ownership
record is missing.
* Fix (privacy): analytics transport failures save and log only bounded error codes,
without freeform connection messages.
* Fix (recovery): a lost database connection returns temporary unavailability during
submission recovery, including after creating a fence, so the browser keeps its
recovery claim.
* Fix (reporting): a try-on started from a cart line of a product variation is
recorded under its main product, so it can confirm the shopper’s purchase; the
try-on still uses the variation’s own photo and name.
* Fix (try-on): recovering a lost submission answer keeps Retry and automatic retries
bound to the accepted job, including while its preview loads.
* Fix (recovery): the small page loader keeps result recovery claims until the
full widget decodes the cached image.
* Fix (limits): failed requests return only daily slots they counted, and same-
key retries count again after a returned slot.
* Fix (privacy): result-download transport failures log only the operation and
error code, without token-bearing URLs or raw transport messages.
* Fix (recovery): an unreadable submission record returns a temporary unavailable
answer so the browser keeps its recovery claim.
* Fix (reporting): an expired product’s try-on job is no longer attached to a different
product whose try-on evidence is still within the reporting window.
* Fix (privacy): API rejection logs and saved delivery errors no longer store raw
response text that can echo a shopper’s session identifier. Response diagnostics
are limited to HTTP status and bounded validation field paths, types and error
codes.
* Fix (reporting): when the plugin asks AnyTry which products the shopper’s own
session tried on, only try-ons that finished before the purchase count. Needs
AnyTry API 6.2.47; with an older API the previous check (try-on started before
the purchase) applies.
* Fix (reporting): a purchase is credited to the shopper’s own try-on when her
browser kept the try-on but the checkout did not receive the list of products
she tried.
* Fix (reporting): when the shopper’s own try-on session is known at checkout or
at purchase but is not paired with the product, the plugin now asks AnyTry which
products that session tried on before falling back to shop-wide recovery. With
analytics enabled, this request carries the shopper’s random session identifier,
so only her own try-ons can match.
* Fix: the Try On button on a product page opens a fresh upload once the previous
attempt is finished. An unfinished attempt is shown again, including its Retry
actions after a result download fails. Earlier results stay available from the
floating button, with keyboard restore and focus handling.
* Fix: a photo that was still loading when the try-on window was reset is no longer
shown or tried on by itself.
* Fix (reporting): a purchase is reported once the order is paid. An order still
awaiting payment (for example a bank transfer on hold) no longer reports a purchase
from its thank-you page; it is reported when it is marked paid.
* Fix (reporting): a product found only by shop-wide recovery is no longer credited
to the shopper just because her try-on cookie was present at checkout, and a
status change made by a shop manager no longer attaches the manager’s own session
to the purchase.
* Fix (reporting): when AnyTry could not answer at checkout which products the
shopper tried, the purchase asks again instead of being left without a report.
* Fix: a try-on result that was already shown is no longer discarded when the before
photo cannot be displayed, and a result download that the server refused is no
longer shown as a broken image.
* Fix: a try-on whose answer did not reach the page (the page was reloaded, the
tab was duplicated or the connection dropped while the photo was being sent)
is now recovered instead of being cancelled or lost. The shop keeps the answer
for that one try-on and hands it back only to the browser that sent it, so the
result appears in the try-on list. A try-on is cancelled only when the shopper
dismissed it. The answer is kept in a new database table created when the plugin
updates.
* Note: a try-on that AnyTry accepted but whose answer never reached the shop (
for example a network failure between the shop and AnyTry) cannot be recovered
yet. It is never cancelled.
* Change: two order-data labels in the personal-data export can now be translated.
* Fix (reporting): a refund made in several parts is reported at its real total.
The refund that completes the order no longer repeats the amounts already reported.
* Fix (reporting): when AnyTry could not answer at checkout which products the
shopper tried and the payment completes at once, the checkout no longer waits
for further lookups; the purchase is looked up again in the background.
* Fix (reporting): a refund of an order whose try-on attribution is still being
confirmed is kept and reported once the purchase is confirmed.
* Fix (reporting): try-ons from one visit are no longer combined with another visit’s,
and a product tried on in the later visit is kept.
* Fix (reporting): a product is credited to the shopper only when her own data
names that product; malformed product lists no longer make a shop-wide match
look like hers.
* Fix (reporting): a refund is saved in the shop’s database before it is sent to
AnyTry. A refund interrupted by a server error or a lost connection, or two refunds
of one order processed at the same time, is now reported once, at its real value.
* Fix (reporting): refunds waiting for their purchase to be confirmed are kept
as separate records in the AnyTry table, so a failed or simultaneous save no
longer loses them.
* Change (privacy): AnyTry records written for an order while its personal data
was being erased are removed during the next hourly maintenance.
* Change (reporting): switching to another API key of the same AnyTry account no
longer holds purchases and refunds that were waiting to be reported; they are
reported under the new key. Entries that earlier versions set aside after a key
change are released automatically once the plugin confirms that the key belongs
to the same account.
* Fix (reporting): purchases, refunds and try-on lookups recorded for one AnyTry
account are no longer reported to a different account after the API key is changed
to that other account’s key. Checkout recovery also checks an existing order’s
account before asking AnyTry. They stay on your site and are reported only if
the shop returns to the account they belong to.
* Change: after the API key changes or the plugin is updated, the plugin checks
in the background which AnyTry account the key belongs to. The check sends only
the key.
* Change (WP-CLI): `wp anytry outbox redrive --adopt-current-key` no longer relabels
queued entries with the current key. It is now an explicit, unverified confirmation
for history the plugin cannot attribute, and it is refused when that history
is known to belong to another account.
* Fix (reporting): purchases that could not be saved are registered reliably when
several requests record them at the same time, and personal-data erasure and
export now include them.
* Change (privacy): the description of the data the plugin keeps on your site now
lists every bookkeeping table and record and how long each kind is kept.
* Fix: a finished try-on result counts as delivered only after it was displayed
and saved in the browser, and a finished try-on is never removed from the list
automatically. The list can hold more than three finished try-ons until the shopper
removes one.
* Fix (reporting): a refund recorded before the purchase confirmed its try-on now
names the purchase’s try-on. The answer is fixed once, before the first report,
so a retried report is identical.
* Fix (reporting): an order with two sizes of the same product names one try-on,
whatever the order of the lines.
* Fix (reporting): the size reported for a purchase, refund or cancellation comes
from the order line, not from the product as it is today, so an edited or deleted
variation keeps its size. A full refund takes its size only from the lines that
were tried on. Unreadable or unusual saved values are reported as unknown instead
of guessed.
* Fix (reporting): for orders purchased with this version, a cancelled order is
reported per tried-on product with the current total of the order lines the purchase
counted (lines removed since are skipped), and with a size only when those lines
do not name different sizes. Another, untried variation of the same product no
longer changes the value or the size. Orders purchased earlier, or whose saved
purchase details are missing or unreadable, are reported as before.
* Fix (reporting): a cancellation is reported only to the AnyTry account the order
belongs to, and is not sent for an order whose analytics were erased (checked
right before each send). When the account cannot be confirmed, nothing is sent
and the shop’s error log names the order.
* Note for shop owners: as before, there is no scheduled background retry for a
cancellation whose report fails; a later status change, or the call `AnyTry_Tracking::
track_cancelled_event( )`, sends it again. In rare cases (two simultaneous
status changes, a lost response or a database error) the same cancellation can
be sent twice; AnyTry keeps the first. If the shop’s server stops in the middle
of re-recording a purchase, that order’s cancellation can include lines the retained
purchase did not count.
* Fix (reporting): purchases and refunds reported from the browser carry only what
the shop’s own code passes, never the product, try-on or session of the page
being viewed. A refund ID passed by the shop is now forwarded.
* Change (reporting): a try-on counts for 90 days from its own date, per product.
Trying on another product no longer extends older try-ons.
* Note for shop owners: try-ons recorded before this update count only where the
shopper’s browser kept their date. Pages still served from a cache with the previous
script record nothing new until the cache refreshes, and a try-on list imported
from another domain by the previous script is dated at the import. The try-on-
backed share may therefore fall slightly for the first weeks.
* Fix (reporting): for orders with valid saved purchase-line details, refunds count
only the lines the purchase counted. Refunding another, untried size of the same
product no longer changes the reported quantity or size. Refund amounts keep
their previous calculation; older orders and unreadable purchase details keep
their previous selection.
* Fix (maintenance): an order record that cannot be repaired or read no longer
prevents later records from being checked during hourly cleanup. Each cleanup
pass limits its work and resumes on a later pass.
* Fix (privacy): a personal-data export now says when queued analytics events or
cancellation records could not be read, so the request can be repeated.
* Fix (WP-CLI): a failed database update during outbox redrive now stops the command
with an error and reports any rows already re-queued.
* Note for shop owners: the try-on-backed share may rise, because purchases that
were previously credited to shop-wide recovery are now credited to the shopper
who made them. Events already recorded are not changed.
#### 1.0.34
* Fix: the try-on works again on a page served from a full-page cache for longer
than a day. The widget now refreshes its security token instead of failing silently.
* Fix (reporting): a refund or cancellation names the same try-on the purchase
named, for each product.
* Fix (reporting): a shopper keeps her own try-on on the products she tried, even
when another shopper tried the same product.
* Fix (reporting): attribution collected at a classic checkout is saved with the
order instead of being lost when the checkout form carries no try-on field.
* Change (reporting): an order recognised on the thank-you page now records which
step recognised it and keeps the shopper’s try-on session.
* Change: WooCommerce 8.2 is now the minimum supported version.
* Note for shop owners: a shop on the classic checkout may see more recorded purchases
after this update, because orders that were previously dropped are now recorded.
The try-on-backed share may also rise, because purchases that were previously
credited to shop-wide recovery are now credited to the shopper who made them.
Events already recorded are not changed.
#### 1.0.33
* Fix (reporting): each purchased line is attributed to the try-on of that product,
on every checkout path.
* Change (reporting): a purchased product with no recorded try-on now names none
instead of another product’s.
* Note for shop owners: per-product conversion and the try-on-backed order share
may rise after this update, because more lines now match. Recorded events are
not changed.
#### 1.0.32
* Fix (reporting): an add-to-cart is attributed to the try-on of that product.
* Fix: the try-on session cookie is measured the way the browser counts it.
* Fix: accented letters in saved try-on file names are converted rather than replaced.
#### 1.0.31
* Fix (reporting): matched lines of the same product produce one purchase event
carrying their combined value.
* Fix (reporting): cancelled orders send the product size using the same rule as
purchases and refunds.
* Change (analytics): the widget checks current analytics consent once per page
before sending events.
* Fix (privacy): with analytics disabled or consent refused, attribution cookies
and stored attribution are cleared.
#### 1.0.30
* Fix (reporting): when a customer returned an item, the report did not record
WHICH SIZE came back — so “do try-ons reduce returns” could be answered for the
shop, but never for a size. Returns now carry the returned line’s size, exactly
as purchases already did. When one order returns two sizes of the same product
at once, the size is left empty rather than guessed, because naming one would
misreport the other.
#### 1.0.29
* Fix (privacy): size recommendations were sent to AnyTry without the visitor’s
session identifier, so the body measurements stored against them could not be
found when that shopper later asked for their data to be deleted. The identifier
is now sent, exactly as it already was for try-ons. Measurements recorded before
this update remain unreachable by session and can only be removed by deleting
the plugin data or asking AnyTry support.
* New: “Also remove these settings” in Security and Limits, off by default. Previously,
deleting the plugin also deleted your API key and your Size Advisor choice, so
reinstalling it left the Size Advisor silently switched off. Your settings now
survive a reinstall unless you tick this box. Customer data — try-on history,
session identifiers, queued events and cached images — is still removed when
the plugin is deleted, whatever this box says.
#### 1.0.28
* Fix (billing): if the page was reloaded at the exact moment a try-on was being
sent, the try-on was still created and charged on the AnyTry side, but the browser
was left with no way to reach it — no result, and no way to cancel it either.
The plugin now remembers the pending send and, on the next page load, asks AnyTry
to cancel that try-on. A try-on that has already started generating cannot be
cancelled and stays charged, because the work has genuinely been done.
* Internal (analytics contract): checkout and conversion events now use the API’s
canonical `source` field, identify the plugin release where raw diagnostics need
it, and no longer send redundant domain/send-time fields or unused lists of all
products and jobs tried during the session.
* Fix (analytics): the number of size measurements reported to AnyTry counted every
time a size recommendation was drawn on screen, including when it was redrawn
from cache — for example when switching back and forth between saved try-ons.
It now counts only genuine new measurements. Expect the “measured sizes” figure
in the AnyTry portal to fall after this update: the earlier number was overstated,
the new one is the real one.
* Fix: when a photo was rejected because of its file type, the message said it
was “too large or in the wrong format” and advised trying a smaller photo — unhelpful
when the file was tiny and the format was the only problem. Size and format now
get their own messages.
* Internal (diagnostics): the ways a photo can be rejected before upload now report
a stable machine-readable code to AnyTry instead of a truncated translated sentence,
so those faults can be counted the same way regardless of shop language. Other
error paths are unchanged.
* Compatibility: verified on WordPress 7.1.
#### 1.0.27
* Fix: the daily try-on limit shown in the settings screen said 30 while the plugin
actually allowed 50. The screen now shows the limit that is really applied; nothing
about the limit itself changed.
* Change: the analytics figures were removed from the plugin’s settings screen.
They were fetched from AnyTry on every visit to that screen and never shown,
so the page now loads without that request. Your statistics live in the AnyTry
portal.
* Internal: events sent to AnyTry now carry the plugin version and the time the
event actually happened (order date, refund date), instead of only the time they
were received. This makes reporting accurate when an event is delivered later
than it occurred.
#### 1.0.26
* Fix (statistics honesty): a completed order was marked “reported” the moment
the plugin handed the purchase over to be sent, not when the AnyTry service confirmed
it had arrived. If that send then failed — a server hiccup, a timeout, a missing
API key — the purchase was lost permanently: the order was already marked as
done, so it was never tried again. Purchases are now queued and retried until
they are genuinely delivered, and the order is only marked once every item has
arrived.
* Fix (statistics honesty): a refund could be reported for an order whose purchase
never arrived, which is what produced returns with no matching sale in your statistics.
A refund now waits for its purchase and is sent afterwards, rather than being
sent regardless or dropped.
* Fix: if the purchase reached the plugin only after the order had already changed
status — which is normal with bank and BLIK-style payment confirmations — the
sale could go unreported entirely. It is now recorded at that point too.
* Fix (privacy): the checkout form’s hidden tracking field was only filled in when
analytics were enabled, but the code receiving it did not check. Withdrawing
consent between opening and submitting the checkout could still attach try-on
data to the order. Both sides now check.
* New: administrators are warned in wp-admin if purchase events stop reaching the
server, instead of it happening silently. Site owners with command-line access
can inspect and retry the queue with `wp anytry outbox status` and `wp anytry
outbox redrive`.
#### 1.0.25
* Fix (statistics honesty): when a purchase could not be linked to the buyer’s
own try-on session, the plugin used to ask the AnyTry service which shopper last
tried the product and attached that shopper’s session to the sale. On shops where
many customers try the same products, this credited sales to the wrong person’s
session and inflated the conversion numbers your dashboard shows. Recovered matches
are now recorded without any visitor identity and are labelled as server-side
recoveries, so your dashboard can tell hard attribution apart from best-effort
matching.
* Improvement: the buyer’s own try-on session is now saved with the order at checkout.
Payment confirmations that arrive server-to-server (for example BLIK, Przelewy24
or other bank callbacks) used to lose that link about one purchase in five; those
sales were still counted, but not connected to the try-on that led to them.
* Improvement: every purchase event now states how it was attributed (buyer’s own
browser data, checkout form, or server-side recovery), matching what the PrestaShop
plugin has always reported.
* Fix (statistics honesty): refunds and cancellations are recorded against the
order they belong to, and no longer against whoever happened to be signed in
when the status changed. Previously, processing a refund from the shop admin
could attach that browser’s try-on session to the record; on a few orders it
did. Those records now carry the order’s own attribution or none at all.
* Fix (size question): the plugin now asks WooCommerce which sizes a product is
actually sold in, instead of reading the size selector out of your theme’s page.
Reading the page failed in two common situations: on category and shop pages,
where WooCommerce prints no size selector at all, and in any shop whose size
attribute is not literally called “Rozmiar” or “Size” – a German “Grosse” or
French “Taille” was invisible to it. In both cases the customer was shown your
shop’s entire size range instead of the sizes that product comes in. Since the
size the customer picks is what the recommendation is built on, offering a size
the product is not sold in produced a confident but wrong suggestion.
* Fix (size question): on shops whose size attribute has an unusual name, the size
advisor did not appear at all on product pages – no message, no error, it was
simply absent. It now appears wherever the product genuinely has more than one
size. Products that really do come in one size are still not asked about, as
before.
* Fix (size question): starting a try-on from a “related products” or quick-view
tile no longer offers the sizes of the product whose page you happen to be on.
It offers the sizes of the product you actually clicked.
* Improvement (size recommendation): the size table sent to the advisor is now
matched to the product’s own sizes rather than to your shop-wide setting. If
your shop is set to letter sizes while a product is sold in numbers (or the other
way round), the advisor is no longer asked to answer in a vocabulary your catalogue
does not use, and it can no longer recommend a size that product is not available
in.
#### 1.0.24
* Fix: the numeric size table stopped at 44. Anything above that could not be entered
and was never sent to the size advisor, so it could not suggest those sizes.
The table now runs 32 to 62, which covers petite and plus-size ranges. It scrolls
sideways rather than stretching the settings page, and sizes you leave blank
are simply not sent.
* Fix: size rows you left blank are no longer sent. Previously a table you had
opened but not filled in was passed along as a row of zeros, which the advisor
treated as real measurements.
* Fix: if you use the optional Cloudflare address list, a typo in one entry no
longer quietly disables the origin check that entry was meant to configure. Shops
that never set that list up are unaffected. A rejected entry is now written to
the error log, so a mistake is visible instead of silent.
* Fix (Safari, iPhone and iPad): your photo is now kept correctly while the try-
on window is open. On Safari it was never stored at all, which is why re-opening
the size question or coming back to a finished try-on could ask you for the photo
again. Every browser on iPhone and iPad uses Safari’s engine, so this affected
all of them.
* Fix (Safari, iPhone and iPad): tapping Save now saves the picture even when the
share sheet does not open in time. Before, that case tried to open a new tab,
which the phone usually blocks – so the tap appeared to do nothing.
* Housekeeping: removed about 150 lines of error-handling code that nothing in
the plugin has ever called, so the download is smaller. No behaviour changes.
#### 1.0.22
* New: a single switch to pause the Try-On across the whole shop without deleting
your API key or losing any other setting. Turn it back on when you are ready.
* New: test mode — the Try-On becomes visible only to the shop users you list,
so you can trial it with your own staff before opening it to customers. Everyone
else sees your shop exactly as it looked before the plugin was installed.
* Note: while test mode is on, conversion tracking records nothing, because ordinary
customers never reach the Try-On. Turn test mode off before you start measuring
sales.
* Note: pausing the Try-On stops the plugin from loading anything on your shop
pages, but it does not stop conversion tracking. Sales of items a customer tried
on before you paused are still recorded, so you keep the data you already paid
for.
#### 1.0.21
* Reliability: the try-on window can no longer end up in a contradictory minimized-
yet-open state. Re-showing the window cleared the internal flag but left the
minimized marker on the element, so which state won was decided only by stylesheet
order — a reorder would have hidden both the window and the floating progress
bubble at once, leaving no way back except the Try-On button.
* Reliability: the background-jobs view no longer dismantles the window (hiding
the result, the upload area and the floating bubble) before checking whether
it has anything to display, which could leave an empty white window.
* Reliability: switching from one product to another now always shows the correct
product’s size options — or none, when the Size Advisor is turned off — instead
of briefly carrying over the previous product’s size choices.
* Reliability: switching to a different product while a result is still downloading
no longer shows the wrong product’s result or freezes the try-on that is still
running.
* Reliability: opening the same store in two browser tabs no longer lets one tab
cancel or drop the other tab’s in-progress — and already paid-for — try-on.
* Reliability: a finished try-on is now picked up correctly after a phone browser
tab is briefly frozen in the background and reopened, instead of appearing stuck.
* Reliability: the Save button, and restoring a saved try-on, no longer hang on
browsers where the local image store is slow or blocked to open — the widget
now falls back to fetching the result instead of waiting indefinitely.
* Reliability: a size suggestion that arrives late no longer appears on top of
an error screen.
* Reliability: a finished try-on shown in the multi-item comparison list now becomes
clickable on its own, instead of remaining on “loading result…”.
* Reliability: a temporary network or CDN hiccup while fetching a finished try-
on no longer shows a dead error. The widget now retries the same, already-generated
result a few times before giving up — it never re-runs or re-charges the try-
on. This closes the most common “generated but not shown” case.
* Diagnostics: clearer error categories (a connection problem is now labelled as
such, an unsupported image as an image problem, instead of a generic “unknown”),
and error events now include the try-on identifier so a store can see exactly
which requests hit a display problem.
#### 1.0.20
* Maintenance: translations now follow the standard WordPress.org model — the plugin
ships English source text, and translations are delivered as community language
packs from translate.wordpress.org rather than as catalogs bundled inside the
plugin. No change to any feature or behaviour.
* Compatibility: verified on WordPress 7.0.2 with PHP 7.4 through 8.5.
#### 1.0.19
* Security: try-on and size requests now require a real, published, try-on-enabled
product and no longer accept a caller-supplied product image, preventing use
of the paid try-on pipeline outside the intended flow.
* Security: an anonymous request can no longer change the store-wide streaming-
proxy setting, and malformed job tokens are now rejected instead of silently
ignored.
* Privacy: with analytics turned off, the storefront now writes no tracking cookie,
local storage, or data-layer event.
* Privacy: Size Advisor now stays fully disabled on both the storefront and the
server when turned off in settings.
* Privacy: GDPR order-data erasure now reliably removes all AnyTry order data.
* Privacy: cancellation and refund analytics are now limited to products the shopper
actually tried on.
* Reliability: the page-resume mini widget loads its stylesheet correctly, cancels
only its own job when closed, and clears that job’s cached photo and result.
* Admin: the Data controller example now suggests your own store name.
* Maintenance: refreshed bundled translations and added third-party licence notices;
aligned the …
## اطلاعات
* نگارش **1.0.35**
* آخرین بهروزرسانی **1 هفته پیش**
* نصبهای فعال **کمتر از 10**
* نگارش وردپرس ** 6.4 یا بالاتر **
* آزمایششده تا **7.1.3**
* نگارش PHP ** 7.4 یا بالاتر **
* زبانها
* [English (US)](https://wordpress.org/plugins/anytry-ai-virtual-try-on-for-woocommerce/)
و [Polish](https://pl.wordpress.org/plugins/anytry-ai-virtual-try-on-for-woocommerce/).
* [به زبان خودتان ترجمه کنید](https://translate.wordpress.org/projects/wp-plugins/anytry-ai-virtual-try-on-for-woocommerce)
* برچسب
* [AI](https://fa.wordpress.org/plugins/tags/ai/)[ecommerce](https://fa.wordpress.org/plugins/tags/ecommerce/)
[fashion](https://fa.wordpress.org/plugins/tags/fashion/)[virtual try on](https://fa.wordpress.org/plugins/tags/virtual-try-on/)
[woocommerce](https://fa.wordpress.org/plugins/tags/woocommerce/)
* [نمایش پیشرفته](https://fa.wordpress.org/plugins/anytry-ai-virtual-try-on-for-woocommerce/advanced/)
## امتیازها
هنوز هیچ نقدی ارسال نشده است.
[بررسی شما](https://wordpress.org/support/plugin/anytry-ai-virtual-try-on-for-woocommerce/reviews/#new-post)
[مشاهدهٔ همهٔ بررسیها](https://wordpress.org/support/plugin/anytry-ai-virtual-try-on-for-woocommerce/reviews/)
## مشارکت کنندگان
* [ Paweł Piórek ](https://profiles.wordpress.org/piezak/)
## پشتیبانی
چیزی برای گفتن دارید؟ نیاز به کمک دارید؟
[مشاهده انجمن پشتیبانی](https://wordpress.org/support/plugin/anytry-ai-virtual-try-on-for-woocommerce/)