In part one I got the basis of the plugin in place. Now I actually made it usable (because I hadn’t even put a contact form on it initially – d’oh!) and added features/docs that mean it could be installed anywhere.
Three ways to book
When it comes to booking, there were various different options that I could foresee and I wanted different site owners to be able to choose how they wanted to handle it:
- No online booking (the default — safest thing to ship without anyone opting into anything). In this case the room sizes/facilities/availability diaries can be seen, but there’s no way to interact with them. The site owner might leave an email or phone number to contact them.
- Visitors can request a time but booking process is manual — Includes a proper week-view calendar, tap a start time then an end time, short name/email form, and submits through the exact same
scrb_request_booking()the REST API always used. None of the pending/confirmed workflow or the email notifications needed to change at all — this only ever added the bit of front end that was missing. The calendar was provided by FullCalendar JS. - Send visitors to a third-party site — Just a booking link field per room, with “Book now” button that opens it in a new tab.
Shortcode, block or button?
I provided a couple of shortcodes: [sc_rooms] and [sc_room id="123"]. The former lists all the rooms that are currently available in a grid format and the latter just picks out one room (by ID) and displays the full room details. There are a couple of options on sc_room to narrow by room type and number of items displayed.
Of course I can’t always rely on the user to remember their shortcodes (even I don’t remember them!) so to make them a bit more user friendly I added a button to the TinyMCE editor which opened a little dialog box to generate the shortcode.
And finally… I had to cater for the Gutenberg block editor: There are two new blocks added: Room Listing, Room Detail. Both of these blocks are dynamic/server rendered and their render.php calls the same functions that the shortcode uses. Easy! So the block and shortcodes will not deviate.
Techie note…
Getting the blocks to look right in the editor was a bit fiddly: The blocks were rendering too wide for the rest of the page editor, so somethings to look out for in Gutenberg are:
- If your editor preview has zero styling, the stylesheet may only be enqueued on the FE.
render.phpneeds to add thewp-block-*wrapper because a dynamic block’ssave()returns nothing- editor’s own width-constraining rule only kicks in once a theme declares
add_theme_support('editor-styles'), which mine didn’t.
The payment question
So once we have our booking form, the next question is “should this also take deposits?”. Well… For now the answer is “no” I’m afraid. There are other built in options of course; the site owner can elect to point to a third party booking link (Eventbrite etc.), but given the amount of extra work picking a provider, refunds, cancellations, eek! It’s a substantial undertaking.
That’s not to say it’s been ignored. The plugin has been built with this in mind as a (hopefully not too distant) future development: there are admin email templates ready to use, custom post statuses like “payment pending”, “paid”, and wiring up basic PayPal payments is not too tricky. It’s the human admin side of things that’s going to take a bit of thought.
Does it actually work outside our dev themes?
This was originally built for two websites that runs Sage/Acorn which owns the whole template hierarchy. What happens on any other site? I built a second, deliberately boring WP install with a plain theme and dropped it on there to see what happens. Thankfully it all worked with no issue at all.
The plugin was able to take over a single-[room name] post type template and output the desired room info.
Teaching the plugin to update itself
Techie note…
If you want to build a plugin yourself, this bit might be really useful for you!
This plugin is not going to be hosted on WordPress.org because I’d like to try to make some money from it! WordPress core’s “Update available” notice only ever checks against WordPress.org. So without doing anything, wp-admin has no idea a new version exists.
To fix this, a vendored library (Plugin Update Checker, no build step) pointed at my GitHub repo instead of the .org API it normally expects. Wire it up on init and every site gets the completely normal “Update available”.
The gotcha, which I’ve actually been bitten by: it checks the repo’s tags, not the default branch. A finished commit on main is invisible to it. The release step is just git tag -a vX.Y.Z -m "vX.Y.Z" then push the tag. The library just pulls the tagged commit’s source archive straight from GitHub.
Final thoughts
Where to go from here? Well the obvious one that I’m already working on behind the scenes is to allow holding deposits to be taken on the rooms. I think this is critical to making it a really really useful plugin. There are smaller ideas in my brain like recurring bookings, and where else this could be used that’s NOT actually a room! In theory any appointment could work? Does that deserve it’s own plugin or an extension of this?