CVS account

Thanks for the reply Sam. I wouldn't mind taking a stab at porting it to 5.x myself, as I feel that's the next logical step in my Drupal evolution. Do you know where I might start to see what's needed to get it ported to 5.x? Are there any good handbook pages for this? When you say it's not much of a module, what features does it currently have. It mentions being able to import gedcom files. That's a good starting point IMO. I'm probably interested enough to try and take this over as a pet project to learn by coding extra features. Thanks again for your reply.

pyutaros, how about Converting 4.7.x modules to 5.x and Converting 4.7.x themes to 5.x? I know the second one is for themes, but it may prove useful, as well as the first one. There's also the coder module, which helps pin-point some of the fixes.

Well, I added a family.info file to the module's directory. I checked the code against the coder module for an upgrade with no objections. So all I need to do now is commit it so others can download. I suppose the thing to do is to create a patch, but since all I did was create a .info file, I will just upload that and recommend you download it to the family module's directory. As for what the module does at this point, see the module maintainer's comments on this. I'm going to look this module over in the next few weeks and see where I might go with it. I will notate progress by creating new issues as if I make any changes.

I created a .install file from the family.mysql included in the Nov 2006 -HEAD. Caveat downloader; it's been a while since I looked at this file.

Here is a patch against the November 2006 -HEAD that works under (at least) Drupal 5.2. I successfully imported 53 people from .ged file.

Next major needs:

Relationships - viewing, editing, etc
Views - family tree view, ascendency graph, etc.

Yes pyutaros, the steps you outlined should work---if they don't then my patch needs to be fixed =)

After playing with the module last night I see a couple major issues with it:

1) Editing family_individual nodes doesn't work. the family_individual_form hook in individual.inc doesn't appear to be getting called, thought individual.inc is being included.

2) When uploading a GED file, currently it wipes the GED-related tables, but does not delete the relevant node data from {node} and {node_revisions}. That leaves orphan nodes without a module to handle them nor entries in the table that would let the family module handle them!

3) Ditto when you uninstall the module. I haven't found a document saying that it's proper to delete node content on uninstallation, but it seems like that makes sense in this case, at least during development.

4) The relationships aren't showing up when you view a family_individual node. That looks to me like another hook that's not happening.

These hook problems are above my pay grade =) I'll enlist a more drupal and php-savvy developer to look into them, unless one of you figures it out first. Please comment on 2 and 3.

Peter

Okay. I'm going to have to stop for the night. Here's my experience so far with HEAD and the patch.

1. When I first enabled the module, I went to access control. I found the permissions for my site admin group already filled in. This may be because I had previously filled out these when I had my own test version installed.
2. I checked the database and noticed the tables were not created. I had this problem before with the shoutbox module when I had made changes to it and reinstalled. At first, I attributed the error to what I thought were syntax errors in the .install file. I made a patch but this still did not install the tables upon enabling. I have attached the patch anyway, as I still received errors when trying to manually run the code through my phpMyAdmin console. Bear with my elementary questions, as I think I'm on the verge of a breakthrough concerning my Drupal coding knowledge. I looked back at the Shoutbox .install file and noticed it had no Hook_Uninstall implementation. My question is, and I think I know the answer, will Drupal not rerun code from a Hook_Install until Hook_uninstall is rerun? If that is the case, this is likely why the tables were not created. (I should probably spend some time reading some primers on coding in Drupal.)
3. Noticed an error when manually creating tables, so created a patch with what I thought is proper syntax. The tables created fine for my MySQL database once I patched and uninstalled. This may not be necessary. I basically removed some parens and added a semicolon. Review the patch code and let me know.
4. Family is grouped in it's own admin category. Browsing directly to the family category brings up a blank page, however you can access the import and auto privacy tools from the main admin page. I don't think this is a problem, but to remain standard we should probably put family admin functions in standard Drupal categories. At the very least, if we leave it that way, we should enable a page for the family category. I will happily take a stab at this if you agree.
5. No exit link from import. Once you run an import and it completes, you're left at a dead page. I could also put in code for an exit link (back to admin settings / go to your family tree) if you agree with this. I didn't get to auto privacy as I never got an import to work correctly.
6. Import generated errors (warnings about duplicate entries). I can send you the error log for this. Here's what they generally said: * user warning: Duplicate entry '2317' for key 1 query: INSERT INTO family_facts (fid, nid, xref, fact_code, fact_value, gedcom_source) VALUES (2317, 1804, 'I1', 'INDI', '', '0 @I1@ INDI\r\n') in /path/to/my/drupal/installation/includes/database.mysql.inc on line 172.
7. All data that was imported came in labelled as unknown, however the node is titled correctly at the top of the page when viewed. This caused data to display like this:
   Correct Individual Name <== this displays correctly
   Unknown Unknown
   * Father: Unknown Unknown
   * Mother: Unknown Unknown
   Spouse:
   Unknown Unknown
   * Father: Unknown Unknown
   * Mother: Unknown Unknown
   Children of Unknown Unknown and Unknown Unknown:
   Last Name First Name Sex Birth Date Birth Place Death Date Death Place
   Unknown Unknown
   I thought this might have been related to my .ged file, so I tried three different things. First, I uploaded my live .ged file from phpGedView by accident. Then I tried exporting and removing the pguv tags. (Proprietary phpGedView tags) Finally I tried exporting and changing the format from UTF-8 to ANSI. None worked. I will send you my .ged file for testing if you like.
