CodeCanyon FooEvent - WordPress Plugin

CodeCanyon FooEvent Setup Guide for Selling Tickets with WooCommerce

CodeCanyon FooEvent is the commercial FooEvents for WooCommerce bundle, where a standard WooCommerce product becomes an event, a ticket, an attendee list, and an access check point. This guide focuses on practical implementation rather than marketing copy: what to prepare before installation, which settings to review first, how to create a test event, why tickets sometimes fail to send, and how to confirm that a customer can actually buy a ticket, receive the email, and complete check-in at the door.

This guide is useful for anyone already working with WordPress and WooCommerce, or planning to build a ticketing page on their site. We will look at the product as a working system: product, inventory, order, email, QR code or barcode, ticket validation, attendee export, reporting, and operational limits. That perspective helps you do more than just "turn on the plugin" - it helps you spot the points where the process is most likely to break before you go live.

This article uses interface labels such as FooEvents > Settings, Products > Add Product, Event Settings and Ticket Settings. They are left in English because that is how WordPress screens and FooEvents documentation usually appear. Everything else is explained in plain language with an emphasis on safe setup and result verification.

How FooEvents Fits into WooCommerce and Where It Excels

The core idea behind FooEvents is simple: the event does not live outside the store - it becomes an enhanced WooCommerce product. The site owner creates a product, enables event mode, fills in the date, venue, ticket type, email settings, and issuance rules. After purchase, WooCommerce creates the order, and once the order reaches the right status, FooEvents generates a ticket for each attendee.

This matters before you start configuring the plugin because FooEvents inherits both the strengths and the weaknesses of WooCommerce. Payment gateways, coupons, taxes, inventory, order statuses, emails, and customer accounts all remain part of WooCommerce. FooEvents adds the event layer: attendee data, ticket generation, email presentation, barcode or QR code, entry check-in, reports, and exports.

The best use case for CodeCanyon FooEvent is a site that already uses WooCommerce, or where the owner specifically wants to sell tickets without sending people to a third-party ticketing platform. That includes conferences, workshops, local concerts, tours, classes, club events, paid webinars, hybrid events, and free registration with guest list control.

Still, FooEvents should not be treated as a magic replacement for the entire event operations stack. Large events still require a check-in process, email delivery testing, separate roles for staff, a backup attendee list, a clear refund workflow, and testing across multiple devices. The plugin provides the tools, but a reliable process only comes from proper setup and rehearsal.

What the Official Sources Confirm

The product page and documentation confirm several core capabilities: operation on top of WooCommerce, unlimited events and tickets within the site license, ticket emails with 1D barcodes or QR codes, the free FooEvents Check-ins app for ticket validation, attendee export, reporting, customizable terminology, localization support through .po and .mo, plus separate extensions for PDF tickets, seating, calendars, bookings, POS, and other use cases.

This guide treats those facts carefully: if a feature belongs to a separate extension, it is not described as part of the base plugin. For example, PDF attachments, seating, and advanced bookings require the relevant add-ons. The base setup here is built around the WooCommerce product - event - order - ticket - check-in workflow.

Who This Approach Works For, and Who Should Consider a Different Model

FooEvents is a strong fit for site owners who want to keep ticket sales, customer data, and the branded user journey inside WordPress. If you already use WooCommerce, understand order statuses, and can control your site's email delivery, the product fits naturally into the familiar store model. The ticket is not a separate entity with someone else's checkout - it becomes part of your own catalog.

The plugin is especially useful when tickets need to coexist with regular products. For example, a training business might sell passes, material bundles, and workshop tickets in a single checkout flow. A conference organizer might offer multiple ticket types through a variable product, limit inventory, collect attendee details, and later export the list to CSV.

Where FooEvents Makes Sense

• WooCommerce is already installed on the site, and the team is comfortable working with products, orders, and emails.
• The organizer wants to store attendee data in their own WordPress database rather than in a third-party service.
• Branded tickets, custom terminology, an event logo, and a controlled email template matter.
• Entry control through an app or a desktop check-in station with a scanner is important.
• You need to sell both free and paid events while using standard WooCommerce tools for coupons, inventory, and order statuses.

When to Be More Cautious

If the site runs on weak hosting, has unreliable email delivery, conflicting security plugins, or an unpredictable order workflow, ticketing will suffer along with WooCommerce. FooEvents generates tickets based on order data and selected statuses. If the order never reaches the right status or emails land in spam, the issue will show up not as "the plugin is broken," but as a break somewhere in the sales chain.

