GeoDirectory Events Tickets Marketplace - WordPress Plugin

How to Set Up and Use GeoDirectory Events Tickets Marketplace

GeoDirectory Events Tickets Marketplace does more than add a ticket purchase button. This add-on connects the GeoDirectory events directory, the GetPaid checkout form, inventory control, the organizer wallet, QR ticket validation, and sales reports into one working flow. In this guide, we'll walk through how to prepare your site, where to find the settings, how to display the ticket sales button on an event page, how to verify a purchase, and what to do if the event owner, buyer, or administrator is seeing the wrong outcome.

This article is written for a WordPress site owner who already understands the basic idea of an events directory but wants to turn it into a manageable ticketing marketplace. It does not cover license purchases or activation workarounds. We are focusing on the practical launch of an add-on you already have: installation, dependencies, commission settings, payment form selection, placement of the Sell Tickets block, a test purchase, QR code validation, reports, and careful troubleshooting.

The main characteristic of GeoDirectory Events Tickets Marketplace is role separation. The site administrator controls the overall platform, the event owner creates tickets on the front end of the site, the buyer pays for the selected ticket type, and the person checking entry can confirm the ticket status and mark it as used. If you set up this chain without checking roles, templates, and the payment form, the site may look functional in the admin area but break in the real sales flow.

That is why this guide is not written as a promotional overview. It starts with a product map and preparation, then moves into detailed setup, a real event example, result validation, troubleshooting, related solutions, and FAQ. At the end, there is a natural download link so you only move on to the file after deciding whether the add-on fits your site.

What the Add-On Actually Adds to an Events Directory

GeoDirectory already lets you build a directory with post types, maps, detail pages, blocks, widgets, and shortcodes. The free Events Calendar for GeoDirectory add-on brings in event functionality: dates, schedules, recurring events, a calendar view, and time-based filters. GeoDirectory Events Tickets Marketplace sits on top of that foundation and adds the commercial layer: the event owner can create ticket types, the visitor can buy a ticket, the system generates confirmation and the ticket itself, and the owner or administrator gets control tools.

The official documentation describes the add-on as a way to sell tickets through a directory website and, if needed, collect a commission on sales. That is an important distinction: the product is not just for a single event owner, but also for a platform where different organizers publish their own events. In that model, the site becomes more than a simple event listing - it turns into an events marketplace where the platform owner provides the infrastructure and organizers manage their own tickets.

How a Ticketed Event Differs from a Regular Event

A standard event page answers the questions "where," "when," and "what's happening." A ticketed event page also needs to answer "which ticket should I choose," "how many spots are left," "how do I pay," "where do I download the ticket," "how does entry validation work," and "what does the organizer do after the sale." That is why setup cannot stop at installing the add-on. You need to verify the full chain from the event to the report:

• The event must be created under the correct GeoDirectory event post type.
• The event owner must see the Sell Tickets button, while a regular visitor must not see it as a management tool.
• The buyer must see Buy Tickets, choose a ticket type, and go through the GetPaid checkout form.
• After payment, the buyer must get access to the ticket, and the event owner must get access to sales management and the scanner.
• The administrator must be able to see total tickets sold, reports, and commissions.

If even one of those items is not checked, the problem may show up late. For example, the organizer may successfully create an event but never see the ticket creation button. Or the buyer may pay successfully, but the ticket email lands in spam because of the server's mail configuration. The guide below follows that exact chain rather than an abstract feature list.

Who This Ticket Marketplace Is For, and When Another Approach Makes More Sense

GeoDirectory Events Tickets Marketplace is a strong fit for sites where an event is part of a directory. That could be a city events listing, a directory of clubs and venues, a regional tourism site, a niche portal for workshops, an education-focused showcase, a local concerts database, or a private organizer network. One of the add-on's strongest points is the connection between the ticket and the owner of a specific GeoDirectory listing, along with the ability to display management tools directly on the event page.

If you only need a single landing page for one event once a year, the product may be more than you need. In that case, a dedicated ticketing plugin, a payment form, or a WooCommerce product will usually be simpler. But if you are building a directory where events are submitted by different owners, the value of GeoDirectory Events Tickets Marketplace becomes much clearer: each organizer works with their own event, while the platform administrator can monitor sales and build commission into the model.

Strong Use Cases

