• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.
  • Chevereto Support CLST

    Support response

    Support checklist

Add External Media to Wordpress no longer works from Chevereto site following upgrade

homeplannz

Chevereto Member
Over the past week we have upgraded (via TMD) to V3.13.5, and overnight to 3.14.1. Following these upgrades, a WordPress plugin we rely on has stopped working with Chevereto. We have tested this with two alternative plugins, all of which can no long reference Chevereto images while still working when the images are stored on other platforms.

We use Chevereto solely to host images and generate image URLs that are then referenced by other platforms including WordPress and Matterport. Since the upgrades, WordPress now 'fails to get info on the images' from Chevereto, causing the upload/reference to fail. It is failing to get the image width, height and MIME type data.

Note URL access by Matterport is still working as expected.

Can you please urgently investigate? This severely hampers our business operations.
 

Attachments

  • Screenshot 3.pdf
    470.1 KB · Views: 10
If I get this right, you have a WP which you feed with image URLs generated by Chevereto. I ignore how that plugin fetches the image properties, but I assume that it fetches the image and then analyze it as there's no other way to do it.

If I'm right in describing how it works, then let me clarify that the image files are handled by Chevereto (create, remove, etc.) but it is your server (Apache, Nginx, etc.) which delivers these files. Any issue on image delivery is on the server, Chevereto is not even touched when the server delivers a static file like an image.

Can you send over (inside a zip file) one of the images which don't work to check if it is corrupted?
 
Thanks Rodolfo for getting back to me so quickly. You're right, here's what the documentation for the plugin says:


"Note that WordPress needs to know in advance the width and height of an image in order to correctly display it in the media library page and any post/page. In most cases, the plugin resolves these properties automatically without worrying you. But in rare cases, the plugin may fail to get the widths and heights of the images you specify. In that case, some input fields will show up and let you fill in the properties manually. "

That's what is happening since the Chevereto upgrade - the plugin is failing to get the widths, height and MIME type (we can add them manually but it still scraps the thumbnail).

We've tested the same plugin on a number of issues hosted outside of our Chevereto instance - all upload just fine straight away, no issues.
We've tested about 10 images from our Chevereto instance - all fail. We have tried images recently added, and images added over a month ago - all same result.

Zip of two files attached, one recent, one old, both of which fail. I think the plugin is looking for something that it can no longer retreive from the image URL.

If you have a URL to an image hosted on someone else's Chevereto instance - let me know and I'll try that?

Thanks again.
 

Attachments

  • Files.zip
    892.3 KB · Views: 2
Files doesn't look corrupted. The problem is elsewhere. You can try with images uploaded to the demo.

It may work if you enable curl and allow url fopen in your cPanel for your blog. Give it a try. Also try without https, maybe there's an issue with SSL.

I suggest you to check a way to debug the alleged plugin, it will help a lot if you manage to retrieve the reason why the plugin is failing.
 
Good news - images from the demo site work fine, so it's a config issue specific to our site. And the demo site is also https so I think that might rule out an SSL issue. Allow_url_fopen is already enabled, where do we find the curl setting? Sorry not an expert, Google didn't dig me out.

TMD did the setup and it's been problematic (e.g. we can do updates ourselves). Any way we, or an expert can compare our settings to those on the demo site to spot the difference that's killing us?
 
I tested demo uploading the image URL (from the PDF) and I didn't have any issues, so the server delivering images is not failing here. The problem is specific to your context, most likely a connection refused. The plugin does the detection using getimagesize on the image URL: https://github.com/zzxiang/external...master/external-media-without-import.php#L227 (the @ means to silence the PHP errors if any) so simply remove that and make sure that error display is turned on, then you should be able to detect the actual issue.

Unless you get the actual error message (the technical reason why fails) you will have to keep testing.
 
Thanks, but it's not out plugin and and we don't have a way of playing with its code to turn on error display. I'm going to log this with TMD, as there is obviously something in our configuration that differs to the demo site config causing this. There are other indications of setup errors e.g. we can't us the upgrade script, and now - cPanel backups failing (compression failed). Is there any way you can provide a full export of the standard settings that should be in place for a site, so we can get TMD to do the same for our site and compare?
 
Found it. TMD investigated and found that the IP address of the server to which your domain homeplan.nz is pointed was blocked by the BitNinja firewall of the TMD server. They unblocked it, issue solved! Thanks for your support helping us work this through. Glad to be up and running again.
 
Found it. TMD investigated and found that the IP address of the server to which your domain homeplan.nz is pointed was blocked by the BitNinja firewall of the TMD server. They unblocked it, issue solved! Thanks for your support helping us work this through. Glad to be up and running again.

Glad to know!

most likely a connection refused
:cool:
 
Back
Top