GeoDirectory Events Tickets Marketplace - Плагин WordPress

Руководство по настройке и использованию GeoDirectory Events Tickets Marketplace

GeoDirectory Events Tickets Marketplace нужен не просто для добавления кнопки покупки билета. Это расширение связывает каталог событий GeoDirectory, форму оплаты GetPaid, управление остатками, кошелёк организатора, QR-проверку билета и отчёты по продажам в один рабочий сценарий. В этом руководстве разберём, как подготовить сайт, где искать настройки, как вывести кнопку продажи билетов на странице события, как проверить покупку и что делать, если владелец события, покупатель или администратор видят не тот результат.

Материал рассчитан на владельца WordPress-сайта, который уже понимает базовую идею каталога событий, но хочет превратить его в управляемую билетную площадку. Здесь не будет инструкций по покупке лицензии или обходу активации. Мы говорим о практическом запуске уже полученного расширения: установка, зависимости, настройки комиссии, выбор платёжной формы, размещение блока Sell Tickets, тестовая покупка, проверка QR-кода, отчёты и аккуратная диагностика.

Главная особенность GeoDirectory Events Tickets Marketplace - разделение ролей. Администратор сайта контролирует общую площадку, владелец события создаёт билеты в публичной части сайта, покупатель оплачивает выбранный тип билета, а проверяющий на входе может подтвердить статус билета и отметить его как использованный. Если эту цепочку настроить без проверки ролей, шаблонов и платёжной формы, сайт может выглядеть рабочим в админ-панели, но ломаться на реальном сценарии продажи.

Поэтому руководство построено не как рекламный обзор. Сначала идёт карта продукта и подготовка, затем подробная настройка, пример реального мероприятия, проверка результата, диагностика проблем, похожие решения и FAQ. В конце есть естественная ссылка на скачивание, чтобы перейти к файлу только после понимания, подходит ли расширение вашему сайту.

Что именно добавляет расширение к каталогу событий

GeoDirectory уже умеет строить каталог с типами записей, картами, страницами деталей, блоками, виджетами и шорткодами. Бесплатное расширение Events Calendar for GeoDirectory добавляет событийную механику: даты, расписания, повторяющиеся события, календарь и фильтры по времени. GeoDirectory Events Tickets Marketplace работает поверх этой базы и добавляет коммерческий слой: владелец события может создать типы билетов, посетитель может купить билет, система формирует подтверждение и билет, а владелец или администратор получает инструменты контроля.

Официальная документация описывает расширение как способ продавать билеты через сайт каталога и, если нужно, собирать комиссию с продаж. Это важный нюанс: продукт подходит не только владельцу одного мероприятия, но и площадке, где разные организаторы публикуют свои события. Сайт в таком сценарии становится не просто афишей, а маркетплейсом событий, где владелец площадки даёт инфраструктуру, а организаторы управляют своими билетами.

Чем билетный сценарий отличается от обычного события

Обычная страница события отвечает на вопросы "где", "когда" и "что будет". Билетная страница должна дополнительно отвечать на вопросы "какой билет выбрать", "сколько мест осталось", "как оплатить", "где скачать билет", "как пройти контроль" и "что делать организатору после продажи". Именно поэтому в настройке нельзя ограничиться установкой расширения. Нужно проверить цепочку от события до отчёта:

• Событие должно быть создано в правильном событийном типе записи GeoDirectory.
• Владелец события должен видеть кнопку Sell Tickets, а обычный посетитель не должен видеть её как инструмент управления.
• Покупатель должен видеть Buy Tickets, выбирать тип билета и проходить платёжную форму GetPaid.
• После оплаты покупатель должен получить доступ к билету, а владелец события - к управлению продажами и сканеру.
• Администратор должен видеть общие проданные билеты, отчёты и комиссии.

Если один из этих пунктов не проверен, ошибка может проявиться поздно. Например, организатор успешно создаст мероприятие, но не увидит кнопку создания билетов. Или покупатель оплатит заказ, но письмо с билетом попадёт в спам из-за почтовой конфигурации сервера. Руководство ниже идёт именно по этой цепочке, а не по абстрактному списку возможностей.

Кому подойдёт такой билетный маркетплейс, а кому лучше выбрать другой подход

GeoDirectory Events Tickets Marketplace хорошо подходит сайтам, где событие является частью каталога. Это может быть городская афиша, каталог клубов и площадок, сайт туристического региона, нишевый портал по мастер-классам, образовательная витрина, локальная база концертов или закрытая сеть организаторов. Сильная сторона расширения - связь билета с владельцем конкретной записи GeoDirectory и возможность показать инструменты управления прямо на странице события.

Если вам нужен один лендинг для одного мероприятия раз в год, продукт может оказаться избыточным. В таком случае проще использовать отдельный билетный плагин, форму оплаты или WooCommerce-продукт. Если же вы строите каталог, где события добавляют разные владельцы, ценность GeoDirectory Events Tickets Marketplace становится заметнее: каждый организатор работает со своим событием, а администратор площадки видит продажи и может заложить комиссию.