For events with highly complex seating, multiple venues, marketing automation, multi-track programming, sponsor portals, or partner payouts, the base setup may not be enough. Some of that can be handled through FooEvents extensions, and some of it is better solved with separate tools. That is why it helps to make a list of required scenarios before launch and separate "needed now" from "might be useful later."

Practical rule: if the event depends on precise entry validation, set up a test ticket, a test order, a test email, and a test check-in in the app before opening sales to real attendees.

What to Check Before Installing on a Live Site

Before installing CodeCanyon FooEvent, it is important to review more than just the plugin ZIP. A ticketing system depends on several layers: WordPress, WooCommerce, server libraries, email delivery, the REST API, the theme, and any plugins that interfere with the cart, checkout, or user login flow.

The official FooEvents documentation states that the environment should meet WordPress and WooCommerce requirements. It also points to server components that are usually available on hosting, but may matter during troubleshooting: GD Graphics Library with PNG and JPEG support, allow_url_fopen, and mbstring. That does not mean you should change servers immediately, but it is a useful checklist when dealing with strange issues involving images, PDFs, encoding, or ticket generation.

Minimum Pre-Launch Checklist

• Confirm that WooCommerce is installed, activated, and able to complete a normal test order.
• Make sure the theme correctly displays standard WooCommerce pages: the product page, cart, checkout, and "My Account" page.
• Test WordPress email delivery with a test email or an SMTP plugin, especially if the site has had spam issues before.
• Open a URL such as https://example.com/wp-json/ to confirm the REST API is not fully blocked.
• Create a full site backup before installation, and especially before updating WooCommerce, payment gateways, or related extensions.
• If the site uses caching, script optimization, login protection, or CAPTCHA, prepare a list of exclusions and a test mode in advance.

Why You Should Not Skip WooCommerce Testing

FooEvents does not replace checkout. If the site cannot complete a normal virtual-product purchase reliably, ticket sales will not be reliable either. Start by verifying the base WooCommerce flow: the product can be added to the cart, checkout does not break, the payment gateway returns the correct status, the customer email is sent, and the order appears in the admin area. Only then does it make sense to look for issues in the event settings.

For testing, you can create a simple virtual product without FooEvents, complete a purchase in the payment gateway's test mode, and inspect the final order status. If that step is unstable, it is better to postpone the ticketing rollout. Otherwise, WooCommerce, email, and FooEvents issues will all get mixed into one troubleshooting mess.

Installation and Initial Validation Without Unnecessary Risk

FooEvents is installed like a standard WordPress plugin through Plugins > Add New Plugin by uploading the ZIP archive. The documentation explicitly notes that WooCommerce must already be installed. Once activated, a FooEvents menu appears in the admin area, and event settings become available within product data.

This guide does not cover purchase flow, licensing, or activation codes. For practical setup, it is enough to know that the plugin is installed, activated, and available in the admin area. Everything that follows assumes you already have a working plugin archive.

Safe Installation Sequence

1. Verify that you have a current site backup and a way to roll back.
2. Open Plugins > Add New Plugin and upload the plugin ZIP through Upload Plugin.
3. Activate FooEvents and confirm that the FooEvents section appears in the left admin menu.
4. Open FooEvents > Settings without changing every option at once.
5. Create a test event product, but do not share it with real customers until you have tested both the purchase flow and the email.

Initial Validation After Activation

After installation, do not move all real events into the system right away. Start with one private test event, ideally with a very low price in test mode or as a free registration. What matters is walking through the entire flow as a normal attendee: open the event page, add a ticket to the cart, complete checkout, receive the email, see the ticket in the admin area, and test check-in through the app or Express Check-in if that is part of your process.

Quick checkpoint: the installed plugin is only truly ready for configuration when you can see its menu, open its settings, create an event product, and complete a test purchase without WooCommerce errors.

First Settings in FooEvents > Settings

Global FooEvents settings define how events and tickets behave site-wide. You do not need to enable everything. A better approach is to work from the business logic outward: how the purchase button should appear, where attendee data should be collected, when tickets should be created, whether you need QR codes, which emails should be sent, how attendees should be labeled, and what should happen after the event expires.

General Options: Button Text, Sorting, Dates, and Variations

In the general settings, you can change the add-to-cart button text for events, enable sorting by event date, show the event date in product lists, hide the event details tab, or display event variations in a table format. That last option is useful when you have multiple ticket types and want attendees to choose quantities row by row, but the documentation warns that it changes standard add-to-cart behavior and may conflict with plugins that customize that process.

