1

I need to add a city field for a content type in D7. I'm getting it from a federal census table and it's going to be around 35K+ records. Any thoughts on filtering this list down by state and/or county? Without some kind of filtering, I'm afraid I'll bring Drupal to it's knees. BTW, I can't just use a taxonomy list because I need to key the list on a city ID. I also will have county ID info. So, I really need to filter the counties list to just those for the state the user has selected, then the cities by that county.

Here's the general structure: User selects State -> County-> ->Cities.

I tried looking at the references module but the reference field I created didn't seem to be filterable.

Thanks for any assistance!

  • you need ajaxable dropdown list for countries – Aboodred1 May 8 '13 at 18:04
2

Sounds like a perfect job for Simple hierarchical select

Simple hierarchical select defines a new form widget for taxonomy fields to select a term by "browsing" through the vocabularies hierarchy.

The widget is available in node forms and as Views exposed filter.

You can add your locations as a hierarchical taxonomy, and SHS will AJAX-load child terms into a new inline select, then children of those in a new select, and so on. Something like

enter image description here

  • Thanks, but the issue with this tool is that it's using taxonomies. I need to import my lists with a key (e.g.: fips_city, city_name), but typically, taxonomy terms don't have multiple fields, just a term name. The reason for doing this is there are duplicate city names, but fips_city is a unique field, already stored in the related table data (which I'm importing in a feed), and I need to link that data to this data via the fips_city field. Any thoughts on doing that? – Jav May 9 '13 at 13:22
  • "taxonomy terms don't have multiple fields, just a term name."...in Drupal 6 that might have been true, but in Drupal 7 taxonomy terms are entities and just as fieldable as nodes. Contrib modules are written to extend core functionality, unfortunately they're very unlikely to match a use case that doesn't use Drupal's core elements. Just from a design perspective, you don't need to key the relationship on a city ID, it sounds like you'd just prefer to keep things that way. The parent/child term relationship offered by Drupal core is just as good, and will allow you to use contrib modules – Clive May 9 '13 at 13:28
  • Clive, I realize I can use custom fields for the vocabulary type and can store the information this way. I was trying to use a node reference for the sake of having more advantages of storing the lists in an actual node, but I think your suggestion is probably a good one if I can successfully migrate my data to test it. Thanks! – Jav May 9 '13 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.