Miva Merchant Empresa Bugs?

[wmgilligan]

Re: Miva Merchant Empresa Bugs?

Do you have a link to the incorrect docs?

http://www.mivascript.com/item/mivas...tags/MvDO.html

Under examples.

Although I just realized... this isn't actually Miva's site is it?

Bill

[Rick Wilson]

Re: Miva Merchant Empresa Bugs?

Do you have a link to the incorrect docs?

[wmgilligan]

Re: Miva Merchant Empresa Bugs? MvDo ?

That worked back in the days of interpreted mivascript, but I don't think it's ever worked with compiled mivascript as the include has to be a compiled mivascript.
You can use file_read() function and and <mveval > to achieve the intended result.

If thats actually the correct answer, can we get the docs updated?

[virtualkiwi]

Re: Miva Merchant Empresa Bugs? MvDo ?

Not sure if its me or Miva, but the docs say (and I have done this before):

<!--#include file="/external.html"-->

This can be replaced by:
<MvDO FILE="/external.html">

So I add this:

<MvDo file="news.html">

But this error occurs:

MvDO: Unable to open 'news.html': File is either corrupt or not a valid compiled Miva Script file

That worked back in the days of interpreted mivascript, but I don't think it's ever worked with compiled mivascript as the include has to be a compiled mivascript.
You can use file_read() function and and <mveval > to achieve the intended result.

[Rick Wilson]

Re: Miva Merchant Empresa Bugs?

I would guess you won't get a reply on this from Burch until next Tuesday when he's back in the office.

[wmgilligan]

Re: Miva Merchant Empresa Bugs? MvDo ?

Not sure if its me or Miva, but the docs say (and I have done this before):

<!--#include file="/external.html"-->

This can be replaced by:
<MvDO FILE="/external.html">

So I add this:

<MvDo file="news.html">

But this error occurs:

MvDO: Unable to open 'news.html': File is either corrupt or not a valid compiled Miva Script file

[burch]

Re: Miva Merchant Empresa Bugs?

I was able to reproduce the issue with your sample code, so I'll file a bug and we'll try to get a fix in for 5.20. I'm not sure what we would have changed recently to introduce that behavior.

Edit: It looks like it was introduced in 5.14, BTW.

[branden]

Re: Miva Merchant Empresa Bugs?