8. +1 to the idea of uninstalling all nodes related to module. At least while still testing. I can try taking a stab at that. It shouldn't be too hard to add to the uninstall if you agree.
9. Don't take any of this as criticism. Am very impressed with what you've done so far and am glad that someone is excited to work on this

I'll make a second post to address your comments from above.
Thanks,
Jonathan

Pyutaros,

RE your first response:

I think that most of your problems (1,2,3,6,7) are due to not fully removing the previous version of the module. Why don't you uninstall the module, remove all your family_indivual nodes and node_revisions, and try installing from my patch again?

I don't think the changes in your patch are a good idea: {foo} in db_query adds the db_prefix and handles mysql vs postgresql etc syntax differences, so you want to keep that. I had semicolons previously but they seemed to be causing a problem.

I'm not experienced with drupal conventions enough to respond coherently to your issues 4 and 5 (admin category and exit link). If it's doing something unconventional, I do think we should fix that.

RE your second response:
I did fix the editing functionality, and the fact that it wasn't showing relationships (it was a problem with hook_node_info iirc). I think the Unknown entries are due to you not clearing the database before importing.

I like the idea of using taxonomy to deal with separate GED spaces, but I'd need to try implementing it to see if it would actually work.

I'll work on having it remove the appropriate nodes and node_revisions when you uninstall the module.

Remaining bugs:

1) Debug handling of big GED files (could be a Drupal or PHP upload limit)
2) Should give the option of removing all family_* nodes when you uninstall
3) Should inform the user that importing will delete all existing data (for now)
4) Should remove nodes of any individuals it removes upon import.

Features requested (in order of importance to me =):

1) Generate pretty graphs of ascendency and descendency. -- I'll look into implementing this with reports. I've asked the author of http://w3future.com/html/orgcharts.html whether I can incorporate his code to support this feature.
2) Allow editing, adding, and removing relationships
3) GED export (and import merge if it's not too hard---seems like there must be third-party tools for that)
4) Make view.inc more theme-friendly
5) Link users to individuals
6) Create permission to allow users to edit anyone, themselves, direct relations, and indirect relations
7) Create permission to allow users to view anyone, themselves, direct relations, and indirect relations
8) Allow GED "namespaces" using Taxonomy?
9) Use Timeline module to plot various events for a set of individuals (specified as [individual,distance up, distance down] as with trees?)
10) Tie in with Event module (details? I'm not really familiar with Event)

I'll try to tackle the bugs today.
Peter

Just a quick update. I did try uninstalling and reinstalling as directed.

1) I deleted all family_individual nodes (there were no family_location)
2) I disabled the module.
3) I ran the uninstall.
4) I checked my database to ensure table removal. (There were no entries pertaining to family in node_revisions)
5) I deleted the module directory.
6) I extracted HEAD tar. <== sounds gross
7) I applied family_0.patch.
8) Enabled the module. (tables were created, my patch was in fact unnecessary though it worked either way for me.)
9) Received errors when importing. Also noticed that Access permissions were kept from previous install. Nodes still display as shown in item 7 of post #14

I'm thinking I may try uninstalling again tomorrow and seeing if your original patch enables me to import correctly. Perhaps the second patch unintentionally broke that functionality. I can also send you my ged file if you would like. I will also try tackling the minor issues I said I would now that you gave the go ahead. (i.e. admin groups and other small stuff.)

Also, here's a description of Event from the module's main page. Many people use gedview sites to keep up on anniversaries, remembering death dates. All of these could be EVENTS on the calendar.

This is a simple module to keep track of events and show them to users in various calendar displays. It also provides an event API to allow other modules to store and work with date data.

The 4.6 version of this module has been completely rewritten by Aaron Welch.
The 5.2 version of this module has been completely rewritten by Gerhard Killesreiter.

The contrib directory includes basicevent module (obsolete as from 5.2). Enabling this module gives you an event node without having to use flexinode or CCK.

Custom event types can be created using flexinode or CCK. Any node type can be event-enabled by selecting this option on the content workflow page.

