JetBooking - Плагин WordPress

Руководство по настройке JetBooking для сайта бронирования на WordPress

JetBooking нужен не просто для вывода календаря на странице. В реальном проекте вокруг него приходится собрать структуру объектов, правила доступности, форму или WooCommerce-товар, расчёт стоимости, статусы заявок, уведомления и проверку результата в публичной части сайта.

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

Материал не заменяет официальную документацию Crocoblock, но помогает связать отдельные инструкции в рабочий сценарий. Особенно полезны разделы про различие Plain mode и WooCommerce-based mode, логику календаря доступности, сезонные цены, единицы размещения, уведомления и диагностику пересечений дат.

Какую задачу закрывает плагин и где он особенно полезен

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

Главная особенность продукта - он не живёт изолированно. В большинстве сценариев JetBooking работает вместе с другими инструментами Crocoblock и WordPress: JetEngine помогает создать пользовательские типы записей и динамические шаблоны, JetFormBuilder используется для формы в Plain mode, WooCommerce подключается для оформления заказа и оплаты, JetThemeCore или редактор блоков помогают собрать шаблон отдельной страницы. Поэтому настройка плагина всегда начинается не с красивого календаря, а с вопроса: где будут храниться объекты бронирования, как пользователь отправит заявку и где администратор будет управлять заказами.

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

Сценарии, где JetBooking выглядит логично

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

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

Когда лучше выбрать другое решение

Если бизнес работает с короткими приёмами по времени, сотрудниками, кабинетами, услугами и повторяющимися встречами, чаще уместнее смотреть в сторону appointment-плагинов. JetBooking умеет работать с Timepicker и буфером времени, но его базовая модель всё равно ближе к объектам, датам, периодам размещения и аренде. Если нужен только календарь доступности без заказов, формы и сложной цены, отдельный простой календарный плагин будет легче в поддержке.

Ещё один важный момент - экосистема Crocoblock. Если сайт уже собран на Elementor, Gutenberg или Bricks и использует JetEngine, JetFormBuilder, JetSmartFilters или JetWooBuilder, JetBooking проще встроить в существующую структуру. Если проект построен на другой логике и команда не хочет добавлять дополнительные плагины, перед установкой стоит оценить трудозатраты на интеграцию.

Подготовка перед установкой: структура данных важнее кнопки Activate

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

Для Plain mode подготовьте пользовательский тип записи для объектов бронирования и отдельный тип записи или таблицу для заказов, если мастер не будет создавать их автоматически. Официальные инструкции Crocoblock показывают сценарий с CPT, JetFormBuilder и пост-сабмит действиями. В этом режиме пользователь отправляет форму, а JetBooking сохраняет данные бронирования и блокирует даты для выбранного объекта.

Для WooCommerce-based mode подготовка другая. Вам нужен установленный WooCommerce, а объекты бронирования будут создаваться как товары. После выбора product data JetBooking у товара появляются настройки, связанные с датами, гостями, единицами, ценами и дополнительными услугами. Этот режим стоит выбирать, если checkout, статусы заказов, оплата и письма WooCommerce являются частью вашего процесса.

Мини-чеклист перед первым запуском

• Проверьте, какой редактор используется для шаблонов объекта: Elementor, Gutenberg или Bricks.
• Решите, нужен ли WooCommerce checkout или достаточно формы бронирования.
• Подготовьте минимум один тестовый объект: номер, апартамент, автомобиль или другой ресурс.
• Продумайте поля заявки: имя, email, даты, количество гостей, дополнительные услуги, итоговая стоимость.
• Определите, кто будет менять статусы бронирований и смотреть календарь занятости.
• Сделайте резервную копию сайта перед настройками, которые меняют таблицы бронирований или структуру данных.

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

Что может помешать уже на старте

Самая частая ошибка подготовки - смешать режимы. Например, владелец сайта хочет WooCommerce checkout, но начинает строить форму так, будто работает в Plain mode без интеграции. Или наоборот: включает WooCommerce-based mode, а затем ищет в форме блок Check-in/Check-out, который в этом режиме уже не используется так же, как в Plain mode. В официальной документации подчёркивается, что в WooCommerce-based mode данные берутся из WooCommerce product fields, а даты добавляются к форме товара.

Вторая ошибка - пропустить email в Plain mode, а потом пытаться настроить автоматические уведомления клиенту. Если в форме нет email-поля или оно неправильно связано с данными бронирования, уведомление не сможет отправиться конкретному пользователю. Это лучше исправить до запуска рекламы и реальных заявок.

