Drupal 7 port for location module

subscribe

subscribe

subscribe

My module weather depends on Location for displaying the weather nearby a node's location. I'm currently porting the module to D7, but this functionality cannot yet be implemented because of the missing port of Location. Could you give a status update when you'll start the porting?

Regards,
Tobias

I am also interested in a port to Drupal 7. Please let us know if there are any specific tasks we may help out with...

subscribe

+1

The current maintainer is a bit busy at the moment, but I can commit patches that help with the port.

Browsing the CVS repository, I know that some work has been done on a port. When I get a chance, I (or, if someone wants to volunteer, someone else) can checkout the latest copy of the MAIN branch (where the port is taking place) and test it against Drupal 7 and report back with a more specific list of things that are working in D7 and what still needs to be fixed. That might make it easier to put together a specific list of coding tasks to make the module compatible w/ D7.

-Ankur

+1.

+1

better title/category (and subscribe)

subscribe

subscribe.

I was stated at http://drupal.org/node/440984#comment-2910188 that Location for D7 will provide Locations as entities.

It's be great if Location could server as a basis for both the Drupal Commerce ( http://www.drupalcommerce.org ) and Drupal CRM ( http://tinyurl.com/drupalcrm ) projects.

Subscribe. My assumption is that some mix of OpenLayers and/or Geo is likely to replace Location as the default location module in D7. Unfortunately, there's no peep of a migration route from Location with either of those. Really, only OpenLayers appears to have the necessary level of development activity at present.

I'm currently looking at getting the current issues down a bit but I'm happy to help out with/test/commit any patches in relation to the D7 port.

As ankur mentioned in #9 if anyone can get together a todo list that would be a big help and then we can get into checking things off it.

It would be great to be able to have this ready as close as possible to D7 release.

I discussed the location module for D7 with bdragon at DrupalCon SF back in April. We discussed two possibilities:

(1) A straight port to Drupal 7 on the -3.x branch where the location module fields would still be added to nodes via hook_nodeapi(). Once the straight port was completed. That 7.x-3.x branch would be maintained and a separate 7.x-4.x branch would be started in which locations would be implemented as field-able entities.

(2) A non-straight port directly to a 7.x-4.x branch in which locations are field-able entities.

The idea for (1) was that it would be the quickest route to a D7 location module, enabling sites currently using the module to an easier and sooner move to Drupal 7. The feeling I got from bdragon was that skipping over a straight port and providing a proper uprade path to locations as field-able entities in D7 might be something no one has time for.

At the time I discussed this with him, the plan was for me to head up a straight port for (1) with bdragon conducting the development of the field-able entities branch afterward. However, as of late, time constraints make it difficult for me to regularly commit myself to working on the straight port.

I'd like to hear what route others (specifically, others that are actually interested in contributing patches) think we should take and why. Maybe we can get some input here and those of us working on patches can get together on IRC and put together a roadmap of some sort.

I'm happy to help out when I can, but cannot guarantee spearheading the process on a consistent basis. If you've worked on modules before and want to see a port sooner than later, this is where you can help out.

I vote for path (1) and will chip in as best I can, I've managed to port most of my own small collection of modules so I've got the hang of the new db methods, forms and menus haven't changed much but I don't know about CCK or Views.

Path (2) sounds like too big a jump to me.

Do post here for IRC get-togethers, I will try to join in though there are timezone mismatches which the issue queue avoids.

Clear delegation of tasks helps avoid duplication of effort too.

HTH

I agree, path 1 sounds much more manageable and would give a working D7 version much sooner.

subscribe

Let's skip the IRC get-together and go for path #1.

I guess the next question would be how to handle branching.

I know that bdragon (Brandon Bergren) did some work on porting location to Drupal 7 fields and that work in is HEAD.

My suggestion would be starting a new branch point from the current DRUPAL-6--3 branch for a DRUPAL-7--3 branch. When the fields version in HEAD is ready for dev releases, we could call that branch DRUPAL-7--4. I'm not sure if I'm right about this, but I don't think the automatic scripts actually create dev releases until one is actually created by one of the maintainers, meaning it would be safe to create a DRUPAL-7--3 branch and not worry about people mistakenly downloading a tarball of it from the project home page, thinking that it was mostly functional on D7.

Anyone have any thoughts on this?

Your plan makes sense to me and your understanding of the release system is the same as mine.

+1 ;)