The add-on is especially useful when you need to combine event discovery with ticket sales:

• A citywide events directory with paid concerts, lectures, exhibitions, and tours.
• A local organizers portal where event owners create their own tickets and monitor sales.
• A directory of courses, workshops, and meetups where an event can offer multiple ticket types.
• A venue website that wants to sell tickets without sending visitors to a third-party platform.
• Events with recurring dates where the buyer needs to choose a specific visit date.

When the Product May Not Be the Right Fit

Do not install this add-on just because the word "tickets" appears in the name. It depends on GeoDirectory, Events Calendar for GeoDirectory, and GetPaid. If your site is already built around The Events Calendar, WooCommerce Tickets, Event Espresso, or a standalone SaaS platform, switching will require you to migrate event logic, templates, and roles. If you need complex seat mapping, interactive seating charts, multi-layer promo automation, or deep WooCommerce inventory integration, compare this product with the alternatives in the section below before moving ahead.

The practical decision rule is simple: if the event needs to be a full GeoDirectory listing and the organizer needs to manage tickets from their own event page, this is a product worth testing. If the ticket is simply a store product or a registration form without a directory, choose a more focused tool.

What to Check Before Installation

Before installation, it is important to check not just your WordPress and PHP versions, but also the dependency stack. The official documentation states that the add-on requires GeoDirectory, Events Calendar for GeoDirectory, GetPaid, GetPaid Item Inventory, and GetPaid Wallet. The documentation also notes that if those dependencies are missing during installation, the add-on may install them automatically. In practice, it is still better to understand why each one matters, because troubleshooting almost always starts with dependencies.

Platform and Dependencies

The core logic looks like this:

• GeoDirectory provides the directory, post types, detail pages, blocks, widgets, and front-end submission.
• Events Calendar for GeoDirectory adds event fields, schedules, recurring events, and calendar views.
• GetPaid handles checkout forms, invoices, and payment for selected tickets.
• GetPaid Item Inventory is needed for quantity control so you do not sell more tickets than are available.
• GetPaid Wallet is used when distributing funds to organizers and handling balance withdrawals.

Ideally, you start by running GeoDirectory and Events, create a test event, verify the public event page, and only then add the ticketing layer. If you install everything at once on an empty site with no event structure, it becomes hard to tell what exactly is broken: the event page itself, the detail template, the ticket sales block, the payment form, or the report.

User Roles and Event Publishing

In a ticketing marketplace, user registration becomes part of the business logic. The event owner must be able to log in and manage their own event. GeoDirectory documentation separately describes a common issue where users cannot register and points to the WordPress setting under Settings - General - Membership - Anyone can register. That option should be enabled intentionally: if you allow organizer signups, add moderation, anti-spam controls, and a clear review flow for new events.

For a public site, define the rules in advance:

• Who can add an event: any registered user, only approved organizers, or the administrator.
• Whether new events go live immediately or require moderation.
• Who is responsible for price accuracy, dates, seat quantity, and ticket text.
• Who validates tickets at the entrance and how they get access to the scanner.
• What happens to organizer funds after a sale if Wallet is being used.

Payments and Email

GetPaid covers the checkout form, but the payment side of the site still depends on configured gateways, test mode, and email delivery. Before your first real event, verify at least one test payment, the buyer email, the event owner email, the confirmation page, ticket download, and the report. If emails are not arriving, GeoDirectory documentation recommends starting with Email Log: first confirm that WordPress generated the message, and only then start looking at hosting, domain email, or your mail provider.

Safe launch order: test event - test ticket with a small price or test gateway - test purchase - email - ticket download - scan - report - and only then real sales.

Installation and Initial Validation in WordPress

The official GeoDirectory documentation describes two ways to install extensions: automatic installation through GeoDirectory - Extensions and manual installation by uploading a ZIP under Plugins - Add New - Upload Plugin. In this guide, the method itself matters less than the initial checks after activation. Once installed, GeoDirectory Events Tickets Marketplace should add a Tickets menu to the WordPress admin area with the subitems Sold Tickets, Reports, and Settings.

Automatic Installation