Хорошие сценарии применения

Расширение особенно уместно в сценариях, где нужно совместить поиск событий и продажу билетов:

• Городской каталог мероприятий с платными концертами, лекциями, выставками и экскурсиями.
• Портал местных организаторов, где владельцы событий сами создают билеты и смотрят продажи.
• Каталог курсов, мастер-классов и встреч, где у события может быть несколько типов билетов.
• Сайт площадки, которая хочет продавать билеты без отправки посетителя на стороннюю платформу.
• Мероприятия с повторяющимися датами, где покупателю важно выбрать конкретную дату посещения.

Когда продукт может не подойти

Не стоит ставить расширение только потому, что в названии есть слово "tickets". Оно завязано на GeoDirectory, Events Calendar for GeoDirectory и GetPaid. Если ваш сайт уже построен вокруг The Events Calendar, WooCommerce Tickets, Event Espresso или отдельной SaaS-платформы, переход потребует миграции логики событий, шаблонов и ролей. Если вам нужны сложные места в зале, интерактивная схема посадки, многоуровневая промо-автоматизация или глубокая интеграция с WooCommerce-складом, сначала сравните продукт с альтернативами в отдельном разделе ниже.

Практический критерий выбора простой: если событие должно быть полноценной записью каталога GeoDirectory, а организатор должен управлять билетами со своей страницы события, этот продукт стоит тестировать. Если билет - просто товар магазина или регистрационная форма без каталога, выбирайте более узкий инструмент.

Что проверить перед установкой

Перед установкой важно проверить не только версию WordPress и PHP, но и состав зависимостей. Официальная документация указывает, что расширение требует GeoDirectory, Events Calendar for GeoDirectory, GetPaid, GetPaid Item Inventory и GetPaid Wallet. Документация также отмечает, что если зависимости не найдены во время установки, расширение может установить их автоматически. На практике всё равно лучше понимать, зачем они нужны, потому что диагностика почти всегда начинается именно с зависимостей.

Платформа и зависимости

Базовая логика такая:

• GeoDirectory даёт каталог, типы записей, страницы деталей, блоки, виджеты и публичную подачу записей.
• Events Calendar for GeoDirectory добавляет событийные поля, расписания, повторяющиеся события и календарные представления.
• GetPaid отвечает за платёжные формы, инвойсы и оплату выбранных билетов.
• GetPaid Item Inventory нужен для контроля количества, чтобы не продавать больше билетов, чем доступно.
• GetPaid Wallet используется в сценарии распределения средств организаторам и вывода баланса.

В идеале сначала запускают GeoDirectory и Events, создают тестовое событие, проверяют публичную страницу, затем подключают билетный слой. Если поставить всё сразу на пустой сайт без событийной структуры, сложно понять, что именно не работает: сама страница события, шаблон деталей, блок продажи, платёжная форма или отчёт.

Роли пользователей и публикация событий

В билетном маркетплейсе пользовательская регистрация становится частью бизнес-логики. Владелец события должен иметь возможность войти на сайт и управлять своим событием. В документации GeoDirectory отдельно описана типичная проблема, когда пользователи не могут зарегистрироваться, и указывает на настройку WordPress Settings - General - Membership - Anyone can register. Включать её нужно осознанно: если вы разрешаете организаторам регистрацию, добавьте модерацию, антиспам и понятный процесс проверки новых событий.

Для публичного сайта лучше заранее определить правила:

• Кто может добавить событие: любой зарегистрированный пользователь, только проверенные организаторы или администратор.
• Публикуются ли новые события сразу или проходят модерацию.
• Кто отвечает за корректность цены, даты, количества мест и текста билета.
• Кто проверяет билеты на входе и как получает доступ к сканеру.
• Что происходит с деньгами организатора после продажи, если используется Wallet.

Платёжная и почтовая часть

GetPaid закрывает платёжную форму, но платёжная часть сайта всегда зависит от настроенных шлюзов, тестового режима и почты. Перед первым реальным мероприятием проверьте хотя бы один тестовый платёж, письмо покупателю, письмо владельцу события, страницу подтверждения, скачивание билета и отчёт. Если письма не доходят, документация GeoDirectory рекомендует начинать проверку с Email Log: сначала убедиться, что WordPress сформировал письмо, и только потом искать проблему у хостинга, доменной почты или почтового провайдера.

Безопасный порядок запуска: тестовое событие - тестовый билет с малой ценой или тестовым шлюзом - тестовая покупка - письмо - скачивание билета - сканирование - отчёт - только потом реальные продажи.

Установка и первичная проверка в WordPress

Официальная документация GeoDirectory описывает два пути установки расширений: автоматический через GeoDirectory - Extensions и ручной через загрузку ZIP в Plugins - Add New - Upload Plugin. В этом руководстве важнее не сам способ, а первичная проверка после активации. После установки GeoDirectory Events Tickets Marketplace должен добавить в админ-панель WordPress меню Tickets с подпунктами Sold Tickets, Reports и Settings.

Автоматическая установка

