While setting up the field groups for a new Expression Engine-based project (which I’m very excited to tell you about, just as soon as it’s ready!), I got to thinking: instead of creating a bunch of separate fields for an address—address, city, state, zip code, country—there should be a way to drop them all in as one field. A quick check of Devot-EE didn’t turn up such a thing, so I threw one together this afternoon. VZ Address is a fieldtype for EE2 that combines the standard address fields you’ve probably set up many times into one unit. It even gives you a variety of ways to get the address data back out, and it works as a cell in a Matrix field.
Template Tages
Single Tags
{address_field [style="microformat|schema|rdfa|plain|inline"]}Will output the complete address, in a standard format. Use the style attribute to get code that supports one of the markup standards for parseable content (defaults to microformats) or to get the address with no html markup at all (plain or inline).
{address_field:street}
{address_field:street_2}
{address_field:city}
{address_field:region}
{address_field:postal_code}
{address_field:country [code="yes"]}
Output particular pieces of the address. If you use the parameter code=“yes” on the country tag, you will get the the international country code rather than the full country name.
Tag Pair
{address_field}
{street}
{street_2}
{city}, {region} {postal_code}
{country}
{/address_field}
If you need more control over the output, use the tag pair to output each part of the address individually.
Installation
Download and unzip the archive. Upload the vz_address folder to /system/expressionengine/third_party/.
Comments:
Chris Brauckmuller on June 28, 2011 at 11:31am#1
This looks very nice. Will definitely download and give it a whirl!
Dylan Smith on July 18, 2011 at 9:38pm#2
Would love to see a 1.x version of this!
EliVZ on July 19, 2011 at 9:33am#3
Chris- Thanks! I hope it worked out for you.
Dylan- I would love to say that there is a 1.x version in the works, but honestly I don’t know when I will have time to port it. You are welcome to give it a shot, if you know some PHP. Or obviously if you or your employer wanted to sponsor the development, we’ll talk…. :)
Adam Kragt on July 22, 2011 at 3:22pm#4
I don’t suppose you have any plans to add geocoding? It would be perfect if it could spit out latitude and longitude as well. :)
EliVZ on July 23, 2011 at 10:46am#5
Adam- Yes! That is in the plans, although it will probably be another month or so before I have a chance to get to it (going on vacation). I will definitely keep you posted and send you a beta version once I have it.
Raj on August 6, 2011 at 8:10pm#6
Can you make the city and states auto populate too ... like you did for the country….fantastic addon…was looking for it since long
EliVZ on August 6, 2011 at 8:39pm#7
Raj- I thought about that. The problem is, I would need some kind of API to provide that data, as I’m not going to compile a list of all the cities in all the states in the world. I haven’t looked very hard for one yet…. maybe someday.
Daniel Matarazzo on October 11, 2011 at 12:59pm#8
Hello, for some reason after installing the latest version of vz_address (as of this writing), I’m getting the letter “a” returned for each field, even if the field was left empty in the cp. For example, a simple call to my field in the template, {practitioner_address style=“plain”} returns this:
a a a, a a a
I tried removing and re-installing the plugin to no avail.
Assuming I can get this fixed, is there any way to search addresses via dynamic_parameters?
Thanks!
EliVZ on October 11, 2011 at 4:52pm#9
Daniel,
The new version - 1.1.1 - fixes that bug. Good catch!
As for your other request, do you mean using the search:address=”” style searching? It should work as long as you use “contains” matching (the default). The data is stored as a serialized array, which means each part of the address is stored as normal text, but there are random characters between them. So search:address=“New York” would work but search:address=“New York, NY” would not. I don’t think there is any practical way around that caveat.
Dane on December 8, 2011 at 1:12am#10
I have a similar question to the last one. I’m trying to display listings by state, and would like to be able to show, for example, all of the Arizona listings on one page. The only way I can get it to work is to use: search:address=“AZ” - the problem with that is that it returns results that have, for instance, the word “plaza” in the street address, because of the az in the word. Unfortunately search:address:region doesn’t work, and neither does search:region.
Any ideas for me?
The only other solution I can think of is to create a category for all 50 states, then go through my hundreds of listings and add them to their respective state categories one by one.
Or I guess I could use an {if} statement inside of the channel entries to filter out anything that doesn’t match the field, but I’m afraid that will be server intensive, since (I believe) it would have to parse every result to match the field.
EliVZ on December 9, 2011 at 3:50pm#11
Dane,
Unfortunately, modifying the search parameter in that way would require overriding the entire exp:channel:entries tag, which would be impractical (if someone has an idea for a work-around, I’d love to hear it!).
So I think your options are:
1. Use the {if} statement, like you mentioned. You are right that this will have a processing overhead… you would definitely want to cache the template if you do this. Mark Croxton’s Stash and/or Switchee add-ons would be very useful here.
2. The data is stored as a serialized array, which is a fairly easy-to-read format. (You might want to take a look in your exp_channel_data table to see an example.). The values are quoted, so you should be able to do something like
search:address=‘“AZ”’to get what you want. Or evensearch:address=‘“region”;s:2:“AZ”’to ensure that you only get values in the “State/Province” field if there is the potential for the same value in tho fields, with “2” being the length of the value.Neither is ideal, I’m afraid, but they should work. I will keep this problem in mind and update the add-on if I have any flashes of inspiration.
Dane on December 9, 2011 at 4:19pm#12
Perfect! That last solution works exactly like I need it to. You saved me a lot of time doing tedious categorization.