For a typical site, a sensible starting point is to enable only the options that directly improve purchasing. For example, showing the event date in product listings helps visitors avoid clicking outdated events, and custom button text can make the action clearer. Table-style variation display is better enabled only after testing with your theme, cart behavior, Ajax add-to-cart flow, and payment gateway.

Attendee Data and Field Positioning

FooEvents can add a separate step for collecting attendee data before checkout. That is useful when the buyer and the attendee are not the same person - for example, when a manager purchases multiple tickets for a team. The field position setting can help resolve conflicts with themes and third-party checkout plugins. If the fields break the page visually, start by changing their position instead of rewriting the checkout template.

For the first rollout, it is best to enable only the standard fields you actually need at the door: first name, last name, email, phone, company, or job title. The more required fields you add, the greater the risk that the attendee abandons checkout. Extra fields should only be added through the appropriate extension, and only after you understand exactly how that data will be used.

The Order Status That Triggers Ticket Creation

By default, FooEvents creates a ticket when the WooCommerce order reaches Completed. That makes sense for digital tickets, but in practice the final status depends on the payment gateway and the product type. The documentation recommends using the Virtual and Downloadable product settings for automatic ticket delivery so the order can complete after payment is confirmed.

If your payment workflow leaves the order in a different status, open FooEvents > Settings, go to the General tab, and review Send on order status. Select only the statuses that truly mean the attendee should receive a ticket. Do not enable a broad set of statuses "just in case" - that can lead to tickets being sent before payment is confirmed or before manual review is complete.

Ticket Design and QR Codes

The global design section controls colors, logo, header image, barcode or QR code format, and PDF options if the relevant extension is active. For a basic launch, it is enough to choose a logo, clean colors, and decide whether you want QR codes instead of 1D barcodes. The documentation notes that the QR code stores the unique ticket identifier, but scanning it with a regular third-party scanner will only show the raw value. To actually mark an attendee as checked in, you need the FooEvents Check-ins app or Express Check-in.

Pay close attention to logo and header images. In ticket emails, lightweight JPG or PNG files work best. If the email loads slowly or ends up in spam, oversized images and overly heavy layout design can make the situation worse.

How to Roll Back a Risky Setting

Enable any setting that changes checkout behavior, order statuses, or ticket appearance one at a time. After saving, place a test order and note what changed. If the result is worse, revert that one setting and repeat the test. It is a boring process, but it saves time: you know exactly which checkbox caused the problem instead of hunting through ten changes at once.

Creating an Event from a WooCommerce Product

The most important FooEvents workflow is turning a product into an event. In the documentation, this process starts in Products > Add Product: enter the title, description, categories, and image, then open the Product Data tabs and select Event Settings. The key toggle is Is this product an event?. That is what turns on ticketing logic for the product.

The Product Page as the Public Event Page

In most cases, the visitor does not see the "FooEvents admin panel" - they see a standard WooCommerce product page. That means the product description needs to function as the actual event page: what is happening, where it takes place, who it is for, how long it lasts, what is included in the ticket, and what refund or access rules apply. FooEvents adds the event date, location, event details, gallery, variations, and other blocks, but the foundation is still the product page.

Do not rely only on automatically generated fields. If the event is complex, use the main description to add clear structure: agenda, speakers, what to bring, access conditions, and organizer contact details. That reduces pre-purchase questions and keeps the ticket from feeling like a generic catalog item.

Event Type and Extension Dependencies

The event settings include multiple event types. A standard single-day event is the best place to start for testing. Multi-day events, selectable individual dates, bookings, and seating all require the relevant extensions. In the interface, those options may look like part of one unified settings set, but in practice some capabilities depend on which add-ons are installed.

If you are planning a conference with multiple days, rooms, and workshops, do not start with the most complex configuration possible. Create a basic event first, verify the ticket flow, then add extensions for multi-day scheduling, seating, calendar display, PDF output, or bookings. After each layer, repeat the order test.

Using Variations as Ticket Types

The easiest way to handle multiple ticket types is through a WooCommerce variable product. For example, you can create options such as "Standard," "VIP," and "Online Access," each with its own price, inventory, and description. Because FooEvents uses WooCommerce logic, it is important to set up attributes, variations, and stock levels carefully.

For a small event, a simple product with one ticket type is enough. For a conference, concert, or festival, variations provide flexibility, but they also increase the chance of mistakes: the attendee may pick the wrong option, inventory may be assigned at the wrong level, or the theme may display the dropdown poorly. If you enable table-style variation output, test it separately.

What to Check After Publishing the Event

