Image+ TV not creating downsized Thumbnail while using migxdb

I’m sorry to create another Image+ post, really thought I would’ve figured that stuff out by now, but apparently not.

I have an Image+ TV which is filled using migxdb through a cmp. When displaying the image to the frontend though, it is not resized. The image links to a path within the pthumb cache folder, but still has its original size.

The image TV is set in both input and output to Image+, setting options to &w=500 and also defining an output template. The image is then called with other content with migxLoopCollection in a tpl:

<img src="[[ImagePlus? &value=`[[+image]]` &options=`w=500`]]" />

I’ve tested many things, without luck so far:

  • set the Image+ TV output to Default
  • displaying the image with just [[+image]]
  • displaying the image using its own tpl [[ImagePlus? &value='[[+image]]' &type='tpl' &tpl='img-tpl' &options='w=500']]

The Image+ TV itself works fine, both displayed and resized properly as a single TV as well as inside a migx TV. I am pretty sure, that I have this exact same setup working on a different site as well but I can’t figure out, why it’s not working here.

Also nothing related in the error logs, besides some deprecation warnings. Any help is highly appreciated.

I can’t reproduce this issue. It seems to work fine when I test it.

Maybe to debug it, you can output the placeholder [[+width]] in the chunk img-tpl when you call it with

[[ImagePlus? &value=`[[+image]]` &type=`tpl` &tpl=`img-tpl` &options=`w=500`]]

[[+width]] should have a value of 500.

It’s really odd, like I said I have the exact same setup working on a different site.

I tried that, interestingly enough, it has a value of 0

Ok, I updated to the newest version of Image+ (2.8.6-pl) and now I have the same problem as you.

So that is either a bug in the newest version or the syntax for the options property has changed.

Somehow in this initProperties() function the value of the options property gets deleted.

I think this line

should be changed to 'options' => '',

I tried to change that, but it doesn’t seem to work for me, except there is any special procedure I have to do after the change to make it count? I tried deleting the core/cache as well as the stored cached images.

Did this change work on your setup?

Yes, this worked when I tested it. No “special procedure” required. I only needed to clear the cache.

Well, it doesn’t work for me unfortunately. Just to confirm we have the exact same setup:

Image+ TV (img-team):

Input Options:

  • Target Aspect Ratio = 1

Output Options:

  • Additional phpThumb Parameters: = &w=500
  • Generate Thumb URL: = Yes
  • Output Chunk: = img-tpl

Image template (img-tpl):

<img src="[[+url]]" alt="[[+alt]]" /> [[+width]]


The img-team is assigned within migxdb to a field named image and then output by another template:

[[ImagePlus? &value=`[[+image]]` &type=`tpl` &tpl=`img-tpl` &options=`w=500`]]

MODX 2.8.3-pl
Image+ 2.8.6-pl
pThumb 2.3.3-pl

On that note, I found that if you display the Alt field (Show Alt Tag Field: Yes) and insert anything in the actual Alt field for the image, both the output and the cmp grid preview (ImagePlus.MIGX_Renderer) break leaving raw JSON in the src field of the image and the Alt field completely empty.

Would be interesting to know, if you can confirm that?

No, I can’t confirm that. Seems to work when I test it.

So, what is the actual value of your image in the column image of your database table?
Maybe if you add a lot of “alt” text, the field is too small for all the content.

I did a test with the same setup you provided, but it still works on my installation.

As far as I can tell, Output Options are not used when you call ImagePlus with a &value property. (And Input Options don’t affect the output either.)