Sorry if this is out of place (I'm a lurker) but I've just spent a while tracking down a bug that was causing the compiler (both Windows and Linux) to hard exit without an error message and without generating a compiled mvc file. I did it by placing poorly-worded MvASSIGN statements that would generate compiler warnings throughout the code, and seeing which was the last warning before the compiler exited.

Anyway, I found that nesting the in-line MvDO-equivalent function calls was causing the compiler error. By which I mean a statement like this:

<MvASSIGN NAME="l.variable" VALUE="{[ './functions.mvc' ].write('Item #' $ [ './functions.mvc' ].cleanup(l.this_item) $ ' added')}">

Code like this used to compile, in earlier versions of the v5.0 compiler, but stopped working around version v5.09. Of course, now that I know the issue, it is easy to work around, but finding it took a bit of effort.

Thanks

[Scott McCollough]

Re: Miva Merchant Empresa Bugs?

Found a reason to use the long-lost keyword_in() function and think I found a bug. Or if not bug, then idiosyncrasy and should be documented.

The keyword(s) entered need to be in lower case, even if the word in the string is upper case.

<MvASSIGN NAME = "l.string" VALUE = "The quick brown fox jumped over the Lazy dog. Meanwhile, grumpy wizards make toxic brew for the evil Queen and Jack.">

<MvASSIGN NAME = "l.keyword_array" INDEX = "1" VALUE = "{ 'quick' }">
<MvASSIGN NAME = "l.keyword_array" INDEX = "2" VALUE = "{ 'orange' }">
<MvASSIGN NAME = "l.keyword_array" INDEX = "3" VALUE = "{ 'queen' }">
<MvASSIGN NAME = "l.keyword_array" INDEX = "4" VALUE = "{ 'Queen' }">

<MvASSIGN NAME = "l.return" VALUE = "{ keyword_in( l.keyword_array, l.string ) }">

<MvFOREACH ITERATOR = "l.words" ARRAY = "l.keyword_array" INDEX = "l.pos">
<br />Did &quot;<MvEVAL EXPR = "{ l.words }">&quot; show up? <MvEVAL EXPR = "{ l.return[ l.pos ] }">
</MvFOREACH>

Output:
Did "quick" show up? 1
Did "orange" show up? 0
Did "queen" show up? 1
Did "Queen" show up? 0

[burch]

Re: Miva Merchant Empresa Bugs?

Scott, your test script is flawed in two ways:

1. The second MvIF in each case is backwards
2. A variable created in this way WILL be NULL, because it will be empty

Here's an example:

Structure before probe: <MvEVAL EXPR = "{ miva_member_exists( g.test1, 'one' ) }"><br />
<MvIF EXPR = "{ g.test1:one }">This is impossible</MvIF>
Structure after probe: <MvEVAL EXPR = "{ miva_member_exists( g.test1, 'one' ) }"><br />


Array before probe: <MvEVAL EXPR = "{ miva_element_exists( g.test2, 1 ) }"><br />
<MvIF EXPR = "{ g.test2[ 1 ] }">This is impossible</MvIF>
Array after probe: <MvEVAL EXPR = "{ miva_element_exists( g.test2, 1 ) }"><br />

When compiled with a 4.06 or newer compiler and no specific compatibility flag, you will get this output:

Structure before probe: 0
Structure after probe: 0
Array before probe: 0
Array after probe: 0

But when compiled with -C 4.05, you'll get this output:

Structure before probe: 0
Structure after probe: 1
Array before probe: 0
Array after probe: 1

[Scott McCollough]

Re: Miva Merchant Empresa Bugs?

This is a script issue too, not just template.

<MvIF EXPR = "{ ISNULL g.test1 }">There is no g.test1 <MvELSE>There is a g.test1 </MvIF><br />
<MvIF EXPR = "{ ISNULL g.test1 }">NOW there is a g.test1 <MvELSE>g.test1 is an illusion </MvIF><br />


<MvIF EXPR = "{ ISNULL g.test2:one }">There is no g.test2:one <MvELSE>There is a g.test2:one </MvIF><br />
<MvIF EXPR = "{ ISNULL g.test2:one }">NOW there is a g.test2:one <MvELSE>g.test2:one is an illusion </MvIF><br />


<MvIF EXPR = "{ ISNULL g.test3[1] }">There is no g.test3[1] <MvELSE>There is a g.test3[1] </MvIF><br />
<MvIF EXPR = "{ ISNULL g.test3[1] }">NOW there is a g.test3[1] <MvELSE>g.test3[1] is an illusion </MvIF><br />

There is no g.test1
NOW there is a g.test1
There is no g.test2:one
NOW there is a g.test2:one
There is no g.test3[1]
NOW there is a g.test3[1]

If you gaze into the variables, the variables gazes also into you...

[RayYates]

Re: Miva Merchant Empresa Bugs?

Downgrades, didn't think of that. OK then, but if I had a vote it would be to Upgrade it :-)

Example for posterity:
<mvt:if expr="(l.settings:breadcrumbs[1]:code EQ g.product_code) OR (l.settings:breadcrumbs[2]:code EQ g.product_code)">


</mvt:if>

Implications:
If you use a mvt:foreach loop on what you expected to be an empty data, the code inside the loop will execute. i


<mvt:foreach iterator="bread" array="breadcrumbs">
If breadcrumbs is empty the code will always execute outputting unexpected data.
</mvt:foreach>


<mvt:if expr="l.settings:breadcrumbs">
If you test the value first the test will return true and again the code will always execute.
</mvt:if>

[burch]

Re: Miva Merchant Empresa Bugs?

So If I'm following this correctly a 4.06 compiled template is creating code so it can run on VM 4.05

Really? How would a new compiled template get on a machine with an older VM?

Yes, really. The compiler can do the same thing, with the -C flag. The difference is that the template compiler defaults to the most compatible code and the regular compiler defaults to the least compatible code. If you compiled your non-template test with "-C 4.05" you should see the same behavior as you're getting from the template compiler.

There are plenty of ways a compiled template could get from a newer engine to an older one. Site migrations, engine downgrades, etc... It's unlikely that this would happen these days since there's so many versions between the releases, but the behavior you're encountering was defined when it was far more likely.

[RayYates]

Re: Miva Merchant Empresa Bugs?

Sorry I'm not following.


4.05 and older: VM had this behavior.
4.06 Problem fixed in VM


4.05 compiled template contains instructions that crash on 4.06 VM
So something undefined was added to VM 4.06 to prevent this.

The template compiler is intentionally generating the most compatible code it can.

So If I'm following this correctly a 4.06 compiled template is creating code so it can run on VM 4.05


Really? How would a new compiled template get on a machine with an older VM?

[burch]

Re: Miva Merchant Empresa Bugs?

The conditional <mvt:if expr="( g.test[1]:code EQ l.settings:topcat:code )"> causes the null array g.test to stop being null.

This is actually intentional behavior for the following reason.

Prior to version 4.06, the VM displayed that exact behavior in all expressions. Reading a member or array element would cause the member/element to be created.

In 4.06, new instructions were added to make those accesses read only. However, if you try to run code that contains those instructions on an older VM, you'll end up with a fatal runtime error. The template compiler is intentionally generating the most compatible code it can.

At this point it's debatable if maintaining backwards compatibility with the 4.05 and older VM is necessary for generated template code, but that's the reasoning behind the current behavior.

I looked through the old compiler/VM release notes and didn't find any explicit mention of this change, FWIW.