calendar: Fix Open Graph tags for better social sharing of ride links

[carrythebanner]

New ride links do work when shared to Facebook etc. but we can tidy up the Open Graph tags to pull in a better preview.

[fool]

I think all we need to do is add Open Graph tags to pages. As an MVP we add one to the theme, that just uses the shift logo, which will work for every page on the site. This might do the trick (untested, generated from an online tool):

<meta property="og:title" content="Shift">
<meta property="og:site_name" content="Shift website">
<meta property="og:url" content="https://www.shift2bikes.org">
<meta property="og:description" content="Shift’s mission is to promote inclusive bike fun. ">
<meta property="og:type" content="website">
<meta property="og:image" content="https://www.shift2bikes.org/legacycalimages/logos/shift-logo.svg">

Level 2 of this would be to use the page or event title instead of the generic ones.

Level 3 of this would be to use the event image IF EXISTING to replace the shift one. There might be some trivial way to do this like "specify a path whether there's an image or not, and if it 404's it'll fallback to this other default setting", or it might be that we have to embed some logic in the page to check with an API call at serve time but geez let's hope not.

[carrythebanner]

Implemented changes in #165, #166, and #167.

[fool]

still needed, at least:

• should get the real event image if any
• should review the rest of the opengraph tags to see if they could be improved (cf https://ogp.me/ and https://developers.facebook.com/tools/debug/sharing/)

[carrythebanner]

Calendar pages are rendered client-side, but Open Graph tags are in the document head and need to be rendered server-side. There are some possible solutions to serve special data or pre-render some data to crawlers specifically, but it needs some more investigation.

At the very least, we can change the description: "Rides calendar" tag in /site/content/calendar.md to be something a little snappier, as that's what currently appears in as the byline for the shared link.

[fool]

When crawlers and social sharing services visit a netlify (where the calendar is hosted) webpage, Netify returns a prerendered version:

https://docs.netlify.com/site-deploys/post-processing/prerendering/#app

Why is that important? It is a place we could "do anything one can do in javascript on the client side" after the page loads, but before Netlify takes a javascript-already-run snapshot in html, and caches it for a day or two, and returns it to the service in question (twitter, slack, google, facebook, etc).

While that service runs, we can notice that it is running by checking the user agent, since the prerendering service uses headless chrome:

const isPrerender = /HeadlessChrome/.test(window.navigator.userAgent)

to detect we're being prerendered, and then do something like "parse URL, and get needed param to make API request to shift calendar backend": https://api.shift2bikes.org/api/events.php?id=12903 and that returns JSON that could be parsed into better OpenGraph data and "inserted" into the DOM before we allow the snapshot to complete (changing pre-set-to-false window.isprerenderReady to true after the API call and OG tag changing is completed, as described here: https://prerender.io/documentation/best-practices) .

This is pretty convoluted but sounds non terrible to write and implement, parsing the JSON from that API call is the hardest part, and it's not super hard for a JS whiz. Netlify will host the lambda function to do it if we wanted.

[onewheelskyward]

Josh and I are going to pair on this at our next meeting. This would be a HUGE win.

[carrythebanner]

Fixed by #424 and #425.