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.
- Define your own set of states, e.g. not just available and booked, but low season, high season, option and booked.
- 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:
- 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:
- select a state, click a begin and end date, and the whole period is changed
- change a whole week or month at once
- change all sundays in a month at once
- Search on availability (through Views integration)
- 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
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.
- 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).
- Server side API for most CRUD operations around availability calendars.
- Drupal 7.14
- PHP5.3 or Date api
Soft dependencies (aka integrates with):
- Date popup
- Entity API
Currently Supported Versions
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.
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.
Main features of the 6.x-2.x branch (compared to 6.x-1.x) are:
- Views support to search on availability. Note: you can only use this feature if you do not use split days and do not allow to override settings per node. See for an explanation of these restrictions.
- Moved enabling support for a content type to the settings form.
- Optimized storage for both variables and tables.
- Better access handling
- Custom configurable availability states.
- Lots of error solved, in a.o. multilingual, database and theme handling,
See the release notes of each version for a complete overview of added features and fixed bugs.
An upgrade path from 1.x to 2.x is available. So, existing sites can easily upgrade by running update.php. As always: backup your database before updating.
Note: if you’re still on 6.x-1.3 or lower you might encounter this problem after upgrading.
If you encounter it, please report all information that might help us to solve it. Though we did implement a fix for this, we did not receive any feedback about whether it actually works or not.
- 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.
- Sork Beach Rentals: earlier D6 development.
- Smeale Farm Cottages: original D5 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 . 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.
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.
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.
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.