CCK Widgets and Fields

+1 for providing CCK widget+field as an alternative to the current approach. you could also include an unlimited number of location fields, and give them different names...

Here's what I was able to accomplish a few hours:

(see attached)

It works for adding fields, inputting values, and displaying them on the node. Unfortunately, it will need a bit more work to function with the Location API to integrate with Views, Gmap, etc. Maybe someone else can run with this? Otherwise, I'll work on it more as I have free time...

I started out by writing a contrib module I call location_cck.module and it works great, but I discovered that it really belongs in the core of the module... For instance:

1. There is no need for the .install file, as CCK handles all the SQL stuff for you.
2. If we are providing as a CCK Widget, then there's no need for any of the hook_form_alter() stuff for integration with nodes--it's just duplication and nobody would use the old method given the choice. Same goes for users--we can just use nodeprofiles and/or usernodes, instead.

I have already written most of the new code (501 lines) and the widget currently works. There's are several new advantages to this approach that are the same for any CCK Widget, but a couple I am excited for specifically are:

• Add an infinite number of locations to any node
• Provide default values for each field (even works if the field is hidden to create suppressed_values)
• Control which fields are visible per-field
• Control the weight per-field
• Control how output is displayed per-field
• and more!

Things that are lacking are:

• ripping out deprecated code
• ensuring the CCK widget will work with the Location API for integration with Views, GMap, etc.
• implementing AJAX to allow instant addition of multiple/infinite location values. (currently only supports 1 value per field, but you can add multiple fields to a node with CCK and this has the added advantage of being able to name them and configure them all individually, so this may not be necessary)

Things I would like to see added once the dust is settled:

• 3 field formatters to choose from to control display of output on nodes: Address (default), GMap, GMap + Address

Mike,

+1, Great work! Just what I was looking for and surprised it did not yet exist. It makes sense to me to use one or more CCK fields for locations.

I hope I have some time soon to look at your module and the location module. A quick question I have right now: why is the field data stored in the 'content_type_x' table and not right away in the location table. If it would be stored in the location table, wouldn't the location module handle the rest (Views, GMap, etc) by itself? Or am I wrong?

Marco

Subscribing. Looks great!
greetings,
Martijn

+1 for this, I'd like to use the city as part of my Autotitle setup.

Is there a module page for this?

Ideally it won't need a module page, it will ship with location module directly...

+1 for having this as part of the location package.

Update to the module posted above. Includes some bug fixes.

In the mean time, can we use simple cck fields (input text) and hope than one day it will be possible to tell to a new generation location module "this field is the city" "this one is the postcode" "this one is the longitude" ?

This would be great

Good work, will this be included in location?'

thanks for your help webmasterkai. we still have a ways to go before this is really very useful. i haven't had time, but after speaking with bdragon it sounds like this functionality is slated for Location 3.

I just wanted to call some attention to rconstantine, who has been doing an excellent job of maintaining the cck_address.module. It even boasts some features location.module never provided, like zip code validation based on the country. IMHO, these two modules should be one. Now that Location.module has a new maintainer, bdragon, is there some possibility of interoperability or merger between the two? Maybe we don't have to build it from scratch.

Subscribing

hello!
Is this patch still in need of testing (just checking since it's not clear from the comments so far whether this would still be relevant or useful)?

If so, what (if any) are the major things that would be helpful to test?

Cheers!
Scott

Just what i needed ! this approach seems clean. One question though are the maintainers willing to depend on cck, or is it just an optional integration point ?

+1 to CCK'ifying the locations module...

+10 to CCK'ifying the locations module... ;)

This is awesome!!! I was wondering if you could add a method to fill out the location data with cck_address data already on the stored in a node or would it be better to do this once with a SQL command in phpMyAdmin and then convert all fields to use the Location widget instead of the cck_address?

+1 CCKing D6 version of Location 3

Would the D5 patch in #11
work with location 5.x-3.0-test2 ?

Any chance that this addition finds
its way into forthcoming 3.0-beta?

Subscribing to this, I like the idea.

What is the latest on integration with Views and GMap?

Subscibing indeed

I've been trying to port Location_CCK to D6.5 as I think it's just as important to have it now as it was in 5.x
Atleast for my website. I use it for things like "Birth Place" on profiles and information pages. In 5.x it worked great out of the box with gmap.

Anyways...

Currently I've made some basic changes, and uploaded what I have, I'm hoping someone can figure out the small left over issue, to get this functioning, but I'm lost. (I believe it's to do with the theme functions, that I just don't grasp yet)

Right now the module can be installed and activated without errors.
You can add Type "Location", and widget "Location Field" (no errors)
In the settings page, you can choose single or multiple (only tried single), and you can select the fields to display. (no errors).

All seems fine on the admin side, but then when you go to create content the fields do not show up for input.

I have an idea what needs to be changed, just can't figure it out at this time, PLEASE HELP!!!!

Sorry, last upload had a syntax error I must of missed. Here's the corrected version.

Whoops! I didn't notice it was completely missing from the 6.x tree!

Looking into it.

hey that would be awesome

Yes, getting the cck fields back into the 6.x tree would be huge... need them for a project right now :)

OK, did some serious work on this.

It should be mostly working now.

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

Hi bdragon - I enabled the new 6.x-3.x-dev location module & tried adding a location field.

But the next screen is blank white: http://MYSITE.COM/admin/content/node-type/profile/fields/field_profile_l...

it's not the white screen of death - it's just this screen that's affected.

Is there anything I can check beyond that at this point?

#326624: location cck field error after saving new field: fatal: cannot use string offset marked dupe.

The fatal error should be fixed now, by http://drupal.org/cvs?commit=149214.

I just tested out the Location_cck widget/field from the DEV I downloaded today (10-31-08 Happy Halloween) on a fresh download of Acquia D6 and here are some things I noticed:

-Phone numbers do not display after submit
-Nothing display's for that field in the "preview" (when you hit preview button instead of submit)
-The Display settings (where you check the items you want it to hide) seems to do nothing.
-Address dont seem to be geocoding, I think this is the same problem as Tristan.oneil above.

Also, is there a way to hide the Long/Lat text entry boxes?

Update, I got my cck location fields to geocode, I have no idea how, they just started working.

But the field lists everything grouped together in views (which is kinda to be expected).

My initial solution to all of my problems is to just not use the cck part of this module. It seems to have quite a few little problems. I decided I didn't need to use it for my current project so I wont :).

Great! Nice work!

Subscribing

subscribing

subscribing

subscribing

tagging as a master issue.
Also, #347030: location_cck needs a views relation seems to be one of the major missing components to people using the cck locations, and #343943: CCK location not available to views/proximity-filtering > PATCH failed for 5.x is the hack some people are using to get around this while they wait for the relation to work.

I'm tempted to mark this issue "fixed" as cck locations are in!

yep. marking this fixed. Please search for issues, or open a new issue for specific things wrong with cck locations.