| 开发者 |
Saso Nikolov
sasonikolov |
|---|---|
| 更新时间 | 2026年5月11日 16:31 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 6.9 |
| 版权: | GPLv3 |
| 版权网址: | 版权信息 |
You need WooCommerce (free) to handle payments and orders. Everything else is included — no additional ticketing add-ons required.
WooCommerce is required for selling tickets. However, you can use the plugin to manage and validate ticket lists manually without WooCommerce sales.
Yes! Premium includes Auth Tokens that give your door staff scanner access via a simple URL — no login required.
The scanner is browser-based and requires an internet connection. For large events, the plugin includes offline fallback options to prevent interruptions.
Yes. Design your venue layout with the drag & drop seating designer, and customers will see an interactive seat map during checkout where they can pick available seats.
Single entry, multi-entry passes, family tickets (multiple tickets per purchase), memberships with expiration dates, and day-chooser tickets where customers pick their event date.
In the free version, the order confirmation email includes a link to download the ticket PDF and view the QR code. Premium allows attaching the PDF directly to the email and adding calendar invites (ICS).
The ticket is automatically deactivated, the assigned seat is released, and the ticket number is recovered for reuse.
Yes. WPML is supported for multilingual ticket sales. The scanner also supports multiple languages including German, Spanish, French, Italian, Japanese, Dutch, Portuguese, and Chinese.
If you reach the limit, the plugin will display a message asking the customer to contact support. Your sales are never interrupted. Premium has no ticket limits.
Yes. The built-in scanner page accepts input from hardware barcode scanners in addition to camera-based QR scanning.
Every ticket number is unique. The scanner detects duplicate redemption attempts. Premium adds CVV verification and brute-force IP blocking for additional security.
<select name="<key>[<i>]"> under the same root name as the parent's checkbox/input, so on a variable-product save $_POST[<key>] arrived as an array. The save handler treated "key is present in POST" as "checkbox is checked" and overwrote the parent meta with yes — which is also why the cart kept asking customers to fill in a value field even when, in the admin, the boxes looked unchecked. The handler now ignores array values for parent-level fields (request_name/value_per_ticket(_mandatory|_label|_def), ticket_start/end_date/time, ticket_amount_per_item, and Premium's expiration_days). After updating, simply uncheck the affected boxes once and they will stay unchecked. No data migration is required.WC_Cart::add_to_cart() without supplying $variation as an array). The internal handler used a strict array type-hint and aborted the whole cart operation — it now accepts any input and normalizes defensively. Affects sites running WooCommerce Wishlists.is_ticket flag on the parent product is now the single source of truth — stale variation/product meta from a previous configuration is ignored. Validation at checkout follows the same rule and no longer blocks orders for non-ticket products with leftover meta. Purchase-restriction codes are unaffected and continue to work on any product type.<p class="form-row form-row-wide"><label>…</label><input class="input-text" />) instead of a custom <small>-label wrapper. This lets the active theme's CSS apply normally so the fields look consistent with the rest of the cart/checkout form.redeemed_via_authtoken_id). Backend ticket detail view shows "Redeemed via authtoken: NAME (#ID)" alongside any WP-user redeem info; CSV export gains meta_wc_ticket_redeemed_via_authtoken_id + _name columns. The token name is resolved live with per-request caching, so a renamed token shows the current name everywhere — only the id is persisted.event-tickets-with-woocommmerce-premium (license-expiry messages) are migrated to event-tickets-with-ticket-scanner, so a single .mo file per language covers both plugins.update_plugins site transient was only cleared BEFORE the upgrade, not after. WordPress then kept the stale "update available" entry until the next WP-Cron (12h later). The transient is now cleared + re-checked after the upgrade completes, so the red badge disappears on the next page load.SASO_EVENTTICKETS::issetRPara() against missing REQUEST_METHOD in CLI/cron context.saso-eventtickets-datepicker and data-product-id for custom stylingorder_id for [sasoEventTicketsValidator_code] to display tickets from a specific order.