MIGX Loop Collection returns array

16 Posts

th0car Reply #1, 8 years, 11 months ago

I'm trying to output an html block using migxLoopCollection and a template but all that is ever returned from migxLoopCollection is the array enclosed by a <pre>-tag.

[[migxLoopCollection?
&classname=`Match`
&packageName=`matches`
&limit=`1`
&tpl=`tpl.boomerang.match-block`
]]

The template:

<div class="wp-block article grid bb">
    <div class="article-image">
        <img src="images/default.jpg" alt="">
	</div>
	<span class="article-category">[[+series]]</span>
    <h3 class="title">
        <a href="" hidefocus="true">[[+description]]</a>
	</h3>
	<p>
	   [[+matchdate]]</br>
	   [[+facility]]
    </p>
</div>

Expected output:

<div class="wp-block article grid bb">
    <div class="article-image">
        <img src="images/default.jpg" alt="">
	</div>
	<span class="article-category">P15 4F</span>
    <h3 class="title">
        <a href="" hidefocus="true">IFK Tumba FK 1 - Mälarhöjdens IK 2</a>
	</h3>
	<p>
	   2015-05-17 11:15:00</br>
	   Storvretens BP 1
    </p>
</div>

Actual output:

<pre>Array
(
    [id] => 26
    [series] => P15 4F
    [description] => IFK Tumba FK 1 - Mälarhöjdens IK 2
    [facility] => Storvretens BP 1
    [matchid] => 151152033
    [matchdate] => 2015-05-17 11:15:00
    [_alt] => 0
    [_first] => 1
    [_last] => 1
    [idx] => 1
    [property.classname] => Match
    [property.packageName] => matches
    [property.tpl] => tpl.boomerang.match-block
    [property.limit] => 1
    [property.debug] => 0
)
</pre>

MIGX version is 2.9.3-pl and MODX is 2.3.3 on modxcloud

What could cause this? It seems to me (from the contents of the array) that MIGX is getting the correct data from the db and that my parameters are applied.

16 Posts

th0car Reply #2, 8 years, 11 months ago

Running the Loop collection with debug=1 returns this:

SELECT `Match`.`id`, `Match`.`series`, `Match`.`description`, `Match`.`facility`, `Match`.`matchid`, `Match`.`matchdate` FROM `modx_matches` AS `Match` LIMIT 1 <pre>Array
(
    [id] => 26
    [series] => P15 4F
    [description] => IFK Tumba FK 1 - Mälarhöjdens IK 2
    [facility] => Storvretens BP 1
    [matchid] => 151152033
    [matchdate] => 2015-05-17 11:15:00
    [_alt] => 0
    [_first] => 1
    [_last] => 1
    [idx] => 1
    [property.classname] => Match
    [property.packageName] => matches
    [property.tpl] => tpl.boomerang.match-block
    [property.limit] => 1
    [property.debug] => 1
)
</pre>

5,888 Posts

Bruno17 Reply #3, 8 years, 11 months ago

normally, you get an array-output, if the tpl-chunk does not exist.

are you sure, this is the name of your chunk:

tpl.boomerang.match-block

if so, try a simplier name, for example:

boomerang_match_block

-------------------------------

you can buy me a beer, if you like MIGX

http://webcmsolutions.de/migx.html

Thanks!

16 Posts

th0car Reply #4, 8 years, 11 months ago

The name of the template is now tpl_matchblock and I have also shortened and simplified all other template and chunk names on the current resource. Same result though I'm afraid...

Any other circumstances that would return the array-output? This is my first attempt at using MIGX so I might have set up something else the wrong way.

Thank you!

16 Posts

th0car Reply #5, 8 years, 11 months ago

I tried replacing the tpl value with code (didn't know I could do that until just now):

[[migxLoopCollection?
&classname=`Match`
&packageName=`matches`
&limit=`1`
&debug = `0`
&tpl=`@CODE:[[+description]]`
]]

This outputs the value of 'description' so there is obviously something wrong with the template name, path or content...

189 Posts

gissirob Reply #6, 8 years, 11 months ago

I think I got something similar when I omitted

&prefix=`yourprefix_`

from the migxLoopCollection call. Of course, you don't need this if you are using the default table prefix. BTW, don't ever use fullstops in any of your names - you'll get really weird errors (or nothing at all).

5,888 Posts

Bruno17 Reply #7, 8 years, 11 months ago

This should only happen, when $modx->getChunk does return an empty result.
Can't see anything wrong with your setup.

-------------------------------

you can buy me a beer, if you like MIGX

http://webcmsolutions.de/migx.html

Thanks!

16 Posts

th0car Reply #8, 8 years, 11 months ago

Quote from: Bruno17 at May 15, 2015, 04:20 AM

This should only happen, when $modx->getChunk does return an empty result.
Can't see anything wrong with your setup.

I think you are right - everything seems to be OK except that the template_chunk can't be found and/or parsed.
I actually tried copying the code from the template and pasted it as @CODE...

&tpl=`@CODE:<div class="wp-block article grid bb">
    <div class="article-image">
        <img src="images/default.jpg" alt="">
	</div>
	<span class="article-category">[[+series]]</span>
    <h3 class="title">
        <a href="" hidefocus="true">[[+description]]</a>
	</h3>
	<p>
	   [[+matchdate]]</br>
	   [[+facility]]
    </p>
</div>`

...and this also works just fine.

However - I know that the name of the template chunk is correct and there are no signs of the code containing errors. Can you think of something else that differs between using a chunk or @code as tpl in the migxLoopCollection execution?

16 Posts

th0car Reply #9, 8 years, 11 months ago

Quote from: gissirob at May 15, 2015, 12:34 AM

I think I got something similar when I omitted
&prefix=`yourprefix_`
from the migxLoopCollection call. Of course, you don't need this if you are using the default table prefix.

Default table prefix is used here and as you can see the array output actually contains the correct data so the retrieving the data doesn't seem to be the main problem.
Quote from: gissirob at May 15, 2015, 12:34 AM

BTW, don't ever use fullstops in any of your names - you'll get really weird errors (or nothing at all).

Thanks for the heads up! I did see fullstops being used in chunk and template names in some tutorials so I thought this was ok. I'll go with your advice here from now on though. This is my first real MODX project so I don't want to cause unnecessary problems for myself wink

1,024 Posts

Frank Reply #10, 6 years, 10 months ago

Solved this one, as I don t use the standard modx default prefix I added

&prefix=``

Output was normal as expected, great.