Если сайт подключён через AyeCode Connect, установка расширений обычно проходит из раздела GeoDirectory - Extensions. Документация уточняет, что платным расширениям нужна действующая лицензия, а на локальном сайте может потребоваться WP Easy Updates. В статье не рассматривается покупка или ввод лицензии, но для диагностики важно знать: если расширение не появляется в списке или не обновляется, проблема может быть не в Events Tickets Marketplace, а в соединении AyeCode Connect, защитном плагине, режиме обслуживания или ограничении REST API.

Ручная установка

Ручной путь обычный для WordPress: загрузить ZIP через Plugins - Add New, нажать Upload Plugin, выбрать архив, установить и активировать. После активации проверьте не только список плагинов. Перейдите в меню Tickets, убедитесь, что доступны Settings, Sold Tickets и Reports, затем откройте страницу любого события в публичной части под владельцем записи.

Проверка после активации

Первичная проверка должна отвечать на четыре вопроса:

1. Есть ли активные зависимости GeoDirectory, Events Calendar for GeoDirectory, GetPaid, Item Inventory и Wallet.
2. Создан ли событийный тип записи и есть ли хотя бы одно тестовое событие.
3. Появилось ли меню Tickets в админ-панели.
4. Можно ли вывести блок или шорткод продажи билетов на шаблоне страницы события.

Если меню появилось, но на странице события нет кнопки для владельца, не спешите переустанавливать расширение. Обычно нужно проверить шаблон деталей события и наличие блока Sell Tickets или шорткода [gd_sell_tickets primary_color="primary" secondary_color="secondary"]. Если блок вставлен, но не виден обычному посетителю, это может быть нормальным поведением: документация указывает, что кнопку Sell Tickets видит владелец события, а обычные посетители её не видят.

Настройки комиссии, формы оплаты и кошелька

Настройки GeoDirectory Events Tickets Marketplace находятся в Tickets - Settings. Официальная документация подчёркивает, что расширение поставляется с разумными настройками по умолчанию, но есть два параметра, которые обычно требуют внимания: процент комиссии площадки и способ оплаты. Именно эти два пункта определяют бизнес-логику площадки: берёте ли вы долю с продажи и как покупатель платит за билет.

Ticket Sales Commission %

Ticket Sales Commission % задаёт долю каждой продажи, которую получает администратор сайта. Для каталога событий это не просто финансовое поле. Комиссия влияет на ожидания организаторов, политику возвратов, отчёты и объяснение условий на странице добавления события. Если вы запускаете площадку с внешними организаторами, не скрывайте комиссию в глубине правил. Добавьте понятное описание в справочный раздел для организаторов: как считается комиссия, когда она удерживается, где организатор смотрит продажи и как выводит средства.

Для первого теста не обязательно сразу выбирать финальное значение. Лучше поставить безопасное тестовое значение, выполнить покупку, посмотреть отчёт администратора и отчёт владельца события, затем решить, насколько модель понятна. Если комиссия неожиданно не отражается в отчётах или организатор видит сумму не так, как ожидает, остановите реальные продажи до проверки платёжной формы и кошелька.

Payment Form: checkout или wallet

Второй важный параметр - Payment Form. Документация описывает два режима: Check Out и Wallet. В режиме Check Out покупатель оплачивает точную сумму выбранных билетов через доступный платёжный шлюз. В режиме Wallet пользователь пополняет баланс заранее, а при выборе билета сумма списывается из кошелька.

Для большинства новых сайтов логичнее начинать с Check Out. Он проще для покупателя: выбрал билет, заполнил форму, оплатил, скачал билет. Wallet имеет смысл, если на сайте уже есть повторяющиеся покупки, внутренний баланс, организаторы с регулярными выплатами или модель, где участники заранее пополняют счёт. Но такой режим сложнее объяснить пользователю, сложнее тестировать и важнее проверять на юридическом и бухгалтерском уровне.

Как проверить, что настройка оплаты сработала

После изменения платёжной формы сделайте тестовую покупку. Для Check Out ожидаемый результат - покупатель видит форму оплаты на выбранную сумму и после подтверждения получает страницу с возможностью скачать билеты. Для Wallet ожидаемый результат - пользователь может пополнить баланс, видеть его через блок, виджет или шорткод Wallet и оплатить билет списанием с баланса. Если меняете режим на рабочем сайте, сначала предупредите тестовых организаторов и проверьте уже созданные билеты.

Кошелёк и вывод средств владельцем события

Документация Events Tickets Marketplace указывает, что для распределения proceeds владельцам событий используется GetPaid Wallet, а администратору нужно разместить Wallet Block, Widget или Shortcode там, где пользователи смогут видеть баланс и выводить средства. На практике это может быть личный кабинет организатора, отдельная страница "Баланс" или вкладка в пользовательском меню.

Не размещайте блок кошелька в случайном месте только потому, что он нужен технически. Пользователь должен понимать, что он видит: доступный баланс, историю, кнопку вывода, ограничения и статус. В WordPress.org-описании GetPaid Wallet подтверждены функции пополнения, вывода, использования баланса на checkout и минимального баланса для вывода. Поэтому в реальном проекте отдельно проверьте настройки Wallet в GetPaid, а не только экран Tickets - Settings.

