failed to open stream – I/O warning – wrapper is disabled

Hello,

Thanks for your support and using my plugin ??

This is server config stuff. If you don’t know how to edit your config or php.ini files, I would suggest contacting your host. They should be able to help you out if you provide the PHP Warnings.

Please do let me know how you go.

It seems that enabling allow_url_fopen gets rid of the simplexml_load_file() warnings… which is far from ideal. Do you have any suggestions on how to get rid of them without enabling that please?

Secondly…

Also, it looks like you should put an error trap in your code for if the image file is missing from the filestore. Currently it appears the way your plugin behaves, it starts to hammer the database with requests, resulting in it exceeding the connection limit of the DB.

See this log…

As soon as we got rid of all the image references to SVG files that didn’t exist, all the connection errors disappeared.

I could be wrong about it being your plugin exceeding the DB connection limit, but it seems like it, and it’s probably worth investigating at your end.

There may be another way instead of using simplexml_load_file… I will have a dig and see if I can work out a way to use cURL instead. The feature is to display the SVG in the attachment modal window when adding media, so it’s a critical feature, but I believe there should be a way around to allow you to leave allow_url_fopen disabed.

As for the DB connections, I have never come across this before.

Are you able to test and provide an error log after enabling the allow_url_fopen? The error log looks like that was still disabled.

We love what your plugin does for our website, so we really hope you do find a solution. But given it’s an eCommerce site, I really can’t justify enabling allowing allow_url_fopen. So for now it’s disabled.

I would test again with the log enabled, but the issue only occurred when we had incorrectly imported product feature image references… so the Media library had image references, but no file existed in the path specified. So when the attachment modal window was open while trying to add media, the thumbnails wouldn’t load at all, because the files didn’t exist. And I suppose it would just keep trying.. and the connections would stack up until they either timed out, or the max number of attempts was reached. The effect was when the DB connection limit was exceeded, any new media file uploads would fail, and some admins pages would fail to load with DB access errors. It’s kind of a rare scenario really, but born from trying to upload thousands of products to woocommerce from configured spreadsheets converted to CSV files… all it takes is a typo in an excel formula, and you trash a bunch of references, or create a bunch of bogus data. Fortunately, we only had 8 pages of bogus SVG images to remove from the media library… it would have sucked if there were hundreds of pages.

I think I have a solution for the main issue and will add it to the list of things I’m working on, hopefully I can dedicate more time to this soon.

As for the DB connections, I see your issue, but I would have to be able to reproduce to successfully test and debug to see if it is indeed something my plugin can help avoid. I will keep it in mind though and see if I can address it at all when I’m working on the plugin next.