Progressive profiling fields above required fields?

[Jenn_DiMaria2]

Thanks, Sanford! That's exactly what was happening. You're a peach

[Victor_Herrero]

I have been able to implement this myself and it seems to be working

I also ran into the issue of forms being loaded twice, because I'm also using a Marketo landing page. Commenting-out the load.form() line in your code seemed to fix it.

I was however unable to determine exactly at what point in the HTML the form is loaded first (it seems inside another forms2.js Marketo proprietary script, but several scripts seem to be launched in succession and it becomes unclear to me, I keep hitting the debug button and understand approximately 1% of what I'm seeing every time I go through it )

I'm encountering an issue, though:

My progressive profiling has something like 20 fields in the list (ok, I probably don't need that many).

The code will work properly and order fields in the order I want (progressive profiling field in 4th out of 6 positions), but only for the first field in the list (because it's the only one I added in your code)

So, company is the first field in the progressive fields list, but the next one, "Country", appears at the top, before first name, etc.

Is there an easy way for progressive profiling fields to remain in 4th position regardless of field name?

OR

Is there a way to determine the position of the progressive profiling field?

Otherwise I will have to include the fields in the form inside the template code (which is not optimal for reusability of the landing page template with other forms), but if there is no other way...

(I'm using your wrappers now, by the way... so maybe a "prog profile" tag or something like that?)

(By the way, what kind of HTML attribute is "for"? I hadn't seen it before. Can you just create new ones?)

Thanks in advance!

[Victor_Herrero]

After reading your scripts (and understanding only like 2% ) I can't really think of a way of differentiating a normal field from a progressive profiling field except perhaps:

1. Marketo only allows for one to be included
2. It's always included at the end

So maybe create another wrapper that tags fields with numbers [1, 2, 3, 4, ..., "lastFieldLoaded"]

Once form is loaded, then determine field order again [1, 2, 3, "lastFieldLoaded", 4, ...]

Don't know, just a very high level idea...

[SanfordWhiteman]

(By the way, what kind of HTML attribute is "for"? I hadn't seen it before. Can you just create new ones?)

<label for> is the W3C standard attribute for the label's corresponding input ID.

data-wrapper-for is a custom attribute, like all attribute with the prefix data-.

[Victor_Herrero]

Actually, now that I'm having a look at it I have encountered "label", in fact I have had to play around with checkbox labels but more on the CSS and not so much HTML so I hadn't paid attention to the "for"

I didn't know about "data-*" though!

Thanks for clearing it up

[SanfordWhiteman]

You can do this with the new FormsPlus 0.2.2-Reorder, which is linked from the Demo page at MktoForms2 :: Override Field Order 1.0.1​.

First make sure you add a Rich Text Area to your form directly above the ProgPro block. As you correctly surmised, Marketo doesn't directly tell you which forms were from ProgPro and which were standard, so you use this RTA as a signifier.

In the Rich Text Area add only hidden input with a special class:

<input type="hidden" class="progpro-separator">

Once the RTA is in place, to shift all the ProgPro fields (without needing to know their names in advance) to the top of the form, run FormsPlus.reorderFields with an empty fieldOrder array as the 2nd argument and boolean true as the new 3rd argument, progProToTop.

FormsPlus.reorderFields(form, [], true);

You can also combine the two features, shifting the ProgPro block to the top and then reordering a subset of known fields:

FormsPlus.reorderFields(form, ["field1","field3"], true);

[Victor_Herrero]

Thanks!

Again, when I find the time and the courage, I'll try to implement both.

but this should do it, also allowing for reusability. It's true that our first 3 fields are usually the same, so I don't mind locking those in place in the template.

I'll let you know!

Thank you so much for this!

[Dan_Stevens_]

Hey Jenn - by chance are you using this on a guided LP that has multiple form regions?  For example, in our template, we have the ability to include the form in the right-rail or in the main content section of the LP.  If someone accidentally includes the form in the main area, then hides the region without first removing the form, the form will appear twice in the visible region - in this case, within the right rail.

[Anonymous]

Hi Sanford Whiteman​ - is this code added at template level on the landing pages? Or am I missing a trick on the actual landing page I've just created? Pretty novice at this but need to implement, as we have our privacy policy ahead of our progressive profiling fields and it looks odd.

Thanks

[SanfordWhiteman]

I would add form behaviors code at the template level, absolutely.

In a Free-Form LP, you can add a named HTML Element or add to the <head> at the LP level; in a Guided LP you can use a Rich Text element, a string variable, or custom <head>; and you can even embed behaviors script in the form itself in a RT area. But I wouldn't use advise any of those placements as they are relatively obscure.