workaround for unencoded ampersand (&) bug in 5.5

[Barrett]

Currently v5.5 is inconsistent in how it renders template code with respect to proper encoding of the ampersand.
Related topic:
http://extranet.mivamerchant.com/forums/showthread.php?t=17305

I don't have the miva script SMT rosetta stone....

Hope there was a redundant syntax to force in the ampersand properly for valid URL's per W3C.

&mvte:[&amp;]&mvte:[& ;] (extra space there cuz the forum renders it - <eye roll>
See what I'm trying to do "codephonetically" speaking ?

So it can render like this:
<a href="&mvte:global:secure_sessionurl;Screen=LOGN&amp;Order=0&amp; Store_Code=&mvt:global:Store_Code;">Account</a>NOT this:
<a href="&mvte:global:secure_sessionurl;Screen=LOGN&Order=0&Store_Code=&mvt:global:Store_Code;">

[PicturesqueWeb]

Although I don't know how to resolve your issue, I can say that even Google links things like this. Ever use GoogleMaps links? They are loaded with ampersands with no way to make them compliant with W3 standards. They aren't the only ones that do this, but it's sure fun to pick on the big guy.
Provided Google doesn't penalize for it and the links work, I wouldn't sweat it too much.

[Barrett]

Sorry I forgot to post the solution here too - the fix is simply using the correct encoding in the string of html.

http://extranet.mivamerchant.com/forums/showpost.php?p=76422&postcount=10

[Barrett]

Update: Additionally any update to the Store Message field with wipe out the fix and will need to be reapplied.
************************************************** ***
Workaround


1. Place either of these in the navbar and click update twice. Ignore what you see remaining in the admin field.

2. Look in browser source of an actual store page to verify syntax is correct and then validate your page at
http://validator.w3.org/#validate_by_uri

<mvt:if expr="g.Basket:cust_id EQ 0">
<a href="&mvte:global:secure_sessionurl;Screen=LOGN&amp;amp;Orde r=0&amp;amp;Store_Code=&mvt:global:Store_Code;">Account</a><mvt:else>
<a href="&mvte:global:secure_sessionurl;Screen=ACNT&amp;amp;Orde r=0&amp;amp;Store_Code=&mvt:global:Store_Code;">Account</a></mvt:if>

<mvt:if expr="g.Basket:cust_id EQ 0">
<a href="&mvte:global:secure_sessionurl;Screen=LOGN&amp;#38;Orde r=0&amp;#38;Store_Code=&mvt:global:Store_Code;">Account</a><mvt:else>
<a href="&mvte:global:secure_sessionurl;Screen=ACNT&amp;#38;Orde r=0&amp;#38;Store_Code=&mvt:global:Store_Code;">Account</a></mvt:if>
&mvte:global:secure_sessionurl; Must use mvte on this as miva engine creates it's own ampersand internally.

[Biffy]

In reality the only time Miva URL ampersands cause a problem is with the W3C validators. These errors can safely be ignored for all practical purposes.

[Barrett]

In reality the only time Miva URL ampersands cause a problem is with the W3C validators. These errors can safely be ignored for all practical purposes.

Understood, but I'd rather have it technically purely correct on validation to satisfy the geek in me. Hopefully the professionals coding the app will clean that up in a future stream.

[Biffy]

Understood, but I'd rather have it technically purely correct on validation to satisfy the geek in me. Hopefully the professionals coding the app will clean that up in a future stream.


It would be very nice if my customers could use the validators and get a green light.

[RayYates]

I completely agree with Barretts assesment. I have a client site completely coded as valid xhtml which validates except for the ampersand problem.

This should be fixed at the Storemorph compiler level; there are other instances where the compiler chokes on &.

The compiler should recognize instances where a url is specified such as href="", src="", or within an third party item as shown below.

For Example:<mvt:item name="my_program" param="url|http://www.mystite.com/dothis.php?parm1=1&parm2=2&parm3=3" />

I have a module that requires passing a url but the compiler chokes.

This is my workaround:
<mvt:item name="ry_toolbelt" param="url|'http://www.mystite.com/dothis.php?parm1=1' $ asciichar(38) $ 'parm2=2' $ asciichar(38) $ 'parm3=3'" />

Doing it this way forces me to evaluate the string expression within my module.

[Rick Wilson]

FYI - We will be fixing this in an upcoming release.

[Pete McNamara]

Alright!