Gramps plugins
Logo Valid HTML 4.01! Valid CSS!

ThomJoy.US

Gramps Plugins



The Gramps project has been producing a linux-based genealogy program for several years now. I have been using it for the last few years to generate my web site and my only real problem has been that I did not like the looks of the default web pages. Being an experienced programmer I undertook to learn enough Python to modify gramps to do what I wanted. Gramps uses a plugin format that allows users to utilize custom modules by installing them in their local .gramps folder. Once you have run gramps from a given linux user account, it creates a .gramps folder in that user's home directory. By simply creating a 'plugins' directory under the .gramps directory, one can install plugins independant of the main installation. My download file, if unzipped from your home directory will place two Python files in the appropriate directory and drop the 'gramps-custom.css' file in your home directory. Simply start gramps and you should see the new reports. Modify and copy the 'gramps-custom.css to your webserver placing it and any needed graphics files in the appropriate areas of your web space.

I have thus far created two plugins. The first, ThomsWeb, was a customization of Don Allingham's NarrativeWeb program:

  • I added a few tags (div tags) to allow more control over the format.
  • I then added a second CSS file to allow me to expand and overwrite the theme files without losing my changes when I upgraded the version of GRAMPS.
  • I added a series of A-Z internal links on the 'Individual' and 'Surname' list pages.
  • Similar links are on the 'Places' page which was reformatted to sort by the city/county/state/country data.
  • Created an 'automatic' download page. By entering a pointer to GEDCOM versions of the database as 'media' and creating a special 'source' record and linking the media to it in the gallery pages, I was able to create a download page complete with files and descriptions.
  • Unless invalid html is embedded in the text areas of your database, the files created all pass W3C's verification tests.
  • Tested with both Gramps version 2.2.6 and 2.2.7.

The second creation, WebCal, is based primarily on the 'built in' plugin named Calendar.py that produces the written calendars, while I borrowed heavily from NarrativeWeb for the user input dialog. This program:

  • Produces a series of calendar files, each named for the month and year for which it was generated.
  • These files along with a style sheet generated by the program are stored in a separate subdirectory one level below that chosen by the user during calendar generation. This is to allow the directory to be separately password protected so that information on living individuals can be shared with family but not made available to the general public.
  • The calendar files for a given year are all cross-linked to each other via a navigation menu along the top of the page.
  • Include the ability to highlight those days with content
  • Print individual notes on each months page
  • More control over general formatting
  • Additionally, I suppress the listing of anniversary dates where I find a record of a divorce or divorce-filing (these are 'events' associated with the family record).

Password protection is provided on linux/apache servers (you are using an apache server aren't you?) via the .htaccess file. This file needs to be copied into the protected directory. Everything below this point should be protected. Additionally you will need to create a password file using the htpasswd command. If you have apache installed go to a terminal window and type

htpasswd -bc filename username password

where you substitute the appropriate terms for 'filename' 'username' and 'password'. This file will have to be stored on your hosting server somewhere. It is common practice to name this file as .htpasswd which keeps it from being directly accessed by a visitor. It also 'hides' the file from normal file access.

The hard part about creating the .htaccess file is that you need to know the 'absolute' location of the password file (as opposed to its location in the web space.) For example, on my home PC my .htaccess file looks like:

  AuthType Basic
  AuthName "Family Only"
  AuthUserFile /var/www/.htpasswd
  AuthGroupFile /dev/null
  Require valid-user

This places the password file outside of the web space, but still readable by apache. It could also be put somewhere under /etc/httpd. On my GoDaddy site the AuthUserFile line looks more like:

AuthUserFile /home/content/t/h/s/thsturgill/html/.htpasswd

which shows what I meant by hard... It took a while to find the documentation as to where the system sees my files.