Как вывести кнопку продажи билетов на странице события

Самая продуктовая часть настройки - размещение Sell Tickets на странице деталей события. Документация говорит, что для владельца события нужно добавить блок или шорткод Sell Tickets в шаблон страницы события. Пример из документации - добавление блока в GD Sidebar, чтобы владелец события видел кнопку Sell Tickets. Также можно использовать шорткод [gd_sell_tickets primary_color="primary" secondary_color="secondary"] в подходящем месте шаблона.

Здесь легко ошибиться. Блок нужно добавлять не в случайную страницу, а в шаблон детали события, где открывается конкретная запись. Если вы используете блоковый редактор, виджеты GeoDirectory или конструктор страниц, сначала выясните, какой именно шаблон отвечает за карточку события. В GeoDirectory элементы могут выводиться как блоки, виджеты или шорткоды, а Shortcode Builder помогает собрать элемент там, где это поддерживается.

Где лучше размещать Sell Tickets

Оптимальное место зависит от дизайна страницы, но логика проста: владелец события должен быстро найти управление билетами, а покупатель должен видеть покупку только после создания билетов. Хорошие места:

• Боковая колонка события рядом с датой, адресом и контактами.
• Верхняя зона страницы под основной информацией о событии.
• Отдельная вкладка или блок в деталях события, если страница насыщена информацией.
• Шаблон для событийного CPT, а не глобальная страница всех записей каталога.

После добавления блока проверьте страницу под тремя ролями: администратор, владелец события, обычный посетитель. Владелец должен видеть Sell Tickets до создания билетов. После сохранения первого билета, согласно документации, кнопка продажи для этого события заменяется двумя кнопками: Buy Tickets, видимой всем, и Ticket Management, видимой только владельцу события.

Шорткод как запасной способ

Шорткод полезен, если шаблон собирается в месте, где блок неудобен или недоступен. Документация приводит такой пример:

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

Не вставляйте его в каждый текст события вручную. Лучше разместить шорткод на шаблоне деталей события, чтобы он автоматически работал для всех записей этого типа. Если шорткод вставлен в неправильную область, он может появиться там, где нет контекста текущего события, или не дать ожидаемой логики владельца.

Проверка видимости кнопок

После сохранения шаблона выполните короткий тест:

1. Откройте тестовое событие под владельцем записи.
2. Убедитесь, что видна кнопка Sell Tickets.
3. Создайте один тип билета и сохраните.
4. Откройте событие в приватном окне как обычный посетитель.
5. Убедитесь, что видна Buy Tickets, но не видна Ticket Management.
6. Вернитесь под владельцем события и проверьте, что доступно Ticket Management.

Если кнопки ведут себя иначе, сначала проверяйте владельца записи и шаблон детали события. Это быстрее, чем переустанавливать расширение или менять платёжные настройки.

Создание билетов владельцем события

GeoDirectory Events Tickets Marketplace переносит создание билетов в публичную часть сайта. Официальная документация прямо указывает, что сейчас билеты создаются с публичной стороны после нажатия Sell Tickets. Это важное отличие от многих билетных плагинов, где администратор создаёт билет в админ-панели как товар или регистрационный вариант.

Какие поля заполняет владелец

После нажатия Sell Tickets владелец события видит окно создания билетов. Документация перечисляет поля: Ticket Name, Ticket Price, Available Quantity, Selected by default, кнопку добавления дополнительных билетов и кнопку сохранения. Этого достаточно для типовых сценариев: обычный билет, льготный билет, VIP-билет, ранняя регистрация или несколько ценовых уровней.

При создании типов билетов лучше придерживаться понятной структуры. Не называйте билеты абстрактно "Ticket 1" и "Ticket 2". Покупатель должен быстро понять, что отличается: доступ, место, дата, формат участия, возрастная группа или пакет услуг. Если событие повторяющееся, отдельная логика выбора даты появится при покупке, но название типа билета всё равно должно быть ясным.

Количество и защита от перепродажи

Available Quantity отвечает за доступное количество. В составе зависимостей есть GetPaid Item Inventory, который по описанию WordPress.org позволяет задавать остатки для отдельных товаров, показывать низкий или нулевой остаток, отправлять уведомления и предотвращать превышение доступного количества, если back orders запрещены. Для билетов это критично: ошибка количества сразу превращается в проблему на входе.

Перед запуском реального события проверьте сценарий "почти распродано": поставьте небольшой лимит, купите несколько билетов, убедитесь, что система не позволяет купить больше доступного. Если у мероприятия физическая вместимость зала, не полагайтесь только на текст описания. Количество должно быть настроено в билетах.

Selected by default

Поле Selected by default удобно, когда есть основной тип билета, который покупатель выбирает чаще всего. Но его не стоит включать бездумно для дорогого или ограниченного билета. Если сайт продаёт несколько категорий, выберите по умолчанию самый массовый и нейтральный вариант. Для специальных пакетов лучше дать пользователю осознанный выбор.