Установка и мастер настройки: что выбрать в первых шагах

После установки и активации плагина основной путь начинается в админ-панели WordPress: Bookings -> Set Up. Мастер помогает пройти базовые шаги и выбрать модель работы. Его задача - не "сделать весь сайт бронирования", а создать каркас: режим, объект бронирования, тип хранения заказов, дополнительные колонки и, если нужно, форму.

На первом шаге мастер предлагает выбрать режим. Plain mode подходит, если вы строите бронирование вокруг пользовательских типов записей и формы. В этом случае можно создать или выбрать post type для объектов, настроить order post type, добавить обязательные колонки и сгенерировать форму через JetFormBuilder. Этот режим гибче для динамических каталогов и кастомных форм, но требует аккуратной настройки полей и действий формы.

WooCommerce-based mode доступен, когда установлен WooCommerce. В этом режиме бронирование строится вокруг товаров, а заказ проходит через WooCommerce. Официальная документация подчёркивает, что в таком сценарии не нужно создавать отдельную форму JetBooking: поля дат добавляются в форму покупки товара, а бронирования затем видны в разделе Bookings.

Разница между Plain mode, WooCommerce integration и WooCommerce-based mode

Здесь легко запутаться, потому что в Plain mode тоже можно включить базовую интеграцию с WooCommerce. Разница такая: Plain mode с WooCommerce integration использует форму бронирования и может сохранять связанный заказ WooCommerce, но сам объект не становится полноценным WooCommerce booking product. WooCommerce-based mode делает весь процесс частью WooCommerce-товара: цена, гости, единицы и дополнительные услуги настраиваются в данных товара.

Как безопасно завершить мастер

Во время мастера не добавляйте случайные колонки "на всякий случай". Официальная документация предупреждает, что значения дополнительных колонок должны использовать латинские строчные символы и подчёркивания. Лучше заранее составить список: guest_count, extra_services, customer_phone, total. Если структура ещё не ясна, создайте минимальный набор, проверьте процесс, затем расширяйте аккуратно.

После завершения мастера перейдите в Bookings -> Settings и проверьте, что выбранный режим, post types, WooCommerce integration и параметры полей соответствуют вашему сценарию. Если вы на тестовом сайте и понимаете, что режим выбран неправильно, можно вернуться к Set Up и использовать сброс, но на рабочем сайте такие действия должны выполняться только после резервной копии и понимания, какие данные уже сохранены.

Ключевые настройки после установки: календарь, период, статусы и таблицы

После мастера начинается настоящая настройка. Раздел Bookings -> Settings содержит вкладки General, Labels, Field Settings, Advanced, Configuration, Schedule, Workflows и Tools. Набор вкладок и часть полей зависят от выбранного режима. Не пытайтесь включить всё подряд: каждая настройка должна отвечать на конкретный вопрос проекта.

General: режим, post types и хранение фильтров

Во вкладке General проверьте режим бронирования и связанные типы записей. В Plain mode важны Booking orders post type и Booking instance post type. Первый отвечает за записи заказов, второй - за объекты, которые пользователь бронирует. Если включена WooCommerce integration, появляется возможность связать процесс с заказами WooCommerce и включить двухстороннюю синхронизацию статусов.

В WooCommerce-based mode во вкладке General появляется Booking hold time. Этот параметр определяет, как долго выбранный диапазон дат резервируется после добавления товара в корзину. Если время слишком большое, посетители могут временно блокировать даты и не оплачивать заказ. Если слишком маленькое, добросовестный пользователь может потерять выбранные даты до завершения checkout. Для начала выбирайте умеренное значение и проверяйте его на тестовом заказе.

Configuration: день, ночь, минимальный срок и вид календаря

Вкладка Configuration управляет тем, как пользователь выбирает период. Самый важный выбор - Booking period: считать по ночам, когда последний день не включается в стоимость, или по дням, когда последний день включён. Для гостиниц и апартаментов обычно логичнее период "за ночь". Для аренды оборудования на календарный день может подойти расчёт "за день".

Здесь же задаются Starting day offset, Min/Max days, End date, переключатели Clear button, Month select, Year select и Show price in calendar. Последняя настройка полезна, если цена зависит от выходных или сезона: пользователь сразу видит, почему разные даты стоят по-разному.

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