Sounds good to me too.

subscribe

subscribe. Path 2 would be fine if the upgrade path is straightforward, though I'm guessing it would take a bit longer.

Subscribe

subscribe

+1 on option 1.

+1

subscribe. +1 for option 1, quicker port and improvements later. hoping to start moving new projects to D7 soon and can't without Location.

subscribe

subscribe

OK. Looks like #1 wins the vote, though the write-in candidate named "subscribe" could've easily one as well ;-)

Anyway, the next step is to create a new DRUPAL-7--3 branch from the current DRUPAL-6--3 branch and create tickets for breaking down the individual pieces of the port into separate tasks.

I'm thinking the first task would be just getting the location module's basic node functionality working, to where we can configure locations for nodes when editing the node type, add locations to nodes, remove locations from nodes and so on.

We'll probably want to make user locations a separate task, views integration its own task and so on.

Being a bit thin on time myself, I will try to get to this as soon as I can, but to anyone else with commit access:

please feel free to do the branching and setting up a group of tickets. I'm thinking once the tasks are broken down, we can get patch submissions flowing a bit more smoothly.

ankur:
HEAD is the 7.x-4.x WIP already. http://drupal.org/node/943130 is the snapshot, but it isn't on the module page atm because it's only partially ported.

I'm fine with a more direct port as DRUPAL-7.x-3.x living in DRUPAL-7--3, but my focus is going to be HEAD. I am starting to get some time allocated on Fridays for contrib stuff so I'll likely get around to working on Location again finally as soon as I'm a bit further on the gmap stuff.

... which is not available for D7.

Location CCK 7.x-4.x-dev Defines a Location field type.
Requires: Location (enabled), Content (missing)

How can I enable the Location CCK field?

just renamed Issue title back to the original. SORRY!

Location CCK needs to be rewritten to work with D7 which has the old 'content' module builtin.

@bdragon in #34:

Sounds good. That seems consistent with the discussion we had at DrupalCon SF.

However, there are a couple of things I wanted to suggest/clarify:

A) Will the gmap module need a similar DRUPAL-7--3/DRUPAL-7--4 split?

B) We should probably create a separate issue for the DRUPAL-7--4 version of location and edit the project home page to indicate the more immediate "as-is" port to DRUPAL-7--3 and a road-map for the future DRUPAL-7--4 version of the module. No hard dates or anything, but a general overview of our plans.

I can volunteer a write-up explaining everything and send it over to you to post on the project home page or I can just make edits to the project homepage and you can make your own revisions. I'm fine with either way.

subscribe

Subscribe

Subscribe

I'm interested in contributing to the port project in particular cck integration. If anyone has any tips on what needs doing first let me know otherwise I'll go stumbling around in the dark until the lights come on.

subscribing.

subscribe

subscribing

subscribing

subscribing

@mori in post #35

Did you find a solution to enabling Location CCK? I am still seeing the same problem

I am using Drupal Core 7.0-rc2, and added the following modules
CCK 7.x-2.x-dev
Location7.x-4.x-dev

Location CCK - 7.x-4.x-dev Defines a Location field type. Requires: Location (enabled), Content (missing)

Also errors when enabling Location > node locations
DatabaseSchemaObjectExistsException: Table location_locations already exists. in DatabaseSchema->createTable() (line 623 of /Users/developer/Sites/drupal-7.0-rc2/includes/database/schema.inc).

Location CCK doesn't seem to work, or node location or user location in D7 currently.. ... happy to help / test if I can in any way.

Thanks, Gordon

@gorsti in #48

The only place the 7.x-4.x-dev tag for the location module exists is in the node for this project on D.O.

Currently, the CVS has not yet been branched for a D7 version and there have been no development releasees of a D& version of the module.

No work has been done on the port yet.

There's a plan (see my comments in #38) to begin this (actually a 7.x-3.x instead of a 7.x-4.x for now), but the resources (i.e., the volunteer time of myself and others) to begin this have not yet been as forthcoming as one might hope.

subscribing

subscribing

Subscribe

http://drupal.org/node/18723/release?api_version[]=103 - get latest dev
subscribing

subscribe

subscribing

I'd be willing to volunteer time to help port things over.

subscribe

Subscribe

subscribe

subscribe

+1