• Open the product page in a private browser window and confirm that it looks like an event page, not a half-configured product.
• Check the date, time, location, price, ticket availability, image, and button text.
• Add one ticket to the cart, then multiple tickets if the event allows group purchases.
• Confirm that inventory decreases as expected and does not allow overselling.
• Place a test order and make sure the ticket appears in FooEvents > Tickets.

Tickets, Emails, and the Moment of Generation

The ticketing side of FooEvents is tied to the WooCommerce order. When the customer checks out with a ticket, WooCommerce creates the order, and the ticket data is stored with it. Once the order reaches the required status, FooEvents creates a separate ticket for each attendee. That explains most "ticket not received" issues: you need to review not only email delivery, but also the order status, product type, payment gateway, and sending settings.

What to Configure in Ticket Settings

Each event has its own Ticket Settings tab. There you choose the HTML ticket theme, the PDF ticket theme if the extension is installed, logo, header image, accent colors, email theme, recipient copies, whether the ticket goes to the buyer or the attendee, whether to attach a calendar file, and whether to display custom fields, date, time, price, barcode, and other details.

You do not need to enable every field at once. For a first launch, the important items are the logo, a clear email theme, date and time, attendee details, and the code used for validation. Showing the price on the ticket is not always useful: at a corporate event, the attendee may only need the name, ticket type, and QR code, while the price can remain in the WooCommerce order.

Why Order Status Matters More Than Email Copy

If the order stays in Processing while FooEvents is waiting for Completed, no ticket will be created. That is not an email theme problem. Start by checking the order: its status, payment method, whether the product is virtual, whether Downloadable is enabled, and then the Send on order status setting. Only after that should you move on to email headers and SMTP.

For a free event, check how WooCommerce handles a zero-total order. For a paid event, review the exact status returned by your gateway. For manual payment methods, it is often better not to issue tickets automatically until payment is confirmed, especially if that matters for your accounting or admission policy.

Branding and Test Preview

FooEvents Ticket Themes let you change the visual appearance of ticket emails. The documentation describes uploading a theme through FooEvents > Ticket Themes, selecting the theme in Ticket Settings, and sending a test preview. It is important to remember that the preview uses test data and is not a real ticket that can be scanned at the venue.

For safer customization, do not edit plugin files directly. If you need deeper changes to the ticket theme, create a copy of the theme in wp-content/uploads/fooevents/themes/, make your edits there, and select that copy for the event. That approach survives updates far better than changing the original files.

A Small Safe CSS Adjustment for a Ticket Theme Copy

If the brand color on the button is hard to read in the email, you can adjust the CSS inside your copied ticket theme. This is not a core plugin edit - it is a change to your own theme copy. Before editing, save the current version of the copied file and send a test preview.

.ticket-button {
  background-color: #0f766e;
  color: #ffffff;
  border-radius: 4px;
  font-weight: 700;
}

.ticket-accent {
  border-color: #0f766e;
}

After the change, send the preview to your inbox, open it in several email clients, and check the contrast. If the email looks worse, restore the previous file or switch back to the default ticket theme. Do not add complex scripts to ticket emails: email clients do not support them, and they can hurt deliverability.

Scenario: Selling Tickets for a One-Day Workshop

A practical example helps connect all of the settings into one working chain. Take a typical use case: a WooCommerce site owner is selling 40 seats for a workshop, wants to collect attendee names, send a branded ticket with a QR code, and validate attendees at the door through the app.

Goal and Preparation

The goal is to create an event page where a visitor can select one or more tickets, complete checkout, receive the email, and later present the ticket at entry. Before you begin, WordPress, WooCommerce, and FooEvents should already be installed. The site's email must be working, and the administrator should have test access to the FooEvents Check-ins app or whichever validation method will be used.

Setup Steps

1. Create a new product through Products > Add Product and name it after the real event.
2. Add the description: workshop topic, duration, address, what the ticket includes, and access conditions.
3. In Product Data, enable the virtual product setting if the ticket does not require physical delivery.
4. Open Event Settings and enable Is this product an event?.
5. Fill in the date, time, location, and the rest of the event details.
6. Go to Inventory or the variation settings and set the limit to 40 tickets.
7. Open Ticket Settings, choose a ticket theme, add the logo, and enable the date, time, and QR code display.
8. Check the global Send on order status setting so tickets are created on the correct order status.
9. Publish the product in a hidden category or with a private link for testing.
10. Place a test order and verify the email, the ticket, the ticket list, and the check-in workflow.

Expected Result

