Skip to content

Getting started

This is a no-code walkthrough for a site builder: enable the modules, publish a bookable resource, put a booking calendar on the site, and take a booking - all from the admin UI, without writing PHP. For the model behind it, read Concepts and Architecture; to book from your own code, see the API reference.

Check the database first

This needs MySQL or MariaDB. The promise that two people never get the same seat is kept by a row lock, and Drupal's SQLite driver drops the clause that takes it, so on SQLite the site will look like it works and will let two bookers hold one seat under a rush. See Requirements.

1. Enable the modules

On the Extend page (Administration › Extend), enable:

  • Yoyaku (yoyaku) - the booking engine. Pulled in automatically by the modules below.
  • Yoyaku UI (yoyaku_ui) - the admin screens. It adds a Booking section at Administration › Booking (/admin/booking), which opens on a page listing what is under it: the daily work first (resources, slots, bookings, orders, placing a booking, checking in), then the venues, then a group each for Tariffs, Workflow, Settings and Configuration.
  • Yoyaku Calendar (yoyaku_calendar) - the public calendar visitors book with.

Optional, depending on what you need:

  • Yoyaku Node (yoyaku_node) - show a resource's calendar on a content page.
  • Yoyaku Order (yoyaku_order) and Yoyaku Payment (yoyaku_payment) - group a visitor's bookings into one order and gate confirmation on payment.
  • Yoyaku Views (yoyaku_views) - build your own lists of bookings, slots and resources with Views.

2. Create a resource

A resource is the bookable thing - a room, a piece of equipment, an event. Go to Administration › Booking › Resources, click Add resource, and set:

  • Name.
  • Default capacity - the capacity a new slot starts from. It bounds the total a slot may offer across every tariff, whether the resource offers tariffs or not; empty means unlimited.
  • Minimum booking notice - how far ahead of a slot starting a booking has to be made, for it to still be bookable.
  • Calendar selection (added by Yoyaku Calendar) - whether a visitor books a single day, several days, or a contiguous range. See Calendar.

3. Decide what is offered: tariffs

Capacity lives on a slot's tariffs: Adult / Child / VIP, Standard / Premium, and so on. Each tariff is counted independently, which is what lets one time window offer several pools without overbooking.

Open the resource's Tariffs tab (/admin/booking/resource/{id}/tariffs) and add the tariffs this resource offers. A simple resource can keep the single implicit default tariff and behave exactly as if the limit were the slot's own capacity.

4. Publish availability: slots

A slot is a concrete time window (start/end) of a resource. Create them two ways:

  • One at a time - Administration › Booking › Slots › Add slot: pick the resource and set the start and end.
  • In bulk - Administration › Booking › Generate slots (/admin/booking/generate): pick one or more resources, a From/To date range, the weekdays to include, a daily start and end time, and a capacity per slot (for resources offering no tariffs).

Each slot is split into its tariffs; fine-tune a slot's per-tariff allocation from its Tariffs tab. Only published and active slots are bookable and appear on the calendar.

A resource's Slots tab lists its upcoming slots with the same checkboxes and bulk actions as Administration › Booking › Slots: update or delete the ticked slots, or all of them at once, and come back to the tab.

A slot that has bookings, in any state, cannot be deleted: each is somebody's record, and deleting the slot would take it along. The delete form says so, and a bulk delete keeps such slots and says how many. To stop a slot being booked, make it inactive or unpublish it instead.

A resource that still has slots or bookings cannot be deleted either: its delete form lists what is left. Delete its slots first: its Slots tab lists those still to come, and Administration › Booking › Slots filtered on the resource lists past ones too. Its tariffs and allotments then go with it. To stop a resource being booked while keeping its history, make it inactive instead.

The same holds for what the schedule is built from. A tariff that bookings were taken at, a resource type that resources use and a tariff class that tariffs belong to cannot be deleted while they do, and each delete form lists what still uses it; a tariff's slot tariffs, and a tariff preset's tariffs and allotments, go with it. A booking that still counts (held, confirmed, completed or a no-show) is canceled, not deleted: only a canceled, released or expired one can be.

A Bookings tab lists the bookings made against a slot, a single tariff or a whole resource, each linked to its transaction (an order can span several slots, so the transaction is a column, not the scope). Filter by transaction number to isolate one order's bookings. With Yoyaku Order installed the tab reads in order terms (an Order column and the Booker). The tab is generic: a module offers it on another entity by adding one line to the booking scope map (hook_yoyaku_ui_booking_scopes()).

The list is paged so it scales to a resource with hundreds of thousands of bookings; the page size is a per-tenant setting (Bookings per page on the tenant edit form, defaulting to 50).

Only a resource's managers (and administrators) can see and use these tabs. They may act on the ticked rows in bulk: Confirm, Complete, Mark unused, Cancel, Release or Delete. Each transition applies only to the rows it fits (others are reported as skipped), each row is re-checked against the operator's manage-this-resource access, and delete asks for confirmation. Manual check-in is this Complete action: filter by order, tick the bookings, apply.

5. Put a calendar on your site

Two supported surfaces, both no-code:

  • A block - at Administration › Structure › Block layout, place the Yoyaku booking calendar block in a region and pick the resource it should show.
  • On a content page (needs Yoyaku Node) - the module adds a Booking resource reference to every content type. Set it on a node, then, under the content type's Manage display, show that field with the Booking calendar formatter. The node then renders its resource's calendar.

6. What the visitor does

The calendar shows a month grid colored by availability - green available, orange partial, red full. The visitor navigates months, picks a day (or several days / a range, per the resource's selection mode), enters a quantity per tariff, and submits. Each selection immediately becomes a held booking that reserves capacity; the visitor sees a "Held N booking(s)" confirmation.

To let anonymous visitors book, grant the View booking availability and Place booking permissions to the Anonymous user role.

7. Confirm bookings

A hold reserves a unit but is not final. Its order carries the window, so the whole basket expires together unless it is confirmed; how long that window is comes from the booking channel, then the tenant, then the site settings. Manage bookings at Administration › Booking › Bookings (/admin/booking/bookings): confirm or cancel each one, or record one yourself with Place a booking (/admin/booking/place).

  • With Yoyaku Order, the bookings from one submission group into a single order (one payment, one booker record) that you drive from the orders overview.
  • With Yoyaku Payment, confirmation is payment-gated: a hold becomes a confirmed booking once it is paid, within the hold window.

Current limitations

Yoyaku's public calendar places held bookings and stops; turning those into confirmed, paid or acknowledged bookings is the job of other modules. A few things still need code or the full workflow stack today, and are tracked for a future version in #3611565:

  • No one-click demo. The shipped example (yoyaku_orchestra_example) requires the Orchestra workflow; a no-code demo recipe is planned.
  • No automatic confirmation. Without Yoyaku Payment or a workflow, a hold stays held until an operator confirms it (or it expires). A resource-level "confirm automatically" option is planned for free bookings.
  • Minimal post-booking feedback. After a hold the visitor only sees a "Held N booking(s)" message; a configurable confirmation message and redirect are planned.
  • No built-in booker details. The calendar does not collect a name or email. To capture booker details today, use a Webform as the form step (yoyaku_webform).

Next steps