Also bought list in an outer layout?

[dandelion]

I have a design where product pages have a 3 column outer layout. The product layout is in the second column which is INNERLAYOUT. I want to populate the third column (which is controlled by my outer layout at the moment) with an also bought list for that product. Is this possible, or does the also bought list have to be within the product layout?

I see that 'AlsoBoughtListIsEnabled' is a variable available through the Dreamweaver interface, but no ' ProductAlsoBoughtList'.

[NormanRouxel]

You may be able to do this via CSS. Put a DIV around your Also Bought List and use CSS to reposition it so it displays in the sidebar area.

Another way is to capture the lists HTML into a PHP variable and later echo it out in the sidebar. This assumes that your Sidebar code comes after the Product Layout code. E.g. (N.B. untested):


Put this just above </head> in your Overall Layout:

<actinic:block php="true">$ablisthtml = '';</actinic:block>

This makes sure that nothing will be output on pages without such a list.

In your Product Layout(s), replace:

<actinic:variable name="ProductAlsoBoughtList" />

With:

<actinic:block php="true">
$ablisthtml .= <<<ENDOFABLIST
<actinic:variable name="ProductAlsoBoughtList" />
ENDOFABLIST;

</actinic:block>

This captures the lists HTML (from each product on the page in turn) and saves it for later.

Put this in your Sidebar:

<actinic:block php="true">echo $ablisthtml;</actinic:block>

This displays the lists HTML.

[dandelion]

Thanks for the pointers Norman. Will give 'em a go and report back later. Second option sounds favourite to me, otherwise I'll have to break out the AB div with absolute positioning which I try to avoid.

[dandelion]

Having some trouble with this.

I have implemented the PHP variable approach, but Actinic gives me a parse error, somewhere in the PHP block.

If I remove the Also Bought list variable and just bung some text inside the HEREDOC it works fine.

Have then tried the other approach (re-positioning with CSS) which works OK, but because it takes the list out of the flow, if the list is longer than the middle column, the list overruns above the footer. I could use some JS to reposition the footer I suppose. I'd rather avoid this.

Having sorted the layout for the second option, I then pasted the generated HTML back in in place of the Also Bought list variable into the PHP variable (first option), and still see the parse error.

Perhaps it is the local href "file:///..." preview folder paths which are causing the problem? Am just testing locally a the moment without a test server.

[NormanRouxel]

Without seeing the code you're using it unlikely anyone can help.

[NormanRouxel]

Here's a weird thing. I was tinkering with this block of code:

<actinic:block php="true">
$ablisthtml .= <<<ENDOFABLIST
<actinic:variable name="ProductAlsoBoughtList" />
ENDOFABLIST;
</actinic:block>

And it was giving PHP errors. Even when I trivialised it to remove any Actinic layouts. E.g.

<actinic:block php="true">
$ablisthtml .= <<<ENDOFABLIST
WOOT
ENDOFABLIST;
</actinic:block>

Then I put a newline in after the ENDOFABLIST; E.g.

<actinic:block php="true">
$ablisthtml .= <<<ENDOFABLIST
<actinic:variable name="ProductAlsoBoughtList" />
ENDOFABLIST;

</actinic:block>

And it started working.

And even more weirdly it continued to work after I removed the newline so the code was back as first posted!

[dandelion]

Joy!

Well, it's working for me now too!

I had tried similar things relating to PHP heredoc requirements, i.e. new line after the closing identifier, and removing indenting (closing identifier must start in first column of new line) throughout the layout hierarchy, and I didn't think it had done any good. So I then created a test site for my project (before was only testing single page locally), and published site, and lo and behold when I put the block of code back in it all worked.

So I thought it was something to do with having local pathnames (preview folder), but now... maybe not.

I must admit my testing with the new lines, indents etc was not 'scientific', more 'fiddling', so I can't guarantee that this isn't what fixed it. In fact, I'm sure it must have been.

Anyway, all seems good now. Many thanks Norman.