Schedule: дни недели, выходные, Timepicker и буфер

Вкладка Schedule нужна, когда не все дни доступны одинаково. Здесь можно задать правила для дней недели, дни недоступности, Timepicker, временные интервалы и буфер между бронированиями. Буфер полезен, если между выездом и следующим заездом нужна уборка, подготовка автомобиля или техническая пауза.

Timepicker не стоит включать только ради визуального усложнения формы. Если бизнес работает посуточно, время заезда и выезда часто проще описать в тексте или письме. Если же объект действительно бронируется с точностью до времени, настройте Time range, Time Slot Interval и ограничения, а затем проверьте, что занятые слоты блокируются ожидаемо.

Advanced: iCal, автосмена статусов и защита от случайных изменений

Во вкладке Advanced находятся настройки, которые сильнее всего влияют на поддержку сайта. Enable iCal synchronization включает вкладку календарей и помогает синхронизировать бронирования с внешними календарями. Automatically switch bookings statuses позволяет менять зависшие статусы после выбранного интервала. Automatically remove temporary bookings помогает очищать временные записи. Hide DB columns manager снижает риск случайного удаления или изменения колонок в Tools.

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

Tools: дополнительные колонки и осторожность с данными

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

Хорошая практика - разделять поля, которые нужны для расчёта и логики, и поля, которые нужны только для удобства администратора. Например, total и guest_count могут участвовать в письмах и отчётах, а внутренний комментарий менеджера лучше хранить в месте, которое не ломает процесс бронирования при изменении.

Формы, календарь доступности и страница объекта

В Plain mode пользовательский путь обычно выглядит так: посетитель открывает страницу объекта, видит календарь доступности, выбирает даты, форма подставляет выбранный диапазон, пользователь заполняет данные и отправляет заявку. Чтобы это работало, нужно связать форму, объект и календарь. Здесь особенно важны JetFormBuilder, скрытые поля, поле Check-in/Check-out и post submit action, который создаёт бронирование.

Официальная документация показывает форму с текстовыми полями, email, количеством гостей, дополнительными услугами, calculated field и действием Apartment Booking. Для руководства по JetBooking важно понять не только список блоков, но и логику данных: форма должна знать, какой объект бронируется, какой диапазон дат выбран, какую цену нужно передать и куда сохранить результат.

Календарь доступности в Elementor, Gutenberg и Bricks

Booking Availability Calendar доступен как виджет, блок или элемент в зависимости от редактора. Он может быть размещён на кастомной single-странице объекта в Elementor, Block Editor или Bricks. У него есть ключевая настройка Allow to select dates. Если она выключена, пользователь всё равно видит календарь, но выбранные даты не подставляются в форму. Если включена, выбор дат синхронизируется с полями check-in и check-out.

Вторая полезная настройка - Scroll to the form. Она автоматически прокручивает страницу к форме после выбора дат. На длинных страницах объекта это улучшает путь пользователя: человек видит доступность в верхней части карточки, кликает даты и сразу попадает к форме отправки заявки.

Почему дата может не попасть в форму

Если календарь отображается, но форма не получает даты, проверьте три вещи. Во-первых, календарь должен быть на странице того же объекта, с которым связана форма. Во-вторых, в форме должен быть корректный Check-in/Check-out dates field. В-третьих, для календаря должна быть включена настройка Allow to select dates. В Gutenberg сценарий похожий: добавьте JetForm block, выберите нужную форму, затем добавьте Booking Availability Calendar block и проверьте результат в публичной части.

Не называйте такой сбой "ошибкой плагина", пока не проверите связку источника данных. В динамических шаблонах часто проблема не в JetBooking, а в том, что single template не получает правильный post type или форма вставлена без нужного скрытого поля объекта.

Цена, сезоны, гости и дополнительные услуги

Цена в JetBooking складывается из нескольких уровней. Самый простой вариант - указать цену за день или ночь в настройках объекта. Более гибкий вариант - добавить rates по длительности, weekend pricing для отдельных дней недели, seasonal prices для конкретных периодов, а также дополнительные услуги и гостей. На практике именно эта часть чаще всего требует тестов, потому что пользователь видит одну цифру, администратор ожидает другую, а причина может быть в формуле, метаполе, сезоне или периоде расчёта.

