WordPress for Genealogy: Adding a Lineage Snapshot Box to Blog Posts About Ancestors, Part III

This is the third and final part in the series on my process for creating the biographical profile box (what I call a Genealogy Snapshot Box) that I attach to each blog post about a particular ancestor or relative on my family history blog [see Figure 2].

This Part III works for self-hosted WordPress.org-run sites, as well as hosted freemium WordPress.com and hosted free Blogger sites. 

If you need to get back up to speed, or start from the beginning:

1. Part Ia: Adding a Lineage Snapshot Box to WordPress.org Blog Posts About Ancestors — How to create the container, style it, and populate it with data.
2. Part Ib: Adding a Lineage Snapshot Box to Ancestor Posts in WordPress.com & Blogger — How to create the container, style it, and populate it with data.
3. Part II: Adding a Lineage Snapshot Box to WordPress.org Blog Posts About Ancestors — How to populate and update all posts about a particular ancestor, from a one-stop code block library.

The Master Library File

In my Part II post, I explained that I maintain the actual Genealogy Snapshot Box markup (the code that populates the box fields and data) in an external text file (.txt), and then copy and paste from that text file into the appropriate block of the Global Content Block for that particular ancestor. Those on a WordPress.com or Blogger site can copy and paste right into the text or HTML view of your blog post WYSIWYG editor — you just don’t get the ability to reuse one single code block, or update all posts from one single code block when modifying data, such as a newly discovered parent, spouse, or child.

As a reminder to those using the Global Content Blocks plugin, the code that displays and styles your Snapshot Box should be kept in your child theme’s custom functions and custom style sheet (see Part Ia). The external text file I refer to in this post is simply for the data inside of your Snapshot Box.

During my normal blogging workflow, when created a Snapshot Box for a new ancestor or updating an existing one with new information, I keep the Snapshot Box code library file open next to the browser in which I am writing my blog post [see Figure 1].

One File to Rule Them All

I use one single (very long) text file to store every single Snapshot Box block for each individual ancestor or relative [see Figure 3]. Initially, I played around with creating a separate text file for each main (paternal) surname, but I just found it more efficient and convenient to save everyone to a single text file.

At the top of the file is a template (empty shell) code block that I can copy and populate with data when creating a Snapshot Box for a new ancestor.

After that, each ancestor block is arranged in alphabetical order. First by surname (always the primary paternal surname), and then by given name(s).

Each surname group is separated by surname header. I apply a standard naming convention to each surname header (“SNAPSHOTS: SURNAME”).

Searching the Really Long File

Maintaining every code block in a single text file might seem like it could get unwieldy, and might make it difficult to find the desired ancestor. My computer’s regular Find feature (Cmd + F on a Mac, Ctrl + F on a PC) allows me to quickly search through this text file for a particular surname group or a particular ancestor.

Because a single ancestor’s name often appears multiple times throughout my Snapshot code block library, I find it more efficient to search first for the proper surname group [see Figure 4], and then scroll down through that group until I find the right ancestor. Why might a single ancestor appear multiple times throughout the code block library? While each ancestor only gets one Snapshot code block, that same name may show up as the spouse, parent, or child for another ancestor’s Snapshot block. And then there are those identically named ancestors.

Cloud Storage + Version Control

Because I invest so much time into creating, updating, and maintaining my Snapshot Box code library, I am very particular about making sure this file is backed up every time I modify it. I also want to be able to retrieve previous versions of that same file. And because I blog from multiple computers, I keep that backed up file in cloud storage instead of just my local hard drive.

GitHub Version Control

My backup + version control tool of choice for this process is GitHub. If you aren’t familiar with GitHub, it is a cloud-based distributed revision-control and collaborative source code management system. GitHub might be overkill for this particular use case for many of you. However, since I use GitHub for ALL of my coding activity, it makes sense (for me) to stick with a tool that integrates into my everyday web development workflow.

One of the key reasons I use GitHub as my version-control tool of choice for all code (versus something like Dropbox) is the ability to check-in (commit) every single new piece of code and every modification to an existing piece of code, and to be able to annotate each check-in with a meaningful note to myself [see Figure 5]. I have learned from years of mishaps that it is not simply enough for me to keep different versions of code each time I modify it. I need to keep good notes explaining exactly what I changed and why I changed it.

While tools like Dropbox and Google Drive have some form of version control, one cannot attach meaningful notes as metadata to each revision (that information would have to be entered into the actual text file itself). GitHub shows me a clear history, with a clean reverse-chronological display of that valuable metadata [see Figures 5, 6, and 7].

Other Solutions

If something like GitHub is indeed overkill for your needs, Dropbox or Google Drive can still work nicely for a cloud storage solution with version control.

Regular readers know what a big fan I am of Evernote, and how much I integrate it into my daily productivity and information management workflows. However, I do not use Evernote to store raw source code. While it is incredibly handy to clip snippets of code I find elsewhere (for reference), I have found that actual raw markup sometimes does not copy cleanly from Evernote notes.