If the site is connected through AyeCode Connect, extension installation usually happens in the GeoDirectory - Extensions section. The documentation notes that paid extensions require a valid license, and on a local site you may need WP Easy Updates. This article does not cover license purchase or entry, but for troubleshooting it helps to know this: if the extension does not appear in the list or fails to update, the problem may not be Events Tickets Marketplace itself. It may be related to AyeCode Connect, a security plugin, maintenance mode, or a REST API restriction.

Manual Installation

The manual route is the usual WordPress flow: upload the ZIP through Plugins - Add New, click Upload Plugin, select the archive, install it, and activate it. After activation, do not just check the plugin list. Open the Tickets menu, confirm that Settings, Sold Tickets, and Reports are available, then open any event page on the front end while logged in as the listing owner.

Post-Activation Checklist

The initial validation should answer four questions:

1. Are the GeoDirectory, Events Calendar for GeoDirectory, GetPaid, Item Inventory, and Wallet dependencies active?
2. Has the event post type been created, and is there at least one test event?
3. Did the Tickets menu appear in the admin area?
4. Can you output the ticket sales block or shortcode inside the event page template?

If the menu appears but the owner button does not show on the event page, do not rush into reinstalling the add-on. Usually, you need to check the event detail template and make sure the Sell Tickets block or the shortcode [gd_sell_tickets primary_color="primary" secondary_color="secondary"] is present. If the block is inserted but not visible to a regular visitor, that may be normal behavior: the documentation states that the Sell Tickets button is visible to the event owner, while regular visitors do not see it.

Commission, Payment Form, and Wallet Settings

GeoDirectory Events Tickets Marketplace settings are located under Tickets - Settings. The official documentation emphasizes that the add-on ships with sensible defaults, but two settings usually require special attention: the platform commission percentage and the payment method. Those two options define the business logic of the marketplace: whether you take a share of each sale and how the buyer pays for a ticket.

Ticket Sales Commission %

Ticket Sales Commission % sets the share of each sale that goes to the site administrator. For an events directory, this is more than just a financial field. Commission affects organizer expectations, refund policy, reports, and how you explain the rules on the event submission page. If you are launching a platform with external organizers, do not hide the commission deep inside your rules. Add a clear explanation in the organizer help section: how commission is calculated, when it is withheld, where the organizer can review sales, and how they withdraw funds.

For initial testing, you do not need to choose a final value right away. It is better to set a safe test percentage, run a purchase, review the administrator report and the event owner's report, and then decide whether the model is clear enough. If commission does not appear in reports the way you expect, or the organizer sees the amount differently than expected, pause real sales until you verify the payment form and wallet behavior.

Payment Form: checkout or wallet

The second critical setting is Payment Form. The documentation describes two modes: Check Out and Wallet. In Check Out mode, the buyer pays the exact amount for the selected tickets through an available payment gateway. In Wallet mode, the user adds funds to their balance in advance, and the ticket purchase amount is deducted from the wallet.

For most new sites, Check Out is the better place to start. It is simpler for the buyer: choose a ticket, fill out the form, pay, download the ticket. Wallet makes sense when the site already has repeat purchases, an internal balance system, organizers with recurring payouts, or a model where participants preload funds. But that mode is harder to explain to users, harder to test, and more important to review from a legal and accounting perspective.

How to Verify That the Payment Setting Works

After changing the payment form, run a test purchase. For Check Out, the expected result is that the buyer sees a payment form for the selected amount and, after confirmation, gets a page where tickets can be downloaded. For Wallet, the expected result is that the user can add funds, view their balance through a Wallet block, widget, or shortcode, and pay for the ticket using that balance. If you switch modes on a live site, warn your test organizers first and verify any tickets that were already created.

The Wallet and Organizer Withdrawals

Events Tickets Marketplace documentation states that GetPaid Wallet is used to distribute proceeds to event owners, and that the administrator needs to place a Wallet Block, Widget, or Shortcode where users can see their balance and withdraw funds. In practice, that may be an organizer dashboard, a separate "Balance" page, or a tab in the user menu.

Do not place the wallet block in a random location just because it is technically required. The user should understand what they are looking at: available balance, transaction history, the withdrawal button, limits, and status. The WordPress.org description for GetPaid Wallet confirms features such as deposits, withdrawals, balance usage at checkout, and a minimum balance requirement for withdrawals. So in a real project, review the Wallet settings inside GetPaid itself, not just the Tickets - Settings screen.

How to Display the Ticket Sales Button on the Event Page

The most product-specific part of the setup is placing Sell Tickets on the event detail page. The documentation says that for the event owner, you need to add the Sell Tickets block or shortcode to the event page template. The documentation example places the block in the GD Sidebar so the event owner sees the Sell Tickets button. You can also use the shortcode [gd_sell_tickets primary_color="primary" secondary_color="secondary"] in the appropriate template location.

This is an easy place to make mistakes. The block should not be added to a random page, but to the event detail template where the specific listing is rendered. If you are using the block editor, GeoDirectory widgets, or a page builder, first determine which template controls the event card. In GeoDirectory, elements can be rendered as blocks, widgets, or shortcodes, and the Shortcode Builder can help you assemble the element wherever that output is supported.

Where Sell Tickets Works Best

The ideal location depends on the page design, but the logic is simple: the event owner should be able to find ticket management quickly, and the buyer should only see the purchase flow after tickets have been created. Good placements include:

• The event sidebar near the date, address, and contact details.
• The upper section of the page below the main event information.
• A separate tab or block in the event details if the page is content-heavy.
• The template for the event CPT rather than a global page for all directory listings.

After adding the block, test the page under three roles: administrator, event owner, and regular visitor. The owner should see Sell Tickets before any tickets are created. After the first ticket is saved, the documentation says the sales button for that event is replaced with two buttons: Buy Tickets, visible to everyone, and Ticket Management, visible only to the event owner.

Using the Shortcode as a Fallback

The shortcode is useful if the template is built in an area where the block is inconvenient or unavailable. The documentation gives this example:

[gd_sell_tickets primary_color="primary" secondary_color="secondary"]

Do not paste it manually into the content of every event. It is better to place the shortcode in the event detail template so it works automatically for all listings of that type. If the shortcode is inserted into the wrong area, it may appear where there is no context for the current event, or it may not deliver the expected owner-specific behavior.

Checking Button Visibility

After saving the template, run a short test:

1. Open a test event while logged in as the listing owner.
2. Make sure the Sell Tickets button is visible.
3. Create one ticket type and save it.
4. Open the event in a private browser window as a regular visitor.
5. Confirm that Buy Tickets is visible, but Ticket Management is not.
6. Switch back to the event owner account and confirm that Ticket Management is available.

If the buttons behave differently, check the listing owner and the event detail template first. That is faster than reinstalling the add-on or changing payment settings.

Creating Tickets as the Event Owner

GeoDirectory Events Tickets Marketplace moves ticket creation to the front end of the site. The official documentation explicitly states that tickets are currently created from the public side after clicking Sell Tickets. That is an important difference from many ticketing plugins, where the administrator creates a ticket in the admin area as a product or registration option.

What Fields the Owner Fills In

After clicking Sell Tickets, the event owner sees the ticket creation window. The documentation lists the following fields: Ticket Name, Ticket Price, Available Quantity, Selected by default, a button to add more tickets, and a save button. That is enough for typical cases: a standard ticket, a discounted ticket, a VIP ticket, early registration, or multiple pricing tiers.

When creating ticket types, it is best to stick with a clear structure. Do not name tickets something vague like "Ticket 1" and "Ticket 2." The buyer should immediately understand what is different: access level, seating, date, participation format, age group, or service package. If the event is recurring, date selection logic will appear during checkout, but the ticket type name still needs to be clear.

Quantity and Overselling Protection

Available Quantity controls the number of tickets available. The dependency stack includes GetPaid Item Inventory, which according to its WordPress.org description allows you to set stock levels for individual items, display low or zero stock, send notifications, and prevent sales beyond the available quantity when back orders are disabled. For tickets, this is critical: a quantity mistake becomes an entrance problem immediately.

Before launching a real event, test the "almost sold out" scenario: set a low limit, buy several tickets, and make sure the system does not allow purchases beyond availability. If the venue has a real physical capacity, do not rely on descriptive text alone. Quantity should be enforced in the ticket settings.

Selected by default

The Selected by default field is useful when there is a primary ticket type that buyers choose most often. But do not enable it carelessly for an expensive or limited ticket. If the site sells multiple categories, make the default the most common and neutral option. For special packages, it is better to let the user choose deliberately.

Editing and Management After the First Sale