On the public page, the visitor sees an event, not a contextless product listing. After checkout, WooCommerce changes the order status, FooEvents creates the ticket, the email reaches either the buyer or the attendee depending on your settings, and the ticket appears in the admin area. When scanned through the FooEvents Check-ins app, the ticket should be found and marked as used.

A Detail People Often Miss

If the buyer purchases multiple tickets, check what data is collected for each attendee. For a small workshop, a name and email may be enough. For a conference, you may also need company, job title, or session selection, but those belong to a separate layer of logic and should be planned in advance. Do not collect extra data "just in case" if it is not needed for admission, communication, or reporting.

Result check: a test only counts as successful if the order, ticket, email, QR code, attendee list, and entry check all work together. A nice-looking email by itself does not prove the system is ready.

Entry Validation, QR Codes, and On-Site Team Workflow

Once tickets are sold, the second half of the process begins - admitting attendees. FooEvents supports check-in through the mobile Check-ins app and through Express Check-in with a USB or Bluetooth scanner. The documentation states that the mobile app uses the device camera, and for faster processing you can enable Auto Check-in so the attendee is marked as entered immediately after scanning.

How to Choose a Check-In Method

For a small event, a smartphone with the app and a test user is enough. For a flow of hundreds or thousands of people, it is better to prepare multiple entry points, confirm stable internet, enable time-saving settings, and consider an external scanner. FooEvents documentation specifically notes that every second matters with high-volume entry, and Auto Check-in reduces the time spent returning to the list after each scan.

If you use Express Check-in on a laptop, test in advance that the scanner enters the value correctly into the search field, and that Auto Search and Auto Check-in behave the way you expect. Do not run the first test on the day of the event. At the door, there is no time to figure out why the scanner is typing extra characters or why a staff member is logged in under the wrong role.

Roles and Staff Access

By default, full access to FooEvents features belongs to the WordPress administrator. That is usually too much for check-in staff. The documentation describes using WordPress capabilities together with User Role Editor: you can assign a role or a specific user permissions related to event_magic_ticket, and for access only to the Check-ins app, app_event_magic_tickets.

In practice, it is better to create a separate role or a separate user for entry control, grant only the minimum required permissions, and test app login before the event. After the event, access can be revoked or the password changed. That reduces the risk of giving temporary staff full administrative access to the site.

A Backup Plan for Problems

Even a well-configured system still depends on internet access, the phone, battery life, the camera, the REST API, and the server. Prepare a CSV export of attendees, a printed or local backup list, chargers, and a backup user account. If entry cannot stop, the team needs to know how to mark attendees manually and how to sync the data afterward.

FooEvents allows CSV export per event through the Event Export tab in product data. The file can include ticket numbers, custom fields, check-in data, booking details, and buyer and attendee information. That is useful not only for reporting, but also as a backup spreadsheet at the door.

Reports, Exports, and Attendee Data After the Event

The event does not end when the ticket email is sent. After sales begin, the organizer needs to understand how many tickets were sold, how many seats remain, who attended, who did not, and which data should be passed into a CRM or a report. FooEvents provides reports and attendee export for that purpose.

What the Reports Show

The FooEvents > Reports section shows events, revenue, tickets sold, check-ins, and available tickets. It is a useful snapshot, but not a full analytics platform. If you need deep analysis of sales channels, campaign performance, or repeat purchases, use WooCommerce reporting, analytics tags, and your CRM separately.

The official documentation also notes that FooEvents reports do not provide a separate export directly from the reports screen. To export the attendee list, use the Event Export tab inside the event product settings. So if you cannot find the CSV inside the report view, that is expected - open the product itself and export attendees from there.

How to Use CSV Without Creating Chaos

The CSV can be opened in Excel, Google Sheets, or another spreadsheet tool. Before handing the file to your team, remove extra columns that are not needed for the specific task. For entry control, you may only need the attendee name, ticket type, ticket number, check-in status, and possibly email. Marketing needs a different dataset, and using it should align with your privacy policy and user consent.

Do not mix the operational check-in list with the marketing list. The first exists to admit people to the event. The second exists for communication after the event and should follow your consent rules, data retention practices, and privacy policy.

Calendar, Shortcodes, and Event Display Blocks

If the site has only one event, a direct product link is enough. If there are many events, visitors need a list or a calendar. FooEvents Calendar adds calendar shortcodes and widgets, and the documentation includes examples such as [fooevents_calendar], [fooevents_events_list], and [fooevents_event product=23270]. These elements help display events on a page, inside a post, or in a widget area.

