I have just released a minor update to PBBooking. The current version available for download is now 3.2.14.
You can find the changelog here: https://hotchillisoftware.com/support/support?view=announce
This update includes 1 minor bug fix for Google Calendar where some events were being returned without an end date. I only had one report of this bug in the wild so it is not something that occurred regularly.
This update also includes additions to the menu item configuration to hide the title displayed on the component and also to control the start and end dates which should be shown as linkable in the calendar.
These changes will not break existing layout overrides however if you wish to use them you will need to modify your layout overrides to support the new settings.
As part of Pbbooking 3.2 I’m moving payment out into plugins. The goal is to allow plugins for a variety of payment types including PayPal, onsite credit card etc.
The last couple of days I have been writing the integration with PayPal and trying to develop end to end tests with PHPUnit and Selenium. Previously testing stopped at a successful redirection to PayPal, the PayPal response triggering a notification email and marking the event validated was something I had to test by hand. As anyone involved in software development can tell you, if it needs manual steps to test, it won’t happen.
At first glance end to end testing of the PayPal gateway should be pretty straight forward. Fill out a form, hit the submit button, after login hit the confirm payment button and make sure the redirect happens back to your landing page, simple right?
Are you using any sort of CSS precompiler? Up until about 12 months ago I had always written plain old CSS by hand. I hadn’t worried about precompilers or anything like that. I guess my CSS needs had always been pretty simple.
Then about 12 months ago, as some of the projects I was working on got bigger, and more prone to changes, I decided I needed something better. At that stage all I was really looking for was something to handle variables. You know the sort of thing when you’re working on a site and the customer says “I’d really like the buttons and headings to be green”.
With Joomla, and Gantry, using Bootstrap, and Bootstrap at that stage using Less, it was a pretty simple decision.
I settled on Less, and for the simple variables that I use it for Less has served me well.
That started to change a couple of months ago. I was starting to do a lot more WordPress work. Most required custom themes and I was using the super cool _s starter theme. _s uses Sass… Yes I know there’s a Less port, but it seemed to lag a bit behind.
At first I thought, ahh that’s cool. Sass looks just like Less but with $ signs, and I was happy. Then I took the time to really start experimenting with Sass and looking around at the range of community tools built to work with Sass. Tools like:
For a kick start with Sass, check out the book from Pragmatic Bookshelf - Pragmatic Guide to Sass.) - (https://pragprog.com/book/pg_sass/pragmatic-guide-to-sass).
It’s a little old now, published 2011, but I found it really helped to get a handle on the fundamentals of Sass. With the fundamentals in hand I found it much easier to really start taking advantage of all the advanced tools that third party frameworks made available.
I’ve been talking to a lot of people at the moment about PBBooking v4 so it’s high time a put out a blog post about it.
Earlier this year I made some rash promises to another developer about implementation of other payment gateways including some country specific gateways and on-site payment gateways (you know who you are). I say rash, because after spending way to much time trying to implement these modifications without breaking the rules of semver I realised it wasn’t going to possible.
That paved the way for bumping what was previously going to be versioned as a 3.2 release to 4. It also opened the flood gates to a whole heap of other requests I had been delaying implementing until I could comfortably break backward compatibility.
At the moment I am down to about 42 tracker items that need to be addressed before I can release a 4.0 update. These include writing user tests and documentation. I have set myself an ambitious goal with the 4.0 release is to have:
I have found that part of the slow turn around with releases other than patch releases was that only 50% of code was tested automatically. The remaining testing was done manually and updating a Google Form.
For the two users that have been incredibly patient on their feature requests, thank you! I am happy to confirm that changes you requested have been implemented and will be included as part of the final 4.0 release.
This is a question I get a lot so I thought I’d take the time out to do a proper table showing the differences.
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.
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
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:
This module has the following system requirements.
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.
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:
Version 3.0.0 has also seen a number of other improvements including:
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