В Plain mode с JetFormBuilder итоговая стоимость обычно выводится через calculated field. Документация показывает макрос %ADVANCED_PRICE::check_in_check_out_dates% и более сложные формулы, где учитываются даты, цена объекта, дополнительные услуги и количество гостей. Если поле цены объекта пустое или формула ссылается на неправильное имя поля, расчёт может дать ноль или некорректную сумму.

Weekend pricing и seasonal prices

Weekend pricing позволяет назначить отдельную цену для выбранных дней недели. Это не обязательно только суббота и воскресенье: для конкретного бизнеса "выходной" может означать любой день с другим тарифом. Seasonal prices нужны для периодов высокого и низкого спроса. Например, цена на новогодние даты, летний сезон или праздничные выходные может отличаться от обычной.

Чтобы пользователь видел разницу до отправки формы, включите Show price in calendar, если это подходит вашему интерфейсу. Но не перегружайте календарь, если цена зависит от множества условий. Иногда лучше показать базовый диапазон цены в карточке объекта, а точную итоговую сумму вывести в calculated field после выбора дат и услуг.

Гости и услуги в WooCommerce-based mode

В WooCommerce-based mode часть логики переносится в WooCommerce attributes и product data. Документация Crocoblock показывает тип атрибута Booking Service, термины услуг, поля Service Cost, Cost Format, переключатели Multiply cost by guests count и Everyday service?. Это удобно, когда у объекта есть завтраки, трансфер, наборы услуг, количество гостей и выбор единицы.

Обратите внимание на тонкость с единицами: если включить Unit Selection и одновременно разрешить пользователю выбирать количество units, фронтенд может вести себя не так, как ожидает владелец сайта. В документации указано, что одновременное включение обоих controls отключает возможность выбора конкретных units на публичной части. Поэтому сначала решите, пользователь выбирает конкретный номер/единицу или только количество доступных единиц.

Как проверять расчёт без гадания

1. Создайте один тестовый объект с понятной базовой ценой.
2. Выберите короткий период без выходных и сезона, чтобы проверить базовую формулу.
3. Добавьте weekend pricing и проверьте тот же объект на датах с другим днём недели.
4. Добавьте seasonal prices и проверьте, что сезонный период имеет приоритет там, где ожидается.
5. Включите дополнительную услугу и количество гостей, затем сравните итоговую сумму в форме и заказе.
6. Проверьте запись в Bookings и, если используется WooCommerce, связанный заказ.

Мини-итог: если расчёт цены стал сложным, не пытайтесь проверять его на реальном каталоге. Один тестовый объект с простыми числами быстрее покажет, где ошибка: в цене объекта, формуле, услуге, гостях, режиме периода или WooCommerce order data.

Units manager и защита от пересечений дат

Units manager нужен, когда один объект в каталоге представляет несколько физических единиц. Например, "Стандартный номер" может означать десять номеров одного типа, а "Семейный апартамент" - три одинаковых юнита. Без units каждый объект обычно бронируется как единая сущность: если выбран период, он занят. С units JetBooking может назначать бронирование на первую доступную единицу или позволять пользователю выбрать конкретную единицу, если такой сценарий настроен.

В Plain mode units добавляются в CPT posts. В WooCommerce-based mode они настраиваются внутри товара с product data JetBooking. В обоих случаях цель одна: не дать двум клиентам забронировать одну и ту же физическую единицу на один и тот же период. Администратор может видеть unit в данных бронирования и менять его при редактировании, если это допустимо для процесса.

Как JetBooking предотвращает наложение бронирований

В JetBooking dashboard при создании или редактировании бронирования даты уже занятых периодов исключаются из выбора. Если администратор пытается вручную ввести занятый диапазон при редактировании, система не сохраняет изменение и показывает сообщение о недоступных датах и пересечении. Это важная защита, но она работает только при корректной связи объекта, unit и дат.

Проверяйте пересечения не только на публичной форме, но и в админ-панели. Создайте тестовое бронирование, затем попробуйте забронировать тот же объект на тот же период с публичной страницы и вручную через Bookings -> Add New. Если в одном месте дата блокируется, а в другом нет, ищите проблему в режиме, связи объекта, units или тестовых данных.

Когда units усложняют поддержку

Units не стоит включать, если у каждого объекта на сайте реально один экземпляр. Лишняя детализация усложнит редактирование, фильтрацию, объяснение для менеджеров и тестирование. Она нужна там, где бизнесу важно продавать одинаковые единицы одного типа или показывать доступность не только объекта, но и конкретного ресурса.

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

