Properly handle new `mc-*` fields

[gMagicScott]

Extracted from #20

In a recent update, 1ShoppingCart split up how it handles client names. It used to only have a Name field (that still works) that contained the contact's full name. Now they have split it up:

• mc-firstname containing only the first name
• mc-lastname containing only the last name

  Displaying merge data on the front-end

Currently, there is are two "magic" fields:

• [as what="firstname"]
• [as what="lastname"]

They look at Name and split it at the first space into first and last names.

I think the best solution is to use the first available

1. mc-firstname or mc-lastname
2. split up Name (the current way)
3. output the default

For displaying the full name:

1. mc-firstname + (space) + mc-lastname (as defined using above flow)
2. display only mc-firstname (as defined using above flow)
3. output the default

   Editor Button

In the available fields, according to the defaults, First Name and Name are available. They output [as what="firstname"] and [as what="Name"] respectively. Of course that might change depending on what settings are provided on the admin page.

I think Name is still good as-is. Should we

1. Update First Name to use mc-firstname?
2. Add Last Name to the drop-down using mc-lastname?

   Autoresponder merge link

When generating the link, currently the variations of first and last name are combined to only use Name:

• firstname
• mc-firstname
• lastname
• mc-lastname

This does result in a shorter URL than if we included all of them, but could present issues where a double-word first name could be split incorrectly (think "Mary Jane Doe" where firstname should be Mary Jane and lastname should be Doe).

One alternative is to combine like this:

• firstname or mc-firstname combines to mc-firstname
• lastname or mc-lastname combines to mc-lastname
• Name splits into mc-firstname and mc-lastname

A second option is combining like this:

• firstname or mc-firstname combines to mc-firstname
• lastname or mc-lastname combines to mc-lastname
• If both mc-firstname and mc-lastname are needed, combine to Name
• If Name is used, combine mc-firstname and mc-lastname into it.

Are there any other ideas for how to construct the link? I prefer the first option. The link will be a touch longer (there's a limit, but I'm not sure where that limit is), but will generate better names (as in the "Mary Jane" case)

Other

I think that covers everywhere that this is an issue. Have I missed anything?

[twinsmagic]

just got done with gigs for the weekend. Give me a day or so to think about these details. Thank you!

[twinsmagic]

The issue is that it depends on if they are using an "old" form or "new" form. The old forms work off of "Name" but the new forms work off of "mc-firstname" and "mc-lastname". So I'm not clear on what the solution could be besides having two versions of the firstname merge code, one for old and one for new.

[twinsmagic]

And depending on the initial form, that will determine the hyperlink that populates. So I'm still not clear how we can address that because it depends if they're using the old form or new form on the initial step that leads them to the e-promo-kit. That will determine which version of the merge codes we need, which will then determine which version needs to show in the populated hyperlink.

[gMagicScott]

No need to rush @twinsmagic to these. I'm just trying to brain dump any problems/ideas into one place for when we're ready to begin on 0.6.0. Feel free to start your own. I got a few labels set up. "On Deck" is anything that is truly ready to be worked on. Anything without a "status: X" is just mostly so it's not forgotten.

---

I find it easiest to think about each "page load" by itself.

When the page content contains this:

[as what="Name" default="(client full name)"]
[as what="firstname" default="(client first name)"]
[as what="lastname" default="(client last name)"]

Scenario 1

An old form is submitted using Name. We will call the client "John Doe" Name is available to merge. mc-firstname and mc-lastname are not available.

1. [as what="Name"]
   1. Combine mc-firstname with mc-lastname Since neither are available, continue
   2. Use Name if available This works. Use this value and stop here.
   3. Use mc-firstname only We are already done, unneeded step.
   4. Use the "Default Text" We are already done, unneeded step.
2. [as what="firstname"]
   1. Use mc-firstname It's not available, continue.
   2. Split Name at first space and use first part This works, use this and stop here.
   3. Use the "Default Text" We are already done, unneeded step.
3. [as what="lastname"]
   1. Use mc-lastname It's not available, continue.
   2. Split Name at first space and use second part This works, use this and stop here.
   3. Use the "Default Text" We are already done, unneeded step.

Output:

