Upgrade Location Module to 5.0

I'm only using location sparingly, but I can say that this patch applies without error.
Installs without error and allows me to update the settings.

Some additional fixes:
- Changed "form_render" to "drupal_render"
- Fixed some errors with t()s still using % resulting in HTML in the string.
- Removed extra admin/settings/location path.
- Added drupal_get_form + callback arguments syntax for settings pages.

Marking code needs work because:
- The location search form is still messed up
- I'm not seeing location fields on node edit pages
- Haven't tested user locations yet, but I'm reasonably positive they won't work.

Unfortunately, I've used up my allotted time to port this module, so hopefully someone else can take it home the rest of the way.

Subscribing to issue, I may be able to provide some help soon.

Subscribing to issue as I have been tasked with :-

• Cleaning up the bug issue queue
• Ensuring the D5 upgrade is complete

If anyone is working on this right now, please let me know, it may save me a whole bunch of time ;)

This needed doing also http://drupal.org/node/64279#node-type-settings
Patch re-rolled to include

Subscribing

rerolled to include location and location_views info files with a dependency on views and remove the help items as appropriate. Someone may want to add version information. Additionally i just noticed that "/admin/settings/location/geocoding/us/google" does not work. I'll take a look into this but patches welcome.

my mistake. patch was reversed. this is updated and the right direction. sorry for the spam.

subscribing

So is there a 5.0 version available?

subscribing

subscribing

I'll be testing the patch over the next week or two.

And should the priority maybe be bumped up a bit? It's getting awful late in the 5.0 development cycle to not have such a crucial module ported...

I'd recommend a pause on further work for this task as I am currently working on a feature request from a client that involves enabling multiple locations for users/nodes. I don't know how much it will invalidate the hours of work already spent on the port patches, but if it ends up changing the module too much, I'll take the port on myself.

-Ankur

I think too long a pause is unacceptable. If you want to fork it for the client and come back to this later, fine, but a lot of us need this sooner rather than later. We want to be able to use Drupal 5.0 for our new clients in the next political cycle (since it'll almost certainly be released within the next month or two) and a significant delay in this module would really kill us as we use it on every one of our sites.

I agree with Greg's approach.

It also might not be too unreasonable to see if anyone else is interested in being a maintainer with Ankur -- I know that would help alleviate the long pauses for everyone. I'm not sure if anyone can/wants to do that nor if Ankur wants that, but just thought I'd throw that suggestion out there :-)

Thanks. I'll be doing this this week.

BTW, Merry Christmas!

Multiple locations patch has landed, resume patch for 5 now??

i'm all for getting this going. location is the only module on my site that hasn't been updated.

Me too; we really need a DRUPAL-5 branch, and these changes are all pretty basic.

Porting and branching to DRUPAL-5 is the next priority. My personal deadline for it is the end of MLK Day (Monday Jan 15th), though most likely it will be done before that.

I actually plan on doing some work on it tonight. I don't suspect that it should take more than an hour or two over 3-4 weeknights.

-Ankur

Subscribing to follow

So, I've committed the attached as the current patch to HEAD to bring location upto 5.0. However, I wanna give it a day or two of testing before I branch it for 5.0 in CVS. All other new features and whatnot will be considered once the existing functionality is verified as bug-free (or at least as bug-free as the latest 4.7 version). In anycase, I added some extra stuff to the port patch when I discovered a couple of minor errors (such as the missing display of locations in the node-view because of changes to nodeapi).

In anycase, if anyone finds something broken in this HEAD version that wasn't broken in 4.7, please report it here. I'll give it 2-3 days before the next commit (if one is necessary) before branching to DRUPAL-5.

To greggles, webchick, and michaelfavia, I want to give you guys a big thanks for submitting the patches. Because of recent changes made to 4.7/HEAD, the patches you guys submitted wouldn't apply directly via the UNIX 'patch' utility, but it still saved me hours of time since I was just able to go thru the diffs manually and apply them by hand.

Ack. I left AjK out of the list of people to thank for submitting patches.

Hey! Where did everyone go? Thought people's intense desire to see this thing ported and branched asap would yield some testers...

ankur, I haven't had time up to now, but I want to get location_views ported, so I'll be testing soon , hopefully

ankur, i've got it up on a test site (http://scratch.kpsu.org/) but a separate login bug has kept my users from logging in to really test it.

A small item on the .info file - you should add

version = "$Name$"

Also, do you want to declare a package for location? Are there enough location-related modules for that to make sense?

I've run into problems in the configuration area, setting up 'map links' and 'geocoding options'. The values aren't getting saved, and in the setup area for geocoding I'm getting extra blank lines. I've set up two countries, Canada and the US, if anyone wants to try to replicate the problems. I'm trying to find a way to get it working but no luck so far.

There is also still some use of $_POST['op'] in various places and that no longer works.

Also found a form_render on line 324 of location.module that needs to be changed to drupal_render.

I'll try to provide a patch if I can get it working, but in case someone else gets to it first, those are issues I ran into so far.

Just reporting back that other than the configuration problems, this seems to be working in 5.x. I've tried out both node and user locations.

