Looks like they also don’t approve of checking the current user, so I’ll have to build in a check to prevent that. Hopefully that clears up the other errors too. New release is due out in a couple days (or sooner).
The fix will be pushed to the repository (development release) by the end of the day.
I downloaded again the plugin and the API key was saved, but still get this error:
Warning: get_current_user() has been disabled for security reasons in /home/machomen/public_html/wp-content/plugins/ewww-image-optimizer/ewww-image-optimizer.php on line 18
Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at /home/machomen/public_html/wp-content/plugins/ewww-image-optimizer/ewww-image-optimizer.php:18) in /home/machomen/public_html/wp-content/plugins/paid-memberships-pro/paid-memberships-pro.php on line 23
Then I tried optimizing one image and I got the same error like yesterday. Maybe I am doing something wrong?
Did you download 1.6.3 again, or the Development Release?
1.6.3 … I don’t know where to find the developer release.
http://wordpress.org/plugins/ewww-image-optimizer/developers/
The fix is in the Development Release, a version that is already released (like 1.6.3) can’t be modified.
I downloaded and installed the development version but the optimization doesn’t do much good. I tried optimizing 5 images (and all related image sizes that WP creates) and most of the images returned “No Savings” although they are not optimized. Is it a bug?
Later edit: my mistake, I didn’t realize that the images on the server were already optimized by Smush.it 🙂
Anyway, I checked with 2 pictures that I have on another site and PageSpeed tells me that they can be optimized by 8%. First I uploaded one picture with your plugin enabled and it was reduced by 11% (more than PageSpeed could have done – WOW!). Then I disabled your plugin and uploaded the second picture and PageSpeed told me that I can save 8% by optimizing it but I ran a Bulk Optimize on both pictures and for the second picture I got an awesome 12% reduction! Great job!
But I have to mention one thing: if I upload the picture using WP Uploader, your plugin optimizes only the main picture, it doesn’t optimize all the other sizes of that picture, created by the theme. If you need to optimize them as well (and for sure you need to do that), you have to go again in the Library, select the main picture and click “Bulk Optimize”. However, I hope the future release will fix this problem.
Great, great job man! Keep up the good work! I have no chance but to upgrade my membership for your API key. I just need to know this: can I use my API key on all my wordpress sites?
Thank you!
Looks like we have 2 questions then (feel free to re-ask if I missed something in there):
1. optimizing resizes
A: resizes should all be optimized automatically via the new wp_image_editor extended classes. To see the results though, you have to look under Tools->Optimize More and then click the Show Table button
I’ll do some testing on my external test site and run it through pagespeed just to make sure.
2. using the api key on multiple sites
A: absolutely! While I do ask for your primary site just to have something on record for troubleshooting my logs, the key is not restricted to a single site.
looks like you’re right, there’s some sort of bug there. I’ll have to see what the deal is.
aha, I remember what is happening now. It can be a bit puzzling, but if you look at the actual filesizes after upload, and then after running a bulk-optimize, they are identical.
Here’s what happens:
1. On initial upload, the image is first processed by wp_image_editor and by extension, the appropriate EWWW_IO_Editor class.
2. This information is stored in the database instead of the attachment metadata, because the metadata hasn’t been generated yet. This is stored in the ewwwio table.
3. When the metadata is generated, it triggers the normal optimization routine. This is the way 1.6.3 and before did the resizes.
4. During the normal optimization function that has just been triggered, it checks the database to see if the resizes have already been optimized.
5. Since they have already been optimized, it skips the optimization. BUT, it retrieves the optimization status from the database and copies it into the metadata. This then gets displayed during the bulk optimization, and makes it appear that you are saving an additional amount.
So, maybe I should modify that slightly. Instead of just copying the status, perhaps there should be an indicator that it’s the status from a previous optimization.
I understand now … you should indeed modify it a bit, because it is a bit confusing :). Other than that, really amazing plugin 🙂
