Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image+ TV "Image not found" error when upgrading from 2.8.9 to 2.9.2 #112

Open
pmacswebteam opened this issue Sep 6, 2022 · 5 comments
Open
Labels

Comments

@pmacswebteam
Copy link

We are receiving the following error after upgrading from Image+ 2.8.9 to 2.9.2 and when trying to select an image to add to a context:

imageplus-2-9-2-error
"The image was not found and can't be cropped. Please select a different image."

The image is there on our server and is not corrupted.

We were unable to troubleshoot the issue / find a solution on our end.

Reverting back to Image+ 2.8.9 solves the immediate problem though.

@Jako
Copy link
Owner

Jako commented Sep 7, 2022

According to the screenshot the image is inside of MIGX so this can be a misconfiguration. If I can get access to the backend, it is a lot easier to look into this.

@pmacswebteam
Copy link
Author

Hi Jako,

Thanks for the attention. Most of our imageplus usage is inside of a MIGX TVs. We created a new imageplus TV and it seems to have the same problem so I don't think it has to do with MIGX.

This is only happening for our non-web context.

In the test TV the correct media source is chosen for the TV/context and the correct media source loads in the media browser when we click the image button in the imageplus TV. imageplus just isn't finding the image.

Imageplus must be looking for the image in the web context default media source because if an image with the same file name and path exists in the web context media source, imageplus appears to work in the other context.

image

image

Short of having you log in to our manager, is there more info we can provide to help you help us?

Thanks!

@Jako
Copy link
Owner

Jako commented Sep 12, 2022

This looks more like an initialisation issue in MIGX. I have tried a lot of different configurations this morning. Even if MIGX -> Formtabs -> Fields -> 'item' -> Fields -> 'item' -> Mediasources -> source From is set to tv, the source is set wrong from MIGX to the Image+ TV. I had to add the sources in MIGX -> Formtabs -> Fields -> 'item' -> Fields -> 'item' -> Mediasources -> Sources -> Add Item. Then the Image+ TV is initialised right.

Please check this out and close the issue, if you are successful.

@Jako
Copy link
Owner

Jako commented Sep 28, 2022

I can't reproduce this issue with a normal Image+ TV. It works well with different Media Sources in all contexts.

@Jako Jako closed this as completed Sep 28, 2022
@hugopeek
Copy link

Hi @Jako, sorry for digging up this old issue, but I've been experiencing more or less the same. Only in my case it's not tied to any context, but to the object ID.

I'm using an adaptation of the migxObjectMediaPath, so the object ID is set dynamically. I think through a session variable. This worked until 2.9.1, but broke after the following javascript got slightly refactored:

bcfaa52#diff-e4b12fbb591640a2ef6c7d16dedce1bacf1c8c36512d2cf1d4814b25e565d3dc

After this update, the baseUrl variable is no longer accurate on the second request. Say you select an image inside object 1, and save, then things are OK. But as soon as you try to do the same for another object, the baseUrl is stuck on the previous selection.

Here's a screencast of that happening (I modded the panel.input.js file a little for debugging):

Kooha-2024-10-24-14-43-33.webm

After a refresh, the image in the second object can be successfully edited, but not any other. Ad infinitum.

I will try to debug this a little more, but any pointers as to where to look would be helpful. I already checked the requests that are coming from MIGX, and the path that's being forwarded is always correct. So I don't know how or where this could be going wrong inside MIGX..

@Jako Jako added the bug label Nov 3, 2024
@Jako Jako reopened this Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants