#2966 Bleed though of person id's between two independant browser windows running on the same client

[Douglas Terry]

I see a bleed though of person id's between two independant browser windows running on the same client.
Context:
I am running 4.3.1 SVN 7337. I open two browser windows, one in Google Chrome and the second as Edge, both opening seperate GED files:
Chrome: .../phpgedview/individual.php?pid=I123&ged=MyFamily
Edge: .../phpgedview/individual.php?pid=I144&ged=weidmark-tree.ged

If I start both windows on different person id's at the "Personal Facts and Details" tab then I refresh the Chrome window, Now flip over to the Edge browser window and navigate to one of the other tabs, the items in the family view on the right suddenly change to the family view of the person whose id is in the other window.
For the example URL's above, Chrome has person id I123, while Edge has I144. The family of edge I44 is F49 and F48, but when I change to one of the other tabs (say Notes, or Media), the family view suddenly changes to F54 and F56, who happen to be the family for person I123 in the other GED file. If I open the raw GED for the individual on the other window than was last refreshed, it will display the record for the person id on the other browser (ie it maintains the correct GED, but carries over the person id). If I make a change to the other window that was not refreshed it will incorrectly update the wrong person id info.

I have cleared all browser caches, exported and reimported GED files, rebooted the server and I can consistently reproduce this issue. It appears there is some global variable carrying the data from one session to the next, even though they are in independant browser sessions on the same machine (so sharing the same destination IP address).

[Gerry Kroll]

That's a pretty rare set of circumstances that are not very likely to come up in general use.

I'll have some fun tracking this one down. It will also be interesting to see whether this happens with my ancient version of PHP, or whether it's just with more current versions.

[Douglas Terry]

Gerry, for me this is a very common configuration now that I am ready to merge two GED trees together. I have over 1500 items in both trees, the newest tree having a significant number of new sources materials. There are about 300-400 overlapping people in the two trees, but because they were built independently the family id's and source id's are all different, and using admin merge unfortunately moves family and source ids without properly creating new entries or merging info in the appropriate GED so I can't use the admin merge capabilty. I have a spreadsheet to help identify common id's between the to separate files then I was intending to have side by side windows to migrate some of the data and by also diving into the individual raw GED items from the current interface.

[Gerry Kroll]

Just one question right now. There will probably be others later.

Do these two trees share the database tables, or are they completely separate, each with their own completely independent databases tables?

The latter is the way to go. You can have them share the actual database, but the table name prefixes need to be distinct. You get all sorts of undesirable interactions when you have two concurrently running programs accessing the same set of tables. This has always been a big no-no.

[Douglas Terry]

I am not sure - Is there a phpgedview configuration setting for sharing vs them being separate? I look into my mariadb with phpMyAdmin and only see one phpgedview structure, but not sure what I am looking for to see if they are distinct tables. I do know that they both share the same media folder but things like the media and source ids overlap (both start from 1 ...) but neither uses the media or source of the other tree (currently). Part of what I need to do is merge this more source/media rich tree into the master tree.

[Gerry Kroll]

You would have to set up a separate PhpGedView installation (giving it a different URL). In this separate installation, you can specify the same database name, but give the new installation a different database table name prefix.

Since they would be in separate PhpGedView folders (named differently on the server), they won't share a thing.

This means that you can use your favourite browser and launch each instance of PhpGedView in a separate window or tab. This will probably make things a bit easier for you, especially if you use a different theme for each instance to give you visual cues as to which one you're working with at any time.

[Douglas Terry]

I understand now. Given I never expected to have a second tree other than for small submissions to integrate in my main trunk, this would never have occurred to me.

[Gerry Kroll]

PhpGedView was never intended to work the way you described. There would be far too many changes to the program logic to make this work.

I have described a suitable method to achieve what you need to do. Therefore, this bug report will be closed.