This project is not covered by Drupal’s security advisory policy.

Abstract

This sandbox project is about providing custom entity types for storing genealogy records for individuals (INDI records) and their (family) relations (FAM records) closely modelled after the GEDCOM spec. Goal is it, to be able to import a GEDCOM file containing a family tree and have a genealogy database with proper storage and presentation.

Change history

4/28/17 Kick off
Basic INDI + FAM records
Events still stored as fields in INDI/FAM record
GEDCOM file import
7/4/17 Refine data model
Added GEDCOM Events and Facts infrastructure
Added basic Notes to INDI, FAM, Events, Facts
Module strings are all English now. German translation added

Update path on code changes

Things are still changing too fast to provide an update path for every change I make. Until the data structures have not fully settled, there may be even minor changes that make it necessary to perform a full uninstall/install cycle, so be aware that this project is still in the beginning.

Personal objective and motivation

My personal objective is to create a family website where the presentation of a family tree (provided by a GEDCOM file) is one part among others, so until this is done, I can't really afford to make this module a full fledged genealogy module.

This is also my very first Drupal module and after going through the pain of learning PHP, Drupal and trying to figure out where to get all the information needed, it was/is a lot more fun than I thought.

Data model and implementation details

First stab at data structures for a Drupal 7 based Genealogy site proposes a data model of how to implement genealogy data structures in Drupal and was important as guidance how to do things.

What has settled already?

This module tries to stick close to the main record descriptions of the GEDCOM spec in terms of data modelling. There is one entity type for INDI records (GCIndi) and one for FAM records (GCFam).

However, the similarity in structure of what's called Event and Fact or Attribute in GEDCOM led to an implementation where the different event types and fact types are represented in one entity type called GCAttr, that uses bundles to distinguish the differences.

Thanks to the great inline_entity_form events/facts can be edited inline. But being implemented as 'complex' inline entity forms means, that you have to click on "edit" for each item that you want to edit. Since this affects editing only, this is something I can live with.

All types (INDI, FAM, all Event/Fact bundles) are fieldable. However the GEDCOM import will not handle added fields in any way.

What is incomplete and needs more work?

GEDCOM Notes are not complete yet. For now they are implemented as 'string_long' fields with a 1:n cardinality and do not have the ability to reference GEDCOM Source information.

Since GEDCOM Notes can appear in events and events are presented as 'complex' inline entity forms, I haven't figured out, if and how it works when using nested inline entity forms.

What hasn't been touched?

The following list gives an overview of what has not been touched in terms of GEDCOM structures (records or record fields) so far:

  • Multi media records
  • Repository records
  • Source records
  • A couple of organizational fields like RIN and so forth
  • No support for _UID identifiers

Installation

Installation is best done with composer as this module depends on skypal/php-gedcom which is my slightly modified version of mrkrstphr/php-gedcom.
Replace GEDCOMTEST with the name of where you want to install the D8 test site.

composer create-project drupal-composer/drupal-project:8.x-dev \
  GEDCOMTEST --stability dev --no-interaction
cd GEDCOMTEST
composer config repositories.sandbox \
  vcs https://git.drupal.org/sandbox/skybow/gedcom.git
composer require skypal/php-gedcom
composer require drupal/search_api
composer require drupal/gedcom

After that you might continue with installing via browser. If you prefer quick testing with SQLite, as I do, you can continue with the following (which requires drush):

cd web
drush site-install standard -y \
   --account-mail=you@example.com --account-name=admin --account-pass=secret \
   --site-mail=you@example.com --site-name="GEDCOMTEST" \
   --db-url=sqlite://sites/example.com/files/GEDCOMTEST.db
drush en -y gedcom

After that you go to http://example.com/admin/config/gedcom/import and start with importing your GEDCOM file. Results can be viewed in http://example.com/admin/content/gedcom/indi. Happy exploring from there...

Make the family tree searchable

There is a submodle gedcom_search_demo which demonstrates how to integrate searching the GEDCOM entities using the search_api module. This has not been updated to the 7/4/17 release.

Notes on identifying INDI/FAM records during (re)importing

INDI and FAM are distinct entity types with distinct ID domains. Therefore it is possible to use the @INDI@ and @FAM@ IDs in a GEDCOM file as IDs for the entities themselves. When a GEDCOM file is imported again, existing records will be loaded and changed.

As mentioned above, the INDI._UID field is not (yet) supported.

Where to go from here?

  • Reworking the Notes handling
  • Extend the data model to support the missing GEDCOM data types
  • Exporting back data to a GEDCOM file
  • Adding more fancy stuff like visualising relations between individuals graphically

Credits & Links

Project information

  • Created by skybow on , updated
  • shield alertThis project is not covered by the security advisory policy.
    Use at your own risk! It may have publicly disclosed vulnerabilities.

Releases