Adding Events to Ghost?

(The original of this post lives over on my Ghost blog, at Can we add events to Ghost?

I have a (badly in need of update) site over on Blogger. Mostly, I use it to aggregate upcoming STEM (and more specifically robotics) events that are geared towards kids or at least family-friendly, along with some blog posts. I actually store the events over in a public Google Calendar, and then some client-side JavaScript grabs them and inserts them on the Blogger page. It works pretty well on the user side. Events are a smidge slower to load than the rest of the page but it’s not so slow that it detracts from the user experience. On the user side, it’s fine. There’s a custom block on the front page that renders those events, and I pull data out of Google calendar to render events individually (matching the theming on the site) when users click them. [It’s likely terrible for SEO, but that’s a separate issue.]

I can do the same thing with a Ghost theme, or even with code injection. The script that pulls calendar events just needs an API key and the link to the public calendar. But the problem with this approach is that it doesn’t take advantage of the Ghost WYSIWYG editor (which is far nicer than the Blogger calendar event editor), events won’t be searchable (because Ghost itself knows nothing about them), storing images for events is another layer of complexity, and so on. And maybe we do care about SEO for those faked-up event postings that a Google crawler won’t see.

So… I thought I’d get clever and create a tighter linkage. I still wanted to use Google Calendar, to deal with Ghost not having custom data storage and because letting Google deal with some of the complexity seemed like a good idea.

Here was my idea going out the gate:

Post/Event creation:

  • Make a custom page on the ghost site that creates a stub-ish post with the event name, a custom_excerpt, a callout like block of text with time, location, and other calendar-type data, and some custom tags.
  • Make a Google Calendar event with the same id as the Ghost post using all the same data. Set the description to the the custom_excerpt plus the link back to the Ghost post.
  • After both creations are complete, redirect the user to the actual WYSIWYG editor for the new post, so they can add images, rich text, etc.

Post/Event viewing:

  • Users can view event posts on Ghost just like any other post. Events are tagged, so it’s easy to make an “upcoming events” stream, sort of like the “related posts” partial.
  • Posts start out with the original calendar information, but some JavaScript runs on the page to update the calendar bit, if desired. (For example, one could pull in the number of people registered, or anything else exposed by the API.) Everything else is a normal post = good for SEO.

Worth thinking about: Is there a page for updating the Ghost post if the Google Calendar event changes? Or does some JavaScript on the client side pull that information when someone visits the Ghost post page?

I pretty much got everything to proof-of-principle yesterday. Here’s a short summary of what I think of this approach, at this point:

Experience for Site Visitors

  • Everything can look great and loads at normal Ghost speeds. If there’s JavaScript to grab the latest calendar information, it should be minimal enough not to slow things down.

:+1:The site visitor experience is great! (Web crawlers will probably like it, too!)

Experience for “Event Editors”

  • Event editors visit a custom page on the Ghost site and enter basic information about the event. Then they hit submit, which triggers calendar event creation and blog post creation.
  • A standard OAuth pop-up asks event editors to choose a Google Account to use and then to grant the site permission. (I think the permissions request only happens once.) Unfortunately, “event editors” need to give the Ghost site permission to edit all their calendars. [There’s no scope provided for editing just the one public calendar.]
  • Event editors are redirected to the Ghost Admin WYSIWYG editor to finish their event post.

:confused: The process is fine, except for having to give calendar permissions. Perhaps the event editor chooses to make a separate Google account just to manage this event calendar, which resolves concerns about having to give the site permissions to EVERY calendar.

Needing to remember the URL for the event creator is a little clunky, since it isn’t linked from the Ghost Admin pages.

Set-up Experience

  • Create a Google Calendar and make it public. (~2 min)
  • Give any other Google accounts that will edit it permissions (through the sharing feature). (~2 min)
  • Grab the Calendar ID, copy it over to Ghost. (~2 min)
  • Work through Google’s API portal to create a project, get an API key (copy over to Ghost). Give the project Calendar access. Also validate the domain with Google (if not already done - may require DNS access). Link the site privacy policy. Create a YouTube video showing how the app uses the Calendar API if you don’t want the OAuth popup to say your app is in testing mode and requiring an extra click, and submit it for Google review. (~10 min - multiple hours)

:anguished:The only good news is that you only have to do this once. With detailed directions, it might be doable in under an hour. And could one common “this is how this package works” video allow multiple different sites to get their projects approved? Maybe.

So now what?

Would you work through the setup headache for this sort of package? Or would it make more sense to just create and aggregate events from the Google Calendar, without trying to integrate with posts?