The Availability Calendar module allows you to add an availability calendar to entities. Example use cases are tourist accommodation - e.g. bed and breakfast, holiday homes or self catered apartments - and car or motor bike rental.

An availability calendar shows your customers at what dates your accommodation is still available and at what dates it is already booked.

A note on D8

For now there are no plans to port this module to D8. If feasible and when available, a migration to BAT is more likely to be seen as the future of this project,

Features

Site admins/owners:

The Availability Calendar is defined as a field, thus fully supported in many scenarios, with all kind of other modules.
The Availability Calendar is also defined as an entity, thereby opening it up to integration with all kind of other modules via entity_api.
Define your own set of states, e.g. not just available and booked, but low season, high season, option and booked.
Supports import and export of iCalendar feeds.
Allows to disable the calendar on a per entity basis.
Allows to give the calendar a name, easy when you have multiple calendars.
configurable date entry and display formats (by using Drupal date and time formats).
Flexible calendar display, options include:
- Show week numbers.
- Define the first day of the week.
- Define your own color scheme for the states.
- Define the number of months.
- Use a viewport to reduce screen estate taken.
Easy editing:

Users:

Search on availability (through Views and search_api integration).
Uses a date range picker on top of the jQuery UI datepicker when selecting a range for searching.
Kick off booking process for customers (booking formlet sub-module):
- Select start and end date in the calendar itself and click "book now".
- Prefilled start and end date based on e.g. an earlier availability search.
- Integrates with webform for further booking details.

Note however, that this module focuses on displaying availability. It does not
try to support the booking or payment process any further than the kick start
through the booking formlet sub-module.

If you are looking for a fully integrated booking and payment process, try the
Rooms module.

Integration with Drupal and contrib modules:

The availability calendar is defined as a field:
- add it to any (fieldable) entity you want.
- position the calendar where you want: configurable per default view, teaser and edit form.
- highly configurable widget (edit form).
- highly configurable formatter (per view mode).
- multiple calendars per entity.
- synchronization of translations using i18n_sync.
If date_popup is enabled it will automatically be used for date entry fields. This module also comes with a date range picker on top of the date popup.
If date_api is enabled you can run on PHP 5.2.
Views integration: filter on availability.
Entity API integration. The availability calendar is also defined as an entity. This opens up the whole data model to Views and other modules that integrate with Entity API, like search API.
Variable integration: a good deal of UI texts has been defined as variable, allowing you to customize them (and translate the customizations).
Migrate integration: a field handler for the availability field is defined including an example migrate project to demonstrate its working.

Developers

Server side API for most CRUD operations around availability calendars.
A javascript API that allows for client side interaction with the calendar.

Dependencies

Drupal 7.14
PHP5.3 or Date api

Soft dependencies (aka integrates with):

Views
Date popup
Entity API
Variable

Currently Supported Versions

7.x-5.x

This version added entity integration support. Availability calendar was (and is) currently defined as a field. This made it a highly flexible and easy to use module and solved many (long standing) feature requests in the issue queue. But this also gave rise to many new features in the issue queue, building further upon what fields brought us.

Besides fields, D7 brought us also entities. Less talked about but an impact as least as big as fields. Contrib jumped in with entity API and nowadays almost all "generic" modules are based on integration via Entity API. Think of Views, Rules and Search API.

We slowly got to the conclusion that embracing Entity API will allow us to more easily solve the new feature requests. So this new branch is gradually adding entity support. It will continue to support Availability Calendar as a field though and we will try to continue to support this hybrid approach. Fields to keep it easy, Entities if you need more power.

Our API, mostly CRUD operations, will be moved to Entity. This will allow site builders and developers to hook into CRUD operations on availability calendars as well as define rules for these actions.

Updating from 7.x-4x

Upgrading should be no problem but please do consult the CHANGELOG.txt for a list of actions and checks to perform after upgrading.

Updating from 7.x-3.x

Upgrading should be no problem but please do consult the CHANGELOG.txt for a list of actions and checks to perform after upgrading. Think of things like:

Clear all caches.
Visit admin/config/content/availability-calendar/styling.
Visit admin/config/regional/date-time and admin/config/regional/date-time/locale.
Visit and save the "field settings" and "manage display" pages for all calendar fields.
Visit and save the "field settings" and "manage display" pages for all booking formlet fields.

Upgrading from 7.x-2.5

Upgrading to this release is possible. However, as the module is renamed to availability_calendar (without an ending s) using the normal update.php path was a bit difficult. Instead:

