Error message in a modal of the Repository Hierarchy module if Fancy Treeview module is installed in parallel

[Jefferson49]

Observed with Fancy Treeview 2.0.0-beta3, Repository Hierarchy 1.2.4, webtrees 2.1.15

If the two modules are installed in parallel, an error message is shown if opening a certain modal in the Repository Hierarchy module.

At least on one installation the issue is reproducible if acitivating/deactivating the Fancy Treeview module. On another installation the issue occured several times and disappeared after re-installation of Fancy Treeview. On a third installation the issue never occured and cannot be reproduced.

[Jefferson49]

See discussion in webtrees forum, thread #37628

[Jefferson49]

At the moment, the issue is not critical for me. I uninstalled the Fancy Treeview module, because it is a beta version anyway. I will re-test after an official release of the Fancy Treeview module is available.

However, if you have some idea about the background of the issue, we can disuss.

[Jefferson49]

Also posted as issue #22 for the Repository Hierarchy module.

[Jefferson49]

I think I found the reason: The route of the Fancy Treeview module is defined as follows and seems to clash with the route of the Repository Hierarchy module:
/tree/{tree}/{module}/{xref}/{name}/{type}/{page}

If patching to the following route, the issue disappears:
/tree/{tree}/fancy_treeview/{module}/{xref}/{name}/{type}/{page}

[Carmen]

I need to look into this. But hard coding the module name in the route doesn't seem like the right way to go.

[Jefferson49]

Thank you for looking at this issue!

Well, hard coding the module name might not be necessary. I think it would alredy help to hard code the attribute names, e.g.:
/tree/{tree}/module/{module}/xref/{xref}/name/{name}/type/{type}/page/{page}

However, while debugging this issue, I learned that webtrees cannot distinguish the modules and will just parse the route. If two modules use the same pattern in the route, it might clash.

In my case, I used the following route, which seemingly is completely different. However, it clashes with your route. /tree/{tree}/repositoryhierarchy_create_source/xref/{xref}/source_call_number/{source_call_number}

[Jefferson49]

If my route is sent, I guess that webtrees parses the following:

tree => tree
{tree} => {tree}
{module} => repositoryhierarchy_create_source
{xref} => xref
{name} => {xref}, i.e. the value of "xref" sent on my route
{type} => source_call_number
{page} => {source_call_number}

Therefore, it matches for the webtrees parser, and the request is forwarded to your module

[Carmen]

I see the pattern. We are using the same route with the same variables:

tree => tree
{tree} => {tree}
{module} => jc-fancy-treeview
{xref} => xref
{name} => root person's name
{type} => page type = descendants or ancestors
{page} => the page number.

The url to the Fancy Treeview page looks like this:
https://wijzijnfamilie.nl/tree/wijzijnfamilie/jc-fancy-treeview/I3326/johan-george-honig/descendants/1

So, I don't know how we should solve this. I think @fisharebest should look at this. If the module name is not a unique identifier than there is not much we can do but rewriting our route. Until another module author drops by with the same problem. We cannot prevent that. So webtrees should give us tools to distinguish our routes from one another.

[Jefferson49]

I am not an expert in this. However, from my point of view, it can be solved by adding "hard coded" strings to the route. This makes it distinguishable.

I think the clash with your current route definition comes from the reason that all of your route parameters are just defined with the "values" in brackets, i.e. {value}/{value}/{value}. In this case, webtrees can match a lot of other routes to it. If you put in some hard coded strings in between, it makes the pattern more unique, e.g.:

/tree/{tree}/module/{module}/xref/{xref}/name/{name}/type/{type}/page/{page}

Mathching with my route again:
tree => tree
{tree}=> {tree}
module => repositoryhierarchy_create_source
{module} => xref
xref => {xref}
{xref} => source_call_number
name = {source_call_number}
{name} =>
type =>
{type} =>
page =>
{page}

The matching of the bold lines will fail!

[Jefferson49]

A second example: If mapping your example route to my route, some parts will fail matching. Fails again marked in bold:

tree => tree
{tree}=> wijzijnfamilie
repositoryhierarchy_create_source => jc-fancy-treeview
xref => I3326
{xref} => johan-george-honig
source_call_number => descendants
{source_call_number} => 1

[Greg Roach]

I think I found the reason: The route of the Fancy Treeview module is defined as follows and seems to clash with the route of the Repository Hierarchy module:
/tree/{tree}/{module}/{xref}/{name}/{type}/{page}

If patching to the following route, the issue disappears:
/tree/{tree}/fancy_treeview/{module}/{xref}/{name}/{type}/{page}

I would suggest just /tree/{tree}/fancy_treeview/{xref}/{name}/{type}/{page}

{module} doesn't match a module name. It matches any text. Your route matches any URL that starts with /tree/ and has 6 parts that follow. It would match /tree/a/b/c/d/e/f.

I need to look into this. But hard coding the module name in the route doesn't seem like the right way to go.

You would not be hard-coding the module name. You would be hard-coding the type of chart/page.

[Carmen]

Thanks Greg for your reply. It's clear now.