Автоматические уведомления, Webhook и iCal-синхронизация

После того как форма и календарь работают, следующий уровень - автоматизация. JetBooking Workflows позволяют отправлять письма после создания бронирования или изменения статуса. В той же логике можно настроить напоминание перед заездом, письмо после выезда или Webhook для передачи события во внешний сервис. iCal-синхронизация помогает связать сайт с Google Calendar и другими календарными системами.

Начинайте с простого подтверждения бронирования. Включите Enable Workflows во вкладке Workflows, создайте workflow item с событием Booking Created, добавьте action Send Email, укажите получателя и тему. Для динамических данных используйте макросы JetBooking, например данные бронирования, ID, даты, имя клиента, unit title или дополнительные колонки. Важно: если глобальный переключатель Enable Workflows выключен, отдельные items не сработают, даже если они заполнены правильно.

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

• В Plain mode в форме есть email-поле, и оно сохраняется в данных бронирования.
• В workflow выбран правильный event: Booking Created или Booking Status Changed.
• Для запланированного письма выбран корректный date type: Check in или Check out.
• Статус бронирования меняется достаточно заранее, если письмо должно уйти до даты заезда.
• Адрес отправителя относится к домену сайта или правильно настроен через почтовую доставку WordPress.

Для писем с напоминанием не делайте первый тест на дате, которая уже наступает через несколько минут. Официальная инструкция предупреждает, что если напоминание должно уйти за день до check-in, статус нужно изменить минимум за соответствующий период до даты. Иначе задача просто не попадёт в нужное окно времени.

iCal и внешние календари

iCal-синхронизация нужна, если бронирования должны попадать во внешний календарь или наоборот. Включается она во вкладке Advanced через Enable iCal synchronization. После этого появляется вкладка Calendars, где можно настроить шаблон iCalendar, макросы, экспорт и импорт. Для двухсторонней синхронизации Crocoblock описывает отдельный сценарий с двумя календарями: один передаёт бронирования с сайта во внешний календарь, другой забирает внешние события обратно.

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

Практический пример: бронирование апартамента с ценой, гостями и проверкой результата

Разберём сценарий, который ближе всего к реальному запуску. Нужно создать страницу апартамента, дать пользователю выбрать даты, указать гостей, увидеть итоговую стоимость, отправить заявку и проверить, что период заблокирован в календаре. Для примера используем Plain mode, JetFormBuilder и single template. Если ваш проект работает через WooCommerce-based mode, логика проверки похожа, но форма заменяется товаром и checkout.

Цель

Получить рабочую страницу объекта, где выбор дат в Booking Availability Calendar заполняет форму, calculated field показывает итоговую цену, отправка создаёт бронирование, а повторный пользователь не может выбрать уже занятый период.

Подготовка

• JetBooking установлен, активирован и настроен через мастер в Plain mode.
• Создан CPT для объектов, например apartments, и один тестовый объект "Апартамент у парка".
• Создан или выбран тип записи для orders, если он нужен в вашей структуре.
• В объекте указана цена за ночь и, если нужно, несколько weekend или seasonal rates.
• JetFormBuilder установлен, потому что форма собирается на нём.

Шаги настройки

1. Откройте Bookings -> Settings -> General и убедитесь, что Booking instance post type указывает на CPT объектов.
2. Во вкладке Configuration выберите расчёт по ночам или дням, задайте минимальный срок и включите Clear button, если пользователь должен быстро сбрасывать даты.
3. Создайте форму в JetFormBuilder -> Add New: имя, email, Check-in/Check-out dates field, количество гостей, дополнительные услуги и calculated field для стоимости.
4. В post submit actions добавьте действие, которое создаёт бронирование, и сопоставьте объект, даты, цену и дополнительные поля.
5. Создайте single template для объекта и вставьте форму на страницу.
6. Добавьте Booking Availability Calendar рядом с формой и включите Allow to select dates. При длинной странице включите Scroll to the form.
7. Опубликуйте шаблон и откройте тестовый объект в публичной части сайта.

Проверка

Откройте страницу тестового апартамента в режиме обычного посетителя. Выберите даты в календаре и убедитесь, что они попали в поля формы. Заполните имя, email и количество гостей. Посмотрите на calculated field: сумма должна соответствовать цене объекта, периоду и дополнительным услугам. Отправьте форму и перейдите в Bookings. В списке должна появиться новая запись с объектом, датами, статусом и дополнительными данными.