Редактирование и управление после первой продажи

После создания первого билета у владельца события появляется Ticket Management. Документация описывает вкладки или разделы внутри управления: Types со списком билетов конкретного события, Sales со списком продаж, Report со статистикой и Scanner для проверки билета вручную или через QR-код. Для организатора это личный пульт события. Он должен быть понятен до дня мероприятия, а не только в момент, когда пришли первые посетители.

Совет для запуска: до публикации реального события создайте внутреннее тестовое мероприятие и дайте организатору пройти весь путь самостоятельно. Если он не понимает, где создать билет и где проверить продажу, добавьте короткую инструкцию на сайте.

Покупка билета и форма оплаты GetPaid

Когда владелец события создал хотя бы один билет, обычные посетители должны увидеть Buy Tickets. Нажатие открывает окно с формой покупки. Документация описывает, что пользователь может выбрать тип билета, задать количество, заполнить данные и оплатить доступным способом. В примере документации форма просит только email, но GetPaid checkout form builder позволяет запрашивать дополнительные данные во время оформления.

Какие данные запрашивать у покупателя

Минимальная форма проще продаёт, но не всегда закрывает организационную задачу. Для концерта может хватить email. Для мастер-класса может понадобиться имя. Для мероприятия с возрастным ограничением, списками групп или специальными требованиями могут понадобиться дополнительные поля. Главное правило: спрашивайте только те данные, которые реально нужны для проведения мероприятия и коммуникации с покупателем.

Если поле не нужно на входе, не добавляйте его ради привычки. Длинная форма снижает завершение покупки и увеличивает количество ошибок. Для тестового запуска оставьте минимальную форму, затем добавляйте поля по реальным потребностям организаторов.

Повторяющиеся события и выбор даты

Документация уточняет, что если билет относится к повторяющемуся событию, покупатель должен выбрать даты, для которых билет будет действителен. Это ключевая проверка для календарных площадок. Если у вас серия лекций, еженедельный тур или расписание тренировок, тестируйте не только один билет, но и покупку на конкретную дату. На входе проверяющий должен понимать, что билет действителен именно для нужной даты, а не просто для всей серии.

Подтверждение, инвойс и скачивание билета

После оплаты покупатель попадает на страницу подтверждения, где может увидеть инвойс, историю инвойсов и скачать билеты. Это место часто пропускают в тестировании, потому что администратор смотрит только платёжный статус. Для пользователя же важно другое: он должен быстро понять, где его билет и как сохранить его до мероприятия. Проверьте страницу подтверждения на мобильном устройстве, потому что многие покупатели будут открывать билет с телефона.

Скачанный билет в документации описан как HTML ticket с возможностью печати. QR-код делает билет удобным для проверки. Но не обещайте посетителю, что печать обязательна, если ваша команда принимает билет с экрана. Лучше написать в инструкциях к событию, какой формат допустим на входе.

Практический пример: локальная конференция с билетами разных типов

Теперь соберём реальный сценарий. Допустим, сайт GeoDirectory ведёт каталог городских IT-событий. Организатор публикует конференцию, хочет продать обычные билеты и ограниченное количество билетов с доступом к закрытой секции. Площадка удерживает комиссию, а организатор смотрит продажи и проверяет билеты на входе.

Цель

Нужно получить страницу события, где обычный посетитель видит Buy Tickets, выбирает один из двух типов билетов, оплачивает через GetPaid, скачивает билет с QR-кодом, а организатор видит продажи, отчёт и сканер для входа. Администратор сайта должен видеть общий список продаж и отчёт по комиссии.

Подготовка

Перед созданием билетов проверьте:

• GeoDirectory и Events Calendar for GeoDirectory активны.
• Создано тестовое событие с корректной датой, местом и владельцем записи.
• В шаблон детали события добавлен блок Sell Tickets или шорткод [gd_sell_tickets primary_color="primary" secondary_color="secondary"].
• В Tickets - Settings выбран режим оплаты Check Out для простого запуска.
• В GetPaid включён тестовый платёжный способ или безопасный тестовый режим.
• Почта WordPress проверяется через журнал писем или аналогичный инструмент.

Шаги

1. Зайдите под пользователем, который является владельцем тестового события.
2. Откройте публичную страницу события и нажмите Sell Tickets.
3. Создайте билет General Admission, задайте цену, количество и отметьте его как выбранный по умолчанию, если это основной билет.
4. Добавьте второй билет Workshop Access с меньшим количеством, если доступ ограничен.
5. Сохраните билеты и убедитесь, что на странице появились Buy Tickets и Ticket Management.
6. Откройте страницу как обычный посетитель, нажмите Buy Tickets, выберите тип билета и оформите тестовую оплату.
7. После оплаты скачайте билет и сохраните его как файл или PDF.
8. Вернитесь под владельцем события, откройте Ticket Management и проверьте Sales, Report и Scanner.
9. В админ-панели откройте Tickets - Sold Tickets и Reports, чтобы увидеть продажу на уровне всей площадки.

