Photo Gallery Forums

I recently went from a custom html site to a wordpress site. I tested X3 in the wordpress environment a few months ago and all was fine. I recently launched the new site and now X3 does not show the images in the iframe as it did  a few months ago. I am fairly certain this is not an issue with the version of X3. I uploaded the test installation which works in wordpress 4.9.9 However it doesn't seem to like 5.0.2. I was hoping you could take a look and let me know what you think the issue could be. You can see the current installation at tgmiss.com. From the home page the menu link "New Photos at TG Miss" is a good example. Thanks for any help you can provide.

I have been trying to work through the issue and have come across some things that may or may not help. One hopeful point is that images where the zoom tool is used, show up.  One of the errors I see in chrome is
 "/stock/render/w1280/index/3.prairie.jpg:1 Failed to load resource: the server responded with a status of 404 ()" 

I have been testing using the standard demo gallery to make everything more familiar. I have been able to upload an image to a directory that uses zoom and it is visible if zoom is enabled. I have tried in chrome and firefox with the same results. The hosting provider is Inmotionhosting. They are one of the more highly recommended host providers.

I will add any new information I can find.

Hi @melisamy. I checked your website, and I know what the issue is. First of all, it has nothing to do with IFRAME. You will find that the images fail to load if you load the iframe src directly into browser also: tgmiss.com/dmx/index.php.

The issue is related to NGINX server. Either your server has been updated to NGINX after it stopped working, or they have changed the NGINX configuration on your server. 

Here is an original image on your website, working fine:
tgmiss.com/dmx/content/2.galleries/1.landscapes/ridge.jpg

Yet, when it goes through the resizer script, it fails:
tgmiss.com/dmx/render/w480-c3:2/2.galleries/1.landscapes/ridge.jpg

If your NGINX wasn't mistaking the request for a static JPG file, it would correctly pass through to Apache .htaccess, which would then rewrite the request, and the resized image would load:
tgmiss.com/dmx/app/parsers/slir/?w=480&i=2.galleries/1.landscapes/ridge.jpg

This is because your NGINX server is intercepting this file as a JPG, thinking it is a STATIC file that exists in the given path ... When it can't find it, it simply returns "404 not found". Instead, just like all other requests, this request should be passed to the X3 application so that it can process the request and resize the image. It's wrong. You need to make sure all requests are passed through from Nginx, even if nginx thinks it's a static file on system (which is isn't). Or you would need to setup X3 rules in your NGINX config, and make sure your nginx can run PHP.

I showed your comments to the tech at inmotionhosting. They concur that this is a valid issue and are working on a fix on their end. Thanks for explaining this clearly enough for them to move forward on the issue. I will keep you posted on progress.

Missy

Inmotionhosting told me it was not reasonable to make the edits to their server because it was a shared server. They invited me to upgrade to a private server that they would be happy to make ready for X3. This would of course cost much more per month and they would also have to charge me for the customization as this was not within normal standards.

I politely asked them for a refund and cancelled $800.00 worth of hosting. A word to the wise: "If you like X3, you might want to steer clear of inmotionhosting."

Thanks for your support in this Karl. 

melisamy wrote:Inmotionhosting told me it was not reasonable to make the edits to their server because it was a shared server. They invited me to upgrade to a private server that they would be happy to make ready for X3. This would of course cost much more per month and they would also have to charge me for the customization as this was not within normal standards.

I politely asked them for a refund and cancelled $800.00 worth of hosting. A word to the wise: "If you like X3, you might want to steer clear of inmotionhosting."

Good to know thanks. May I ask what hosting package you used that was working like this, and that costed that much? I have seen this issue before, but mostly custom servers, not pro shared hosting. Using NGINX to serve static files (without passing to Apache) is a fair concept in itself. But requiring all requests that end with JPG (or any static file type) to be a physical file path, without forwarding to Apache, is blocking all virtual requests. That means we would need to revert to PHP parameter style to make image resizing work (ex. /x3_resizer.php?path=/path/file.jpg&w=300), which is a bit outdated and would cause issues with caching. Even our servers at Flamepix are using NGINX in front of Apache, but all requests are still by default forwarded to Apache, which handles the required processing.

Thanks for the feedback!