You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!
Here's a list of features that a Genealogy module or distribution might have. Please add to the list as you see fit, and/or add your username to one of the right hand columns beside a feature indicating your vote on whether it's Essential, or a Plugin (nice to have).
| Feature | Essential | Plugin | Comments |
|---|---|---|---|
| Entities defined for Content | lhridley | ||
| GEDCOM Imports | lhridley | ||
| Graphical Pedigrees | lhridley | ||
| REST API/Services Integration | lhridley | ||
| Media | AldenC | ||
| Logged on User to node ID | AldenC | ||
| Book structured Narrative | AldenC | ||
| PDF report capability | AldenC | ||
| Privacy | mike_san | To prevent unauthenticated users viewing private content. | |
| Document field | mike_san | To provide for the upload of PDF or similar files. |
Comments
User integration? I am trying
User integration?
I am trying to get my family to participate in the "building" of the site.
It would be nice to have, a plugin I guess that links user data to the family tree...
So that when you pick an individual out of the tree, you end up at his/her profile page.
Or does this fall under the REST API/Services integration?
That would fall under Plugin
That would fall under Plugin since most family trees I've seen don't have living family members listed on the tree due to the risk of publishing that information, which can be used to guess security question answers or passwords, or for identity theft purposes
IMO
That would fall under Plugin
That would fall under Plugin since most family trees I've seen don't have living family members listed on the tree due to the risk of publishing that information, which can be used to guess security question answers or passwords, or for identity theft purposes
IMO
Entities and Content
@lhridley...could you please elaborate for me what you mean by "Entities defined for Content"?
And if I may ramble while awaiting your response...
There are modules, and there are modules made by the gods. The three top in my opinion are Views, Rules, and Panels. I have discovered the importance of defining content types carefully to take maximum advantage these three. It is essential to building pages with good user interface. And after all that is why developers (and wannabee developers like me) have been placed on this earth.
I envision a core content structure that has unalterable fields, as well as the ability for user to add additional fields (easy enough). My experience is not to rely to heavily on taxonomy, it tends to be "soft", vulnerable to user error and cumbersome to use even with autocomplete. I see a need to have the core data structure to be indexed more "hard" with the core module using the data tables extensively for management.
The Relation module will be essential but I found the relation tables become very angry when a node is deleted. The core module will require extensive consideration to the logic of dealing with orphan nodes and broken trees. We both know there will be a lot of adding/deleting/editing of the "person" nodes by the user of this module. One of my big frustrations is how Ancestry.com and the linked Family Tree Maker will seemingly haphazardly duplicate people and screw up tree structures ending with floating "branches" that are difficult to grab on to and delete.
I think it will be easy enough to link the user table to the core genealogical data structure so a logged in user will be "me" within the family tree. This will be handy for access and edit permission functions. I have successfully used Rules along with relations to limit access on a site that allows parents to access their kids' content even if flagged private. So this site could have multiple layers of privacy protection based on roles, "me", and relation of "me" to other nodes.
My input here is probably premature, but I believe it relates to the Entities we will need to define.
A core content type, or
A core content type, or fieldable entities, are what I have in mind. Taxonomy has it's place for things like name prefixes and suffixes, event types, etc, and can also be used in conjunction with surnames and places to get quick browse listings of people with the same surname, or buried in the same location, etc.
The fieldable core entity types can be easily contained in a module or modules, along with any related taxonomy, and associated views built with that content type.
Understand now-thanks.
I know I can be stuck in the Node mindset...and that is SO D6 ;).
Having taken a peak at mad_dog's work on FTREE I see what you mean about the lighter weight entity concept. I need to educate myself a bunch more to but I am sure you are right about this. I am most interested in how easy it is for non-coders to add fields since I would like to have a module that is flexible for the user. Everybody wants to manage different data.
Adding fields to a fieldable
Adding fields to a fieldable entity through the admin interface works just like adding fields to a node in D7, if the developer sets up the entity correctly (and that's not hard to do).
Drupal Genealogy Follow-Up
Hi AldenC,
Your comments seem to indicate that you are/were the most serious one considering applying Drupal to a Genealogy solution. I am presently in the process of learning Drupal and designing a Drupal 8 site to replace an extensive Joomla! site that contains business for our extensive family as well as many other features.
The site is a large Family Homestead site spanning 6-generations of family history and records of our family corporation. We currently use a separate TNG genealogy also for tracking ancestry connections. I would love to see the new Drupal 8 site integrated with the genealogy side. I question the wisdom of trying to incorporate the old "The Next Generation Integration" Drupal 7.x module in order to do that. It would be great to bring all of it over to Drupal.
Have you pressed on with Drupal genealogy efforts? Do you have any advice or new ideas?
I hope you get this and can spare the time for a response.
yours,
I’m not OP, but my suggestion
I’m not OP, but my suggestion would be to look at the GEDCOM specification and use it to define the Drupal MVP object design. One simple first ‘project’ could be to create a field formatter that displays a Drupal date object in GEDCOM format ie "20 JUN 1914". the specification tells if certain data can be 0 to 1, 1 to many, and even what the text format should be for some fields. You can use field validation to ensure this is correct.
You would certainly need a few entities; individual, family, source, repository, submitter, and shared note. You might be able to modify the existing Drupal media entity to work in this context by adding some other fields.
You might make a few custom fields for data that requires certain validation. For example, I think the "Citation Details" specification mandated that a colon character be somewhere in the text string.
My list additions
I believe the Media needs to be integrated into the core module since it is fundamental to a pleasant site and will be related to many of future plugins. By making it core and setting up some interface, media should be easily linked and embedded into pages. Leaving it to some gallery module may make it too difficult for users to integrate into their sites. The media itself can use taxonomy extensively. The only feature not yet provided within Drupal (I think) is the ability to tag portions (faces) of images, something TNG appears to have succeeded at. But Drupal does do a fairly good job of handling the wide range of media that a user would like to include in their site.
The underused Book core module can be adapted with some interface improvements to be a great way for users to add a narrative to their family tree.
And by logged in user-Node ID I mean the logged in user will be recognized as the "me" in the tree as well as provide for the profile link that Bokkie describes.
this sounds great
this sounds great