Gergana Petrova

Hello @kontaktdigital ,

The error message indicates that a 404 error occurred when trying to access a specific JavaScript file (chat-widget.esm.js) from the?siteground-optimizer-assets?directory on the website. As you may know, a 404 error means that the requested resource is either missing or incorrectly linked.

The best course of action is to contact us through your SiteGround Client Area so our team can further investigate the cause of the issue.

You can link the support topic here as a reference.

Best Regards,
Gergana Petrova

Hello @djtribunus,

Thank you for your question. The logs are not stored in files, they’re kept in the site’s database.

The plugin doesn’t have a feature to export this data into a .txt file or any other format. You can view the logs only through the plugin’s interface.

If you have any more questions or need help, feel free to reach out.

Best Regards,
Gergana Petrova

Hello @jeherve,

Just wanted to let you know that the recommended change has been applied in the plugin’s most recent update from last week, in version 1.5.1.

Thank you once again for the suggestion.

Best Regards,
Gergana Petrova

Hello @micol78 ,

The information provided is a bit limited, and we will need more details to properly investigate the issue.

If you’re a SiteGround customer, it will be best to reach out to our team through your Client Area providing us with detailed steps on the issue and how can it be recreated on our end.

Best Regards,
Gergana Petrova

Hello @jeherve,

Thank you for the suggestion. I have already passed this on to our plugin’s developers and they will review it at the earliest opportunity.

As soon as there’s been any progress on this – we will update the topic as well.

Best Regards,
Gergana Petrova

Hello @xendo,

Thanks for your suggestion!

Disabling 2FA for specific users, regardless of their user role, does sound like a useful feature. We will forward your request to the plugin’s developers for consideration.

If this feature is approved and implemented, it will be noted in the changelog.

Best Regards,
Gergana Petrova

Hello @karenmansoldo,

This is certainly not intended to happen and we will be more than happy to further check the case on your behalf.

Please reach out to our Support team from your Client Area at SiteGround, so we can investigate in more details what can be the culprit of the issue experienced.

Best Regards,
Gergana Petrova

Hello @atontchev,

The plugin is tested up to WordPress version 6.5.2 and no functionality issues have been observed on a standard install. The issue is most likely related to an incompatibility with other plugin and/or theme.

Please verify if the Security Optimizer is updated to it’s latest version – 1.4.13 and that there are no conflicting settings from other security plugins active at the same time. Make sure your site is also properly configured to work over https://.

If you’re a SiteGround client – you can contact our Support team from your Client Area – in case the issue persists.

Best Regards,
Gergana Petrova

Hello @nek12,

To completely remove our plugin, you must first uninstall it via the website’s Dashboard. After this is done, make sure that all of the following directories are removed as well:

• wp-content/plugins/sg-cachepress/
• wp-content/uploads/siteground-optimizer-assets/
• wp-content/cache/sgo-cache/

Additionally, purge any database records containing the term siteground_optimizer.

Our plugin also inserts .htaccess rules, each preceded by a comment indicating its origin from SiteGround Speed Optimizer. For example:

# 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

Make sure to remove these rules as well. Once the above has been completed, the plugin should no longer be listed in any capacity.

Best Regards,
Gergana Petrova

Hello @estar69,

I have tried to recreate the issue on your website, however the currency was properly detected and displayed while I was browsing. I have also inspected your website, and I can see that the page in particular is not being cached due to the presence of a cookie.

The most effective way to investigate this is further is for you to disable one by one all?Frontend Optimization features?which you have enabled, until you identify the one that may be causing a conflict. Once you’ve identified the feature responsible, you should exclude the conflicting script from this optimization feature, using the?appropriate exclusion filter.

Based on the very limited information we have and without any means to recreate the issue, our best guess here would be either the scripts associated with the Currency Switcher or any Geolocation plugin you may also utilize.

Best Regards,
Gergana Petrova

Hello @pronamic_reuel,

Thank you for the additionally provided information. Your findings have been forwarded to our plugin developers and they are working on resolving this as soon as possible.

While we do not have an ETA, we will make sure to let you know once there’s an update.

Best Regards,
Gergana Petrova

Hello @emma24,

Thank you for reaching out.

I have checked the provided video and I can see that at the moment the test installation is not configured to work over https://.

Could you please reconfigure the install to load securely and then test one more time on your end to see if the issue will still be present?

Best Regards,
Gergana Petrova

Hello @borrypsy,

The Restricted Access page is usually shown when the Login Access feature has been configured and admin access is allowed from specific IPs only. These settings can be adjusted from the WordPress Dashboard >> Security Optimiser? >> Login security >> Login Access >> Configure.? In order to access the site’s admin – you will need to do so from the IP which has been allowed within the above mentioned settings.

In case you’re unsure of the IP – you can proceed with re-installing the plugin a new. You can uninstall the plugin using wp-cli or by deleting the plugin’s folder. In case you remove the plugin manually by deleting the folder, make sure to ?remove all the tables generated by the plugin, as well as any plugin associated entries in the _options table – cron scheduler, version definition (sgs_install_xxx),? etc.

If the issue is still present after reinstall and if you’re a SiteGround customer – you’re more than welcome to contact our Support team so we can further review the case on your behalf.

Best Regards,
Gergana Petrova

Hello @ilgrizly,

Based on your latest update, the information about the styles and scripts you want to exclude is not properly set, which is why the filter is not working as expected.

What you have added in the exclude list is the full path to the .css/.js in use, however what you need to add the .css/.js handle only.

You’re welcome to check the topic previously provided: https://www.ads-software.com/support/topic/how-to-use-sg-optimizers-filters-procedure/ on how to identify the handles.

Best Regards,
Gergana Petrova

Hello @mikepfive, 

When enabling the WebP option for the plugin, it generates copies of all currently existing images and will keep generating such for new images uploaded from the Media Library specifically.

At the moment there’s no option for the plugin to scan for skipped images, so disabling/re-enabling the option is the only way to start the process again.

That said – any manually uploaded images via FTP or other means – will not have WebP copies generated. If any of the skipped images are uploaded via different means than the Media Library, even re-enabling the option will not resolve the issue.

If you’re a SiteGround customer, you’re welcome to reach our support team from your Client Area and we will be happy to take an additional look on your behalf. 

Best Regards,
Gergana Petrova