Question Dokuwiki plugin for webtrees

I've created a plugin for Dokuwiki (tested with Hogfather) to link back to persons and places in webtrees (tested with 2.0.16) by the ids, similar to the exisiting URL markup tags. Just extract the zip into the lib/plugins/ directory of Dokuwiki. Configuration happens in conf/default.php and is (hopefully) self-explanatory.

Backstory: After playing with notes and shared notes I've decided to use a wiki for the more general blocks of information which are not strictly related to a specific person; for example, background information about places. A wiki is more suitable for managing this kind of information, as it allows easy structuring and media handling.

The plugin creates a new markup tag which can be used in the following ways:
[WT person=1]: creates a hyperlink to the person with its name taken from webtrees' database, eg "John Doe"
[WT person=1|*1765]: same as above, but appends information, eg "John Doe (*1765)"
[WT place=1]: creates a hyperlink to the place with its name taken from webtrees' database, eg "Alpha Centauri"
[WT place=1|now destroyed]: same as above, but appends information, eg "Alpha Centauri (now destroyed)"

There's also the option to not access the database at all. It will use only the information for the linktext, thus requiring a tag like [WT person=1|John Doe (*1765)]. Obviously, this also means that name changes are not happening in the wiki. It basically only exists to keep markup more clearly structured.

Notes:
My wiki is private and without any ACLs, so this is untested with the extension manager of the admin section.
Dokuwiki uses caching, so you might have to flush it after making changes in webtrees.
Preferably Dokuwiki and webtrees run on the same host to avoid bottlenecks and networking issues.

I've been pondering to create something to also link places from webtrees to Dokuwiki, but it's in the old code, so it would require to patch webtrees manually, meaning it breaks on every update. Should that happen somewhere in the future, it probably would mean that existing page names in the wiki need to be recreated to match a given naming structure (eg from "placename" to "placename_id") to avoid that two different places with the same name link to a single wiki entry.

Provided as-is: if it breaks, you keep the pieces

Can this be a replacement for the webtrees "Stories"?

EDIT:
[strike]What ist the meaning of [/strike] ?[strike] Is "1" a XREF like "I1234"?[/strike]

[strike]Is the "1" in [/strike] [strike] a XREF of a _LOC record (Vesta module)?[/strike]

Now after installing dokuwiki and your plugin I can see it.

You are using the internal XREF as a link for persons. XREFs should - following the GEDCOM standard - never be used in an external system because this XREF can be changed by a system like webtrees at any time, maybe when merging individuals. And you are assuming that all XREFs of an individual are starting with the letter X, but this is not the case. This letter can be any letter or maybe this letter is not existing. Most of the XREFs for individuals in my tree are starting with an "I". So "I1234" or "X56" or "1111111111111111111" are all valid XREFs.

You are using internal database IDs for locations.

The generated URLs back to webtrees do not work in my case, but to repair this will be easy. I will use your plugin to replace some of my webtrees "Stories". But I will replace the XREF by an user defined GEDCOM ID. And I will use links to _LOC records (Vesta module) instead of IDs from the database table xxx_places.

hermann wrote: XREFs should - following the GEDCOM standard - never be used in an external system

All good and well, but imho there is no other choice but to use the XREF. It's part of the URL in webtrees for a reason: it's the only unique ID (within a tree) that's guaranteed to exist.

hermann wrote:

You are using the internal XREF as a link for persons. XREFs should - following the GEDCOM standard - never be used in an external system because this XREF can be changed by a system like webtrees at any time, maybe when merging individuals. And you are assuming that all XREFs of an individual are starting with the letter X, but this is not the case. This letter can be any letter or maybe this letter is not existing. Most of the XREFs for individuals in my tree are starting with an "I". So "I1234" or "X56" or "1111111111111111111" are all valid XREFs.

Thanks for you input on this. I'll put the X bug on my todo list (I didn't see any other letter so I assumed that's the standard prefix; plus the X in XREF misled me here it seems).

Yeah, I assumed that XREFs are static and don't randomly change in an installation (with merging trees being an exception due to possible collisions). I was looking for something that can be easily identified, and which is present for all persons without needing to manually create a target-id first. I haven't found anything else that comes close.

The question is if webtrees (with the excepton of merging trees) will randomly change IDs for some reason. I'm somewhat fine with the webtrees/Dokuwiki connection being installation specific in this case. I'm not sure how a gedcom export and import in webtrees would affect the IDs though.

hermann wrote:

The generated URLs back to webtrees do not work in my case, but to repair this will be easy.

What was the issue in your case?

The idea has potential. There's also the stories tab and the shared places module.

I just use a Wordpress blog and hand-code the links. I use the stories tab to make a bulleted list of links to blog posts pertinent to the individual. I wish there were a stories tab for FAMs. Have to put links in NOTEs instead. Places, I'm still trying to figure out this part.

In the blog, I put obituaries, letters, biographical info, musings about oddities in sources, local history (example, the whole village burned), etc.

I was a bit hesitant to post this, because it is somewhere between alpha/beta status and because it involves patching exisiting webtrees source; meaning it will probably break on an update. On the other hand, it might be useful to some.

My reason for this patch was that I ran into more general information about places which is not specific to a single person. In my case, a distant relative died in a war and I know the place. The information about the battle and involved military units is (imho) outside the scope of webtrees. It's kinda similar for a location where generations lived: the amount collected about a city can be too cumbersome for a shared note.

So this patch adds external links to the wiki to every location in the facts tab. Specifically, it splits up the locations, so if you use "Earth, Solar System, Milkyway Galaxy" then you'll get three additional links.

First of all, make a backup of at least the two modified files; to undo the changes, just overwrite the two files with those from your backup.

In "app/Place.php" add the following new function (I started in line 274):
In "app/Functions/FunctionPrint.php" replace on line 423 with
From now on, you should see the new links in the facts and events tab. Note that links are pointing to the namespace "places" in the wiki to keep things grouped and organized. If you do not want that, just remove the "places:" from above. Oh, and you'll need to adjust the example.com to point to your actual installation.

I'm still a bit undecided about this because I haven't properly tested it (like, with non-ascii locations); plus a location can only exist once, so if you have multiple identically named locations in different geographic areas, you'd need to create a "switch"-entry; kinda like Wikipedia does for entries with different meanings.

Have you tried the Vesta Shared Places module? It allows you to define unique place record (using the GEDCOM custom tag _LOC). Then you can put there a NOTE to tell a story about this place or to put there a link to dokuwiki. The shared place record has a URL and can be used like the URL to a person, so that it is possible to link back from dokuwiki to webtrees.

Regarding the links generated by your dokuwiki plugin:
- generated: ahnen.hartenthaler.eu/index.php?route=/t...hnen/individual/X318 (ok instead of X318 it should be I318)
- my webtrees page: ahnen.hartenthaler.eu/tree/ahnen/individ...ef-Hartenthaler-I318
So the link in dokuwiki does not work because I have "pretty URL" activated. Maybe it is my configuration fault that your link is not working, I have to check this.

Another topic: since you are using direct access to the webtrees database, you are bypassing all the data security functions of webtrees. So a user of your plugin has to take care that visitors of the dokuwiki cannot get access to confidential information.

hermann wrote:

Another topic: since you are using direct access to the webtrees database, you are bypassing all the data security functions of webtrees. So a user of your plugin has to take care that visitors of the dokuwiki cannot get access to confidential information.

The approach of putting URIs in the text has the benefit of allowing webtrees to control access. (And I don't have to write any SQL. Thought I was done with that when I retired, but …)

Hello !

Are you working on this plugin for Dokuwiki ?
Can you tell me where to download it ?

Thanks