stanimirpanayotov

Hello,

The case has been reported to our WordPress Developers, and they have confirmed that a fix should be deployed in the next release of the Speed Optimizer plugin. In the meantime, you can either disable debugging mode in WordPress:

https://developer.ww.wp.xz.cn/advanced-administration/debug/debug-wordpress/

Or, you can keep debug mode enabled and disable only the display of errors and warnings. You can do this by defining the following constants in the wp-config.php file:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );

Best Regards,
Stanimir Panayotov

Hello Nikola,

Our WordPress developers agree that your suggestion is valid and will consider it for future updates to the plugin. However, we cannot guarantee if or when this feature will be added.

For now, you can use the current integrations with third-party form plugins that provide CAPTCHA/reCAPTCHA protection.

Best Regards,
Stanimir Panayotov

Hello @kodako,

The latest version of the Speed Optimizer plugin (v7.7.5) is tested and confirmed to work with the latest version of the WordPress core (v6.9). You can also see this in the “Tested up to” field on the plugin’s page here.

Just in case, I installed a brand new WordPress application using the latest stable versions of the WordPress core, the Speed Optimizer plugin, and Elementor (v3.33.3). However, I was not able to spot any issues or errors while browsing through the website or creating a sample page.

I also checked our internal channels but I did not find any recently reported problems with the plugin and the latest version of WordPress. This leads me to believe that the reported issue is specific to your website(s) and its (their) setup. In order to investigate this further, however, we will need more detailed information like the exact error that you saw or instructions on how to recreate the issue on our end. If your website(s) are hosted with SiteGround, please post a Help Desk ticket through your SiteGround User Area and provide us with as much information as possible regarding the reported problem and how we may reproduce it.

In case you are experiencing problems with the frontend optimizations (CSS, JS, HTML minification, or CSS/JS combination), you can use the built-in exclude feature under each of those optimizations and exclude the specific script or stylesheet that is not compatible with the optimization feature. If the script/stylesheet in question is not listed in the exclude option, you can follow this guide on how to find its handle and exclude it with custom filters:

https://ww.wp.xz.cn/support/topic/how-to-use-sg-optimizers-filters-procedure/

Best regards,
Stanimir Panayotov

Hello Jan,

Thank you for your suggestion and the detailed information about the Live Preview feature. While I cannot confirm if or when this feature will be implemented, I have shared your feedback with our WordPress developers.

Best Regards,
Stanimir Panayotov

Hello again,

I wanted to provide you with a brief update: our WordPress developers have confirmed that an internal task has been created and a solution has been implemented. This solution is planned to be included in the upcoming plugin releases.

Thank you once again for your valuable feedback and patience!

Best Regards,
Stanimir Panayotov

Hello @skolcs,

Thank you for your feedback! The behavior you reported, where all WebP images are deleted after disabling the “Use WebP Images” feature, is normal for the current version of the plugin. This has been the standard behavior for several years. Additionally, a pop-up warning informs you of this action and requires your confirmation before proceeding.

In case the images were lost and you are a SiteGround customer, you can use the latest available daily backup for your site and restore only the “wp-content/uploads/” folder. This should effectively restore all missing media files. For more details on the backup service and how to use it, please refer to this article:

https://www.siteground.com/kb/backup-service/#How_to_restore_files_databases_and_emails

We understand the importance of such cases, and I can assure you that we value our customers’ feedback. This is why we requested our WordPress developers to review the case. However, as we cannot specify an ETA on when this would happen and if the feature will be reworked, there is no need to keep this thread open. You can regularly check the release notes of future updates to see if a change has been implemented for this functionality.

Thank you for your understanding and cooperation!

Best Regards,
Stanimir Panayotov

Hello @theduck ,

This is expected behavior because WooCommerce and third-party extensions do not automatically recognize custom login URL changes. To resolve this, you or your developer should update the relevant email templates to include the custom login URL. Alternatively, you can log in to the WordPress Dashboard before clicking on the email links, ensuring your browser is already authorized to access these pages.

Best Regards,
Stanimir Panayotov

Hello Dan,

We actually do not change the file extension, and the image URL remains the original one. When there is a request for an image, we check if there is a WebP image variant for it. If there is one, we serve the WebP image instead of the requested one. If there is no WebP image variant, we serve the original image. This not only helps preserve the original image URLs but also allows older browsers that do not support WebP to see the website’s media—in this case, the original image will be served.

You can confirm this in the response headers of the request for that image and checking the “content-type” header. For example, using the following CURL command:

Stanimir.Panayotov@SiteGround:~$ curl -I -H "Accept: image/webp" https://cliftonaudiology.com/wp-content/uploads/2025/06/hearing-aid-test-clifton-sm.jpg

Here are the response headers:

HTTP/2 200
server: nginx
date: Wed, 09 Jul 2025 16:24:19 GMT
content-type: image/webp
content-length: 73932
last-modified: Tue, 17 Jun 2025 10:46:08 GMT
etag: “68514770-120cc”
expires: Thu, 09 Jul 2026 16:24:19 GMT
cache-control: max-age=31536000
host-header: 8441280b0c35cbc1147f8ba998a563a7
x-proxy-cache-info: DT:1
accept-ranges: bytes

As you can see from the above example, although I am requesting the hearing-aid-test-clifton-sm.jpg image, the returned one is with a “content-type: image/webp”. This indicates that the returned media file is a WebP image instead of the original JPG one.

You can also use your browser’s developer tools (Network tab) to see this information as well. Here is a screenshot: https://snipboard.io/PRTNpz.jpg

I hope this information will be useful.

Best Regards
Stanimir Panayotov