After the first ticket is created, the event owner gets access to Ticket Management. The documentation describes the tabs or sections inside it: Types with the list of tickets for the current event, Sales with the sales list, Report with statistics, and Scanner for manual or QR-based ticket validation. For the organizer, this becomes the event control panel. It needs to make sense well before event day, not only once the first attendees start arriving.

Launch tip: before publishing a real event, create an internal test event and let the organizer go through the full process on their own. If they do not understand where to create a ticket or where to verify a sale, add a short instruction on the site.

Buying a Ticket and the GetPaid Payment Form

Once the event owner has created at least one ticket, regular visitors should see Buy Tickets. Clicking it opens the purchase form. The documentation explains that the user can choose a ticket type, set the quantity, fill in their details, and pay using an available method. In the documentation example, the form only asks for an email address, but the GetPaid checkout form builder lets you request additional information during checkout.

What Information to Ask From the Buyer

A minimal form usually converts better, but it does not always meet the organizer's operational needs. For a concert, an email address may be enough. For a workshop, a name may be necessary. For an event with age restrictions, group lists, or special requirements, you may need extra fields. The main rule is simple: ask only for the information that is actually needed to run the event and communicate with the buyer.

If a field is not needed at entry, do not add it out of habit. A long form lowers checkout completion and increases mistakes. For an initial test launch, keep the form minimal, then add fields based on real organizer needs.

Recurring Events and Date Selection

The documentation clarifies that if a ticket belongs to a recurring event, the buyer must choose the dates for which the ticket will be valid. That is a key test for calendar-based platforms. If you have a lecture series, a weekly tour, or a training schedule, test not just a single ticket, but a purchase for a specific date. At the entrance, the person validating tickets needs to understand that the ticket is valid for the correct date, not merely for the series in general.

Confirmation, Invoice, and Ticket Download

After payment, the buyer lands on a confirmation page where they can view the invoice, invoice history, and download tickets. This part is often skipped during testing because the administrator only looks at payment status. For the user, however, something else matters: they need to quickly understand where their ticket is and how to keep it until the event. Check the confirmation page on a mobile device, because many buyers will open their ticket on a phone.

The downloaded ticket is described in the documentation as an HTML ticket with a print option. The QR code makes it convenient to validate. But do not tell visitors that printing is required unless your team actually requires a printed ticket. It is better to state in the event instructions which format is accepted at entry.

Practical Example: A Local Conference with Multiple Ticket Types

Now let's build a real-world scenario. Imagine a GeoDirectory site that runs a directory of city tech events. The organizer publishes a conference and wants to sell standard tickets plus a limited number of tickets with access to a private session. The platform takes a commission, while the organizer monitors sales and validates tickets at the entrance.

Goal

The goal is to have an event page where a regular visitor sees Buy Tickets, chooses one of two ticket types, pays through GetPaid, downloads a ticket with a QR code, and the organizer sees sales, the report, and the scanner for entry. The site administrator should be able to see the overall sales list and the commission report.

Preparation

Before creating tickets, verify the following:

• GeoDirectory and Events Calendar for GeoDirectory are active.
• A test event exists with the correct date, location, and listing owner.
• The event detail template includes the Sell Tickets block or the shortcode [gd_sell_tickets primary_color="primary" secondary_color="secondary"].
• Check Out is selected under Tickets - Settings for a simple launch.
• A test payment method or safe test mode is enabled in GetPaid.
• WordPress email is being checked through a mail log or a similar tool.

Steps

1. Log in as the user who owns the test event.
2. Open the public event page and click Sell Tickets.
3. Create a General Admission ticket, set the price and quantity, and mark it as selected by default if it is the main ticket.
4. Add a second ticket called Workshop Access with a smaller quantity if access is limited.
5. Save the tickets and confirm that Buy Tickets and Ticket Management now appear on the page.
6. Open the page as a regular visitor, click Buy Tickets, choose a ticket type, and complete a test payment.
7. After payment, download the ticket and save it as a file or PDF.
8. Return to the event owner account, open Ticket Management, and check Sales, Report, and Scanner.
9. In the admin area, open Tickets - Sold Tickets and Reports to view the sale at the full-platform level.

Validating the Result

The setup counts as working when those three layers match. The buyer has a ticket and a clear confirmation page. The event owner sees the sale in Ticket Management, and the scanner shows the correct ticket status. The administrator sees a record in Sold Tickets and data in Reports. If any one layer is missing, do not launch real sales until you find the break in the chain.