When to Use a Listing Page

An event list works well when you have several upcoming events and visitors choose by topic, date, or category. In that case, create a dedicated page, add a short introduction, and insert the event list shortcode. If you use categories, apply the include_cat filter so different types of events do not get mixed together.

For calendar views, keep readability in mind. A monthly grid works well for recurring classes, but for occasional events a simple list is often clearer. Do not force people to hunt through an almost empty calendar if the site only has two upcoming workshops.

Testing the Shortcode in the Editor

After inserting the shortcode, open the page as a visitor. Make sure events are displayed, links point to the correct products, date sorting behaves as expected, and the mobile layout does not turn the calendar into a cramped table. If the shortcode does not render, first check whether the required Calendar extension is active, then review page permissions, caching, and possible errors in the shortcode parameters.

Localization, Terminology, and Careful Adaptation for a Non-English Site

FooEvents supports terminology changes in settings and localization through language files. Those are two different layers. Terminology settings let you quickly replace words such as "event," "attendee," or "book ticket" with wording that fits your scenario better. Language files are for deeper and more stable translation of system strings.

The documentation describes creating .po and .mo files in Poedit and placing them in wp-content/languages/plugins/ or in the language folder of the relevant plugin. For the main FooEvents for WooCommerce plugin, the documented text domain is woocommerce-events. That is useful if you want to translate the interface and emails without editing plugin files directly.

What Is Best Changed Through Settings

• The attendee label, if terms like "guest," "student," "participant," or another role fit your event better.
• The purchase button text, if "Add to cart" feels less appropriate than "Book Ticket" or "Register."
• Terminology inside the ticket email, if the default wording does not fit your niche.

What You Should Not Translate Manually in Templates

Do not edit strings directly inside plugin files. Those changes are easy to lose during updates. If you need system-level localization, use language files. If you need to change the appearance of a ticket theme, work with a copied theme in the uploads folder. If you need to change the customer journey in WooCommerce, first review the theme settings and checkout plugins before you start thinking about code.

Performance, Caching, and Ticketing Security

A ticketing system touches sensitive parts of the site: checkout, email, API endpoints, attendee lists, check-in, and reporting. That means optimization should not break dynamic behavior. Caching is helpful for event pages and overall load, but the cart, checkout, account area, REST API, and ticket validation workflow must remain fully live.

Caching: What Can Be Accelerated and What Must Stay Dynamic

Event description pages can usually be cached like normal product pages if the theme and WooCommerce correctly update ticket availability. But the cart, checkout, account area, and API requests must not be turned into static pages. If, after enabling optimization, the customer sees outdated inventory, cannot submit the form, or the app cannot connect, temporarily disable caching and test the flow without it.

For larger events, FooEvents documentation recommends confirming in advance that the site can handle heavy traffic, and it also points to the REST API and a possible XML-RPC fallback path for the app. That does not mean you should disable site security. It means your security rules must allow legitimate app requests and must not block check-in staff at the door.

Email and SMTP

If tickets are landing in spam, the cause may be the sender address, the WordPress mail method, the email theme, the content, or the domain's sending reputation. FooEvents documentation recommends using an SMTP plugin if default WordPress mail has poor deliverability. For a ticketing site, that is close to a mandatory practical step: the ticket email needs to arrive quickly and reliably.

Safe Permissions for Staff

Do not give administrator access to everyone working the entrance. Create separate user accounts, restrict their permissions, and test access to the Check-ins app. After the event, disable temporary accounts. That reduces the risk of accidental changes to products, orders, or site settings.

Troubleshooting Tickets, Emails, and Check-In Issues

Most FooEvents problems are easier to diagnose not by plugin name, but by the exact point where the chain breaks: product, order, ticket, email, API, app, user role, or cache. Below is a practical symptom map for issues that commonly appear on WooCommerce ticketing sites.

The Ticket Is Not Created After Purchase

Symptom: the order exists in WooCommerce, but there is no ticket in FooEvents > Tickets, or no ticket email was sent.

Possible cause: the order did not reach a status selected in Send on order status, the product is not configured as virtual and downloadable for automatic completion, the event is not enabled in Event Settings, or the payment gateway returns an intermediate status.

What to check: open the order, review its status, check the product, the Event Settings tab, the Virtual and Downloadable options, and then the global send-on-status setting.

How to fix it: configure the correct status for ticket generation, complete a test order manually, and see whether the ticket is created. If it only works manually, investigate the gateway behavior.

The Ticket Email Does Not Arrive or Goes to Spam