Modules related to event include:

* Event repeat: allows you to create recurring events.
* RSVP: users can create and manage RSVPs associated with events
* signup: allows you to signup enable
* event views: adds views module compatibility

Please take some time to look at the module's settings and read the documentation.

Thanks for your work,
Jonathan

Here is the patch that puts Family's admin settings into standard Drupal categories. Import is now under Content Management. Auto Privacy is now under Site Configuration. You may have to disable and reenable the module to have this take effect once patched.

Results of testing.

Untarred HEAD.
Applied family.patch.
Enabled module.
First upload successful.
Reupload successful.
Deleted all records.
Disabled module.
Applied patch only to individual.inc. (Skipped all other hunks)
Import fails.

user warning: Duplicate entry '19453' for key 1 query: INSERT INTO family_facts (fid, nid, xref, fact_code, fact_value, gedcom_source) VALUES (19453, 3151, 'I1', 'INDI', '', '0 @I1@ INDI\r\n') in /path/to/my/drupal/root/includes/database.mysql.inc on line 172.

Line 172 is just an error check trigger. It seems that somehow the changes you made are causing duplicate values for the FID which is the fact table's primary key. I think it may have less to do with your specific changes and more to do with how import.inc creates nodes when the fact_code = INDI. Can't remember the line number in import.inc where this happens, but I'm sure you'll find it.

Created patch for admin settings from family_0.patch directories. Realized I can't test to see if import works under second patch. Got very sleepy. Will rewrite the patch again tomorrow from your original family.patch.

I actually did this work a two weeks ago, but lost the long comment explaining it.

Attached please find a new patch for the Family Tree module v5.

Fixed bugs and changes:

• Menus reorganized - per Pyutaros' patch
• Import now works - as Pyutaros thought, I had broken it
• Removes nodes when it removes family_relationship and family_fact data
• Makes it optional to delete existing family data when you import new data
• Handles arbitrarily-large GED files
• Started User-Family_individual linkage

Importing received the biggest update. I successfully imported 26000 facts about 2800 individuals from one monster GED file I have. The way you import large files is:

1. Go to /admin/content/family_import
2. Browse to your GED file
3. Change "First record to import" to 1
4. Change "Number of records to import" to 500 (or a suitable number for your script timout)
5. Check "Replace existing GED data"
6. Submit
7. While the notes on the submitted page say "Next start record: R" (for some R):
   • Go Back
   • Make sure "Replace existing GED data" is not checked
   • Change "First record to import" to R (501, in this example the first time through)
   • Submit

To Do

I don't know of any outstanding bugs.

Features requested (in order of importance to me =):

1. Generate pretty graphs of ascendency and descendency. -- The author of http://w3future.com/html/orgcharts.html gave permission for me to incorporate his code.
2. Allow editing, adding, and removing relationships
3. GED export (and import merge if it's not too hard---seems like there must be third-party tools for that)
4. Make view.inc more theme-friendly
5. Link users to individuals (started: see /user)
6. Create permission to allow users to edit anyone, themselves, direct relations, and indirect relations
7. Create permission to allow users to view anyone, themselves, direct relations, and indirect relations
8. Allow GED "namespaces" using Taxonomy?
9. Use Timeline module to plot various events for a set of individuals (specified as [individual,distance up, distance down] as with trees?)
10. Tie in with Event module (details? I'm not really familiar with Event)

Yes, Ring TFM is always humbling but empowering.

I'd recommend you start with Event functionality. I think you'll get good results without too much effort. I suspect that the Taxonomy thing will be quite hard, but go for it! I'm going to tackle the pedigree, etc, diagrams next.

I think someone needs to commit this stuff, but I don't know the process. Having CVS commit ability would help for us both to coordinate our development, but I don't really want to be responsible for the module on an ongoing basis...not sure where that leaves that.

Peter

I tried to give you both (pfolk & pyutaros ) CVS access, but neither of you have CVS accounts. If you apply for accounts I can add you. :-)

Sorry, by the way, for not taking any notice of this project for the last year or so. I don't intend to now, I have to admit: I've moved on from the annoying-ness of Drupal to the lovely world of CakePHP! (And for family history stuff, I'm using MediaWiki, by the way.)

CVS accounts approved and I have added you both to the project.

I think I just created a new branch for Drupal-5 in CVS. Hard to tell as I hear it takes while for that branch to become available for browsing. I'm admittedly having some difficulty learning CVS, but WinCVS seems simple enough. PFOLK, I'm going to have to hit you up via e-mail about the import. I'm no longer getting errors, but I appear to still be having problems with my relationship database. I'll probably shoot you a message with the details sometime this week.
Thanks,
Jonathan

Automatically closed -- issue fixed for two weeks with no activity.