As mentioned in #21, #33, and #34, I've created a DRUPAL-7--3 branch. If you have commit access and have done recent work on the module, feel free to make incremental commits (to this new DRUPAL-7--3 branch) for the "straight port" and document it in the issue queue. Perhaps it'd be better to break up the straight port into separate issues for adding locations to nodes, adding locations to users, views integration, etc.

I've been doing some patch reviews/commits over the last few days and I will be able to spend some time on the 7 straight port over the next few days before I start back at work again.

Hopefully I will be able to get a fair bit done.
My plan is, as you mentioned, to work out from the core. So location > location_node > location_user > views integration > contrib.

- Crap, I just realised I have been committing changes only to HEAD and not also DRUPAL-7--3. I will go back over my recent commits tomorrow and get DRUPAL-7--3 up to date so it is in line with the DRUPAL-6--3 branch.

Keep up the good work, rooby, I'll try to keep up ;-)

A big thank you!

Thanks a lot, rooby. I don't want to promise anything myself, but I'll see if I can find some time to work on the port as well. Maybe if a couple of us start working on this, more people might show up.

Subscribe

Subscribe

Also, I guess the next release of the D5 version (5.x-3.2) will mark the end of support for the drupal 5 branch.

Any comments/objections?

@rooby in #69

Sounds good to me. In with new, out with the old.

I had a break from coding and knocked over some support requests and now back to it.

The DRUPAL-7--3 branch is now up to date with the latest patches committed to the other branches.
Luckily there weren't many to catch up on as it was created more recently that I assumed.

Tomorrow I'll start porting and as suggested I might create issues for the different parts of the module to keep track of where things are up to.

Subscribe

Subscribe

I have committed my first lot of changes to DRUPAL-7--3.

I have been working on location, location_node & location_user through the list of API changes and am up to http://drupal.org/update/modules/6/7#theme_links_with_context

Before it is ready for any use or testing I still have to:
* finish going through the list
* go back and do DB API changes
* go back and do any File API changes
* Move the settings page to where it should be

I probably won't have any time for it tomorrow but I should be able to get through it by the end of the week and have a version that is testable.

Please consider it still completely not working and don't worry about providing any bug reports or anything for the time being.

http://drupal.org/cvs?commit=479182

@rooby in #69
Pls. go ahead. D5 is getting old. Looking forward to start testing on D7.

Thanks rooby!

subscribing

subscribing

subscribing

subscribing

subscribing

subscribing

subscribing

HEAD (7.x-4.x-dev) now has somewhat working location_node and location_user. Despite me really wanting them to go away in the future, I need them for testing purposes so they're gonna stick around a while longer.

@rooby:
The approach I've been taking is to fix stuff as it's detected as broken and run coder a lot, instead of going through the list. You may wish to use some of the changes from HEAD in your porting.

@bdragon: Thanks, I will have a good look at DRUPAL-7--4 tonight, I'm sure it will be of use for my port.

It's probably a little time consuming but using the API list is partially for my benefit because I'm going to have to make/port many more modules in the long run so it's good to be familiar with the changes.

Subscribe

for now, views integration didn't work, right?

Sub

Update on 7.x-3.x:
Getting close to having a version for you all to test.
Most of the api changes have been done.

To do:
* The DB API changes for location.install are only half done.
* Move the settings pages to where they should be within the new site structure.

I will create a 7.x-3.x-dev version when it is ready for testing but I won't add it to the project page until the views & contrib parts are done too.

sub

I just wish to inquire that if it is possible to make city auto-search like state
And as far as I have read in other post I agree to the fact that city list are not fix across world
Can it be like {autocomplete from existing data} rather than {autocomplete from allowed data}

subscribing

@ babbar.ankit in #91,

Please keep the discussion in this thread strictly to the matter of porting this module to Drupal 7.

Your comments sound like they belong in another issue, if one already exists for it. If an issue with a similar feature request doesn't already exist, please create a new, separate one.

sub

subscribing

@babbar.ankit:

Try this issue: #404830: Location autocomplete implementation for cities

subscribe!

this has been coming together nicely, thanks

subscribe

Dev release up once the packaging scripts next run - http://drupal.org/node/1034952

I have done (a little) testing for location, node locations & user locations and it is all working for my small test cases. Please post bug reports if you find any in these modules (in separate issues, not here).

I still have to do views support and contrib modules (in that order most likely) so no need to post bugs for those parts yet.

I have only tested an install, I have not tested any upgrading from D6.
It may or may not work. Feel free to post bug reports for that if it doesn't.