A Detail People Often Miss

The test needs to be performed with users in different roles. An administrator may see more than a regular organizer. If only the administrator tested everything, you may miss the fact that the event owner cannot see Ticket Management, or that the buyer is seeing the wrong button. The minimum set of test accounts is: administrator, event owner, and regular visitor.

QR Validation, Ticket Statuses, and Entry Control

Ticket validation is a separate part of the product, not a decorative feature. The documentation explains that the event owner can use the scanner to validate a ticket by number or QR code. A ticket can have several statuses: invalid for this event, valid for a future date, valid today, already used, or expired. When the ticket is valid, a redeem button appears, and the ticket can then be marked as used.

This logic protects against two common problems: entry with a ticket for the wrong event and reuse of a ticket that has already been redeemed. For a venue with a single door, that may be enough. For multiple entrances, decide in advance who scans tickets and how their devices get access to the management page.

How to Prepare the Entry Team

Do not leave validation until the last hour. Run a rehearsal:

• Create one valid test ticket.
• Create a ticket for another date or event so you can see the warning state.
• Mark one ticket as used and try checking it again.
• Test the scanner on the device that will actually be used at the entrance.
• Prepare manual ticket-number lookup in case the camera or lighting makes QR scanning difficult.

What to Do with Recurring Events

For recurring events, date-based status is especially important. A ticket may be purchased for a future date and should not validate as valid for today's entry. The documentation explicitly highlights the status "valid for future date." So for recurring events, make sure you test not only the purchase flow, but also validation across different dates. If the organizer does not understand which date is being checked, entry errors are inevitable.

When You Should Not Click redeem

The redeem button should only be used after the visitor is actually admitted. If the staff member clicks it during a preliminary check in email or at the information desk, the ticket may be marked as used before entry happens. The internal instruction for the team should be short: scan, confirm the status, admit the visitor, then mark the ticket as used. If the status is red or yellow, do not click redeem and escalate the issue to the responsible person.

Reports for the Event Owner and the Platform Administrator

GeoDirectory Events Tickets Marketplace has two reporting levels. The event owner sees data for a specific event through Ticket Management: ticket types, sales, a simple report, and the scanner. The site administrator sees the global Sold Tickets and Reports pages under the Tickets menu. This separation matters not only for convenience, but also for trust between the platform and its organizers.

What the Event Owner Should See

Organizers usually need three things: how many tickets were sold, which ticket types are selling, and whether each attendee can be validated. Do not overload them with admin-level data if they are not site administrators. Their working area is the individual event. If they cannot find sales, add a link to the event page in their dashboard or provide a short instruction after the event is published.

What the Administrator Controls

The administrator looks at the wider picture: all sold tickets, overall trends, commissions, potentially disputed transactions, and the health of the payment flow. If the site operates as a marketplace, the administrator should regularly compare GetPaid reports, Tickets reports, Wallet data, and actual payment receipts. Do not treat the internal report as an accounting document unless it has been reviewed against the requirements of your jurisdiction and payment provider.

How to Use Reports to Improve the Platform

Reports are useful not only after the event. They can show which ticket types sell faster, which organizers create clearer event cards, where buyers drop out of the flow, and which recurring dates are more popular. If sales are weak, do not change the commission right away. First, review the event page, the clarity of ticket names, the payment form, the number of required fields, and the trust signals on the site.

Customizing Tickets, Emails, and Safe Improvements

The GeoDirectory Events Tickets Marketplace documentation states that the add-on includes two email templates and two ticket templates. For email, those are wpinv-email-user_tickets.php and wpinv-email-tickets_sold.php. For tickets, they are ticket.php and base.php. The official customization method is to copy files from the add-on folder into a child theme using the documented paths, rather than editing plugin files directly.

What You Can Change in Templates

Templates should only be changed where it brings real value: add clearer entry instructions, specify the organizer contact, make the email text less dry, adjust ticket branding, add attendance rules, or explain whether the ticket can be shown on a phone. Do not change the technical parts of the QR code, ticket number, or status unless you fully understand the template.

The safe approach looks like this:

