INVOICEADDRESS4 problem

[taliesyn]

I am trying to implement Graham Bradley's 'User Input Format' routine on v9.05, to correctly format the names/addresses, and have noticed a problem. It works as expected on every field apart from 'InvoiceAddress4'.

I noticed an old post (#5) here regarding v7 which exhibited the exact same problem. Whatever you add to the end of the 'Invoice Address 4' <input type = /> block, it is substituted with the original code when you upload, which is why it doesn't work. So on upload (if you view the checkout page source):

<input type="text" name="INVOICEADDRESS4" size="40" maxlength="200" value="<Actinic:Variable Name="InvoiceAddress4"/>" onblur="format(this,'capitals')"/>

within 9.05's design view becomes :

<input type="text" name="INVOICEADDRESS4" size="40" maxlength="200" value="<Actinic:Variable Name="InvoiceAddress4"/>" />

on the uploaded checkout page.

Norman's style="text-transform:capitalize"' method (as per the v7 thread) works fine, but if you try and use the onblur= javascript method, it is stripped out by Actinic on upload (but only for this field)

This is the working code fragment using Norman's method (which gets uploaded correctly):

<tr>
   <td>
      <actinic:block if="%3cactinic%3avariable%20name%3d%22InvoicePrompt007Required%22%20%2f%3e" /><span class="actrequired"></actinic:block>
         <Actinic:Variable Name="InvoicePrompt007"/>
      <actinic:block if="%3cactinic%3avariable%20name%3d%22InvoicePrompt007Required%22%20%2f%3e" />*</span></actinic:block>
   </td>
   <Actinic:LOCATION TYPE='INVOICEADDRESS4'>
   <td>
      <input type="text" style="text-transform:capitalize" name="INVOICEADDRESS4" size="40" maxlength="200" value="<Actinic:Variable Name="InvoiceAddress4"/>" />
   </td>
  </Actinic:LOCATION>
</tr>

The onblur= method works fine for every other field, and the CSS method just looks inconsistent on the site for a single field, as it behaves differently when you type.

However, I have found that if you remove the following block markers:

<Actinic:LOCATION TYPE='INVOICEADDRESS4'>
</Actinic:LOCATION>

and leave the rest of the code as is, then it works as expected and the onblur= source changes are uploaded normally, and are not stripped out.

Following the lengthy preamble (), my question is as follows - What are the implications of taking those two lines out of the code, and is it going to be detrimental to Actinic v9.0.5 itself?

That block is obviously doing something there, but what?

[taliesyn]

Nobody got any idea what Actinic:LOCATION TYPE= does?

Guess I'm on my own then

[Mike Hughes]

I would say that this:

<Actinic:LOCATION TYPE='INVOICEADDRESS4'>
</Actinic:LOCATION>

Is telling Actinic where to insert the location code. i.e it's overwriting whatever's there with something else.

It's also worth following the thread you link to above. You'll see that the text-transform code only changes the appearance of the text entered on the page. It doesn't actually alter the entered text so capitalisations, etc won't be seen in the order details. (in other words it doesn't work.)

Mike

PS. I assume the 'location' stuff is because invoiceaddress 4 will be the 'state' location so the code will vary depending on whether you use and have set up any states in shipping.

[taliesyn]

Thanks for your help Mike

I hadn't checked if the 'style' change actually changed the data itself or not. Just as well you pointed that out!

I've commented those block lines out, put back the onblur= line and tested it with various combinations of country/county/state and it doesn't seem to affect our ordering in any way, and works entirely as expected. Orders are all coming in OK, are transferring correctly to the PSP, and are appearing correctly within v9.05, so I think I'll leave it like that for a while and just monitor it to see if there are any adverse effects.

It does slightly concern me that I'm having to change something that we're not entirely sure of, but I suppose I should be used to that by now.

[Mike Hughes]

I hadn't checked if the 'style' change actually changed the data itself or not. Just as well you pointed that out!

I only know because I tried it in the original thread (is that really almost 6 that way. It doesn't actually do anything to the text entry.

tbh I'm impressed that I can remember what happened back then. I did have to check the thread to make sure though.

Mike

PS. I doubt if you'll have any problems with what you've done. I pretty sure that's just there so actinic can change the data entry form for when people are using defined states.