New version of previous vcard submission

[markc]

See here for background:

http://forums.fengoffice.com/index.php?topic=3714.0

I've done a re-write of the previous version. I also have a version of the patch that adds a second and third address line to each address (see http://forums.fengoffice.com/index.php?topic=3919.0 ) and because I also have several versions for 1.6.2 and 1.7 in various states of completion...the scope is getting a bit beyond me. I'm not quite as sure about this version because I can't as easily visualize all versions of my entire code. It has gotten a bit big to keep my head wrapped around, but I think I'm just imagining problems at this point. I'm an IT guy, not a coder!  

However! I'm pleased to say that the code works great for us; much better than the last one (which went into 1.7). Some examples of the improvement is that it can classify phone numbers better, it understands parameters better ( "TYPE=HOME,WORK;" and "TYPE=HOME;TYPE=WORK" come out looking the same! ), and for contacts that are already in FO it can usually do a lossless export and reimport including FO only fields. It tags those FO only fields as custom in the export and the importer knows where to look. AFAIK the way it does this is within the vcard spec.

It is commented out for a later version, but this code was also close to being able to handle strings that are have their own delimiter escaped within a field. The regex matches odd or even numbers of backslashes to tell preg_match_all() whether to break to the next field or print the backslashes and the delimiter literally. Didn't quite get that part working.

I'm going to attach four versions of "v2 final", if you will. At one point each one was thoroughly tested and I THINK I've kept them cleanly applying to their various code-bases. You might be able to apply them and use them in production straight-out, but I'm only using the last one from here on out.

Since my patch list has been growing it is my hope that the vcard part will get committed, and that maybe even the devs will see value in having two more address lines in the contacts object (since vcard supports it and that support is already working in that version of this patch). It'd let me juggle less but I suppose I'll live if I have to keep updating these patches myself to your new versions.

Same patch instructions as the last version. I think that is about it. Let me know if you have any questions.

Hope these help,
Mark

1. vcard v2 for 1.6.2
2. vcard v2 for 1.6.2 w/ address line 2/3 expansion
3. vcard v2 for 1.7
4. vcard v2 for 1.7 w/ address line 2/3 expansion    <(in production!)

[markc]

(edit: I'm of course only saying you need to do this part if you're using one of the patches that expands your address fields!)

OH!! Here is what I used to make mysql play nice with my new fields! If you happen to apply my patch before running the main installer, the patch fixes the schema file so you shouldn't have to do this.

If not...you need to add the following fields:

w_address2
w_address3
h_address2
h_address3
o_address2
o_address3

Base them on this example for the first few, or install phpmyadmin, or something. Be sure to update the name of the contacts table...yours may not be og_contacts.

ALTER TABLE `og_contacts` ADD `w_address2` VARCHAR( 200 ) NULL AFTER `w_address1` ;

ALTER TABLE `og_contacts` ADD `w_address3` VARCHAR( 200 ) NULL AFTER `w_address2` ;

...etc...etc...

[cabeza]

Thanks a lot markc!

[markc]

Sure thing!

I've already thought of a few improvements besides getting the escaped delimiters regex working.

-For one I only put in the english lang info for the extra address fields.

-Also I came across a vcard that had quoted-printable encoding. My function just imported the encoded characters literally. Looks like vcard spec for v3 dropped that encoding and only supports b-type. This one did at least say v2.1 inside it though so it was kosher.

I see php has a convert function for QP so I may have to add a check/convert for that. I suspect there may be more of this issue to come with other types of encoding.

Mark