Strange behavour in Places list

[HRN65]

Since 2.0 I've seen this strange behavour in Places list. Every now and then a "new" place appears in level 0 (countries) showing "The location of this place is not known".

The name is always a level 2 or 3 place name of an already existing place, but now moved up to level 0 with no coordinates, and zoom always set to 2.

Deleting the place in Control panel/Geographic data does not help, the place will reappear immediately, and can only be deleted from DB.

After "cleaning" out these places from places list, I exported places as csv, checked the file, and reimported while deleting existing data.

I also checked my gedcom to make sure these places only exists at level 2 or 3 in place names, and they do.

Now everything looks fine, a day or two, then "new" places starts popping up as level 0 again.

I'm the only user of the site, no others have edit permission, and I have not made changes to any individuals connected to these places recently.

How can this happen?

[t-karcher]

I've seen this as well in my database! Not as frequent as you, and since a couple of family members have edit rights in my tree, I didn't analyze it any further, but quietly blamed it on a user error. Maybe I was wrong.

[HRN65]

Again I cleaned the places list. Tried both adding a new place and editing an existing place, to see if this was triggering the appaearance of "new" places, but everything looked normal. Now, visiting my site 6 hours later, a level 2 place has again appeared as level 0

[t-karcher]

I was finally able to reproduce it!

1) Add a wrong place ("Dummytown") to any publicly visible individual in any public tree. 2) Delete "Dummytown" from the places list. 3) Visit the previously edited individual again, or wait for any web spider to visit this page. 4) Dummytown will be added to the places list again.

So the issue is that places will be (re)added to the places list not only when I manually transfer them from selected trees, but every time the place is displayed - even in test trees.

[HRN65]

Yes, I think this works as intended. The places list is populated with all places from GEDCOM. If a place is deleted fro Places list, it will reappear.

My problem is that places already existing as level 2 or 3, every now and then pops up as level 0.

A place like Dummytown, Almeda County, California, USA may suddenly appear as Dummytown level 0, with no location, nor any individuals connected.

This seems to happen without any action related to the place, or connected individuals, but always shortly after adding/editing other data.

As Places list is populated from GEDCOM, I guess there is a "hickup" when writing to DB, resulting in just "Dummytown" instead of "Dummytown, Almeda County, California, USA"?

As writing this, a new place popped up in my list: Innergård In GEDCOM this only exists as Innergård, Salangen, Trom, Norge Checking my data, there has not been edits to any individuals connected to this place since january 2011

[t-karcher]

As Places list is populated from GEDCOM, I guess there is a "hickup" when writing to DB, resulting in just "Dummytown" instead of "Dummytown, Almeda County, California, USA"?

I doubt that: Everytime I had this issue, I eventually found the culprit - a wrongly formatted place (with no region details at all, or entered as "USA, California, Almeda County, Dummytown") - somewhere in the GEDCOM file (not necessarily linked to an individual or family).

[fisharebest]

When we display a place on the map, we fetch the location details from the database. If they are not found, then an empty record is created.

This is one step towards the elimination of the "import places from family trees" option in the control panel.

I want this to become fully automatic/transparant.

I doubt that: Everytime I had this issue, I eventually found the culprit - a wrongly formatted place (with no region details at all, or entered as "USA, California, Almeda County, Dummytown") - somewhere in the GEDCOM file (not necessarily linked to an individual or family).

That is my thoughts.

But it is always possible that a bug exists. @HRN65 - can you reproduce the issue?

[HRN65]

@Greg Well, it kind of reproduce itself. I tried yesterday to edit/add places to see if this could trig this bug, but everything looked normal. Returning to my site this morning, I found this new level 0 place "Innergård", and visiting my site just now, another place has "popped up": Farstad https://visitusinmaputo.com/webtree/module/places_list/List/29082010.GED

I've searched through the GEDCOM, and these places only exist as level 3 (and as text in notes)

I've used webtrees for years, and have not seen this before upgrading to 2.0. First time I noticed this, I of course blamed myself for adding a wrongly formatted place name, and deleted it. But as more level 0 places appeared I got puzzled, as I realised these plces/individuals have not been "touched" by me for ages, and I'm the only person having edit permission.

I run a copy of my site locally on a wampserver, and do not see this problem there, so I suppose it is a server/database problem.

Please find logs attached php_error_log.txt webtrees_log.txt

[HRN65]

During the night, another level 0 place has appeared: Sundnes

https://visitusinmaputo.com/webtree/module/places_list/List/29082010.GED

In website logs I find same error as above at 3:30

[HRN65]

And now 2 hours later, a new level 0 place has popped up. No error messages. No changes have been made to my data since yesterday, I've only logged in twice today to check error logs.

[HRN65]

Visiting my site again in the afternoon, the erroneous places from this morning are gone! Is the Places list somehow recreated from my gedcom data?

[HRN65]

Again, new erroneous places have appeared since last time I visited my site...

[fisharebest]

Again, new erroneous places have appeared since last time I visited my site...

And does this placename appear in your website logs?

Perhaps someone (or a robot) has tried to view the page for that place?

[HRN65]

Looking around, I find in Google Search Console 28 pages not indexed because of 5xx server errors. Checking the indi pages, I recognise level 2 and 3 place names that have recently been erronous displayed as level 0.

[HRN65]

Going through the logs I have now found one of the erronous places that popped up last night

petalbot-114-119-165-47.aspiegel.com - - [12/Jun/2020:00:05:40 +0200] "GET /webtree/placelist.php?parent%5B%5D=Larsnes&ged=29082010.GED HTTP/1.1" 200 - petalbot-114-119-165-47.aspiegel.com - - [12/Jun/2020:00:05:41 +0200] "GET /webtree/module/places_list/List/29082010.GED?place_id=40395 HTTP/1.1" 200 8966

[fisharebest]

This is a webtrees 1.7 URL, and you are presumably using webtrees 2.0 (with the "legacy URLs" module enabled).

This would cause the place to be created.

(In webtrees2.0, the place list uses IDs in the URL, to prevent exactly this problem).

[HRN65]

Yes, you are right. I'm using 2.0 with the legacy URLs module enabled. I now found the other place name from tonight. Same pattern

petalbot-114-119-161-3.aspiegel.com - - [12/Jun/2020:07:16:44 +0200] "GET /webtree/placelist.php?parent%5B%5D=R%C3%B8yken&ged=29082010.GED HTTP/1.1" 200 - petalbot-114-119-161-3.aspiegel.com - - [12/Jun/2020:07:16:45 +0200] "GET /webtree/module/places_list/List/29082010.GED?place_id=40396 HTTP/1.1" 200 8980

Here we se the two places have been created with ID's 40395 and 40396

Anything that could be done to prevent this?

[fisharebest]

Anything that could be done to prevent this?

Probably. wt1.7 URLs contain a placename. wt2.0 URLs contain a place ID. So the legacy URL module creates an ID to match the place, and then redirects to it.

[HRN65]

Well, I guess the old 1.7 URL's will be around for a while, and more places will be created. At least I know the reason, and can safely delete them as they appear :) Thank you for looking in to it!