John Doe
John
Doe

Scenario 2

An old form is submitted using Name. We will call the client "John" (He didn't fill out his full name) Name is available to merge. mc-firstname and mc-lastname are not available.

1. [as what="Name"]
   1. Combine mc-firstname with mc-lastname Since neither are available, continue
   2. Use Name if available This works. Use this value and stop here.
   3. Use mc-firstname only We are already done, unneeded step.
   4. Use the "Default Text" We are already done, unneeded step.
2. [as what="firstname"]
   1. Use mc-firstname It's not available, continue.
   2. Split Name at first space and use first part This works, use this and stop here.
   3. Use the "Default Text" We are already done, unneeded step.
3. [as what="lastname"]
   1. Use mc-lastname It's not available, continue.
   2. Split Name at first space and use second part Name is available, but there isn't a second part to use.
   3. Use the "Default Text" End of the road, use the default.

Output:

John
John
(client last name)

Scenario 3

A new form is submitted using mc-firstname and mc-lastname. We will call the client "John Doe" Name is not available to merge. mc-firstname and mc-lastname are available.

1. [as what="Name"]
   1. Combine mc-firstname with mc-lastname We got what we need, stop here.
   2. Use Name if available We are already done, unneeded step.
   3. Use mc-firstname only We are already done, unneeded step.
   4. Use the "Default Text" We are already done, unneeded step.
2. [as what="firstname"]
   1. Use mc-firstname We got what we need, stop here.
   2. Split Name at first space and use first part We are already done, unneeded step.
   3. Use the "Default Text" We are already done, unneeded step.
3. [as what="lastname"]
   1. Use mc-lastname We got what we need, stop here.
   2. Split Name at first space and use second part We are already done, unneeded step.
   3. Use the "Default Text" We are already done, unneeded step.

Output:

John Doe
John
Doe

Scenario 4

A new form is submitted using mc-firstname and mc-lastname. We will call the client "John" (He didn't fill out his full name) Name and mc-lastname are not available to merge. mc-firstname is available.

1. [as what="Name"]
   1. Combine mc-firstname with mc-lastname We don't have both parts, continue.
   2. Use Name if available This isn't available, continue.
   3. Use mc-firstname only We got what we need, stop here.
   4. Use the "Default Text" We are already done, unneeded step.
2. [as what="firstname"]
   1. Use mc-firstname We got what we need, stop here.
   2. Split Name at first space and use first part We are already done, unneeded step.
   3. Use the "Default Text" We are already done, unneeded step.
3. [as what="lastname"]
   1. Use mc-lastname Field is not available, continue.
   2. Split Name at first space and use second part Field is not available to split, continue.
   3. Use the "Default Text" End of the road, use the default.

Output:

John
John
(client last name)

---

You can re-run any of those scenarios as a link that is either

• example.com/e-promo-kit/?Name=$%name$% Scenario 1 & 2
• example.com/e-promo-kit/?mc-firstname=$%firstname$%&mc-lastname=%$lastname$% Scenario 3 & 4

[gMagicScott]

I think both of these are true, but they probably should be verified:

• Will an old style form with mc-firstname and mc-lastname fields submit and save correctly in 1Shop?
• Will an old style form with Name correctly merge first name and last name individually into an email? %$firstname$% and %$lastname$%

As far as generating the link for use in emails, I don't think it matters, if both of those questions are true. For a link example.com/my-page/?key=value, 1Shop won't care about key only that it can merge value. We just use consistent naming of the key for our own sanity.

[twinsmagic]

just realized the populated link is using the wrong merge code for email. It's listed in the link as %$Email1$% but it's actually supposed to be %$email$%

[twinsmagic]

been swamped with shows and travel man. Sorry for the delay. Thinking about this stuff now.

[twinsmagic]

your 4 scenarios look and sound great man. Did you need any additional feedback?

[twinsmagic]

Will an old style form with mc-firstname and mc-lastname fields submit and save correctly in 1Shop?

No, I don't believe so.

Will an old style form with Name correctly merge first name and last name individually into an email? %$firstname$% and %$lastname$%

yes, indeed.

[twinsmagic]

when do you think I could get an updated zip file?