If someone manages to hit this with postgresql, I'd be quite suprised, as the call has been broken since March and it is rather obvious when db_next_id is called against something invalid on postgresql -- it throws an error.

I put a message in the postgresql case to followup on the issue.

Don't blindly enable location_user, only enable it if location is already enabled.

#300426, part 1: Split off user locations into a seperate module to make it easier to completely disable.

* Implement multiple country autocomplete.
* Allow location_province_code() to operate on an array of countries.

* Add per-location-field weights and defaults.
* Add location_api_variant() that I will increment when breaking something in the future that might be used from another module. It is now 1.
* Make settings on location_cck work nicely.
* Field settings are now in a table.
* Field settings defaults can now be overridden in the UI.
* Field settings are now weighted. (Draggable in D6!)
* "Force Default" may now be used for all fields.
* Content type settings validation is repaired again.
* Major COW changes (again) -- Should not have any impact on sites, but be careful until the new code is proven.
* Tests were added to ensure COW functionality doesn't break. (Tests were committed earlier)

API Changes:

* If you were using a location_element, the #location_settings is now the *entire* settings array, not $settings['form']['fields']!
* hook_locationapi() 'collection default' and 'default values' ops  have been merged into a single 'defaults' op, which now allows specifying default weight.
* Collection status 3 is now 4. (Relevant for the 'country' field.)

#330318, reported by danielb: Never, ever load anything when an empty id is passed. We have to enforce this on our side because Drupal doesn't do SQL NULLs.

Better fix for #306171: Pass along criteria to location_save() to ensure that the lid conservation code doesn't reuse a lid tied to a single *other instance*.

This fixes a bug when making a change to a location when adding a revision.

This makes using a location_element much easier, and centralizes the code that does required.

Simplify the titles a bit in the directory view, and make the Drupal 5 version match the Drupal 6 version.

#292993 reported by EvanDonovan: Fix some title glitches in the default directory view. (Also, fix country and province argument titles, they were broken.)

This allows us to have multiple user locations, and simplifies the API for associating locations with other things.

The variables used by location got all shuffled around because of this, but I put in compatibility code to keep setting location_maxnum_{nodetype} and location_defaultnum_{nodetype}, because there is a lot of contrib modules checking for them.

B) Made user locations work more like node locations.

C) Allow more than one location to be "required".

D) Reorganize the variables. Now there is a single variable per content type. (location_settings_{nodetype})

E) Make virtual fields hideable, and add the map link as a virtual field.

F) API change: The return value of 'virtual fields' op is now an array of keys and values, where the values are the labels for the hide checkboxes.

(The Drupal 5 version of this is a quick as possible port, there may be lingering typos. It seemed to work OK, but I won't know for sure until I minimize the diff against HEAD again.)

Fix map centering when editing locations with LOCATION_LATLON_UNDEFINED coordinates.
See [#317159]

 * Removed the workaround that involved truncating the views cache.
 * Fix [#321291]
 * Behavior change: Exposed proximity map filters now have correct field names. This allows optional exposed proximity maps to work. (Otherwise, views would not be able to see that the filter was actually filled in.)
 * Work around a Views 1 bug that failed to persist filter settings properly when editing a view.

Move the search templates to the location_search folder.

Here is a rewritten location_search.module. It uses the search apis and is able to do fulltext searching. It's also cleaner, and will be ported to Drupal 6.

It searches by location, not node. (Restriction to specific types of objects is possible but not implemented yet.)

Hopefully I didn't accidentally leave out / forget any features people were using.

It will need to generate a search index before it will work properly, so do the same thing you would do if you were reindexing the site (i.e. run cron in a loop and watch the percentage indexed number)

Minor api change (optional):
* Add an 'instance_links' op to hook_locationapi so modules can stick in the correct urls for the instances they handle.

* Fix $op 'delete' on hook_locationapi().
* API CHANGE: Use location_save_locations() with an empty array instead of deleting rows from {location_instance}. This lets us have "real" deletion instead of relying on garbage collection.

Before:
<code>
db_query("DELETE FROM {location_instance} WHERE genid = '%s'", 'mykey:'. $obj->id);
</code>

After:
<code>
$locations = array();
location_save_locations($locations, array('genid' => 'mykey:'. $obj->id));
</code>

* Remove garbage collection routine and UI from settings page. References are checked automatically now.

#317048, reported by carlogen: Repair some completely broken views 1 code, namely the province and country exposed filters.

Repair broken update that failed to change the weight of location_fax and location_phone. (Preemptive backport of uncommitted Drupal 6 changes.)