1. Copy the template into the child theme using the official path.
2. Make one small change to the text or markup.
3. Buy a test ticket.
4. Check the email, ticket download, print version, and QR validation.
5. If something breaks, remove the override file from the child theme and go back to the add-on template.

CSS Without Interfering with checkout Logic

GeoDirectory documentation on CSS customization recommends adding styles through Appearance - Customize - Custom CSS, the child theme's style.css file, or a dedicated custom CSS plugin. For a ticketing flow, only small visual adjustments make sense: spacing, button visibility, or readability of the block in the sidebar. Do not hide payment form fields or change checkout behavior through CSS.

/* Moderately highlights the ticket sales block on the event page.
   Add this in Custom CSS or the child theme's style.css and test it on mobile. */
.geodir-single .gd-sell-tickets,
.geodir-single [data-widget*="sell_tickets"] {
  margin-top: 16px;
  padding: 16px;
  border: 1px solid rgba(0, 0, 0, 0.12);
  border-radius: 8px;
  background: #fffaf3;
}

This example is intentionally cautious: it does not interfere with payment and does not hide fields. But selectors may differ depending on your theme or markup version, so inspect them in the browser first. If the style does not apply, do not start piling on !important everywhere. It is better to identify the exact block container in your template.

Validation After Customization

Any template or CSS change should go through the same test: the event page as the owner, the page as a visitor, purchase flow, email, ticket download, print or PDF, QR validation, and report. Even if you only changed the visual design, the test still matters because CSS can break a modal window, a button, or the scanner area.

Common Problems and Troubleshooting

Problems in a ticketing marketplace rarely come from a single cause. GeoDirectory Events Tickets Marketplace sits at the intersection of the directory, the event, the user role, the template, payments, email, and reporting. That is why troubleshooting works best when you follow symptoms instead of changing settings at random.

The event owner cannot see Sell Tickets

Symptom: the event page opens, but there is no Sell Tickets button. A regular visitor also sees nothing.

Possible causes: the block or shortcode was not added to the event detail template, the wrong CPT is being viewed, the user is not the listing owner, dependencies are inactive, or the page builder template is rendering a different area.

What to check: the presence of the Tickets menu, whether Events Calendar for GeoDirectory is active, the specific event page under the listing owner account, the event detail template, and the presence of the Sell Tickets block or shortcode.

How to fix it: add the block to the event detail template or place the shortcode [gd_sell_tickets primary_color="primary" secondary_color="secondary"] in the correct area. Then test again as the owner and as a regular visitor. If the listing owner is assigned incorrectly, change the event owner using GeoDirectory or WordPress tools.

Buy Tickets does not appear after a ticket is created

Symptom: the owner created a ticket, but the visitor does not see the purchase button or still sees the old state.

Possible causes: the ticket was not saved, inventory is zero, cache is serving an old page, the user is viewing the wrong event, the template is hiding the block, or there is a theme conflict with the modal window.

What to check: open the event in a private window, temporarily clear the page cache, check Ticket Management under the owner account, and make sure at least one available ticket type exists.

How to fix it: save the ticket again, clear cache, and inspect the template markup. GeoDirectory documentation notes that v2 was designed with caching in mind, but for interactive flows it is still helpful to exclude checkout pages, account pages, and dynamic ticket areas from aggressive optimization if a specific caching plugin is breaking modal behavior.

404 errors appeared after changing settings

Symptom: event pages, ticket pages, or related areas return 404 Page Not Found.

Possible cause: WordPress or GeoDirectory did not refresh permalink rules after a structural change.

What to check: open Settings - Permalinks and save the settings again. If that does not help, the documentation recommends temporarily saving GeoDirectory permalinks to a different value and then switching back to the preferred one.

When to roll back: if the 404 errors started after changing a slug, CPT, or template, restore the previous structure and test changes on a staging site first.

The buyer is not receiving the ticket email

Symptom: payment went through, the ticket is available on the confirmation page, but no email was received.

Possible causes: the email was not generated, the server is not sending mail, the domain does not have SPF/DKIM/DMARC configured, the provider rejected the message, or the content looks suspicious to the filter.

What to check: install Email Log or a similar logger and verify whether WordPress generated the email. If it did, the problem is usually outside WordPress: SMTP, hosting, DNS records, or the email provider.

How to fix it: configure SMTP sending from a domain-based address, verify domain records, reduce suspicious wording in the email, and repeat the test purchase.