После этого откройте ту же страницу в другом окне или очистите выбранные даты. Попробуйте выбрать тот же диапазон. Если всё связано правильно, даты должны быть заблокированы или недоступны для повторного бронирования. Затем проверьте письмо, если оно настроено через form notification или Workflows.

Нюанс, который часто ломает пример

Если calculated field показывает ноль, не начинайте с правки календаря. Сначала проверьте, есть ли цена у объекта, правильно ли указано имя поля дат в формуле и не ссылается ли макрос на поле, которого в форме уже нет. Если бронирование создаётся, но дата не блокируется, проверьте post submit action и соответствие выбранного объекта. Если письмо не пришло, проверьте наличие email-поля, настройки отправителя и журнал доставки почты WordPress, если он установлен.

Как проверять результат перед запуском на рабочем сайте

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

Контрольный сценарий для Plain mode

1. Создайте тестовый объект с понятной ценой и без сезонных исключений.
2. Отправьте форму на короткий период и проверьте запись в Bookings.
3. Откройте подробности бронирования и убедитесь, что даты, email, guests и total сохранены.
4. Попробуйте повторно забронировать тот же период для того же объекта.
5. Измените статус вручную и проверьте, запускает ли это workflow, если он настроен.
6. Проверьте форму на мобильной ширине, но не меняйте логику без причины: сначала убедитесь, что данные сохраняются.

Контрольный сценарий для WooCommerce-based mode

1. Создайте товар с product data JetBooking и задайте базовые параметры.
2. Выберите даты на странице товара и добавьте товар в корзину.
3. Проверьте, как работает Booking hold time, если пользователь не завершает checkout.
4. Оформите тестовый заказ и убедитесь, что бронирование появилось в Bookings.
5. Измените статус заказа и проверьте связь со статусом бронирования, если включена синхронизация.
6. Проверьте возврат доступности даты после отмены или истечения временного удержания.

Что фиксировать в документации проекта

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

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

Полезные улучшения без риска для ядра плагина

Для JetBooking лучше избегать нестабильных PHP-хаков, если вы не нашли документированный hook или официальный пример под конкретную задачу. В документации Crocoblock есть отдельные tips & tricks, но для обычного сайта безопаснее начинать с настроек, шаблонов и CSS. Не редактируйте файлы плагина: при обновлении изменения пропадут, а ошибка в логике бронирования может затронуть реальные заявки.

CSS для выделения календаря и итоговой цены

Если календарь и форма выглядят слишком плоско внутри шаблона, можно добавить небольшой CSS через дочернюю тему, Customizer -> Additional CSS или безопасный плагин сниппетов. Селекторы ниже намеренно мягкие: они не вмешиваются в расчёт и не меняют данные, а только улучшают визуальную иерархию. Перед применением проверьте реальные классы в вашей теме и при необходимости сузьте область до контейнера страницы объекта.

.single-apartment .jet-booking-calendar,
.single-apartment .jet-form-builder {
  border: 1px solid rgba(24, 35, 58, 0.12);
  border-radius: 8px;
  padding: 18px;
  background: #ffffff;
}

.single-apartment .jet-form-builder .calculated-field,
.single-apartment .booking-total {
  font-weight: 700;
  font-size: 1.15rem;
}

После добавления CSS откройте одну страницу объекта, выберите даты и проверьте, что календарь, поля формы и итоговая цена не сдвинулись и не перекрывают друг друга на мобильной ширине. Откат простой: удалите фрагмент CSS и очистите кеш сайта.

Совместимость с кешем и динамическими страницами

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

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

Локализация календаря и подписей

Для многоязычных сайтов используйте штатные настройки Labels и WPML String Translation, если сайт работает с WPML. Документация Crocoblock описывает домен JetBooking Custom Calendar Labels: после включения Use custom labels строки появляются в переводах, а после изменения исходной подписи перевод нужно обновить. Это надёжнее, чем править текст через JavaScript или заменять строки в файлах плагина.

Видео по работе WooCommerce-based mode

Для визуального понимания режима, где бронирование строится вокруг WooCommerce-товара, полезен официальный ролик Crocoblock "Create Bookings in WooCommerce with Additional Services & Guest Options". Он поддерживает запросы вроде "как пользоваться JetBooking с WooCommerce", "настройка дополнительных услуг JetBooking" и "проверка результата бронирования в товаре". В видео показывается путь от настроек режима до товара, атрибутов, гостей, дополнительных услуг и проверки результата.

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

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

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