Проверка результата

Результат считается рабочим, когда совпадают три уровня. У покупателя есть билет и понятная страница подтверждения. У владельца события есть продажа в Ticket Management, а сканер показывает корректный статус билета. У администратора есть запись в Sold Tickets и данные в Reports. Если один уровень пустой, не запускайте реальные продажи, пока не найдёте разрыв.

Нюанс, который часто пропускают

Тест нужно выполнять пользователями разных ролей. Администратор может видеть больше, чем обычный организатор. Если всё проверял только администратор, вы можете не заметить, что владелец события не видит Ticket Management, а покупатель видит не ту кнопку. Минимальный набор аккаунтов для теста: администратор, владелец события и обычный посетитель.

QR-проверка, статусы билетов и контроль входа

Проверка билетов - отдельная часть продукта, а не декоративная функция. Документация описывает, что владелец события может использовать сканер для проверки билета по номеру или QR-коду. Билет может получить несколько статусов: не действителен для этого события, действителен для будущей даты, действителен на сегодня, уже использован или просрочен. Когда билет действителен, появляется кнопка redeem, после которой билет можно отметить как использованный.

Эта логика защищает от двух типичных проблем: прохода по билету на неправильное событие и повторного использования уже применённого билета. Для мероприятия с одной дверью этого может быть достаточно. Для нескольких входов важно заранее решить, кто сканирует билеты и как устройства получают доступ к странице управления.

Как готовить команду входа

Не оставляйте проверку на последний час. Сделайте репетицию:

• Создайте один действительный тестовый билет.
• Создайте билет на другую дату или событие, чтобы увидеть предупреждение.
• Отметьте один билет как использованный и попробуйте проверить его повторно.
• Проверьте сканер с устройства, которое реально будет на входе.
• Подготовьте ручной поиск по номеру на случай, если камера или освещение мешают QR-коду.

Что делать с повторяющимися событиями

Для повторяющихся событий статус по дате особенно важен. Билет может быть куплен для будущей даты и не должен проходить как действительный на текущий вход. Документация прямо выделяет статус "valid for future date". Поэтому для повторяющихся мероприятий обязательно тестируйте не только покупку, но и проверку на разных датах. Если организатор не понимает, какую дату проверяет, ошибки на входе неизбежны.

Когда redeem нажимать нельзя

Кнопку redeem стоит нажимать только после фактического допуска посетителя. Если проверяющий нажмёт её во время предварительной проверки в переписке или на стойке информации, билет может стать использованным до входа. Внутренняя инструкция для команды должна быть короткой: сканировать, сверить статус, допустить посетителя, затем отметить билет использованным. Если статус красный или жёлтый, не нажимать redeem, а передать вопрос ответственному.

Отчёты владельца события и администратора площадки

В GeoDirectory Events Tickets Marketplace есть два уровня отчётности. Владелец события видит данные по конкретному событию через Ticket Management: типы билетов, продажи, простой отчёт и сканер. Администратор сайта видит общие страницы Sold Tickets и Reports в меню Tickets. Это разделение нужно не только для удобства, но и для доверия между площадкой и организаторами.

Что должен видеть владелец события

Организатору обычно нужны три вещи: сколько билетов продано, какие типы билетов покупают и можно ли проверить каждого посетителя. Не перегружайте его админскими данными, если он не администратор площадки. Его рабочая зона - конкретное событие. Если он не может найти продажи, добавьте ссылку на страницу события в личном кабинете или короткую инструкцию после публикации мероприятия.

Что контролирует администратор

Администратор смотрит шире: все проданные билеты, общую динамику, комиссии, потенциальные спорные операции и работу платёжной цепочки. Если сайт работает как маркетплейс, администратору нужно регулярно сверять отчёты GetPaid, отчёты Tickets, Wallet и реальные платёжные поступления. Не считайте внутренний отчёт бухгалтерским документом без проверки требований вашей юрисдикции и платёжного провайдера.

Как использовать отчёты для улучшения площадки

Отчёты полезны не только после события. По ним можно понять, какие типы билетов продаются быстрее, какие организаторы создают понятные карточки, где покупатели бросают процесс, какие даты повторяющихся мероприятий популярнее. Если продажи идут слабо, не меняйте сразу комиссию. Сначала проверьте страницу события, понятность названий билетов, форму оплаты, количество полей и доверие к сайту.

Кастомизация билетов, писем и безопасные улучшения

Документация GeoDirectory Events Tickets Marketplace указывает, что у расширения есть два email-шаблона и два шаблона билета. Для писем это wpinv-email-user_tickets.php и wpinv-email-tickets_sold.php. Для билетов это ticket.php и base.php. Официальный способ кастомизации - копировать файлы из папки расширения в дочернюю тему по указанным путям, а не править файлы плагина напрямую.

Что можно менять в шаблонах

Шаблоны стоит менять только там, где это даёт реальную пользу: добавить понятную инструкцию для входа, уточнить контакт организатора, сделать текст письма менее сухим, поправить брендирование билета, добавить условия посещения или объяснить, можно ли показывать билет с телефона. Не меняйте технические части QR-кода, номера билета и статуса без понимания шаблона.