The QR scanner shows an unexpected status

Symptom: the ticket scans, but the status is red or yellow even though the buyer is sure the ticket is correct.

Possible causes: the ticket belongs to another event, another date in a recurring series, has already been used, has expired, or was checked by the wrong owner.

What to check: the event, the date, the ticket number, usage history, payment status, and the role of the user who is scanning.

How to fix it: do not click redeem when the status is disputed. First find the sale in Ticket Management or Sold Tickets, then compare the date and the event. If the ticket is genuinely not for that event, do not admit the visitor with it unless an administrator makes a manual decision.

The organizer cannot see the balance or withdraw funds

Symptom: sales exist, but the organizer does not understand where the balance is or how to withdraw funds.

Possible causes: the Wallet Block/Widget/Shortcode was not placed, GetPaid Wallet is inactive, Wallet settings are incomplete, the user is looking at the wrong dashboard, or withdrawals are disabled by site policy.

What to check: whether GetPaid Wallet is active, the page with the wallet block, the settings under GetPaid - Settings - Wallet, the minimum withdrawal balance, and user permissions.

How to fix it: create a dedicated balance page for organizers, place the Wallet Block/Widget/Shortcode there, and add a short instruction. If withdrawals require manual review, say so clearly in the platform rules.

The block editor shows an invalid content error

Symptom: in the WordPress editor, a GeoDirectory block shows the message This block contains unexpected or invalid content.

Possible cause: the block markup changed, or the editor cannot match the saved block to the current version.

What to check and how to fix it: GeoDirectory documentation recommends opening the block menu with the three dots and clicking Attempt Block Recovery. After recovery, save the template and test the public event page again.

Compatibility with Themes, Builders, Caching, and SEO

GeoDirectory supports blocks, shortcodes, and widgets, and the core plugin claims compatibility with popular page builders. But the ticketing workflow adds modal windows, checkout, dynamic buttons, and the scanner. That means compatibility should be tested not on the home page, but through specific actions: open an event, create a ticket, buy it, download it, scan it, and view the report.

Theme and Event Template

The theme must render the GeoDirectory detail template correctly. If the event page is built with a page builder, verify that the ticket sales block is placed inside the context of the current listing. Sometimes a polished template works visually as a storefront but does not pass the correct context to a dynamic block. In that case, a shortcode placed in the proper area may be more reliable than a visual block inside an arbitrary section.

Cache and Dynamic Areas

GeoDirectory documentation states that v2 is compatible with multiple caching approaches, including page cache, browser cache, server-side cache, and object cache. But ticket checkout and user-specific states always require extra care. Do not cache pages where the user sees a personal balance, checkout, payment confirmation, or ticket management. If buttons disappear or modal windows open with stale state, temporarily disable JavaScript optimization and page cache for those URLs and test again.

SEO for Ticketed Events

The add-on does not replace proper event page structure. For search visibility, what matters is a unique event description, date, location, category, a clear headline, clean URLs, and a template that is not overloaded. The ticket block should support conversions, not bury the main content. Let the visitor understand the event first, then offer the ticket. If the purchase button appears above the date, venue, and program details, it can reduce trust.

For an event directory, internal linking is useful: city - category - specific event - similar events. But do not put the name GeoDirectory Events Tickets Marketplace into every heading or anchor. Users are looking for the event and the ticket, not the name of the internal add-on.

When GeoDirectory Events Tickets Marketplace Is the Right Choice

GeoDirectory Events Tickets Marketplace is worth using if you are building an event directory on WordPress and want event owners to sell tickets directly from their own event pages in a controlled way. The real strength of the product is not a single purchase button, but the full chain: the owner creates tickets, the buyer completes payment, the ticket is downloaded, the QR code is validated at entry, the organizer sees sales, and the administrator controls reports and commission.

Before going live, walk through the entire chain: dependencies, the Tickets menu, commission and payment settings, the Sell Tickets block, ticket creation, a test purchase, email, download, QR validation, the owner report, and the administrator report. If everything lines up, you can move on to real events. If not, fix the specific break in the chain rather than changing the entire stack.

Once you understand that the add-on matches your directory model and you are ready to test it on a sample event, you can download the GeoDirectory Events Tickets Marketplace archive and follow the launch checklist from this guide step by step.