Календарь виден, но выбранные даты не попадают в форму

Симптом: пользователь кликает даты в Booking Availability Calendar, но поля check-in и check-out остаются пустыми.

Возможные причины: отключён Allow to select dates, форма и календарь вставлены в разные контексты объекта, single template не получает правильный post type, в форме нет корректного Check-in/Check-out dates field.

Что проверить: откройте настройки виджета или блока календаря, проверьте источник single template, затем временно вставьте форму и календарь рядом на одной странице тестового объекта. Если рядом они работают, проблема в шаблоне или контексте вывода.

Как исправить: включите выбор дат, проверьте форму, восстановите скрытое поле объекта и пересохраните шаблон. Если после правки поведение ухудшилось, откатите последний template change и вернитесь к минимальной связке формы и календаря.

Итоговая цена равна нулю или отличается от ожидаемой

Симптом: calculated field показывает ноль, слишком низкую или слишком высокую сумму.

Возможные причины: пустое поле цены объекта, неправильное имя поля дат в формуле, конфликт расчёта "по дням" и "по ночам", weekend или seasonal rate перекрывает базовую цену, дополнительная услуга умножается на гостей или дни иначе, чем вы ожидали.

Что проверить: создайте объект с простой ценой и без сезонов, выберите один короткий период, затем добавляйте условия по одному. Если формула использует макросы, сравните имена полей с фактическими field names в JetFormBuilder.

Как исправить: исправьте имя поля, заполните цену объекта, временно отключите сезонные и weekend rules, затем включайте их обратно по одному. Откатывайте последнюю добавленную rate-настройку, если после неё сумма стала неверной.

Бронирование создаётся, но даты можно выбрать повторно

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

Возможные причины: форма не связала заявку с правильным объектом, post submit action не создал booking record, используется другой post type, кеш отдаёт старый календарь, unit-настройки позволяют выбрать другую доступную единицу.

Что проверить: откройте Bookings и убедитесь, что запись появилась именно для тестового объекта. Затем проверьте, есть ли units и сколько единиц доступно. После этого повторите тест с очисткой кеша или в приватном окне.

Как исправить: восстановите сопоставление объекта в post submit action, проверьте hidden field, исключите динамическую страницу из агрессивного кеша или уточните настройки units. Если не уверены, временно отключите units и проверьте один объект как единичный ресурс.

Workflow настроен, но письмо не отправляется

Симптом: бронирование есть в админ-панели, но клиент не получает подтверждение или напоминание.

Возможные причины: выключен Enable Workflows, в Plain mode нет email-поля, неправильно выбран event, статус не меняется на нужный, запланированное письмо настроено слишком поздно, почта WordPress не доставляется.

Что проверить: включён ли глобальный переключатель Workflows, есть ли email в данных бронирования, совпадает ли trigger с реальным событием, работает ли обычная отправка писем с сайта. Для напоминаний проверьте, что дата и статус попадают в нужное временное окно.

Как исправить: добавьте или сопоставьте email-поле, включите Workflows, упростите workflow до одного immediate email после Booking Created, затем усложняйте сценарий. Если письмо не уходит даже в простом варианте, проверьте SMTP или почтовый сервис сайта.

Google Calendar не показывает бронирование сразу

Симптом: iCal включён, но внешнее событие не появляется мгновенно.

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

Что проверить: используйте удалённый сайт, проверьте вкладку Calendars, шаблон iCalendar, направление синхронизации и ограничения внешнего сервиса. Для двухсторонней синхронизации нужны отдельные настройки для передачи с сайта наружу и обратно.

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

Когда JetBooking будет удачным выбором

JetBooking стоит использовать, если вы готовы строить полноценный booking-сценарий внутри WordPress: объекты, даты, цена, форма или WooCommerce-товар, статусы, уведомления, units и проверка результата. Это не самый лёгкий путь для простого календаря, зато он хорошо подходит для динамических сайтов, где бронирование должно быть частью общей структуры продукта, каталога и шаблонов.

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

Когда проверка завершена и вы понимаете выбранный режим, можно скачать ZIP-архив и протестировать его на копии сайта или staging-среде. Такой подход снижает риск: вы сначала подтверждаете механику бронирования, а уже потом подключаете реальные объекты, цены и пользователей.