Безопасный подход такой:

1. Скопируйте шаблон в дочернюю тему по официальному пути.
2. Сделайте одну маленькую правку текста или разметки.
3. Купите тестовый билет.
4. Проверьте письмо, скачивание билета, печать и QR-проверку.
5. Если что-то сломалось, удалите переопределённый файл из дочерней темы и вернитесь к шаблону расширения.

CSS без вмешательства в логику checkout

Документация GeoDirectory по CSS-кастомизациям рекомендует добавлять стили через Appearance - Customize - Custom CSS, файл style.css дочерней темы или отдельный плагин для пользовательского CSS. Для билетного сценария уместны только маленькие визуальные правки: отступы, заметность кнопки, читаемость блока в боковой колонке. Не скрывайте поля формы оплаты и не меняйте поведение checkout через CSS.

/* Умеренно выделяет блок продажи билетов на странице события.
   Добавляйте в Custom CSS или style.css дочерней темы и проверяйте на мобильном. */
.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;
}

Этот пример осторожный: он не вмешивается в оплату и не скрывает поля. Но селекторы могут отличаться в вашей теме или версии разметки, поэтому проверяйте через инструменты браузера. Если стиль не применяется, не добавляйте всё подряд с !important. Лучше найти точный контейнер блока в вашем шаблоне.

Проверка после кастомизации

Любая правка шаблона или CSS должна проходить один и тот же тест: страница события под владельцем, страница под посетителем, покупка, письмо, скачивание билета, печать или PDF, QR-проверка, отчёт. Если изменяли только внешний вид, тест всё равно нужен, потому что CSS может перекрыть модальное окно, кнопку или область сканера.

Частые проблемы и диагностика

Проблемы с билетной площадкой редко имеют одну причину. GeoDirectory Events Tickets Marketplace находится на стыке каталога, события, роли пользователя, шаблона, оплаты, почты и отчётов. Поэтому диагностику лучше вести по симптомам, а не менять настройки наугад.

Владелец события не видит Sell Tickets

Симптом: событие открывается, но кнопки Sell Tickets нет. Обычный посетитель тоже ничего не видит.

Возможные причины: блок или шорткод не добавлен в шаблон деталей события, открыт не тот CPT, пользователь не является владельцем записи, зависимости не активны или шаблон конструктора выводит другую область.

Что проверить: наличие меню Tickets, активность Events Calendar for GeoDirectory, страницу конкретного события под владельцем записи, шаблон детали события, наличие Sell Tickets блока или шорткода.

Как исправить: добавьте блок в шаблон детали события или вставьте шорткод [gd_sell_tickets primary_color="primary" secondary_color="secondary"] в правильную область. Затем проверьте под владельцем и обычным посетителем. Если владелец записи назначен неверно, смените owner события через инструменты GeoDirectory или WordPress.

Buy Tickets не появляется после создания билета

Симптом: владелец создал билет, но посетитель не видит кнопку покупки или видит старое состояние.

Возможные причины: билет не сохранён, остаток равен нулю, кэш отдаёт старую страницу, пользователь смотрит не то событие, шаблон скрывает блок, есть конфликт модального окна с темой.

Что проверить: откройте событие в приватном окне, временно очистите кэш страницы, проверьте Ticket Management под владельцем, убедитесь, что создан хотя бы один доступный тип билета.

Как исправить: пересохраните билет, очистите кэш, проверьте разметку шаблона. Документация GeoDirectory сообщает, что v2 проектировался с учётом кэширования, но при интерактивных сценариях всё равно полезно исключать страницы checkout, личного кабинета и динамические билетные области из агрессивной оптимизации, если конкретный кэш-плагин ломает модальные окна.

После изменения настроек появились 404

Симптом: страницы событий, билетов или связанных областей возвращают 404 Page Not Found.

Возможная причина: WordPress или GeoDirectory не обновили правила постоянных ссылок после изменения структуры.

Что проверить: откройте Settings - Permalinks и пересохраните настройки. Если не помогло, документация рекомендует временно сохранить GeoDirectory permalinks в другое значение, затем вернуть предпочтительное.

Когда откатить: если 404 появились после изменения slug, CPT или шаблона, верните прежнюю структуру и проверяйте изменения на тестовом сайте.

Покупатель не получает письмо с билетом

Симптом: оплата прошла, билет доступен на странице подтверждения, но письмо не пришло.

Возможные причины: письмо не сформировано, сервер не отправляет почту, домен не настроил SPF/DKIM/DMARC, письмо отклонено провайдером или текст выглядит подозрительно для фильтра.

Что проверить: установите Email Log или аналогичный журнал и посмотрите, сформировал ли WordPress письмо. Если письмо сформировано, проблема чаще находится за пределами WordPress: SMTP, хостинг, доменные записи или почтовый провайдер.

Как исправить: настройте SMTP-отправку с доменного адреса, проверьте записи домена, уменьшите подозрительные формулировки в письме и повторите тестовую покупку.

