vicki

Guust, thanks for the tip about opening location manager pages in a separate tab but as soon as you make a change the page reloads to page 1 in that tab, so that doesn’t help much.

Stiofan, you wrote “a location can have lots of data attached other than listings.” What kind of data? If it is only data manually entered (description or meta data), or entered via a location import, then that’s irrelevant to what I’m trying to do, which is delete location data erroneously entered. Those locations don’t have any other data attached to them, unless GD automatically adds things.

Another customer seems to have had this exact issue

https://wpgeodirectory.com/support/topic/search-issue-3/

and Paolo instructed him: “It’s better if you export listings and correct everything in there. That will also correct the locations.”

But this is not true. Re-importing listings does not remove incorrect location data. I just tested this (again) by exporting all my listings, changing the states to long form and re-entering. The listings are updated but the “old” locations with the state abbreviations are still under locations.

So here’s my basic question. How do you recommend fixing problems in location data created by import mistakes?

Say 500 US listings are imported using the state abbreviations rather than full name. How do you recommend removing the locations that use a state abbreviation?

I think you must agree that doing this manually via the location manager is not a viable option. Can I export locations and delete them in the CSV and then re-import? Paolo advised against that in the other thread. Apparently I’m not supposed to delete them directly from the database, so I don’t know what to do.

Obviously, you know better than me how the data is linked, but it seems logical that if a listing is deleted, other information associated with that listing should be deleted as well. Just like removing an application/program from your computer – you want to remove all the attendant files as well.

The fact that I’m the only person to report the problem doesn’t mean I’m the only person to be affected by it. And I thought you’d want to know how big problems can arise with your software. I know it’s not a bug, and I know there isn’t a quick or easy fix, but this has been a big problem for me and I thought you’d want to know about it.

First, I’d start off by explaining that a CSV listing import also updates the locations table and that users should check the location manager after import to make sure the data there was imported correctly. I don’t know if a listing import affects data elsewhere.

Re: this note

Note 2: We strongly suggest to add a few listings from the frontend, and then export those listings first. That will show you the type and format of the data required to be imported. Also, review the location notes if you have not done so already.

As far as I can tell this exercise isn’t helpful for the abbreviation/consistency issue. If I import a state or country abbreviation, that is what is exported. Obviously looking at the export would be helpful for other reasons.

The “location notes” linked to include this text:

Your locations need to be therefore always city > region > country, exactly like Google suggests when you add a listing from the frontend.
For example Los Angeles > California > Unites States [not LA > CA > US].

This is misleading, at least for the US, because the Google Maps autocomplete on the front end displays state abbreviations, so one would think state abbreviations is “exactly like Google suggests”.

Perhaps it would be clearer to say something like “GeoDirectory uses the full spelling of city, region and country names pulled from the Google Maps API. When importing listings, always use the full spelling for location fields to prevent duplicate location pages. For example Los Angeles > California > Unites States [not LA > CA > US].

To drive the point home I would consider adding text to these lines for the skimmers:

post_city: City, town etc (use full spelling, not abbreviations)
post_region: state, province etc (use full spelling, not abbreviations)
post_country: country (use full spelling, not abbreviations)

I’m still not clear on how the country translations work. I did change those to abbreviations for US and CA and it seems to work. The dropdown on the frontend displays the abbreviation and they show up in the URL and address display. Apparently though I have to import using the full spelling. I’m not sure if you want to mention the country translations option on this or the locations manager page.

One thing I didn’t notice until this issue came up is that the dropdown for states now has both spelled out and abbreviated options since I haven’t finished cleaning up the data yet. You might mention that this is another effect of having inconsistent location data, and another place users can check to make sure their location pages are accurate.

Hope this helps. I’m astounded this issue hasn’t come up a lot before. The only thing I can figure is that people have inconsistent data and haven’t noticed. I only picked it up when I did a crawl of the site and saw broken links generated by the breadcrumb on detail pages. Then the more I dug the more of a mess I found.

