Wrong url when using beans_edit_image

Hey Thierry,

I'm working on a theme where I'm using the beans_edit_image() function for the images of a slider. Everything's working fine locally and on our own server, but I installed the theme at the client's server and there's no image showing up and I'm getting a 404 error in Firebug. Now the strange thing is that the url it's trying to use has the server path mixed in. It's something like:

http://subdomain.domain.org/var/www/vhosts/subdomain.domain.org/wp-content/uploads/2016/10/image.jpg

I've looked inside the Beans Image Editor Class and the beans_url_to_path function to find any hints, but I'm a bit lost. I guess there's something wrong with their server config. Do you have any idea why this happens?

Thanks, Timo

Hey, I've done some more testing with a multisite installation and I could reproduce the problem. The images aren't showing and the src attribute is directing to the server path (but this time it's not mixed up with the url, it's only the path).

So I had another look in the Beans Image Editor Class. At line 67 there's a conditional checking if the image can be edited and it's supposed to return the original image source when image processing fails.

Now the problem is that at this point, the image source went through beans_url_to_path() (if it's a local file) and is not an url but a server path. When image processing fails, the path should be converted back with beans_path_to_url() before returning it (as done when image processing works).

Now I still don't know why image processing fails, but it's probably not a problem with beans but due to either a missing GD library or some missing lines in the htaccess file of the multisite installation (as described here: https://codex.wordpress.org/Multisite_Network_Administration#.htaccess_and_Mod_Rewrite)

As a workaround (instead of overwriting beans core) I let the output of beans_edit_image() run through beans_path_to_url() in my slider template. This should work even when image processing works, as it's returning the url untouched when it's not a server path, but maybe you can fix this part in a future update?

Thanks, Timo

Hey Timo,

Beans automated path to url (and vise versa) may be delicate depending on the server setup you are on. We are really on the chase to make that as solid as possible on all environment as possible and it would really help if you could create a test account your server and send the temporary credentials via the contact form (100% confidential)

Thanks in advance,

Hey Thierry,

I checked our multisite installation with phpinfo and the gd library is not listed/installed. I will ask our server admin to install it. So this should be the explanation why image processing did fail.

I don't think there's a problem with the beans path to url and back functions, at least not on our server, I don't know if the url/path mixing thing that happened on my clients server has something to do with their setup (maybe because they use vhosts?).

But regarding the init function of the beans image editor class: shouldn't the function always return an url? At the moment it's going like:

1. (in the constructor) convert the src url to a path
2. check if the file exists on the server locally
3. store server path in the src property of the class
4. (in the init function) try to edit the image
5. if it fails, return the class src property immediately (without converting it back to an url)
6. if image editing works, return the path of the modified image, but convert it back to an url before doing so

Or am I getting something wrong?

Hey Timo,

The reason it is doing that is simple, speed! The workflow is the following:

1. Check if the edited image exists on the server (we have to convert to a path for that).
2. If exists, then don't run any editing (unless arguments have changed) and return the cached image (that is what makes it fast).
3. If doesn't exists, edit the image, create a version of it in the upload folder and serve the image (this is slower but only ever happens once).

That is what let's you even edit external images which will then be on your server and served fast.

The fact that the url to path and path to url conversion is causing issue on the client server is really something that I would love to take a look at if possible. It is very rare to hear users facing this issue but the stronger we make it the better Beans will be 😉

Thanks,

Hey Thierry,

sorry for being so persistent, but I don't think that the conversion itself is causing any issues, but the fact that inside the init method of the beans image editor class the path is not converted back to an url when image editing fails. I think there's simply one step of conversion missing (in the case of a failing image edit). In my test cases the reason why image editing wasn't possible was due to a missing gd library on the server. That caused Beans to return the image src immediately, but as a server path, because it's not using the path_to_url function in this case (what it should do imo).

So everything's working fine when the gd library is installed (should normally be the case), but if it's not, you'll have a server path in your image src attributes and the images won't show. Probably you'll get an error message when debug mode is turned on, haven't tested that.

Hey Timo, thanks for being so persistent 🙂

What you are saying makes complete sense to me now, I will look into making sure that the original url passed is returned if the image cannot be edited (ie. if gd library isn't installed or fails) for the next version released.

Keep an eye on the changelog/commits 😉

Hey Thierry,

that's great! And thanks for your hard work!