Only one small issue, not enough to hold off on a port. The css needs some work. The node edit form is messy looking in a reasonably wide screen, the fields float together, which is fine except the labels sometimes get separated from their fields and the descriptions get tacked on to the right side of input fields instead of taking up their own lines on the form.

I'm too quick to hit the enter key. I meant to mention that I now have the cvs version of Location Views updated for 5.x and I tested that, too, and the Views integration seems to be working.

I think it'd be good to group location-related modules into a 'Location' package - we have location, location views, gmap, georss, kml, and maybe a few more mapping related modules down the line.

There is also an issue with adding links to the description fields in forms, in that they're not rendered as links but just as plain text. See one of the content type forms, under 'Country names' field for an example.

Attached it a patch that should fix this link based on http://drupal.org/node/64279#t-placeholders

Taking geodaniel's hint, I started looking at the links in t()'s and found a few issues.

Thanks drewish, looks like a better solution than my patch. Before going with the method in my patch I was attempting to do something similar but without using the url() function, which meant that it wasn't working without clean URLs.

I used the patches above to fix up the t() calls, but the forms for map links and geocoding still need some work. Regrettably, this will take another day.

-Ankur

Search by location had a small bug, an extra drupal_get_form() in location_search_get_form().

Patch is attached.

Ankur, I just noticed a mistake in the GeoRSS bits: the tag should be geo:long, not geo:lon (attached patch removes the old commented out lines around there too)

subscribing

Patch in comment #37 was moved to

http://drupal.org/node/113943

sans whitespace.

and the one from #38 is covered by a proposed patch at http://drupal.org/node/86624

Re: Comment #40 -- It is true that this module is mostly ported, but in your light testing you should've come across the fact that the search function does not work. I don't intend to branch for 5.0 until I can get this search function to work as it did in 4.7. I don't want my name on something that doesn't do what it advertizes. If someone is interested in looking at the search function and putting in a patch, please by all means do so. I'm interested myself, but only end up w/ 5-10 hrs a week to spare for this task.

-Ankur

See comment #37 about the search function; I ran into this issue in my testing and provided a patch. There may be more testing required beyond what I patched, but for sure the change I made was necessary.

I also opened a separate issue about this at the request of the opener of this issue.

Seems like a lot of work for a one-line fix, but I'm happy to do what's required to make things better.

subscribing

subscribing

subscribing

It took me a good bit of searching to discover that HEAD was being developed for Drupal 5. If the current problems are specific to Drupal 5, we should move the files from HEAD a DRUPAL-5 branch so that people can test it with Drupal 5 and contribute patches. There's no need to create a release until it's fixed.

subscribing

Location module is now branched from HEAD as DRUPAL-5 (I've not branched anything under contrib).

Ankur is snowed under and asked me to branch, and I should be able to put some time in to testing patches and thing in the near future too. Let's get it up to a releasable state and then create the release node for it.

subscribing...

I have a difficult time finding the "Head" and "Drupal - 5" locations. Would someone please put a link here and LIST the files which should be downloaded for testing. If you don't mind, would someone please do that for GMap also?

I found the CVS and showed "dead" files in GMap, didn't find it in location. Knowing all the different places to go and what to look for are a bit confusing to me.

Thank you.

Joel

reeljustice: if you wait a little while the autopackaged 5.x-dev version should show up for download from the project page.

OK, I think I figured it out.

Go to CVS for the module http://cvs.drupal.org/viewcvs/drupal/contributions/modules/location/?onl...

Look down below the listing of files to a DROP DOWN which allows to see the various categories --- Head, Branch, Drupal 5

I would assume, for testing purposes in Drupal 5 we would download the files in the Drupal 5 list.

I've read a bit about installing the "contributed" modules into a new directory /sites/all/modules or something of the sort. Should the install of the listed modules be in the "regular" modules folder or in the "new" modules folder?

Thanks,

Joel

Honestly, imo with as wide-spread as this module is, it's way very important to get good testers.

I'd highly recommend creating a 5.1.x-dev release, and in the release notes clearly stating that THIS IS ONLY FOR TESTING PURPOSES or whatever. The vast majority of people who use this module every day are not going to be able to figure out CVS, and thus you're going to get only developers testing and hey, we miss stuff. :)

However, it would make it much easier to make this distinction if there were "official" releases for the 4.7.x and 4.6.x branches, and the dev snapshot releases were unpublished.

reeljustice: to answer your question, it doesn't matter, but it's recommended to put contrib modules in sites/all/modules so that they're separate from the core stuff. When time comes to upgrade, you just save your "sites" and "files" folders aside, blow away the old files and replace with the new ones, and set the sites/files folders back.

As opposed to having to go through a huge list in the modules directory and try and remember "which of these modules were core modules again?"

Thanks for the input webchick. Based on your advice I've created a release node for 5.x.1.x-dev which will be available as soon as the packaging script is run.

I don't know if you guys have seen this, but it is a pretty powerful implementation of Google Maps as a graphical type search http://www.recreation.gov/browseMapsRecGov.do?topTabIndex=CampgroundMap

The government implemented a significant portion of this within the past couple of weeks. This is the part of the US Governement where you book your camping/RV reservations in federal campgrounds.

My goal is to implement a similar type process using GMap, Location and anything else needed. At any rate, what I think is an exciting method of "searching".