My Contact Form
Location: Cleveland, Ohio
Occupation: College Information Technology Instructor
- Learned FORTRAN in (OMG) 1970, and did my first Family Tree-related programming in Fortran in about 1976.
- Wrote my first PC genealogy software with QuickBasic for 8-bit CP/M machines in the early 1980's. (I used essentially that same application, with static charts copied to the web, until I started using TNG in 2013!)
- Ph.D. Dissertation dealt with MUMPS programming language (now known as M or Cache').
- Used MS Basic family of languages (esp VB Script/ASP) in the '00's.
- Learned PHP after I bought TNG in August, 2013.
My Mod Manager Compare mod installs a utility that lists mods on a site.to list the published
- My public mods.
(I would have said "published mods", but some of the mods that are meant to be published don't have Wiki articles yet.)
- Other mods that I use.
I have added the suffix "-RR" to mods that I have tweaked. I occasionally change the functionality a bit, but most of the time, all that I have done to these mods is to
- Insert %author tags, and
- Add comments around insertions so that I can easily see which mod inserted each new block of text in each file, and,
Neither list provides good summaries of each mod's purpose. To find out what a mod does, you'll need to follow the link to the mod's Wiki article.
The Inner Mod Menu
The "Inner Mod Menu" is a drop-down menu that I now place at the right end of the standard TNG Inner Menu of Admin programs that are significantly affected by my Admin Mods. It is created by new and updated mods published after 1 August 2019.
The Inner Mod Menu drops down from the label "Mod Information". Here is an example of the Inner Mod Menu in the Places Search program, admin_places.php, which has been affected by three of my mods.
For each mod, the Inner Mod Menu may contain up to four hyperlinks; to:
- The mod's Wiki article
- The Wiki article's "Mod Options" section
- The options editor (typically at Admin>>Setup>>General Settings)
- The link from the Inner Mod Menu opens the Generally Settings form to the subform that contains the mod's options, and, significantly, displays only that mod's options. The rest of the subform can still be opened from the links in the heading of the subform.
- The program's Help File, opened to a section that describes what the mod has changed.
Links 2 and 3 exists only if the mod has options, and link 4 exists only if I have created such content in the program's help file.
New General Settings Subform
I no longer use mod parameters, which are options that are updated through the "Edit Options" button on a mod's row in the Mod Manager list.
Instead, all mod options in my new and updated mods (starting in August, 2019) put their options in admin_genconfig.php (Admin>>Setup>>General Settings). I have enough mods with mod options that I have defined a new subform named "Robin's Mods" to admin_genconfig.php. In the "Robin's Mods" subform, the options for each mod are separated in bordered groups, and are alphabetized by mod name.
The mods with options at Admin>>Setup>>General Settings>>Robin's Mods also implement two new query-string parameter in admin_genconfig.php
- open specifies a subform to be opened automatically, and
- mod specifies a mod (within the "Robin's Mods" subform) to be opened automatically.
Thus, for example, the "Edit Mod Options" link in the Inner Mod Menu of admin_editcemetery.php (Admin>>Cemeteries>>Edit) is
and when you follow that link, you will see only the options for the Admin Cemetery Edit mod:
Even with a single mod open in the "Robin's Mods" subform, if you click on the Robin's Mods heading, the program will open all of the options in the subform. The options are grouped and labeled by mod name, so that they look like this:
TNG System Variable $rrconfig
Whether they are implemented by native TNG code or through mods, all options in the Admin>>Setup screens serve as "TNG System Variables". In particular, the options at Admin>>Setup>>General Settings are saved in TNG system variables in the configuration file genconfig.php, and are loaded into every TNG program. Many of the native options are saved in scalar variables (e.g. $database_host, $database_name, $people_table, $families_table), and several are saved in the array $tngconfig (e.g. $tngconfig['showbookmarks'], $tngconfig['personprefix']).
All of the mod options in Admin>>Setup>>General Settings>>Robin's Mods are saved as system variables in the array $rrconfig.
How These New Features are Implemented
The Inner Mod Menu and the structure for mod options at Admin>>Setup>>General Settings>>Robin's Mods are implemented by numerous mods, using PHP Include files that must then be shared by multiple mods and multiple programs.
The necessary include files are in a mods subfolder named robin_modadmin_shared_subfolder_v184.108.40.206 (for now; new versions will, of course, have new version numbers). That subfolder is zipped into each mod that uses either feature.
When you unzip a mod that contain the shared subfolder, or copy such a mod to the mods folder, you may see a message warning you that the subfolder already exists. You can ignore that warning, and can overwrite the files or not, since all all files with that subfolder are exactly the same in all mods that share that subfolder.
Note that the Mod Manager "Protected Flag" that was implemented in TNGv12 now allows multiple mods to install the same files. In brief, when a mod applies the Protected Flag to a file that is installed (i.e. copied to a TNG folder) by the mod
- Before and during mod installation, if that file is already installed, no error message is generated, and the installed file will not be overwritten, and
- When the mod is uninstalled, the file is not removed from the TNG folder.
Mods That Use These New Features
The Inner Mod Menu and mod options at Admin>>Setup>>General Settings>>Robin&quo;s Mods are implemented by mods that I modified or created starting in August 2019. As of August 16, only three updated mods with these features are available, and two of them are Beta test versions:
|Mod Name||Mod Version||Has Mod Options||Inner Mod Menu|
|Admin Cemetery Edit (beta)||v9||Y||admin_editcemetery.php|
|Admin Places Search (beta)||v4||Y||admin_places.php|
Several other nods are essentially ready for beta testing (and may be available by the time you read this)
|Mod Name||Mod Version||Has Mod Options||Inner Mod Menu|
|Admin Cemeteries Search||v9||Y||admin_cemeteries.php|
|Admin Media Predefined Search||v5||Y||admin_media.php|
|Admin Media Search||v11||Y||admin_media.php|
|Admin No Frameset (new)||v1||Y||(none)|
|Admin Places Date||v3||N||admin_places.php|
|Admin Places Geocode||v4||Y||admin_geocodeform.php|
|Admin Reports Search||v4||Y||admin_reports.php|
|Regroup Person Profile||v18||Y||(none; an end-user program)|
|TextPlus Charts||v16||Y||(none; an end-user program)|
Unpublished Mod Upgrades
What can I say? Even after an upgraded mod .cfg is finished, it takes some time to test the mod and update its Wiki article, and I don't always do everything when I should. If you want to use the new version of a particular mod, let me know, and I'll prioritize that mod.
- Add Name to PersonID v220.127.116.11 - works in TNGv12.0.1 and TNGv12.0.2
- Admin Media Search 18.104.22.168 - changes the missing thumbnail message, and handles medialinks to Citations (which are new in TNGv12)
- Admin Places Date 22.214.171.124 - Changes the database definition of the Creation Date timestamp so that
- The database stores a timestamp if a value is not provided, but
- Programs such as the Gedcom Import can provide a value that is constant for all records created in a batch.
- Admin Thumbnails 126.96.36.199a - Small improvements, but I'm having terrible problems with the thumbnail process, both with the native code, and the code affectedby my mod.
- Admin Users-More 188.8.131.52b - Fixed a bug that prevented the program from handling sort by the home tree in a user record.
- Branch Timestamps 184.108.40.206 - No functional changes.
- Updated the cust_text.php search strings & author tag
- Renamed the files installed by this mod to have the common prefix rrbranch_timestamps_
- Cemetery Edit 220.127.116.11c - No longer automatically displays the Placename Lookup & Copy Widget for new cemeteries & Fixed a bug that prevented the Placename Lookup & Widget from setting the State or County in some cases.
Several other mods have changes that aren't fully tested.
Mods in development
Please let me know if you see something that you would like for me to prioritize.
|Admin Places Copy||Copy certain fields from one TNG site (for example, a production site) to another (such as a development site). This is not the same as, backing up the table on one site and then loading the table on another. For instance, it lets you keep non-empty values, or only copy values that are not empty.||Working fine for me; just needs a Wiki article|
|Place Name Format (upgrade)|| Upgrade to Place Name Format that
|File Browser||Browses through TNG files & folders, displaying descriptions of them based initially on the appendix.html file that is supplied with TNG releases.||Working prototype|
|Places Topdown Search||tweaks the end-user Places report to explain what "Localities" are.||Working prototype|
|Track Relatives||Uses a variant of ajx_labels.php to count all relatives (not just descendants) of a person by generation.||Had a working program; I may have trouble finding it. Not implemented as a mod|
|Browse Branches Restricted||In browsebranches.php, shows only those branches that the user has rights to. Searches for partial match in branch ID and in branch name separately. Also shows full branch membership count, not just count of records the user can see. Still only lists records the user can see.||Incomplete|
|Snapshot||Saves snapshots of database counts into two snapshot tables, to provide a historical record of the growth of the database. For now, the Gedcom Import Monitor mod takes a bit of a snapshot when a Gedcom file is imported.||Barely started|
|Events Table||Store primary built-in events into the same table as custom events to facilitate analysis. It's awkwardly challenging, for example, to write a query that looks at all burial events, especially if citations and notes are involved. I don't know yet whether this will wind up being a brand-new table for analysis only, or whether I can add built-in events to the existing events table and flag them so they are not misinterpreted as custom events.||Conceptual|
These are templates I use in web pages, whose names I keep forgetting:
- V12_cust_text - Goes at the top of TNGv12 mods to remind users about the need to upgrade cust_text.php files.
- construction|notes - Hard to believe that I forget this one, but I keep trying to capitalize the C, and forget the parameter name.
- RobinInstallationBoilerplate - A template that I use to display standard installation instructions in three subsections under a single "Installation" section. If the mod just has a .cfg file without a subfolder or related .cfg files, I say so. Otherwise, I add a message describing the subfolder or other .cfg files. See, for example TextPlus Charts#Installation.
Wiki Pages Under Construction
- Incorrect Living - SQL queries that look at Living flags that might not be correct
- lots more...
TNG Technology Notes
Each of the sections below is derived from an email message or TNG Community posting. They could become Wiki articles some day.
MM Comparison Report Notes
Double Toggle Example
The Code Inspector
Colors in TNG Search Programs
Document.ready and striping
What is GEDCOM?
GEDCOM is a formal technical standard whose stated purpose is
- "to provide a flexible, uniform format for exchanging computerized genealogical data".
The name "GEDCOM" is an acronym for GEnealogical Data COMmunications. GEDCIN is
- a data and file format,
- a description of genealogical data elements and structures, and
- a specification that maps those genealogical elements and structures to the file format.
As a consequence, GEDCOM also provides (or serves as a) Genealogy Data Model
The GEDCOM standard was first formalized in 1985, and when GEDCOM version 5.5 was released in 1996, it did such a good job of incorporating the data elements of current genealogy software that some widely-used genealogical software packages used GEDCOM files as their core data/database files.
Amazingly, although the features of (and data elements within) genealogical software packages have changed considerably since 1996, GEDCOM 5.5.1 (dated 2 Oct 1999) is the "current" version of GEDCOM'. (There is a draft GEDCOM 5.6 standard, from 2000, but it ventured into XML as a file format, and never gained anyt traction.). Though the current GEDCOM standard is almost 20 years old and is far from perfect, it is very widely used, and it is essentially "all we have."
GEDCOM File Format
The GEDCOM data/file format is strictly text-based:
- One GEDCOM file contains all of the data records that represent what we generally think of as a "family tree".
- Records are organized hierarchically. For instance, a "Person" record contains multiple "Event" records (Birth, Death, etc.), which contain "Date", "Place", and "Source" records, and so on.
- GEDCOM records consist of
- A line of text that consists of three space-separated elements:
- An integer "level number" that identifies the record's place in the record hierarchy.
- A short "Tag" (essentially a record type), and
- A possible tag value whose nature depends on the tag)
- and all subordinate records, defined on subsequent lines with larger "level numbers"
- A line of text that consists of three space-separated elements:
- GEDCOM tags are generally no more than 4 characters long
- Some tag values essentially serve as attribute names (CITY, CTRY, PHON, AGE, NAME, SEX)
- Some tag value are analogous to relational record types (INDI-individual person, FAM-family, OBJ-media object, etc.)
- Long data values and textual data values that may contain end-of-line characters are broken into records that extend the value that was started in their parent record or in the previous record.
- The top level of the hierarchy is level zero.
Overall, a GEDCOM file consists of
- A zero-level HEAD record that describes the file itself; filename, date, copyright, gedcom version, language, etc.
- A zero-level SUBM (submission) record that indicates who or what created the file, and that can describe the number of records or generations in the file.
- The data itself - in a series of zero-level data records (each of which contains the appropriate subordinate records)
- A zero-level TRLR record that simply marks the end of the file.
GEDCOM Person Record
Each person (which GEDCOM calls an "Individual") is defined in a zero-level GEDCOM record, with, of course, all necessary subordinate records. n a GEDCOM file is Here's a hypothetical GEDCOM excerpt of a single zdescribing part of my grandmother's genealogy record. I've indented the text lines lines to illustrate the hierarchical structure, and added colored, italicized text as documentation.
|0 @I4526@ INDI||Level 0 INDIvidual record - person #I4526|
|1 NAME Ida Marie /HAZLET/||NAME fact. Last names are typically marked with slashes|
|2 SOUR @S41@||Source #S41 supports the Name fact|
|1 BIRT||Birth event|
|2 SOUR @S77@||Source #S77 supports the Birth event|
|3 Page 112||Info about her birth is on page 112 of the source|
|3 DATA||Relevant quote from the source|
|4 TEXT Birth date: abt 1899||The beginning of the text|
|5 CONT Birth place: Iowa||The quotation continues|
|5 CONT Residence date: 1915||The quotation continues|
|5 CONT Residence place: Eden||The last line of the quotation|
|3 OBJE @M3349@||A media object associated with the Source (and the birth, and the person)|
|1 SEX F||Sex fact|
|1 EDUC Harper College||EDUC event|
|2 DATE FROM 1920 TO 1923||The duration of the education event|
|2 PLAC Harper, Harper, KS||The place of the education event|
|1 OBJE @M502@||Media object #M502 (probably a photo) is tied to this INDI record|
|1 FAMS @F1513@||She is one of the spouses in Family #F1513|
|1 FAMC @F2324@||She is a child of Family #F2324|
|0 @I43@ INDI||The INDI record ends when the next Level 0 record starts|
The actual complete GEDCOM record for my grandmother in my last extract was 266 lines long, and included birth, death, and residence events, plus additional source and media object references. But really, that additional length doesn't add to the complexity of the GEDCOM file; just to its volume.
- An overview of how GEDCOM files are used, from FamilySearch.org,
- A discussion of GEDCOM quirks called A Gentle Introduction to GEDCOM
- A more detailed look at the GEDCOM format,
- A multi-page GEDCOM tutorial,
- The GEDCOM Wikipedia article, and
- The GEDCOM v5.5 standard, which is NOT a good tutorial, but is a useful reference.
You can also review any GEDCOM file (you'll find plenty on the Internet) by opening it with a text editor or word processor. GEDCOM files are certainly not primarily written for human eyes, but they are structured text files, and it's pretty easy to understand them in small pieces.
GEDCOM Media Record
A media item in the GEDCOM file is represented by a set of lines that might look similar to the examples just below. Here is a hypothetical media record from an Apple MacIntosh environment. The record starts at level 0 with a OBJE (for media object) line, and contains 7 additional subordinate lines (all at level 1).
0 @M232@ OBJE 1 FORM jpg 1 FILE ~/Documents/Documents/Genealogy/Roger/ReunionPictures/photos/people/RogerOval.JPG 1 TITL Roger Moffat 1 NOTE Taken at the time of Kurt and Ann Christensen's wedding - 2 March 1996. 1 _TYPE PHOTO 1 _PRIM Y 1 _SIZE 147.000000 193.000000
Note, in particular, the FILE line, which contains a fully specified filename, with its complete path on the Macintosh PC.Here's the beginning of a comparable media record from a GEDCOM generated on a Windows PC. The only significant difference is that the PC GEDCOM (not surprisingly) uses Windows syntax to specify the filepath and filename.
0 @M232@ OBJE 1 FORM jpg 1 FILE C:\Users\me\documents\gene\photos\people\RogerOval.JPG ...
GEDCOM data model (part 1)
(BTW - GEDCOM isn't supposed to be a data model, and many people will tell you that it isn't one. But the GEDCOM standard defines data structures for essentially genealogical concepts such as "events", "source citations", "people", "families", "sources", "repositories" (and more). For all practical purposes, those definitions ARE a data model.)
GEDCOM has six fundamental genealogical object types, which are identified by their record tags, and by a letter that prefixes their record ID:
- People, that is, "Individuals": INDI (I)
- Families: FAM (F)
- Data sources: SOUR (S)
- Repositories: REPO (R); places where data sources are held, such as libraries.
- Notes: NOTE (N)
- Media objects: OBJE (M). Generally, OBJE records simply describe media files.
Records of these six types are called "level zero" records, because they all start at level zero in the record hierarchy. In level-zero records,
- The tag comes after the tag value, not before, and
- The tag value is a record id, which is numeric except for an initial letter that identifies the object type.
(Actually, in GEDCOM files, record ID's are always wrapped with @-signs.)
INDI and FAM records are quite similar. They consist primarily of
- Level 1 "Event" records, in which the tag (NAME, BIRT, DEAT, OCCU...) represents a particular "event" or "attribute" (Name, birth, death, occupation...).
Event records typically contain subordinate level 2 records that specify
- A date,
- A place,
- Source citations that can occupy several levels,
Event records and their subordinate records can also contain NOTE and OBJE records, which are typically just references to zero-level NOTE and OBJE records. For instance, if hich can be multiple levels, themselves)
- SOUR, REPO, AND OBJE records are, for the most part, not really hierarchical. That is, they consist mostly of level 1 records that provide specific attributes such as source name, source title, source author, repository name, filename, file type, etc.
- NOTE records just contain a value that is continued on subordinate level 1 CONC and CONT records.
are simply broken into chunks with CONT and CONT records. always and only consist of CONC and CONT r
- A level 2 DATE record such as "2 DATE 15 Jan 1832",
- A level 2 PLAC record such as "2 PLAC Chicago, Cook, Illinois, USA"
- And often one or more level 2 Source Citation records that occupy multiplesource citation
The GEDCOM standard was developed and is owned by FamilySearch.org, a service of the Church of Jesus Christ of Latter-Day Saints (the Mormons). Its latest version dates to the 1990's, and is far from perfect, but it is very widely used, and it essentially "all we have."
Each line in a GEDCOM file starts with an integer number (typically less than 10) that represents that line's level in the hierarchy. Each line also has a record type keyword (INDI for Individual, EVEN for Event, DATE for date, etc.) known as a "Tag". A GEDCOM "record" consists of a line plus any subordinate lines - i.e. subsequent, contiguous lines that start with larger level numbers.