WolfgangHammersmith

It is perfectly fine and understandable to expand your functionality but the nagging prompts in our sites have been misleading the admin users/site owners to think your plugin has lost functionality locally.

We have no choice but to seek alternatives since we do not work with “exec-deprived servers” that lack local functionality. In fact, I rarely encounter these servers in my travels at all.

I am sure that if you saw the questions we are getting you would understand why we have to abandon Ewww at this point.

Yeah you didn’t test the ‘delete’ option or consider why you’d leave the substitution code in the .htaccess when deleting the originals?
I saw all the complaints about SEO issues, tested it with Google tools, confirmed the issue, tested the simple fix, and then I tried to help you.

It breaks when Google (and other crawlers) don’t send agents that don’t declare support for WebP so your erroneous .htaccess rules point them to original files that were deleted.

The fix is super easy, as I mentioned originally.

• This reply was modified 11 months, 3 weeks ago by WolfgangHammersmith.

Just a heads up. The latest plugin version has a delete function and it creates the files with the original name + the .webp extension added on making it easy to tell which file was the original.

Technically the safest solution is to make a directory and put only optimized images into that directory, but how to choose a unique directory base name that is not in use?

Perhaps take all the extra vowels out of ‘imageoptimize’: ..site_root/imgoptmz/ ...?
Actually that could be unique and short enough?

If the plugin can then mirror the existing website directory structure inside that unique base directory for storage it would keep everything tidy with low risk of issues.

Actually, rsync can do the directory mirror in a single command: rsync -av --include='*/' --exclude='*' source_dir/ destination_dir/

• This reply was modified 1 year, 5 months ago by WolfgangHammersmith.
• This reply was modified 1 year, 5 months ago by WolfgangHammersmith.

The current version does now delete but the plugin author needs to update the plugin to omit the http_accept line in the .htaccess changes.

If the line is not omitted when you choose to delete then basic crawlers will fail the http_accept rule and try to request the original images, which were deleted, leading to errors.

A 410 is not a redirect. It’s a reply telling the source that the content has been removed permanently.

You want the ‘410 for WordPress’ plugin. Don’t forget to make a copy of the current theme 404.php to 410.php and tweak the wording for a nice 410 response!

Nope. Limiting it to a smaller file PNG size wasn’t the ticket. I really should ask for a directory listing. I hate remote servers with CMS only access!

The developers literally added an /img/ folder where there hadn’t ever been one so that path was never checked previously.

I suspected the issue is with folder but I’ve removed it and still get the error.

Server log has:
[Fri Feb 05 11:30:21.135006 2016] [fcgid:warn] [pid 35554] [client 100.70.20.100:62069] mod_fcgid: stderr: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 159 bytes) in /var/www/clients/client0/web77/web/wp-content/plugins/ewww-image-optimizer/aux-optimize.php on line 448, referer: https://clientwebsite.net/wp-admin/upload.php?page=ewww-image-optimizer-bulk

Our development server has Version 2.5.6 of the plugin paired with WordPress 4.4.1. Scan and optimize is fine pre-update and post (both the core & plugin).

UPDATE: I re-read what you’ve said and now I’m wondering if they didn’t stick a massive file into the /img/ folder by mistake! I will test with file size limits next.

The crawler complaint is a minor concern that Google’s just getting around to emailing us about. Once you have the latest version of the Wordfence plugin you should stop getting the error when you re-test in webmaster tools.

A much larger concern would be your pagespeed score: https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.shrimpsaladcircus.com%2F&tab=desktop

If you install the ‘EWWW’ image compression plugin, tell it in the options to remove the meta-data from images, and tell it to scan and optimize your whole site (in the Media menu), your score will jump up massively and the site will be much more peppy.

Want more? In Yoast there’s a ‘Tools’ section, and in the advanced tools there’s a ‘Files Editor’. In that section you can add things to your .htaccess file. This is where you can add some rules that will turn on browser caching and compression. I’d normally just fire off a link to a David Walsh post on stealing the best parts of the .htaccess file from HTML5 Boilerplate, but I can’t find the right one so here’s a pastebin of the caching rules (WP doesn’t like long code dumps):
https://pastebin.com/6yQX33E4

Pasting the rules into your .htaccess and saving will instantly improve your PageSpeed scores and stop people from re-downloading everything on each visit which will make the site run better/use less bandwidth.

There’s also rules for server side compression that are usually safe to add to your .htaccess but have a higher chance of not working with your particular server so I don’t share them as readily.

For anyone else that thought the .info link was anything more than a spamming attempt, please just ignore that submission.

The robots.txt is by default “allow”.

Method 1 says “All agents can access everything except /wp-admin/ and /wp-includes/ and further states that all agents can access /wp-content/plugins/ and /wp-content/themes/” which were never disallowed… !?

If you wanted something actually relevant you might try:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

This is explained here: https://support.google.com/webmasters/answer/6062596?hl=en (Notice it’s not a .info domain?)

Blocking /wp-admin/ is very common with WP installs, it’s a default for one of the most popular SEO plugins for WP.

Expect these messages to be the tip of your iceberg in the next few days.

Oops an this is resolved.. (Wish I could edit that back in?)

Ahh you might want to consider adding that note to the option?

That’s exactly what it was. Each image that was still on the ‘needs optimization’ list was created by a paid professional who charged lots of money to deliver those images crammed with loads of pointless data.

It rhymes with Kobe Toto-stop.

Same problems here with two sites.

The first site was a timthumb issue in most cases, but there were some files in both the uploads folder and themes area it skipped with no pattern.

On the second site most of the files it skipped were in the uploads folder so I installed the ‘Replace Image’ plugin and used the PageSpeed extension for Chrome to get the compressed versions of the images to replace manually one-by-one.

For the files NOT in the uploads area I am stuck because I don’t have FTP/Shell access so I cannot touch those.

Example path of files that won’t compress and I cannot reach them:
https://site.com/wp-content/themes/innerhop/img/tip_border_grey_up.png

The rest were in the uploads so I could manually fix em..

I would be happy to PM a URL but I don’t post real site URLs online.

EDIT: Here’s the details from the media section:
Optimize Media Library
…
30 images in the Media Library have been selected (0 unoptimized), with 335 resizes (0 unoptimized).

Optimize Everything Else
…
Last optimization was completed on September 30, 2014 at 1:18 pm and optimized 324 images

…
There are 686 images that have been optimized so far.

(So no, I didn’t skip the ‘Optimize Everything Else’ choice and ‘Remove metadata’ was NOT enabled on either site.)