Depends on how/where those images are stored now. Are they still in the Media Library?
When I forked this plugin, one of the things I wondered about in the code was this particular restriction. I’m not sure what the intent was, but I left it as is to avoid creating problems down the road.
If the images are still stored in the Media Library and you’ve updated their locations in the database, it should be feasible to optimize them with the restriction removed.
I’m going to be working on one other issue today, and if I make some good progress, I’ll push out an update tonight.
Hi Shane,
yes they are still in the media library and all future uploads also land there. I just changed the path so that are pulled from another domain.
I did check the plugin and found the restriction, but since I am no expert I would rather that you look at it before I mess something up.
An update would obviously be the best solution as I then wouldn’t have to worry about future updates 🙂
If you will I will gladly test it and report back to you.
Thanks,
Jan
So I need a little more info. How specifically did you change the path? I located the article below that gives me some leads, but I need to know what specifically you did to see what isn’t working, and what needs changing with the plugin.
http://codex.wordpress.org/Editing_wp-config.php#Moving_wp-content
went back and re-read what you said, and looked at what the plugin checks, and realized you are on the right track, but it still would be very helpful to know what specifically you changed in the settings.
In the admin I changed the path under General Setting – Media to the path on der server where the other domain is as well as the url where the domain is.
Instead of the default path of “wp-content/uploads” I now have the full path from home to the directory where the uploads now reside. The url is the same, but as seen in the browser obviously.
I did NOT move the wp-content directory itself. Just the uploads directory. The page you link to is about the former, whereas I followed the instructions here: http://codex.wordpress.org/Settings_Media_Screen and here: http://codex.wordpress.org/Changing_The_Site_URL. The second one (at the bottom of the page) is just about changing the paths to content already uploaded so that may not be entirely relevant, but still it completes the picture so to speak.
That was really all there was to it. The point being that I did not want images to be served from http://www.domain.com/wp-content/uploads but from images.domain2.com/dir
Firstly they are then served without cookies and secondly do I plan letting a cdn pull and serve them. Doing it this way I can serve most of the content from a number of sites using one cdn account.
I hope I explained that well enough 🙂
If I were to guess I would assume that the author of the plugin you build on didn’t want to take the risk of optimizing other images than those in the media library. Not that I see how that could happen as it does its thing within the media library, but who knows.
Removing the restriction should be okay I guess. Alternatively it could be rebuilt so that it looks for the upload directory and accepts that regardless where it is. That should take care of it even if someone got the idea of moving the entire wp-contents folder I think. I am not sure why one would do that, but I guess it relates to security concerns.
Perhaps this helps as well: http://codex.wordpress.org/Function_Reference/wp_upload_dir
that was perfectly explained, and your suggestion is exactly what I did (probably right while you were typing it). I’ll be releasing 1.0.10 later tonight, as I’ve got the ‘resume’ feature added for bulk operations now too.
I’m not sure if other users (like yourself) can see the option to mark a thread as resolved, but if you could remember to come back and mark this one that way, or let me know that it is resolved once you’ve tried 1.0.10, I would appreciate it.
I see the option to check the “Mark this topic as resolved” box and I will when I have tested the update.
Doing it now seems premature even if I have every confidence in you 🙂
Hi Shane,
as far as the error message goes everything works fine. No error message and as it seems no problem optimizing individual images.
When trying to bulk optimize I got this error a couple of times when it was done:
Processing 24/24: imagename.png
Full size – Could not find XYZ*
Elapsed: 74 seconds
*XYZ being the full path to the image.
The images are there and the path is also correct. It also works fine when I optimize those same images individually.
When I try to bulk optimizes it hangs more times as soon as I try doing it with more than 10 images.
Sure, I am on shared hosting, but perhaps it could be set so it does it slower, thus using fewer ressources and being able to finish the operation instead of timing out?
Another thing that I wonder is why it often times can optimize the images that WP created while being unable to optimize the original?
Thanks,
Jan
I am not sure exactly how this is related, but it seems to include the wrong path somewhere.
Once when bulk optimizing I got this:
Warning: file(XYZ*/ewww.tmp) [function.file]: failed to open stream: No such file or directory in PATH_OK/wp-content/plugins/ewww-image-optimizer/ewww-image-optimizer.php on line 179
Bulk EWWW Image Optimize
Bulk Optimization has taken 0.0 seconds.
Warning: Invalid argument supplied for foreach() in PATH_OK/wp-content/plugins/ewww-image-optimizer/bulk.php on line 41
Warning: unlink(XYZ*/ewww.tmp) [function.unlink]: No such file or directory in PATH_OK/wp-content/plugins/ewww-image-optimizer/bulk.php on line 66
Finished
* XYZ again being the full path to the image i.e. the defined upload directory.
Seems to me that it refers to the tmp file in the wrong directory perhaps?
In the past, some users have had issues with the path stored in the database being slightly off when they try to optimize particular images. Generally speaking, if it gives that error on the bulk optimize, it should do it when you optimize it individually. Quite odd that it would error one time, as it shouldn’t ever be a timeout.
I’ve done some investigating, and the code tests the file with 2 functions:
is_file()
file_exists()
file_exists() tests to make sure there is something on the filesystem (but it could be a directory), thus the is_file() test. However, it sounds like is_file() could fail if there are odd characters in the filename (like international ones). Can you confirm if this is a possibility with the files in question?
The other option would be to do a negative test with is_dir() and is_link() which would give the same (possibly better) results by process of elimination.
The files names are rather long, but not the longest so it really cannot be that. WordPress automatically strips out international characters as well as other stuff like * for example so the filenames consists of only letters and – indicating spaces between words.
One of the files was named: Daniel-Pink-on-the-surprising-science-of-motivation.png for example.
Just saw your second comment about ewww.tmp. This is simply a temp file we use to track our progress on the bulk operation and resume it later if need be. Can you see if the path it points to looks valid?
Well, if the files is supposed to be in the upload folder then it is valid.
I would have assumed it in the plugin folder in which case it would not be valid 🙂
That I get an error stating that it could not be found indicates to me that it looks for it or creates it in the wrong directory.
I tried finding one while the process was running but couldn’t so perhaps it is simply not created…
Yes, it is supposed to be in the upload folder, since the webserver user should always have ‘write’ privileges there, but may not on the plugins folder. Seemed like the best place to put it anyway…
Are your wordpress folder and uploads folder on the same filesystem? It almost seems like there is some trouble with files in the uploads folder being inaccessible (perhaps if they are on a network share), since you are having trouble with some images during the bulk process as well. I would check with your host to find out (if you don’t already know).
Oh, and you asked why it has no trouble with files wordpress created, but trouble with the originals, and I would suspect it is a simple matter of size. The smaller files (resizes) are able to be read quicker. If we take this into account with the ewww.tmp file then we have to consider how many images you are processing at once. On my test site with around 550 images, I get a .tmp file of about 450k, which would be closer in size to some of your original images (or perhaps even larger).
Last thought for now regarding ‘slowing things down’ is that many users already have trouble getting a bulk operation to finish due to timeouts and such, so I don’t imagine this being a good solution. Especially on shared hosting, long running processes are prone to getting killed by the server. Your issues seem to be purely with the actual read from disk, and I’m honestly a little surprised that it would actually timeout on this portion. Perhaps it is a memory issue, where the file is too large to be read into memory due to some limitations of your host?
