BUG! Bizarre interaction between PHP and line spacing within lists.

[NormanRouxel]

Seen on all V8 and V9.

Spurious and unreliable PHP code execution within Product Lists. Problem seems to be dependent on a combination of number of items in the list and the spacing / line breaks used in the code.

Scenario:

We're trying to add some code to display the number of products in a Section.

The following code is added to a Section Link layout:

<actinic:block php="true">$productsonpage=0;</actinic:block>
<actinic:block type="ProductList">
  <actinic:block php="true">
    $productsonpage++;
  </actinic:block>
</actinic:block>
<actinic:block php="true">echo "Product count: $productsonpage";</actinic:block>

Results are as expected unless the Section contains exactly 1 product. In this case Product count: 2 is displayed.

Changing the code so that there are no line breaks or spacing between the product list block and the PHP block seems to fix this. E.g.

<actinic:block php="true">$productsonpage=0;</actinic:block>
<actinic:block type="ProductList"><actinic:block php="true">
    $productsonpage++;
  </actinic:block></actinic:block>
<actinic:block php="true">echo "Product count: $productsonpage";</actinic:block>

[gabrielcrowe]

i must say, i noticed this too.

it got to the point sometimes where i grepped all the line breaks out of the code, and had to take extreme workarounds, to get certain things to work right.

i did not realize it was related to this kind of tomfoolery.

[NormanRouxel]

Quite. A programming system that intermittently thinks that 0 + 1 => 2 cannot be trusted.

[TraceyG]

Thanks Norman, I've reported it to development.

[TraceyG]

Hi,

The developers have reported back that the 2nd block at the productlist part is not necessary. They've provided me with:

<actinic:block php="true">$productsonpage=0;</actinic:block>
<actinic:block php="true" type="ProductList" >
$productsonpage++;
</actinic:block>
<actinic:block php="true">echo "Product count: $productsonpage";</actinic:block>

which seems to work.

[NormanRouxel]

A workaround. However it doesn't explain why the first one fails when the code is correct. I hope it'll be fixed as it will trip up numerous others if not.