Symptom: the ticket exists in the admin area, but the buyer cannot find the email.

Possible cause: default WordPress mail has poor deliverability, the domain is not configured for sending, the message looks suspicious to mail filters, the email theme is overloaded with images, or the sender address does not match the domain.

What to check: the SMTP plugin send log, the spam folder, the sender address, the email theme, image sizes, and delivery of normal WooCommerce emails.

How to fix it: enable SMTP, send a test ticket, simplify the email theme, and verify the domain's SPF/DKIM records in your mail service settings. If the problem started after changing the ticket theme, temporarily switch back to the default theme.

The Check-ins App Cannot Connect to the Site

Symptom: the app does not accept the site, rejects the login, or does not load events.

Possible cause: incorrect URL, wrong account, insufficient permissions, blocked REST API, a security plugin, CAPTCHA on the login form, the site living in a subdirectory, or an address mismatch between the www and non-www version.

What to check: the site URL in Settings > General, the availability of /wp-json/fooevents/v1, the user role, security plugins, REST API restrictions, and CAPTCHA on login.

How to fix it: use the exact site URL, create a dedicated user with the required permissions, temporarily disable the blocking security module for testing, and then add proper exclusions. Do not leave security disabled after the test.

The QR Code Scans in a Generic App but Does Not Mark the Attendee

Symptom: a third-party scanner shows the code value, but the attendance status does not change.

Possible cause: a regular QR scanner does not perform FooEvents validation. The documentation explicitly states that attendee check-in requires the FooEvents Check-ins app or Express Check-in.

What to check: which app is scanning the code, whether the site connection works, whether the app can see the correct event, and whether the user role is sufficient.

How to fix it: use the official app or Express Check-in, and test with a real test ticket rather than a Ticket Theme preview.

The Checkout Page Breaks After Enabling the Variation Table

Symptom: ticket type selection or add-to-cart behavior starts acting strangely, especially with Ajax buttons, the theme, or a third-party checkout plugin.

Possible cause: the Display event variations as a table mode changes standard variable product behavior and may conflict with plugins that already customize WooCommerce add-to-cart.

What to check: disable table mode, clear the cache, try adding a ticket again, and then temporarily disable plugins that modify the product page or checkout.

How to fix it: keep the default variation display if the table layout breaks the critical purchase path. A nicer ticket selector should never matter more than a stable payment flow.

The Report Does Not Show What the Organizer Expects

Symptom: the report shows sales and check-ins, but the needed CSV or detailed analytics are missing.

Possible cause: FooEvents Reports is meant for a quick overview, while CSV export comes from the event product through Event Export. Marketing analytics require separate tools.

What to check: open the event product itself, go to the Event Export tab, choose the required options, and download the CSV. For revenue and order data, also review WooCommerce reports.

How to fix it: separate FooEvents operational reporting, the attendee list, and WooCommerce financial analytics. Do not expect one screen to answer everything.

Limits and Risky Settings You Should Know About Early

FooEvents has strong WooCommerce integration, but that also creates a dependency on the condition of the store itself. If the site is overloaded with plugins, checkout is heavily customized, the REST API is blocked, and email is sent without SMTP, the ticketing workflow becomes fragile. That is why good setup starts not with "turn everything on," but with reducing risk.

No Open API or Hooks for Arbitrary Development

FooEvents documentation states that, at the time of review, the product does not provide a public API or hooks for third-party developers, although it does include a code snippets section. This is an important limitation for agencies. If a client already wants a non-standard integration, synchronization with an internal system, or deep automation, you should not promise it as a simple WordPress filter-based customization. First review the official snippets, data structure, WooCommerce capabilities, and whether custom development is realistically viable.

PDF, Seating, Calendar, and Bookings Are Not Part of the Base Install

The product page and documentation often mention extensions alongside the main plugin. That is normal in the FooEvents ecosystem, but when planning your budget and site structure, it is important to separate base functionality from add-on functionality. If you need PDF attachments, interactive seating, multi-day events, a calendar, or POS, verify which extension is required and how it changes the user journey.

A Ticket Preview Is Not the Same as a Real Ticket

In Ticket Themes, you can send a preview email, but the documentation warns that the test data does not match a real ticket and will not scan as a valid attendee ticket. Use the preview to review the design, and use a real test order to validate the ticket workflow.

Final Dry Run Before Opening Sales

