Compatibilty with fullcalendar_view

Glad it's working for you! A good calendar integration would be great, I agree. I see your issue on smart_date, I'll try the same steps without translations and see if I get the same issues or not.

Marking #3183554: Entries don't appear when Start date is in a relationship entity as potentially related, since it seems a possible root cause. If you have an opportunity, please test the patch there and provide feedback.

I've been testing a few modules, this is the one Iam stuck with but I am having problems with fullcalendar view integration. it is worth waiting

I got missing tokens message in status report. I change the code as below in bookable_calendar.module. The message is gone. Hope it is correct

/**
 * Implements hook_token_info().
 */
function bookable_calendar_token_info() {
  $info = [];
  $info['types']['bookable_calendar'] = [
    'name' => t('Bookable Calendar'),
    'description' => t('Tokens associated with Bookable Calendars')
  ];
  $info['tokens']['bookable_calendar']['title'] = [
    'name' => t('The title of the Calendar'),
	'description' => t('The title of the Calendar')
	];
 
  $info['types']['booking_contact'] = [
    'name' => t('Booking Contact'),
    'description' => t('Tokens associated with Booking Contact')
  ];
  $info['tokens']['booking_contact']['url'] = [
    'name' => t('The URL for the Booking Contact'),
	'description' => t('The URL for the Booking Contact')
	];
  $info['tokens']['booking_contact']['email'] = [
    'name' => t('The Email for the Booking Contact'),
	'description' => t('The Email for the Booking Contact')
	];
  $info['tokens']['booking_contact']['party_size'] = [
    'name' => t('The Party Size for the Booking Contact'),
	'description' => t('The Party Size for the Booking Contact')
	];
  $info['tokens']['booking_contact']['values'] = [
    'name' => t('The RAW Booking Contact Entity'),
	'description' => t('The RAW Booking Contact Entity')
	];
  $info['tokens']['booking_contact']['hashed_login_url'] = [
    'name' => t('A public login path to let the user edit their booking without being a Drupal user'),
	'description' => t('A public login path to let the user edit their booking without being a Drupal user')
	];
  $info['tokens']['booking_contact']['calendar_title'] = [
    'name' => t('The Calendar Title for this contact'),
	'description' => t('The Calendar Title for this contact')
	];

  $info['types']['booking'] = [
    'name' => t('Already Booked'),
    'description' => t('Tokens associated with Bookings')
  ];
  $info['tokens']['booking']['date'] = [
    'name' => t('The date of a Booking'),
	'description' => t('The date of a Booking')
	];
  $info['tokens']['booking']['created'] = [
    'name' => t('The time a Booking was created'),
	'description' => t('The time a Booking was created')
	];
  $info['tokens']['booking']['values'] = [
    'name' => t('The RAW Booking Entity'),
	'description' => t('The RAW Booking Entity')];

  return $info;

}

Hello, for a few days ago a module called "fullcalendar block" was released and I've put some time on integrating bookable calendar with fullcalendar.
The module creates a fullcalendar block fetching the json file you create from the view bookable calendar. I haven't found any issue so far. Everything works smoothly.

I personally appreciate if the booking is done by site members instead of booking contact users. May be in the future.

@DonoD Thanks for the fix to the tokens, got that pushed into dev branch and attributed to you.

Great news! In the dev branch of the module is now VERY basic support for module fullcalendar block. I added a new API endpoint of `bookable-calendar/api/{bookable_calendar}/openings` where `{bookable_calendar}` is the ID of the calendar you want to pull opening for.

You will need the module Fullcalendar Block, place the block on a page, and it asks for the Event Source URL which is where you put in the API endpoint URL.

Once that's there, you view the page you will see something like what I have below.

Clicking on an opening will open that opening page for you. Currently, I'm setting `title`, `start`, `end` and `url`. Are there more fields that we need to set?

Issues I need to work out:

• The issue with Title is we really only have titles on the parent calendar and the parent opening. I'm setting title as the Parent Calendar, but then everything just has the same title so it seems pointless. Do you have a better idea on how this should be handled?
• What if you want one Fullcalendar block that pulls all your Bookable Calendars in a single display, that currently doesn't exist but would be easy enough to add. If I did that, should I just randomly set each calendar to a different color, or I could probably make that configurable on the calendar edit form.
• Currently, the API is pulling EVERY instance on the site for a calendar, which very likely could crash your site by hitting memory limits. I believe the Fullcalendar Block module passes in some parameters when it hits the API which can be used to trim down the results.

Great! and thanks for the api.
I used opening instance as json source so my titles are dynamically fetched from calendar. I have 2 bookable calendars with various different booking openings on my site they are listed in the calendar columns as they should. When I click the the title booking rendered data in modal shows up. I can directly book it. And finally no performance issue with 140 instances.

it would be great to distinguish the calendars by colors. Many benefits for those who need many different calendars on their site. But theming so many data in fullcalendar rows and make it simple for site visitors might be tricky

This report targets Drupal 9-era versions of Bookable Calendar, Smart Date,
and Fullcalendar View. Bookable Calendar 3.0 supports Drupal 11/12 and exposes
opening data through Views and JSON:API; Calendar View is the currently
documented optional Views-based calendar display. Please reopen or create a
new issue with exported View configuration, exact current module versions,
and the full exception if Fullcalendar View compatibility is still required
and reproducible on 3.0.0-rc1.

AI-Generated: Yes (OpenAI Codex helped draft this project-maintenance update, which was verified against the Bookable Calendar 3.0 branch.)