Download and install the 7.x-2.5 version.
Run update.php.
Download and install the latest 7.x-4.1 version.
Read "README when coming from Availability Calendars.txt".
Enable the new Availability Calendar module (in the fields group).
Enable the Availability Calendar Update module.
Read "UPGRADE.txt".
Run the update and follow the on-screen instructions.

Note: if you use split days in a not foreseen way, you might loose data. Not foreseen here means: using the split day option to allocate a resource twice a day, not to emphasize that you are allocating the resource per night instead of per day. If your am status equals (or should equal) the pm status of the day before, data won't get lost.

7.x-2.5

The last D7 non-fields based version. A direct upgrade from 6.x-1.5 (or higher) to 7.x-2.5 is possible. However, older versions (6.x-1.4 or lower) must first upgrade to 6.x-1.6 or 6.x-2.3 (in Drupal 6) before upgrading to Drupal 7.

This version is no longer supported, except for upgrade (to 7.x-5.2) problems.

The 6.x version is no longer supported.

Sponsors

Les Camélias: iCal import and export.
Les Camélias: the date range picker.
Felip Manyer i Ballester: developed the Migrate integration.
MotoJP: Some of the new features in the 7.x-4.x version: full day versus overnight rental and booking formlet integration with Views search results.
Marc-Antoine posted working and complete patches for several issues.
White Wedding Pages: D6 backport of Views support.
Exclusive North Devon: Parts of the D7 field based rewrite: booking formlet and search on availability through Views support.
Buro RaDer: initial D7 port and the field based 7.x-3.0 rewrite.
Maisonnera: configurable statuses and the editable calendar, including javascript API.
Sork Beach Rentals: earlier D6 development.
Smeale Farm Cottages: original D5 development.

Future Development

With the fields based version that included Views integration, many feature requests were fulfilled. However, it also gave rise to many new feature requests in the issue queue. Also, Entity API has become a stable and widely supported module to integrate with Views, Rules, Search and many other modules. So, we are now working on redefining the calendar as an entity. This will again lead to many new possibilities and many feature requests to be fulfilled.

On the other hand, there is also the Rooms module. We still would appreciate your say in the discussion in #1229920: [AC] Possible integration of availability_calendars and rooms. All reactions are welcome and will help in deciding on the future of this module!

However with all the recent new features, new requests will come up, to further enhance the module. Think of new formatters, new editors, other integrations, ... You are welcome to share your ideas on future features.

Support

The maintainers will actively provide support on reported bugs.
Regardless the lower pace of new development and the possible integration with Rooms, this module will remain to be maintained by us. Bug reports are often solved the same day and we strive to keep it that way.

Help requested

All these activities cost us a lot of time. Some of it paid, some not. So, help will be warmly welcomed. How can you help?

Get your client or employer to sponsor a feature and program it yourself or let us do it. If you contact us prior to making the modifications, we can arrange that the feature will be added to the module. Assuring your client of support and future upgrades without hassle. Note that of course we can’t support private forks of this module. The funder will be properly attributed. If, on the other hand, you dump your almost completely rewritten customized version without prior notification, chances are that we cannot accept it.
Add a feature or bug fix in your own time. Again, it will be better to contact us beforehand, to better align various activities. You will of course be properly attributed.
Back port features from D7 to D6 or vice versa. Some new development will first take place in D7. As many sites will continue to run on D6 for a long time to come, back porting these features will be highly welcomed.
Test or review new features. Most features will have their own issue. Test the feature as soon as it reaches the state ‘needs review’. Because without reported tests and reviews, the issue “cannot” proceed to ‘reviewed and tested by the community’.
Write help. We want to move to the advanced help module, so help becomes separated from the code. This will allow for more extensive help than we can now fit into the UI.
Provide translations for the module on localize.drupal.org. You don’t have to do the whole module at once: a few strings a time and the module will be translated within a few days. This is better for your current client and future clients, as you don’t have to redo the translation on every project and you can grab others contributions as well.

PhpStorm

This module is developed and maintained using PhpStorm. Prevent errors while programming, by using their extremely smart PHP and JavaScript code analyzer, spell checker and other features.

If you are a Drupal core or contrib maintainer, you might apply for a free "Open source project license" as well. Check the conditions on the site of JetBrains PhpStorm. If you like to use it for custom website development, check their very affordable license prices.

Availability Calendars

Issues

Drupal 8PostponedCode Created about 9 years ago

Drupal 8
Postponed
Code
Created about 9 years ago