QR-сканер показывает неожиданный статус

Симптом: билет сканируется, но статус красный или жёлтый, хотя покупатель уверен, что билет правильный.

Возможные причины: билет относится к другому событию, другой дате повторяющегося события, уже использован, просрочен или был проверен не тем владельцем.

Что проверить: событие, дату, номер билета, историю использования, статус оплаты и роль пользователя, который сканирует.

Как исправить: не нажимайте redeem при спорном статусе. Сначала найдите продажу в Ticket Management или Sold Tickets, сверяйте дату и событие. Если билет действительно не для этого события, не допускайте посетителя по нему без ручного решения администратора.

Организатор не видит баланс или вывод средств

Симптом: продажи есть, но организатор не понимает, где баланс или как вывести средства.

Возможные причины: не размещён Wallet Block/Widget/Shortcode, GetPaid Wallet не активен, настройки Wallet не заполнены, пользователь смотрит не тот кабинет или вывод отключён политикой сайта.

Что проверить: активность GetPaid Wallet, страницу с блоком кошелька, настройки GetPaid - Settings - Wallet, минимальный баланс вывода и права пользователя.

Как исправить: создайте отдельную страницу баланса для организаторов, разместите Wallet Block/Widget/Shortcode и добавьте короткую инструкцию. Если вывод средств требует ручной проверки, так и напишите в правилах площадки.

Блок в редакторе показывает ошибку invalid content

Симптом: в редакторе WordPress блок GeoDirectory показывает сообщение This block contains unexpected or invalid content.

Возможная причина: блоковая разметка изменилась или редактор не может сопоставить сохранённый блок с текущей версией.

Что проверить и как исправить: документация GeoDirectory рекомендует открыть меню блока с тремя точками и нажать Attempt Block Recovery. После восстановления сохраните шаблон и проверьте публичную страницу события.

Совместимость с темой, конструкторами, кэшем и SEO

GeoDirectory поддерживает блоки, шорткоды и виджеты, а основное ядро заявляет совместимость с популярными конструкторами страниц. Но билетный сценарий добавляет модальные окна, checkout, динамические кнопки и сканер. Это значит, что совместимость нужно проверять не по главной странице, а по конкретным действиям: открыть событие, создать билет, купить, скачать, отсканировать, увидеть отчёт.

Тема и шаблон события

Тема должна корректно выводить шаблон деталей GeoDirectory. Если страница события собрана через конструктор, проверьте, что блок продажи билетов находится в контексте текущей записи. Иногда красивый шаблон работает как витрина, но не передаёт нужный контекст для динамического блока. В таком случае шорткод в правильной области может быть надёжнее, чем визуальный блок в произвольной секции.

Кэш и динамические области

Документация GeoDirectory сообщает о совместимости v2 с разными решениями кэширования, включая page cache, browser cache, server-side cache и object cache. Но билетный checkout и пользовательские состояния всегда требуют осторожности. Не кэшируйте страницы, где пользователь видит личный баланс, checkout, подтверждение оплаты или управление билетами. Если кнопки исчезают или модальные окна открываются со старым состоянием, временно отключите оптимизацию JavaScript и page cache для этих URL и повторите тест.

SEO для событий с билетами

Расширение не заменяет нормальную структуру событийной страницы. Для поисковой выдачи важны уникальное описание события, дата, место, категория, понятный заголовок, корректные URL и не перегруженный шаблон. Билетный блок должен помогать конверсии, а не закрывать основной контент. Сначала дайте посетителю понять событие, затем предложите купить билет. Если кнопка покупки стоит выше даты, места и программы, это может ухудшить доверие.

Для каталога мероприятий полезно вести внутреннюю перелинковку: город - категория - конкретное событие - похожие события. Но не вставляйте название GeoDirectory Events Tickets Marketplace в каждый заголовок или анкор. Пользователь ищет событие и билет, а не название внутреннего расширения.

Когда GeoDirectory Events Tickets Marketplace будет удачным выбором

GeoDirectory Events Tickets Marketplace стоит использовать, если вы строите каталог событий на WordPress и хотите дать владельцам событий управляемую продажу билетов прямо на своих страницах. Сильная сторона продукта - не в одной кнопке покупки, а в полной цепочке: владелец создаёт билеты, покупатель оформляет оплату, билет скачивается, QR-код проверяется на входе, организатор видит продажи, а администратор контролирует отчёты и комиссию.

Перед рабочим запуском пройдите цепочку полностью: зависимости, меню Tickets, настройки комиссии и оплаты, блок Sell Tickets, создание билетов, тестовая покупка, письмо, скачивание, QR-проверка, отчёт владельца и отчёт администратора. Если всё совпадает, можно переходить к реальным событиям. Если нет, исправляйте конкретный разрыв, а не меняйте весь стек.

Когда вы уже понимаете, что расширение подходит вашей модели каталога и готовы проверить его на тестовом событии, можно загрузить архив с GeoDirectory Events Tickets Marketplace и запускать проверку по шагам из этого руководства.