rooby,

admin/config/content/location/geocoding
->
click: Configure parameters
->
admin/settings/location/geocoding/by/google

but on this page i see normal drupal administration options, (content, structure, appearance,etc)

location_cck is not working..

babbar.ankit... how can work location cck if cck is not present in d7?

There is sill a CCK module (for some functions not in core) which I think is need for Location CCK. But I think location CCK is not saving properly the information yet, there is a related issue.

1. If you find bugs can you please open issues for them. This issue is discussion related to the D7 versions, not bugs. It would be way too hard to follow what is going on if everyone starts posting different bugs here in this issue.

2. If you read post #100 it says that location, node locations & user locations are ported and contrib modules and views support are not yet done. This includes Location CCK, which is why that is not working yet.

@rooby thanks for the update. I hadn't reflected on Location CCK (or Location Field?) being part of contrib.

In any event someone has created #1026970: errors when adding a location field which seems to be caused by the missing Location CCK support.

I think there is still a bit of confusion with the versions.

The version I'm working on is 7.x-3.x-dev (DRUPAL-7--3), which is a direct port of the the 6.x-3.x version.

The version bdragon is working on is 7.x-4.x-dev (DRUPAL-7--4), which is going to be a rewrite (at least partially) specifically for D7 so it will make better use of the field api and other new niceties.

The idea is that the 7.x-3.x version could be ready faster than the 7.x-4.x version so people could use that until the 7.x-4.x version was all complete.

@bdragon:
You have made a lot of progress on the 7.x-4.x branch, do you think it is still worthwhile working on the 7.x-3.x branch as well or is 7.x-4.x still a fair way off yet?
Because if for example the 7.x-3.x version is ready in a week and the 7.x-4.x version is ready in two or three weeks there isn't really much point doing both and I could probably better spend my time either helping out on the 7.x-4.x version or, if you find it easier when there isn't multiple people working on the same thing, clearing 6.x-3.x issues.

@rooby:

Well I think 4.x is "usable" depending on what pieces you use, but needs testing. It turned into a bit of a mix of both straight ported stuff and new stuff.