Before publishing the event link, it is worth running a short rehearsal as if this were a live operation, not just a settings review in the admin area. In FooEvents, many pieces can look ready on their own: the product is published, the email looks polished, the QR code is present, the app is installed. But the attendee does not go through separate screens - they move through one continuous path. If the order stalls in the middle, the email never arrives, or check-in staff cannot see the event, everything may look "almost configured" even though sales should not be opened yet.

The final dry run should be done on a test event using the same settings that will be used for the real one. Do not use an oversimplified product if the real ticket will be a variable product. Do not test only a free order if live sales will go through a payment gateway. Do not test a single ticket if customers often buy several seats at once. The closer the test is to reality, the fewer surprises you will face after launch.

Control Purchase Scenario

1. Open the event page in a private window so you see it exactly as a new visitor would.
2. Select the correct ticket type, add it to the cart, and confirm that the price, quantity, and title are clear.
3. Enter buyer and attendee details the way a real customer would, including multiple tickets in one order.
4. Place the order through the payment gateway's test mode or a safe internal payment method.
5. Check the order status and confirm that it matches the Send on order status setting.
6. Open FooEvents > Tickets and make sure the correct number of tickets was created.
7. Open the email on both a phone and a computer, and verify the logo, date, time, attendee name, and validation code.
8. Scan the ticket using the same method that will be used at entry, and confirm that the status changes.
9. Scan the same ticket again to see how the system warns about repeat entry.
10. Download the CSV from Event Export and confirm that it includes the fields needed for the backup list.

This kind of test takes longer than simply clicking Preview, but it validates what actually matters to attendees and staff. If an issue appears at this stage, you still have time to fix it without public fallout: adjust the ticket issuance status, enable SMTP, change the field position, simplify the ticket theme, or prepare proper staff permissions.

What to Check on a Mobile Device

A ticket page may look fine on desktop and work poorly on a phone. For events, that is critical: many attendees buy tickets on mobile, and later show the QR code from the same device. Check the product page, cart, checkout, email, and ticket itself on a mobile device. Pay special attention to variable ticket options, long titles, required attendee fields, and add-to-calendar buttons.

If table-style variation output is enabled, make sure the table does not run off the edge of the screen or break quantity selection. If the theme hides checkout field labels, try placeholder hints or a different attendee field position. If the ticket email is too wide, reduce image sizes and review the ticket theme.

Entry Rehearsal for the Team

Run a separate rehearsal for the entry team. Create a test staff account, give it only the required permissions, log in to the app, load the event, and scan several test tickets. Then disable internet access on the device or switch to a weak connection so you understand how the team should react if something goes wrong. If the event is large, test multiple devices and different roles.

Staff should know what to do with repeat scans, a "ticket not found" error, a visitor without the email, a camera problem, a dead phone, and manual name lookup. It is best to turn those cases into a one-page internal instruction sheet. FooEvents provides the validation tool, but the actual entry procedure is still the organizer's responsibility.

Readiness Criteria Before Publishing

• The test order completes from the event page to the final status without manual correction.
• Tickets are created in the correct quantity and are visible in the admin area.
• The email arrives at an external inbox, does not look broken, and contains a valid code.
• The Check-ins app or Express Check-in can find the ticket and change the attendee status.
• Staff have separate accounts with only the minimum required permissions.
• The CSV export contains the data needed for the backup list and reporting.
• Cache, security rules, CAPTCHA, and optimization do not block checkout or the REST API.

If even one of these items fails, do not open sales for the live event. Fix the specific break and repeat the test. That may sound strict, but a ticketing site is not about having a nice product page. It is about the promise you make to the attendee: after payment, they will have confirmed access, and your team will be able to validate that access quickly and with the right level of permissions.

Comparable Ticketing Options for WordPress Sites

When CodeCanyon FooEvent Is the Right Choice

CodeCanyon FooEvent is worth using if you want a ticketing system inside WordPress and WooCommerce rather than a separate platform with someone else's checkout. Its main strength is the clarity of the workflow: a WooCommerce product becomes an event, the order creates the ticket, the email delivers the attendee details, the QR code or barcode supports entry validation, and the admin area stores reports and exports.

Before launch, do not try to configure everything in one evening. Start with one test event and verify the WooCommerce order, ticket, email, QR code, app, staff role, and CSV export. Then add ticket variations, localization, calendar features, PDF, seating, or other extensions. That sequence lowers risk and makes the guide applicable to a real production site.

If, after testing, the workflow matches your needs, you can download the ZIP archive and deploy it to a staging copy of the site first. For any live event, the final check is always the same: the attendee buys the ticket, receives the email, arrives at the entrance, and the team confirms access quickly and without unnecessary permissions.