This is the actual value:

  "sourceImg": {
    "src": "filename.jpg",
    "width": 3277,
    "height": 3277,
    "source": 3
  "crop": {
    "x": 0,
    "y": 0,
    "width": 3278,
    "height": 3278
  "targetWidth": 0,
  "targetHeight": 0

And if I add an Alt (just a name), it indeed cuts off:

  "sourceImg": {
    "src": "filename.jpg",
    "width": 3277,
    "height": 3277,
    "source": 3
  "crop": {
    "x": 0,
    "y": 0,
    "width": 3278,
    "height": 3278
  "targetWidth": 0,
  "targetHeight": 0,
  "altTag": "Vibe

So I guess a varchar(255) might not be enough for an Alt tag? But this still doesn’t explain the failed resizing. Afaik this info is not stored within the actual image field of the db (atleast not on my other working site).

You could try adding some log statement to the code, to see where the information is lost.
Then clear the cache, open the page on the frontend and check the MODX error log.

Add these lines

$options =  isset($properties['options']) ? $properties['options'] : 'not set!';
$this->modx->log(\xPDO::LOG_LEVEL_ERROR, 'properties["options"]=' . $options);

above this line.


$this->modx->log(\xPDO::LOG_LEVEL_ERROR, 'options=' . $options);



$this->modx->log(\xPDO::LOG_LEVEL_ERROR, 'phpThumbParams=' . $phpThumbParams);

after this line.

So this is the result:

/imageplus/src/Snippets/Snippet.php : 80) properties["options"]=w=500
/imageplus/src/Snippets/ImagePlus.php : 50) options=
/imageplus/src/CropEngines/PhpThumbOf.php : 117) phpThumbParams=

And you are sure you changed the getDefaultProperties() function in TreehillStudio\ImagePlus\Snippets\ImagePlus?

public function getDefaultProperties()
	return [
		'value' => '',
		'tvname' => '',
		'docid::int' => (isset($this->modx->resource)) ? $this->modx->resource->get('id') : 0,
		'type' => '',
		'options' => '', //CHANGED FROM 'options::associativeJson' => [],
		'tpl' => 'ImagePlus.image',
		'input::bool' => $this->imageplus->getOption('debug')

Maybe add these additional log statements

$this->modx->log(\xPDO::LOG_LEVEL_ERROR, '$result=' . json_encode($result));
$this->modx->log(\xPDO::LOG_LEVEL_ERROR, 'default properties=' . json_encode($this->getDefaultProperties()));

before this line.

Yes, even double checked through web-ftp again.

Here is the additional output:

imageplus/src/Snippets/Snippet.php : 80) properties["options"]=w=500
imageplus/src/Snippets/Snippet.php : 102) $result={"value":"{\n  \"sourceImg\": {\n    \"src\": \"filename.jpg\",\n    \"width\": 3277,\n    \"height\": 3277,\n    \"source\": 3\n  },\n  \"crop\": {\n    \"height\": 3278,\n    \"width\": 3278,\n    \"x\": 0,\n    \"y\": 0\n  },\n  \"targetWidth\": 0,\n  \"targetHeight\": 0,\n  \"altTag\": \"\"\n}","tvname":"","docid":4,"type":"","options":null,"tpl":"ImagePlus.image","input":false}
imageplus/src/Snippets/Snippet.php : 103) default properties={"value":"","tvname":"","docid::int":4,"type":"","options::associativeJson":"","tpl":"ImagePlus.image","input::bool":false}
imageplus/src/Snippets/ImagePlus.php : 50) options=
imageplus/src/CropEngines/PhpThumbOf.php : 117) phpThumbParams=

Well, in your log the default property “options” still has the associativeJson type ("options::associativeJson":"",) which is wrong.

default properties=

Well, I have no clue… should I try to uninstall image+ and reinstall it again? Same for pThumb?

Still I wonder, why the image works in a regular migx TV, isn’t that the same processing happening there?

This error has nothing to do with pThumb. If you reinstall Image+ you still have the same bug.

The bug is specifically related to the ImagePlus snippet and the “options” property. If you don’t use this snippet in your regular migx TV (or don’t use the “options” property), then it may work.

Here is a (ugly) workaround (until the bug is fixed).
In your chunk img-tpl use some code like this:

<img src="[[+source.src:pthumb=`[[+crop.options]]&w=500`]]">
1 Like

Thanks, that works indeed! And also thank you very much for all your time spent thinking and testing with me!

Still very confused that even after you found this (probably) error in the code, it still didn’t work out for me. Also really afraid I messed something else up, but really don’t know where that could be.

Any ideas @jako maybe?

It is my fault. With the last version the snippet property ‘options’ was retrieved wrong. A fix will be prepared on monday.

A patch is here:


This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.