Entity based locations definitely aren't done, but the old school node_location and user_location stuff is working ok at the moment. Upgrading from 6.x isn't tested yet though. (Heck, it might work though, I didn't actually change the schema..)

@rooby:

I'm kinda wondering if I should add an "enable experimental features" toggle or something, so it would be possible to hide unfinished stuff from people who aren't interested in testing. It might help with the "need to release much more often" problem....

Thoughts?

@rooby:

I guess that's my biggest worry -- Once something is used I feel compelled to support it. But I need testers / feedback to get some piece of functionality up and running... I'm split between getting early adopters on 4.x and making a clean split between 3.x and 4.x and handle switching as a pure migration instead of a transitional period where you can flip back and forth...

I am probabaly not going to be able to be the one to make the decision. I just am useless at that sort of decision....

Maybe the best thing would be for you to take what you need from HEAD to help get 3.x up and running as fast as possible and then HEAD can be treated as pure feature development. And maybe it would be possible to backport pieces of functionality from HEAD when they've stabilized.

@bdragon:

I guess my thoughts have been that people could use 3.x until 4.x was fully ready and then they would upgrade to 4.x. Then there would be no downgrading to 3.x, just like any other new release.

Maybe the best thing would be for you to take what you need from HEAD to help get 3.x up and running as fast as possible and then HEAD can be treated as pure feature development. And maybe it would be possible to backport pieces of functionality from HEAD when they've stabilized.

I think that sounds like the best way to proceed and also a bit less confusing to users in terms of "which version do I need to use?".
There could be a notice on the project page that says 4.x is an experimental version for testing new features and is not supported, 3.x is the supported version.
That way 3.x can be up and running soon and people can start using it, then as things like field support are working in 4.x we can back port and everyone can keep using 3.x.

And if the features get backported to 3.x we don't have to feel badly about not giving full support to 4.x.

@bdragon:
From my testing 3.x is usable but only for node locations and user locations at this point.
I have not tested upgrades from 6.x yet but I have done all the API changes for location.install so you can use those if you need to. DB API changes for location.install were fairly time consuming.

So I'll get back to work on 3.x and get that working.
The contrib modules should be a little quicker to knock over hopefully, probably with the exception of CCK locations, but borrowing code from 4.x should save a fair bit of time.

subscribe

subscribe, good job everyone. Really need a D7 port of this for a new project. Thanks for all the great work.

#114 is the right way to go in my opinion.

rooby -> no views support yet.

bdragon in 4.x version, u have views support?

Re #119:
No views support yet unfortunately but soon.

+1

subscribing

subscribing

Subscribe

+1 Subscribing

Re #100: There's still no dev-version on the project page. Does that mean that there's something wrong with the packaging script, or is the problem somewhere else? I guess more people will start testing when the dev version is visible on the project page.

(I've started testing, using http://drupal.org/node/1034952 together with GMap module. Will post separate issues if/when I find anything.)

I have also installed gmap dev and location dev, and will also begin posting more bug reports as well.

The more we all do this, the quicker the module will be ready for a production site.

Subscribe!

I have made some more progress on 7.x-3.x-dev, which will be available next time the package is rebuilt.

The following should be working (are working for my very limited testing):
location
location_node
location_user
location_addanother
location_fax
location_generate
location_phone
location_search
location_taxonomy

The following are not ready yet:
location_cck
views integration

I still have not tested any upgrading from drupal 6, only fresh installs, so there might still be issues there.

If (when :)) you find bugs please create new issues for them and don't post them in this issue.

@zirvap:
The reason I haven't put it on the project page yet is because it was still a long way from ready and I wanted to avoid getting a whole heap of bug reports for things that haven't even started to be ported.

I only have a couple of things now (cck, views) so I will finish up my half finished work on them before I put it on the project page. If they were less used features I would probably just put it up now but a lot of people will expect those areas to work.

Subscribe...

subscribe

subscribing

subscribe

subscribe, would love to see this module on D7

sub

subscribe

subscribing

sub

Hello rooby, thanks a lot for your work! I am in the situation to decide whether I should start building a new project with D6 or D7, and the views integration of Location is a decisive factor. From your experience: when would you think will you have the views integration in a stable version? Stupid question, I know, but if you say it is just "a matter of days" this would make a big difference for me compared to "a matter of weeks".

Thanks!

@henmae:
It is just location_cck, views and token support left at this stage I think.
Location cck is very close but there is one major bug in it that I have to come back to.

I will do views in the next few days and then there will be a usable version.
There will still be bugs to iron out at that point though I imagine but they can be sorted out as they are reported. The quicker they are reported the better.
I guess once views support is done just try it out and see if it is stable enough for your needs.

So far there haven't been any bug reports for 7.x-3.x aside from my own and one other that has been fixed so that either means that it is so far pretty stable, people have it installed but aren't using it or people aren't reporting problems.

subscribe. sounds good !

Will be installing a d7 test site along with the D6 production site I am starting to make. Not all modules from D6 are ported yet so can't make a move. Will be possibly reporting some bugs then.

subscribing

Gmap integration on 7.x seems a bit spotty. In 7.3.x, the map will show up for the coordinate chooser, but there doesn't appear to be any way to choose the coordinates, (in other words, clicking on the map does not fill in the coordinate fields or place a marker on the map). In 7.4.x, You can choose the map coordinates on the edit screen, but then the map is not displaying properly on the node once it is saved. It displays the coordinates as text and then includes a link to a google map, but the link doesn't properly include the coordinates. This is from a dev version from a few days ago. I am uploading the new dev now and will give it a try once I get it up and running.

Edit: would have posted this earlier, but I've had too many other problems on D7 that I've been trying to work my way through.

7.3.x is the straight port from 6.3.x, 7.4.x is more experimental and these two versions are being worked by different people who are looking at each other's changes I've no doubt.

Personally I'm sticking with 7.3.x for now and reporting bugs for that version. The bulk of the porting has been done, just Views integration and possibly Taxonomy left to do.

The location_node module has has been ported and works except (as you have noted) for the movable marker. There is an issue for that in #1051154: Nothing happens when you click the coordinate chooser map.
If you have any ideas as to how that can be fixed then report it there ;-)

What are the differences between the node location in 7.3.x and 7.4.x? It seems like the coordinate chooser in 7.4.x is working, so how difficult would it be to transfer that to 7.3.x?

NathanM:

