Wed November 2014

3.1.0 Release Update so Google API v3

Recently I discovered that Google had deprecated the v2 API for connecting to Google’s services. Unfortunately at the same time I discovered that the Zend Gdata Library was using v2 of the Google API and wasn’t going to be updated to v3 in time to meet the cut off for when Google was turning off the Calendar API.

The last two days have been spent busily re-coding the Syncer class for PBBooking to use v3 of the API instead of the now deprecated v2. This was something I had intended to do across the Christmas break for a 3.1.0 release early in the New Year.

Unfortunately the v3 API removes the option to use client login. Instead ALL logins now need to be done using OAuth2. This means that upgrading is not going to be seamless and will require you to make some changes.

So let’s step through what needs to be done to enable Google Calendar on the new PBBooking 3.1.0.

This information is for PBBooking 3.1.0 only. Stay tuned for updates to 2.5 versions of PBBooking

Firstly, as with previous versions click on the resource you wish to link to Google calendar and click edit. Then go down to Enable Google Calendar Integration and ensure that this is set to Yes.

pbbooking-calendar-1
pbbooking-calendar–1

In the Calendar Id field enter the google calendar ID for the calendar you wish to link. If this is your primary calendar it will typically be your email address. If that is another calendar than your primary calendar, or a calendar that someone else has shared with you it will be a longer string.

You will notice that that Google Calendar Username and Google Calendar Password fields have been removed. These are no longer stored by PBBooking, instead OAauth is used to authorise PBBooking to access your calendar information.

Previously if you wished to access Google calendars from different accounts you could put different credentials for each calendar. The change to v3 of the API and OAuth2 means that the calendar user will need to share their Google Calendar with you form their account. You will then be able to link to this account.

Once you have enabled Google Calendar integration for the Calendar / Resource it is now time to link your PBbooking Installation to Google Calendar using OAuth2. Save & Close to apply your Calendar changes then go back to the Dashboard.

From the Dashboard click configuration and go to the Google Calendar Settings tab. Under this tab ensure that:

  • Enable Google Calendar Integration is set to Yes
  • Sync Forward Events is set to One Month or greater
  • Sync Google Events to PBbooking is set to Yes if you wish to sync events entered into Google Calendar back to PBBooking
  • Google Cal Sync Secret is set to your preferred sync secret.
  • Google Query Max Results is set to a value appropriate for your site. Anywhere between 100 and 250 - 300 works well for most sites.
pbbooking-config-1
pbbooking-config–1

For now Auth Code can be left blank. We will get this from Google.

Click the Link Calendar button and this will open a Google authorisation prompt in a new window or tab.

From the list of accounts, choose which account you would like to grant PBBooking access to. Only one account’s credentials are stored, so if you need to access calendars from more than one account you need to share these from within Google Calendar.

If you are not currently logged in to your account Google will ask you for your password to login. Just enter your password as normal.

Google will now display a landing page advising that Purplebeanie Online Booking for Joomla would like to Manage Your Calendars. Just click Accept.

From the next page copy the code in the text box to your clipboard. The code may be longer than the text box so ensure that you have copied all of it.

Once copied, close the window to return to your PBBooking configuration and enter the code you just copied into the Auth Code box. Then click Save & Close.

Congratulations, you are all done. PBBooking is now configured to access your Google Calendar installation using OAuth2 and the new (v3) API.

What Can Go Wrong?

As with all things in life there are things that can go wrong. So let’s look at some of the things that can go wrong with the new v3 API.

Firstly, Google has now introduced daily quotes to many of their services. These quotas are based on the developer API key and for Google Calendar a maximum of 500,000 queries per day can be issued.

By default PBBooking 3.1.0 will use the main PBBooking Subscriber key so that installation is as simple as possible. This means you will be sharing 500,000 queries per day with all other users. If you are a high traffic site I would strongly encourage you to grab your own API key. Raise a support ticket for details.

Secondly, OAuth2 uses refresh tokens that allows PBBooking to sync with Google Calendar off a scheduled task or cron job. Each Google account is allowed a maximum of 25 refresh tokens at any given time. Each time you grant an application offline access using OAuth2 a new refresh token is created.

When you exceed 25 refresh tokens the creation of the 26th token will invalidate the first token. If the PBBooking refresh token is invalidated the sync process will stop. You will receive an email notifying you and will need to re-link the installation.

Where to Get the 3.1.0 Update?

Login to your purplebeanie.com account and go to the Downloads page. The direct link is here http://purplebeanie.com/downloads/pbbooking–245-series/pbbooking–245-series–3–0–0.

This update is only available to subscribers.

Tue November 2014

Deprecation of Google Calendar API v2

Today (18th November 2014) I became aware of problems users were having synching and / or connecting to Google. Typically the following error code is being returned:

0 Expected response code 200, got 403 <HTML> <HEAD> <TITLE>Forbidden</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF" TEXT="#000000"> <H1>Forbidden</H1> <H2>Error 403</H2> </BODY> </HTML>

This is being generated after Google shutdown v2 of the Google Calendar API. This was done on the 17th November. You can see the notice on the API docs here.

Initially I had thought this was not being switched off until April 2015 and I had planned to work on migrating to v3 of the API over the Christmas break. However, it has happened earlier than I expected.

