[WP Smush Pro] WP Smush Pro not auto-smushing on upload

Both on our testing environment and our live, production environment (both set up as large multi-sites), we have Smush Pro set up to auto-smush network-wide (across all subsites) whenever a new image is uploaded to anyone's subsite media folder. The auto-smushing is not happening though.

When an image is uploaded, it is not smushed. When one goes into the media folder and opens the newly uploaded image it appears as if it is smushing, with the text "Smushing in progress" appearing. But after a short moment "Not Processed" appears, followed by a button that says "Smush".

If one clicks on the "Smush" button at that time, the image then gets smushed.

We need to find out why images aren't auto-smushing. We are using WP Smush Pro Version 2.9.1 on WordPress 4.9.8. We would be glad to give you access to our testing environment if if would help.

Thank you.

  • Kasia Swiderska
    • Support nomad

    Hello cbenson583,

    I’m sorry to hear that Smush is not working correctly on your site.

    I just did a quick test on my lab Multisite and I wasn’t able to replicate this issue – so I would like to take a look at your testing environment first.

    Would you mind allowing support access? To enable support access you can follow this guide here:

    https://premium.wpmudev.org/docs/getting-started/getting-support/#chapter-5

    Please respond in this ticket once access is granted.

    kind regards,

    Kasia

  • Kasia Swiderska
    • Support nomad

    Hello cbenson583,

    I tested Smush on subsites on site where you granted access and I can't replicate this issue.

    I tried uploading directly in Media Library and also from the Post and both ways image was Smushed.

    Statistics for smushing were showing instantly after Smushing:

    I have tested on technology subsite.

    Or there is another step I am missing to see this issue? Let me know

    kind regards,

    Kasia

  • Patrick Freitas
    • Staff

    Hi cbenson583

    How are you today?

    Thanks for the access.

    I uploaded a couple of images on your subsite and didn't have the problem either.

    But I would like to ask to try to increase the API timeout for big images.

    Wouldn't you mind, please, go to your wp-config.php file using FTP, click to edit, scroll until you see:

    /* That's all, stop editing! Happy blogging. */

    And just above, paste the following code:

    define('WP_SMUSH_API_TIMEOUT', 200);

    Try to upload a new image, and see if the problem persists.

    I tried to upload the image using Media Library > Add New

    Let us know if you are taking another step, or maybe uploading through a plugin.

    Best Regards,

    Patrick Freitas

  • cbenson583
    • Design Lord, Child of Thor

    Support access has been re-granted.

    We have not changed the API timeout in wp-config yet, but in testing very small images (9kb) we still get the same error (The auto-smushing is not happening. When an image is uploaded, it is not smushed. When one goes into the media folder and opens the newly uploaded image it appears as if it is smushing, with the text “Smushing in progress” appearing. But after a short moment “Not Processed” appears, followed by a button that says “Smush”:wink:.

    Also, we have the “Auto-convert PNGs to JPEGs (lossy)” option turned on, but in uploading PNGs with no transparency the image is not converted to JPEG.

    The two most recent images in that image library are the ones I am talking about.

    Thank you.

    -Chris

  • Patrick Freitas
    • Staff

    Hi cbenson583

    How are you today?

    Still not able to replicate it, I downloaded some not Smushed files on your media library and re-uploaded, it took a quite long time, but when I refresh the page, it shows the image was Smushed.

    It seems something can be blocking the plugin to refresh the status, wouldn’t you mind, please, run some tests?

    First, of all, I see you are using the PHP 5.5, wouldn’t you mind, please, switch to the PHP 7, this is a new version and can avoid further problems, also, please, try to increase the API timeout, and check if the problem is gone.

    If this persists, we would need to run a plugin conflict test.

    So, would you mind please run a conflict test?

    Remember, is essential that you run this test in a staging site, if you can’t do it you must create a full backup.

    Please deactivate all plug-ins keep the reported one, and check if the problem is gone. If so, then enable all plugins one by one and find which one is creating the issue.

    If you still having this issue, could you do a theme test, much the same as the plugin test, but now you’re testing themes!

    Activate one of the default WordPress themes, like Twenty Sixteen or Twenty Seventeen.

    Here you will find more information: https://premium.wpmudev.org/docs/getting-started/getting-support/#chapter-2

    About the PNGs conversion, I tested on my end, and couldn’t replicate too, and I suggest we run those tests and check if the problems are related.

    Best Regards,

    Patrick Freitas

  • cbenson583
    • Design Lord, Child of Thor

    It’s been a while, but we finally updated to new servers featuring the newest PHP, and we’re still getting this issue (WP Smush Pro is not auto-smushing images that are loaded). This is causing massive problems for us seeing as we are constantly running out of space on our hundreds of multisites when Smush Pro does not do what it should be doing.

    Let me know if you need support access to our new Staging environment granted to you.

    Thank you.

    -Chris

  • Patrick Freitas
    • Staff

    Hi cbenson583

    Sorry to hear you still having this issue,

    Wouldn’t you mind please, send us some credentials information for the new Staging environment?

    Note: Don’t leave your login details in this ticket.

    Instead, you can send us your details using our contact form https://premium.wpmudev.org/contact/#i-have-a-different-question:

    Subject: “Attn: Patrick Freitas”

    – Site login URL:

    – WordPress admin username:

    – WordPress admin password:

    – FTP/SFTP credentials

    Host:

    Username:

    Password:

    Port:

    – cPanel credentials

    Host:

    Username:

    Password:

    – Folder path to the site in question:

    – Link back to this thread for reference

    – Any other relevant URLs/info:

    Please, reply to the ticket once you have sent the information.

    Best Regards

    Patrick Freitas

  • cbenson583
    • Design Lord, Child of Thor

    The issue is not with smushing on upload on the new servers. It is with the individually smushing a file.

    This is happening for all files upload on all subsites. Bulk Smush has no problem recognizing the files and smushing them. The individual SMUSH option fails on every file uploaded with File Path Empty. This just started a few days ago. Bulk Smush finds all the files and works fine.

    The individual SMUSH option fails on every file uploaded, regenerating thumbnails has no affect and checking the server shows all files correctly generated and accessible. We have turned off all plugins on our subsite https://updatetest.staging18.gsu.edu except regenerate thumbnails, Smush Pro and WPMU Dashboard and the problem is still occurring. Support access to this site is enabled through the WPMU dashboard.

    I will send the site login credentials as well. However, we are unable to provide sftp access to our server environments. As I mentioned above, we have confirmed the files are there and correct and Buulk Smush finds them and works correctly.

    Julia Thompson

  • cbenson583
    • Design Lord, Child of Thor

    Could I please get an update on this ticket? It is becoming a major issue for us. We have over 350 subsites being modified daily. There is no way we can work with only being able to manually bulk smush images. It’s been almost a week since this issue was first reported.

    Thanks

  • cbenson583
    • Design Lord, Child of Thor

    Patrick,

    If you can provide me with the info on what you need to do via ftp, I can request a temporary login from our hosting vendor. However, we use a source code control system and deployment tool for changes to code and the wp-config.php file so we can deploy them for you.

    Also, if someone can explain what the code is trying to do when it fails, we might be able to help determine what is happening.

    Julia

  • cbenson583
    • Design Lord, Child of Thor

    Could you please provide more details or a specific error? I don’t understand. The user I sent you is a super admin on staging18.gsu.edu with access to all subsites. I just logged into it with no problem. It’s possible that some countries are blocked as we have a lot of trouble with bots. Can you tell me where you are attempting to login from? I was told by your chat support this morning that Patrick Freitas had gotten in and verified the issue and was working on it.

    Also, could someone please tell me what the actual code that is failing on individual smush is doing so I can see if we can pinpoint the issue?

    Thanks

  • Patrick Freitas
    • Staff

    Hi cbenson583

    Hope you are doing well.

    My apologies for the delay here, yes, the site is blocked on my end too, I had to use USA VPN to access the site.

    I’m getting those error,

    While uploading the image, the Media library returns HTTP error.

    This can indicate low memory, https://www.wpbeginner.com/wp-tutorials/how-to-fix-the-http-image-upload-error-in-wordpress/ you can see an overview of this problem.

    About Smush, I was able to replicate this on your site, but not on mine, tested multiple time/server.

    Once the plugin can Smush on the Bulk Smush but not on upload, please, try the following.

    -Enable the wp-debug,

    https://premium.wpmudev.org/blog/debugging-wordpress-how-to-use-wp_debug/

    Upload a new file and check the wp-content from a log.

    – If no log is generated, please, try to increase the plugin API timeout.

    define('WP_SMUSH_API_TIMEOUT', 300);

    Also the max execution time out to 150 at least.

    If that not solves the problem, please, try to disable the firewall/protection module for a moment and upload the file again, check if this is not blocking any of our IP.

    Otherwise, we will need to escalate this thread to our Second Line Support or Developer for further investigation. For this if possible to create a temp FTP that we can access the wp-config and wp-content folders would be great.

    Let us know what result you got on your tests.

    Best Regards

    Patrick Freitas

  • cbenson583
    • Design Lord, Child of Thor

    Hi Patrick,

    Bulk Smush has always worked for us. I put in the timeout but it has no effect and nothing is logged in the debug.log. The File Path Empty on individual smush occurs immediately upon clicking the smush link. Can you be more specific as to what IPs we should not be blocking? I can’t just turn off all our security on the server. We can whitest IPs if we know what they are.

    However, after digging further, the issue only occurs on our subsides which store files in blogs.dir. Individual file smushing works on the main site where the files are stored under the upload folder. So, somehow Smush Pro is not finding the individual files in the blogs.dir folder. I’m including the content of our .htaccess file. Everything else on the site works fine and is able to access blogs.dir.

    # BEGIN WordPress Georgia State

    # Redirect www to http://www.gsu.edu

    RewriteEngine On

    RewriteCond %{HTTP_HOST} ^www$

    RewriteRule ^(.*)$ http://www.gsu.edu/$1 [R=301,L]

    # Redirect gsu.edu to http://www.gsu.edu

    RewriteEngine On

    RewriteCond %{HTTP_HOST} ^gsu.edu$

    RewriteRule ^(.*)$ http://www.gsu.edu/$1 [R=301,L]

    # Rave Rewrite

    RewriteEngine On

    RewriteRule ^rave-alert$ /wp-content/cache/rave-alert/index.html [L]

    # uploaded files

    # RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

    RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

    #sitemap

    RewriteRule ^(.*/)?sitemap.xml wp-content/sitemap.php [L]

    RewriteEngine On

    RewriteBase /

    RewriteRule ^index.php$ – [L]

    # add a trailing slash to /wp-admin

    RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

    RewriteCond %{REQUEST_FILENAME} -f [OR]

    RewriteCond %{REQUEST_FILENAME} -d

    RewriteRule ^ – [L]

    #RewriteRule ^(wp-(content|admin|includes).*) $1 [L]

    #RewriteRule ^(.*.php)$ $1 [L]

    RewriteRule . index.php [L]

    # END WordPress

    Julia

  • cbenson583
    • Design Lord, Child of Thor

    Hi Kasia,

    In an earlier message, someone requested access to wp-content and wp-config.php. I followed up that we cannot make direct changes to permissions or files in these areas as we use a code management and deployment system so direct server changes will get our systems out of sync and the files will be overwritten with the next deployment. I will try to provide read access to those areas. However, if changes are needed, we will need you to provide to us the changed files or changes to make in our files so, we can deploy them.

    Julia Thompson

  • Nathaniel
    • New Recruit

    Hello cbenson583.

    Good day.

    I’m Nathan from SLS. Thank you for your patience on this matter.

    We’re investigating your situation of individual SMUSH option fail for subsites. To do this, we would like to observe the parameters set on your server. May we re-request access onto staging18.gsu.edu? Unforturately, we are getting either blocked or redirected to a “Web Login Service – Stale Request” page when we try to access via VPN (USA setting).

    Also we hope to view the server settings on subsites with blogs.dir set via FTP. We also would like to request FTP access so we can observe your blogs.dir and other items?

    You can send that privately through our contact form: https://premium.wpmudev.org/contact/#i-have-a-different-question

    Send in:Subject: “Attn: Nathan Villaluz”

    – Admin login:

    Admin username

    Admin password

    Login url

    – FTP credentials

    host

    username

    password

    (and port if required)

    – link back to this thread for reference

    – any other relevant urls

    Thank you.

    Best regards,

    Nathan Villaluz

  • Nathaniel
    • New Recruit

    Hi cbenson583

    Thanks for sharing access details to your server.

    I was able to duplicate the condition you’ve mentioned on a couple of the sub-sites. When I was done, I cleaned up after myself and removed the image files I uploaded for testing after I was done.

    I proceeded to inspect the site via FTP and saw that a file relating to smush was in the /mu-plugins folder named smush-remove-double-post-meta.php I noticed this file has an extra space after the .php extension.

    I downloaded the file into the /mu-plugins folder of my local server for testing with my installation of SMUSH. I was able to replicate the condition on my local server that images were not being optimized upon upload. When I disabled the file by renaming it and changing its extension to .php.off , SMUSH PRO was able to proceed normally.

    After discussing with my teammate, this file is a patch for a need you may have had in the past. To resolve the issue, we agreed to rename the file to smush-remove-double-post-meta.php.off to disable it on your server as well. We then found out = that the SFTP credentials have no permissions to rename files.

    For the fix, please rename the file smush-remove-double-post-meta.php to smush-remove-double-post-meta.php.off found in the folder /wp-content/mu-plugins

    Please retest SMUSH after this step is done. Please give us a heads up on results of the upload.

    Thanks and best regards,

    Nathan

  • cbenson583
    • Design Lord, Child of Thor

    This file was added after the problem started in an attempt to resolve it. The file has been completely removed from the staging server and we still have the exact same behavior. In addition, the problem also occurs on our production environment as well which never had that file. It appears that your code is unable to get the path to the image when the content is stored under blogs.dir.

  • Panos
    • SLS

    Hi cbenson583 ,

    As Nathan is no longer with us we missed this task. So sorry for missing this and finding this out so late.

    The subsites that use blogs.dir are ones created in a really old WP version (I think prior to 3.5) so it’s hard to replicate this. I see that ftp access does work but we don’t have enough permissions to modify any files. That is required in order to debug as we can place logs at several checkpoints and compare results. Is it possible to provide a staging with such ability? Also I can’t access the admin, it returns Error 1020 and Access denied messages. Anything you can do there and allow access?

    If it’s not possible to provide such a staging, and since you have mentioned that bulk Smush does work, I have prepared a custom snippet which checks the image’s path, and if it contains /blogs.dir/ in it, it will call the ajax function that the bulk Smush uses. If you are interested of checking that out, you can download it from:
    https://gist.github.com/wpmudev-sls/dc18a8751cd7e709e5f90eeb94965b36

    Once you download it and unzip it, you can upload it to your site’s wp-content/mu-plugins folder. After uploading it, try uploading new images from the Media page and from the posts admin pages Editor and let us know if this works for you or not.

    As you see in the title it mentions [NOT CONFIRMED YET] so please don’t move this to your production site before testing on your staging site first.

    Kind regards!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.