Hello @dinaddd,
The number/size of the images should not affect the compression process. I have reviewed your site and noticed the following error:
Either a security plugin, custom function, or rules in your .htaccess file is preventing the WordPress REST API from working properly. SiteGround Optimizer is using it to store its options and other functionalities so please make sure it works properly.
This means that some of the functionalities of the other plugins installed on your site are blocking the SGO’s API request. This is why the compression process cannot even start. Unfortunately, I cannot specify the exact plugin so you can perform a test on your side by disabling the plugins one by one and check the compression process. Once you have found the conflicting plugin, you just keep it disabled until the compression is complete and then you can enable it again.
Additionally, I have noticed that there are some restrictive rules added to the .htaccess file under wp-admin/ folder, so you can try commenting those as well.
Thank you so much, you are correct. I deactivated one plugin called ‘Booster Plus for WooCommerce’ and it works well.
But does it means that every time when I add a new image, I have to deactivate it and go Media > Compressing Setting > Do all over again? Or new image will be automatic compressed when plugin is activated?
I went ahead and looked into .htaccess file (from wp-admin) and I don’t know how to edit it. Can you help or…?
allow from 35.214.169.47
allow from 88.208.109.130
allow from 185.140.245.198
allow from 196.196.203.142
allow from 89.102.173.218
allow from 185.140.245.226
allow from 78.44.250.70
allow from 5.181.233.108
allow from 185.210.217.100
allow from 89.176.228.197
allow from 84.42.149.61
allow from 154.160.1.197
allow from 193.84.36.129
allow from 102.176.65.135
allow from 154.160.0.244
allow from 154.160.5.182
allow from 41.218.216.8
allow from 193.84.36.135
allow from 102.176.94.76
allow from 193.84.36.132
allow from 193.84.36.131
allow from 193.84.36.130
allow from 151.67.47.4
allow from 89.247.160.1
deny from all
Hello @dinaddd,
Newly uploaded images are compressed automatically if there is nothing that prevents the compression process from working as expected. Editing the .htaccess file is not something we can assist with but since you have already identified the plugin that was blocking the compression any changes to the .htaccess are not needed at this point.
Regards,
Dimo
Hello @dimodi and @delyandelov
I know this is one month ago, but I started again to compress my images (within 1 deactivated conflicting plugin). It worked well until it got stuck again on 91 images, even after 30 minutes… So I decided to deactivated all my plugins and tried again, and it’s still on 91 images. Any solutions?
Here is my .htaccess file:
# SGS XMLRPC Disable Service
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
# SGS XMLRPC Disable Service END
SetEnv PHPRC /home/customer/www/conferenziaworld.com/public_html/php.ini
<IfModule mod_dtimeout.c>
<Files ~ ".php">
SetEnvIf Request_URI "index.php" DynamicTimeout=900
SetEnvIf Request_URI "wp-admin" DynamicTimeout=900
SetEnvIf Request_URI "wp-admin/admin-ajax.php" DynamicTimeout=900
SetEnvIf Request_URI "wp-admin/admin.php" DynamicTimeout=900
</Files>
</IfModule>
# HTTPS forced by SG-Optimizer
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
# END HTTPS
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Please and thank you so much.
Hello again @dinaddd,
I have reviewed your .htaccess file and do not think some of the added directives are causing the issue. Most probably the WordPress cron that manages the compression process is timing out. To verify that, you need to initiate the compression anew and update this thread if the process stalls again.
Alternatively, you can post a ticket through your SiteGround account where our support team will investigate the case in a timely manner.
I have posted a ticket through my account to your support team. They said it’s have to do with WordPress cron, as what you said. Thank you so much.
