The "old" location fields or the "new" cck location field implemetation is the better choice to use for me if our project will be ported to Druplal 7 and future versions of location module? Which orientation will be supported in future? And on other side, which is better choice if we look over other aspects?
Comments
Comment #1
yesct commentedtagging
Comment #2
vthirteen commentedsubscribing
Comment #3
bunset commentedsubscribing
Comment #4
roball commentedGo with Location CCK, which is the future-proof approach, but still buggy.
Comment #5
boabjohn commentedSounds good: but to ask the perhaps obvious...*how* does one "go with" location_cck?
- I have already used Location (old?) to add locations to nodes of this type, based on options set at the content type/edit interface.
- Using devel, load I can see two entries: location (array 1 element) and locations (array 14 elements). This is already a bit confusing...are both arrays necessary?
- I have the location_cck submodule turned on, but have not dropped a cck-location field into my custom node type yet
- If I add a cck-location field nto this cotnent type, what will happen next?
-- yet another location entry will appear and the existing arrays as well?
--what happens to the settings on the content type/edit interface: are they overridden by cck field configs?
Happy to experiment or RTFM (where?) and keen to help with the evolution from old to new...
Comment #6
yesct commentedI'm not sure...
maybe write a rule (rules module) that copies (use custom php) the node location info to the cck location info, trigger the rule on node save.
Then do a views bulk operation so get it to trigger on all the nodes you want it to.
then disable the rule, and disable the location (node location) module?
Comment #7
ankur commentedGo with the classic location fields.
There's less views integration for location CCK fields. Location CCK fields were originally going to be the future, but circumstances have proven otherwise. There is a plan to move locations into their own "fieldable" "entities" in Drupal 7, but that probably won't happen for a long, long time. If and when that happens, there will be an upgrade path allowing you to preserve your existing data.
Comment #8
boabjohn commentedBack to the future: Classic location...okay, must have missed a few chapters from the discussion forums...
Guess I'll leave this thread parked and monitor developments.
@YesCT: thanks heaps for the suggestion...I was thinking about getting off cheap by using a computed field to pull out selected high-value values, like Province (so I can use Province as a facet in faceted search).
My php is non existant: a friend got me this far, but it doesn't actually return any values:
This is trying to grab the value of 'province' and pop it into the computed cck field 'location_state'
I get no value stored in the field after editing/publishing.
Is there any chance someone could help me with the syntax here (and also being mindful of the confusing "duplicate" arrays of location and locations)
Topic drift? Maybe, but if people come looking here for location classic vs location_cck they (like me) could be mostly interested in getting a bit of selected cck-like functionality going...and computed field seems like a reasonably promising strategy (I think).
Little workaround tidbits like this can make all the difference (in my experience).
Thanks in advance for any assistance!
Comment #9
BenK commentedSubscribing
Comment #10
nevergonesubscribing
Comment #11
pancapangrawit commentedsubscribing
Comment #12
g.k commentedsubscribing
Comment #13
kehan commentedsubscribing
Comment #14
naught101 commentedsub
Comment #15
legolasboClosing old D6 issues as D6 is end of life