Quote from roob7 (# 129):
"If (when :)) you find bugs please create new issues for them and don't post them in this issue."

subscribe

@rooby:
Please evaluate these bugfixes for 3.x.
http://drupal.org/cvs?commit=496262
http://drupal.org/cvs?commit=496264
http://drupal.org/cvs?commit=496268

subscribe

Is there going to be an upgrade path from 7.x-3.x to 7.x-4.x?

@animelion:
Discussion on this is around these comments.
#692938-113: Drupal 7 port for location module
#692938-114: Drupal 7 port for location module

At this stage the plan is that new features in 7.x-4.x will be backported to 7.x-3.x at least for now.
If this changes and 7.x-4.x succeeds 7.x-3.x (at some point I'm sure it probably will) then there will definitely be an upgrade path.

I'm currently using the Address module (http://drupal.org/project/addressfield) But I am very interested in using the location module instead. Should I go with the 3.x branch or the 4.x branch for a multi-user site I'm currently designing.

Go with the 7.x-3.x module.
The 7.x-4.x module is more experimental and won't be guaranteed to always be working, at least for the foreseeable future.

subscribe +1

@bdragon re #150:
At a glance I think there will be an issue with the first one (replacing content_fields() with field_info_fields()) because the array structure those functions return are different.
But I will go over the three of them properly tomorrow and actually test them.

I have added issues for things I know need doing so you can now see a pretty good representation of what is outstanding here -
http://drupal.org/project/issues/location?text=&status=Open&priorities=A...

I imagine it will be complete enough in the next day or two to put the dev version on the project page for testing by the masses.

@rooby re: #150:
Yeah, I guess it's different in HEAD. I'm not actually depending on cck anymore there, and location_cck.module is going to go away eventually in HEAD and moved directly into location.module.

@bdragon, does that mean I should avoid Location CCK and try to use Node Location instead? I want to have separate Location fields for different user profiles (using Profile2), so it seemed like Location CCK would be better. I can't use User Location, at least in its current form, because it doesn't recognize the different profiles created by Profile2, and puts itself on the main account form. And there's no way to have more than one for a user. I have users that have a personal profile, and some of them also have a professional profile, which may be at a different location.

@bdragon re #150:
I take back what I said before.
All three look good to me.

My commit for porting views support is
http://drupal.org/cvs?commit=497844

A lot of it you already have in DRUPAL-7--4.

I have tested it basically like checking that the fields work and testing some of the more complex filter/arg/sort's.
I'm sure there are probably bugs in there somewhere but I'll let other people find them.

I have added 7.x-3.x-dev to the project page.

There are still a few minor tasks that need doing but it's pretty ready for more people to be testing it.
All the modules and views support should be working now.

Once the main left over issues and any initial bugs are sorted I'll make a beta release so we can get even more people testing it.

Awesome work.
Just tested and i'm finding the following two issues:

1. Location_generate does not add locations to nodes, despite having "Add locations to each node" checked off and a minimum of one location per node on the content type.

2. Location_search has a redirect loop at /search/location . I'm assuming this is because of the dependency on gmap, which is not yet stable.

Please post all issues to new issues (unless a relevant one already exists).

It's way too hard to track an issue that starts hundreds of posts into an existing issue that has an irrelevant title.

Also, location search was probably the most complex port so there is likely issues there.

@bdragon re #150:
There was a little issue that I fixed here - http://drupal.org/cvs?commit=499672
Due to the fact we are dealing with the same field with different labels I just went with the machine name.
That how views displays fields in the UI anyway.

@bdragon:
Any objections to changing the location_cck module to be location_field?
See #1061496: Rename Location CCK module to be the Location field module (in UI, not in code)

Nope <-- obviously biased

No objections here.

@rooby in #167

I just want to throw this idea out there: since location_cck is an "unsupported" and "experimental" component of the location module, should we bother supporting the port of it to D7 fields?

Would it be better to just discontinue it and have locations implemented using the Fields API in the future DRUPAL-7--4 branch?

I'm also thinking it might make the upgrade path much easier.

ankur makes a good point.
The current version of location_cck is not a yet a fully proper fields implementation and is limited only to nodes.

Eventually location will be fully fields based and location_cck won't even exist.

I don't mind either way really. Functionality wise it doesn't matter what it is called.

re #170:
- oops I just reread your posts properly

I don't know that we can really just discontinue location_cck until the next version comes along since I'm sure that there are a large number of users who use location_cck in D6 and want to be able to upgrade to D7 ASAP.
Plus location_cck in D7 is already working (although it still has a couple of issues).

Will there be a way of converting existing location_cck instances to the 'proper' Fields API method?
Perhaps the same could be asked of location_node instances.

@hutch in #174

I don't want to say this for certain since I can't make a commitment to the actual work myself, but I think that when we do finally implement locations as proper fields using the field API on the DRUPAL-7--4 branch, there will probably be an upgrade path for doing so for both location_node fields and location_cck fields.

@ankur, good to know, I'll keep watching for this and chip in if I can.

I figure if we just leave location_cck in 7.x-3.x as is, once 7.x-4.x has full fields support we can do an upgrade path between the two.

I also don't think I like the idea of backporting fields support to 7.x-3.x once it's done as was previously mentioned because the change will be so large it deserves a new branch.

I'm willing to commit to doing the upgrade path as I don't like the idea of not having an upgrade path for any module let alone one with 30000ish users.
It also shouldn't be too difficult (famous last words).

Sounds good. I also agree very much that we should probably keep the future fields API implementation in the 7.x-4.x branch instead of back porting it (or pieces of it) to 7.x-3.x.

The changeover to default_country, the D7 builtin one should also be left to 7.x-4.x

@rooby: Re: location_cck -> location_field -- My plans for HEAD are to just roll the functionality into location.module.

Best just to leave location_cck in 7.x-3.x as is then.
I'm happy to do/help with an upgrade path from 7.x-3.x to 7.x-4.x when it is done.

Just an FYI,
I'll be away on holiday for the next 2 weeks so for that time I will be unresponsive and not committing anything.

Would definitely appreciate an upgrade path from node location -> fields api because currently it's the only way I can add address data to nodes via node_save in current 7.x-3.x branch! location cck saving just isn't sticking...

@rickman:
There will definitely be an upgrade path, just as with any other module.

Also, if you are having problems doing something that should be doable with location cck in location 7.x-3.x can you open an issue so it can be investigated and fixed.

@rooby.
It was only when trying to save locations programmatically. Saving to node locations worked, but not when they were cck fields. I don't feel too many people have this issue and the issue queue is already large enough as it is.

One question though: in the upgrade paths, is it best to use location cck now knowing that it's going to location fields? Or should we be using node locations instead? Or will it matter (ie upgrade paths for both)?

I plan for there to be an upgrade path (unless for some crazy reason it is impossible, which I highly doubt) for everything so it shouldn't matter.

Use whichever you prefer or suits your needs.

subscribing

subscribing!

Hey rooby, any chance of integration with the awesome Search API module (and specifically its Solr backend module) in 7.x-4.x?
Solr-powered spatial search would be pretty amazing.

Sorry for adding another 'subscribe post', really interested to hear whether or not Search API integration for proximity searching is feasible.

subscribe

Quick Q - is the 7.x-4.x version in GIT in a state that could be tested?

subscribe

subscribe

Same question as #192 here, I'm keen to try 7.x-4.x, but only if it's at least semi-usable, and not likely to lose my data.

sign me up

As a D7 port of location seems quite a while off, a highly recommended alternative is GeoField + Openlayers. Works nicely for me. :)

@RedTop

The 7.x-3.x dev releases for this module have actually been production-ready for quite a while now.

The geofield/open layers combo works well too. Unlike location, it has the ability to store regions in addition to storing points. However, it is currently missing the views integration that allows you to build views for proximity searches. It'll probably get there at some point though.

Until then, this module probably best suits the use case of being able to filter content based on its proximity to a user supplied location while geofield/openlayers may work better if you're trying to do something more novel with maps in Drupal.

Since we do have several 7.x branches, can we please mark this long issue as "fixed" and file separate issues from now on?

The project's page mentions and explains the 7.x-3.x & 7.x-4.x branches, but we also have a brand new 7.x-5.x. Care to also explain what that is about and also copy-paste that info on the project's page?

PS: on a second note (and to remember to file a separate issue if I don't get an answer here), what's up with the Location_node missing warning not allowing people to enable the Location add another submodule?

I'm the #200 comment of this issue!

PS: I agree, lets mark this as fixed :)

...done and done:

#1418884: Update the project's page with info about the 7.x-5.x branch.
#1418888: Location_node submodule missing - Can't enable Location add another

Hi,
could you please create a 7.x-3.0-unstable1 or -alpha1 or -beta1 or -rc1 release?
This would make deployment and upgrades a lot easier.

Thanks!