I am working on an emergency update 3.0.5 3.1.0 to address this issue and upgrade from using Zend Gdata and v2 of the Calendar API to using v3.

In the meantime sites using PBBooking >= 3.0 will continue working, however the Google Calendar Sync will not be occurring. This will mean PBBooking events will not be written to Google Calendar and Google Calendar events will not be written to PBBooking.

For sites using PBBooking <= 2.4.5.11a13 if you have Google Calendar Sync enabled you will be getting the error shown above on both your front end and back end PBBooking pages. A temporary work around is to disable Google Calendar integration on your site which will return to normal function.

The 3.0.5 3.1.0 update will provide a fix for this issue. For Joomla 2.5 users update 2.6 will fix this.

Update 19th November - I have authentication / authorization working with the new API and now only need to update the syncher class for a release.

Update 19th November @ 3:34pm - Fetch events, creation of events and deletion along with authentication and authorisation now working using V3 api. Just some final testing and then I will be releasing.

Update 19th November @ 5:36pm - 3.1.0 released for Joomla 3.3 changes Google API to v3 and fixes broken sync problems. See blog post here. Next up a 2.5 update.

Update 20th November @ 11:46am - 2.6 release for Joomla 2.5 is well underway. Authentication and Authorization for OAuth2 has been done and now just need to reconnect the CRUD methods

Update 20th November @ 3:44pm - Final coding has been done just testing package prior to release.

Update 20th November @ 4:45pm - Testing has been done and package has been released. The Joomla 2.5 version can be downloaded from here

Fri July 2014

Front End Management of Diaries is Now Available

Hot on the heels of the 3.0.0 release of PBbooking, I am really excited to say that front end management of diaries is now available!

The ability to manage diaries from the front end has been one of the most frequent feature requests. There were certain architectural changes that needed to be implemented to make this a reality.

With the new Front End Manage Diaries users can now embed a module into an article to provide the full manage diaries experience in the front end.

Events can be:

  • edited through an edit dialog allowing changes to custom fields, service, calendar and start / end times
  • dragged / dropped to move the event
  • resized to extend the event
  • deleted
  • and of course created.

This module has the following system requirements.

  • Joomla version >= 3.3
  • PHP >= 5.3
  • Purplebeanie Online Booking >= 3.0

This module is not compatible with versions of PBBooking less than 3.0. A script at installation time will run to determine whether your system is compatible.

To download, log in to your account at purplebeanie.com and go to downloads. Not yet a subscriber? you can subscribe here: http://www.purplebeanie.com/levels.html

Thu July 2014

PBBooking Version 3.0.0 Now Available

I’ve been working away getting the PBBooking Version 3.0.0 release ready, and I’m really excited to say it’s finally available for download.

PBBooking 3.0.0 is almost a complete re-write of much of the code. Most of the focus has been on speed. If you have used some of the later versions you may have come across speed problems, particularly with Google Calendar.

This update changes all that! In testing on a cpanel based CentOS host a site with 4 calendars and 1000 (for the current month & next month only) page renders were (exclude JS, CSS & image load) < 1 second.

Speed improvements have come from:

  1. Optimization of the event lookup code and free / busy calculations and database queries
  2. Changing Google cal integration to a regularly updated scheduled job

Version 3.0.0 has also seen a number of other improvements including:

  • Redesigned and rebuilt multi language control centre for a single location to define all multi language strings
  • Proper use of the Joomla media dir to allow all scripts and CSS to be overridden
  • Upgrade to the latest version of jQuery Full Calendar

Please note that Version 3.0.0 is almost a complete re-write from previous versions and any template overrides will need changes.

To download, log in to your purplebeanie.com account and head to the downloads page or click here

Wed June 2014

PBBooking Debug Mode: Security / Privacy & Performance Considerations

In working on some client sites recently I have found that a number of people have turned on debug settings and not turned them off. This is something I generally don’t advise for a couple of reasons.

The latest versions of PBBooking offer three levels of debugging settings:

  1. Enable logging - this setting will print logging messages to the error_log and also to the PBBooking logging able #__pbbooking_logs
  2. Enable test suite hooks - this will enable front end hooks for running user interface unit testing. This is not really a setting that users need to enable.
  3. Enable FirePHP - in conjunction with the enable logging option (1) this will enable support for the Firefox FirePHP extension

Enabling the debugging settings are a useful part of troubleshooting but leaving these turned on long term can have serious implications on system performance and privacy / security.

System Performance

The logging tools are very, very, verbose and can generate a large number of entries in a very short space of time. This is particularly true when you have a large number of events, especially recurring events. The enable_logging will generate logging messages checking the availability of each and every time slot on your calendar.

As your #__pbbooking_logs table get’s larger and the error_log file get’s bigger this will slow down the performance of the booking system overall.

Privacy & Security

Firefox’s FirePHP extension is a fantastic tool for debugging lots of Javascript and AJAX calls. Unfortunately FirePHP logs to the Firefox console. This means leaving this turned on as part of day to day use means that anyone with the FirePHP extension or FireChrome extension will be able to view debugging messages that are generated.

Since introducing support for FirePHP no password’s are included in logging messages, however details of availability, calendar id’s, and system paths are included.

In summary. For performance and privacy and security reasons if you are not actively using the debugging tools to troubleshoot a problem, make sure you turn them off.