Keeping A Family Wiki

Members of my (some of them extended) family recently entered and left life, which is always an opportunity to think about my family. I’ve written before about my own efforts to keep family history in a wiki which is powered by my Family Wiki WordPress plugin (Github).

Every relative gets their own page, like on Wikipedia, just in private. This is why I am also not sharing screenshots, the plugin page has a few fake ones. Here is one screenshot of the editing page though (you can scroll away the bottom when you enter text):

It is not a very elaborate plugin but it was based on a born and died shortcode to create something like a family birthday calendar as well as a generally notable-dates calendar for your family.

In order to add some structure to this, I have now (manually) migrated this metadata to use Advanced Custom Fields through which you’d now not only enter the birth and death date but also parents and children.

With a new [name_with_bio] shortcode, you’ll then receive automatic output like this:

Name (born as Maiden name on January 1, 1900 in Place, died on March 31, 2000 (aged: 100) in Other Place; daughter of Father and Mother; sibling of Brother and Sister; parent of Daughter and Son)

This metadata might make it possible to render a family tree later on, since now the pages are interconnected with each other. Maybe something like this already exists for ACF, I looked a while back and there wasn’t.

Just to recap: my personal mission is to keep stories of my relatives alive, where and what they worked on, who they visited, what adventures they might have encountered. In general: anecdotes, maybe with some pictures. Also, for living relatives, their contact data.

This is why I deem a wiki format to be superior to all those geneaology sites. I don’t value the huge amout of connections to some far-removed relatives that they encourage to build. I care about those that I might have got to know or just missed.

And, having a WordPress blog (network) already, it’s easy to put this on WordPress vs. using a dedicated wiki (and actually it’s quite easy to find cheap WordPress hosting). I had the original versions on a Mediawiki but it was quite a hassle to maintain, now the data is just in a WordPress. Should my plugin no longer work, nothing is lost since the wiki pages are just plain WordPress pages. Some of the nicities will go away but the meat is in the writing.

Oh, and of course a benefit of a wiki is that other relatives can also contribute. In reality, it’s hard to get them to contribute but when they do, they add some details I didn’t know and that’s just worth so much for me!

I can highly recommend to try keeping family history in such a way. It’s a really nice way to pass this on to further generations of your family, and also for my own reference when my poor memory strikes again.

Posted in Web

Mastodon API Tester

tldr: Use the Mastodon API Tester to play with the Client API of Mastodon.

I’ve created the WordPress plugin called Enable Mastodon Apps which does a seemingly small but powerful thing: it enables you to access your WordPress blog using Mastodon apps like Tusky or Ivory. This can be used to browse your own blog and post to it. If you also have the Friends plugin and the ActivityPub plugin installed, this will actually make your WordPress blog behave like a Mastodon instance.

It does this be re-implementing the Mastodon API (unfortunately, Mastodon didn’t opt to implement the ActivityPub client-server API so this is not based on a standard) which can be tricky: it uses REST API endpoints in the (virtual) directories /oauth and /api which are so generic that they are prone to conflicts.

Additionally, although the API is well documented, many apps were created based on assumptions that are true for Mastodon itself (which caused a lot–sometimes hard to reproduce–of issues for the plugin). For example, the id of a post or a user is defined as a string but many apps crash when you put a non-number there. Or that a boosted toot needs to have a different id than the virtual “wrapping” toot (Ivory!). In such cases, apps would crash but work fine with Mastodon itself.

Even more complicated are interactions with other WordPress plugins. It can be hard to understand if the plugin is working correctly, if another plugin is interfering, the hosting provider acts quirky, or if the Mastodon app has an incompatibilty with my implementation.

Thus I have created a simple one-page JS app called Mastodon API Tester hosted on Github pages (source on Github):

I hope that this tool will help identify issues better in future, it can also be used with GotoSocial or a “real” Mastodon instance. Feel free to report issues you might encounter.

PS: the Enable Mastodon Apps plugin will be worked on at the Cloudfest Hackathon, thanks Matthias Pfefferle for taking the lead on this! (Unfortunately, I cannot make it there because I’ll be speaking at WordCamp Asia in Taipei just the weekend before that.)

PPS: Happy Birthday, Matt!