I understand that GD works globally and long names make sense as the default. As I mentioned before, my directory is only for the US and Canada and abbreviations for states and country make more sense on my site.

I know you are frustrated with how much of your time I’ve taken with this issue, and I appreciate your patience and the tremendous value of this support forum. On the other hand, I’ve literally spent *days* trying to grapple with the problems and issues I’ve brought up in this thread. Here are a couple suggestions that could prevent these issues coming up for other customers: On your otherwise wonderful instructions here

https://wpgeodirectory.com/docs/core-export/

perhaps you could make a note that city/country names should be spelled out on the import CSV. It’s hard for me to believe I’m the only one with a database full of US addresses that use the state abbreviation.

Another suggestion is to add to that page a note that the import csv updates the location table along with the listings. I wasn’t aware of that, so I didn’t know my initial sloppy import would cause such problems. I thought I had fixed my errors my re-importing correct listing data.

As I mentioned before, I’m not a js programmer and my questions are to try to understand how your software works, and in this instance how it interacts with the Google Maps API. I think the country abbreviation is taken care of with the translation – at least now that I know I still have to import using the full name.

So one last question: could you at least let me know if it’s **possible** to switch to state abbreviations by making child theme changes? If so, I might explore hiring a developer to make the fix, but right now I don’t know if what I’m asking is even possible. I presume that this is a question your team could answer easily and quickly, but if I’ve underestimated the complexity, please forgive me.

Well I’ve got a mess on my hands. I didn’t realize that making mistakes on imports would cause such chaos. I’m now editing locations directly in the database because it’s a lot faster. I deleted all the “extra” countries and then saw that some US states use abbreviations (because I imported them that way), so now both state names and abbreviations are showing up in the pulldown menu on the front end. I also see some listings in the database where United States is spelled out.

So I’m trying to fix all this and get it consistent and then set up some procedures so I don’t mess it up with future imports. But it would really help if I understood better how all this is *supposed* to work.

I would really, really, really like to use abbreviations for country and state names because it makes breadcrumbs and urls shorter, much shorter, which is better for users and SEO.

I had posted about this awhile back here:

https://wpgeodirectory.com/support/topic/country-state-abbreviations-in-url/

and it seemed like my plan going forward to translate the two countries to abbreviations but spell out the state names would work. Now that I’m looking at things in the database I wonder why I can’t use abbreviations for state names, especially since I’m going to have to manually clean a lot of this up now.

Can you give me good reasons not to? I understand that users can add different names in the front end, but they are more likely to just use the pulldown menu right? All of the states are already in there. And it looks like I’m periodically going to have to go into location manager and clean things up since errors are sure to happen. So why not use state abbreviations when I import and to change all the current listings to abbreviations now?

Also, I’m curious how all this affects the listing search. If I use the state name Massachusetts can someone search for a listing via MA and vice versa? I’ve tried testing this but things are so messed up right now I’m not sure of results – and again, I’d like to make changes based on how things are *supposed* to work.

Sorry this is so long but I’m pretty confused right now and whichever way I go it is going to take some time to fix so I want to make sure I don’t have to repeat it all.

Ack! I just looked at the Manage Locations data. I made some mistakes in earlier import attempts where I mislabeled the column field. I corrected the listings but didn’t realize that the location data from the inaccurate import csv was still saved here. Ack, again.

Sooo, first step is to go through and delete all the bogus locations. I’ve done some testing and I know which ones to delete without deleting the listing, but now I wonder if there’s any way to make these changes in bulk? The only way I see to delete is to click the delete icon for each one. Luckily I only have about 300 to go through but it will still take some time.

I’m not sure why you were saying I have two US countries but I think deleting all this other stuff may take care of the problem.

I reimported the listings using the full name of the country and that did fix the links. They also display correctly, using the abbreviation. Is there any other reason not to translate the country name using the abbreviation? It wasn’t clear to me from your earlier message. Those shorter URLs are really important to me.