iainkirkpatrick
commented
4 years ago This is tricky with the current site architecture - when social media sites attempt to generate preview content for a post, they look for specific Open Graph <meta> tags in the initial HTML served by the site server when they access a particular URL (i.e. https://rightstracker.org/en/country/NZL?as=hi). In our case, we have a single (minimal) initial HTML file that is served for all our relevant URL's, and Javascript subsequently loads on the user's browser to populate that HTML with all the content that we eventually see per page. That single initial HTML file currently just has the generic content (title, image etc - i.e. https://rightstracker.org/hrmi-og.png) built in.
So what we want is some way for our server to respond with a specific HTML file with relevant Open Graph <meta> tags when specific URL's are requested by the social media sites. There's a couple of ways we might go about this:
- either a server-side-rendered or statically-generated approach, in which the initial page is completely built on the server and sent to the user's browser, and subsequent requests are handled by JS in the browser. This is an approach quite suited to the type of site the Rights Tracker is (mostly static data), but could be a lot of work (though there are potential speed and other benefits from this which I've been thinking about, keen to talk about this at some stage)
- we figure out which pages in the site need their own social media preview content, and manually generate HTML 'shells' (similar to the single
index.htmlwe currently use) that are served for those related URL's (i.e. https://rightstracker.org/en/country/NZL?as=hi would send back a custom HTML page with NZL-specific<meta>tags). This is just a bit of manual work, but how much depends on how many pages in the site need their own content - is it just the 200-ish country pages? - we use an approach which isolates requests from social meda sites, and serves them a very minimal HTML page that basically only has
<meta>tags needed to generate the previews. I used this approach for https://gwrc.2050calculator.nz/calculator where there was a similar need for custom content for sharing - see here for the server code, and here for the kind of redirects to facilitate that. The Rights Tracker currently uses a node server, which means this approach should be doable (though IMO a server doesn't seem to be necessary, and this approach would 'lock in' using a server), as long as the preview content can be accessed by the server when a page URL is requested (which I'd assume it can).
I realise that's probably a lot to parse... basically I'd probably suggest option 3 might be the easiest in the short-term, but ideally IMO we'd move to option 1 in the future (but probably as part of a larger piece of work towards not using a node server and pre-building all the pages). I'd estimate around a day's work to get it going (so 6-8 hours), depending a bit on which pages need custom preview content and what that content is, and how Firebase handles redirects (I haven't looked into that yet).
annemariebrook
tmfrnz
Currently the site only produces a generic preview and the dedicated preview image is sometimes not showing.
Meta/preview information (title, description and image) should be dependent on the specific page