Pavel Dosev

Hello @tvdsluijs,

Thank you for your review and the provided feedback. We’re glad you liked the plugin.

After testing, we can confirm that the plugin uninstalls correctly. The issue you’re experiencing is likely due to a conflict with another plugin or a specific setting within your website’s environment. We recommend checking for any such conflicts or reviewing your site’s configuration to resolve the uninstallation problem.

Hello @jaypeg,

The Maximum Image Width works for newly uploaded images. It won’t change the resolution on already uploaded ones.

Thank you, @spartank.
I replicated the problem and forwarded it to our developers for further review. We will update the thread once we receive an update from them.

Hello @spartank,

Thank you for your detailed feedback on the shortcode issue with our Speed Optimizer’s lazy loading feature. To check this further effectively, we need to replicate it on our end.

Please submit a support ticket with all the relevant details if your website is hosted with us. This will enable us to access your site, create a staging copy, recreate the issue, and look for a solution.

Hello @paddy-landau,

Thank you for bringing this to our attention and for taking the time to identify this issue.

I was able to recreate the issue you described on a newly installed WordPress on my end. I submitted a new internal task to our development team so they could address this in a future plugin update.

Hello @bilion,

There is no direct way to adjust the cache creation to occur on the second visit. However, you can achieve a similar result by purging the cache for the post (or the entire site) after the first visit using the filters provided in this section: Speed Optimizer Custom Filters.

Hello @ovinic,

Thank you for bringing this to our attention and the time you’ve taken to identify this issue.

I was also able to recreate the issue you described on a newly installed WordPress. I submitted a new internal task to our development team so they could address this in a future update of the plugin.

The feature in question provides you with the ability to manage specific settings for each individual sub-site. Previously, these settings were likely configured to automatically purge upon update, which remains the default setting. Unfortunately I can’t tell you why this problem occurred for you after the update.

When a post is updated, the page cache will be automatically purged. However, once the updated page is cached again, it will be served from the cache more swiftly than a non-cached page.

These are the Global settings and per-site defaults. As your pages are getting cached, the dynamic cache for them is turned on for these sites. Otherwise, if you turn it off from the plugin, the content of your site is no longer cached.

You can enable the first setting in SG-Optimiser for each site:

SuperCacher Settings? –> turn on

This will allow you to access the cache settings for each sub-site and from their dashboard. You just need to toggle Automatic purge for the sites you are encountering the issue and that should resolve the problem.

Hello @klishb,

We did not make any changes to the way our caching works in the last update.

When you update a post, the cache will be automatically purged if the option Automatic Purge option is turned on in Speed Optimiser >> Caching. This option is turned on by default and purges the cache when a new post is made, or an existing one is updated.

Please see if this option is turned on for your site. If the problem persists after that, it would be better to submit a ticket to us through your User Area so we can investigate, recreate, and see what is causing this on your end.

Hello @negapo,

We are constantly monitoring and optimizing our plugins. Each entry in your database table serves a specific purpose. All the options the plugin uses are used to store settings related to plugin functionality and user settings, ensuring that all functionalities are working correctly and securing/optimizing the websites.

Still, from the ones you listed, the sgal_ options are not used by our plugins and are not related to our products. Our plugin uses the sgo_/sgs_install options for updates, but these are also periodically cleaned up.

Hello @tomo555,

Thank you for bringing this issue to our attention. We truly appreciate your feedback as it helps us improve our services.

We understand the issue with the plugin and the inconvenience it’s causing. Our developers have been notified and will work on resolving it.

Hello @confusedneedhelp

The sgo_bypass_cookies filter works only for File Based Caching. It does not affect the Dynamic cache.

Still, the Dynamic Caching functionality excludes, by default, the most commonly used cookies. You may find a list of all of the cookies that bypass the cache in the article below:

https://www.siteground.com/kb/siteground-dynamic-caching-configuration/#Cookies

If you want to use a custom cookie that is not excluded from the Dynamic caching, you can use headers to manage cache control. We support all the standard Cache-control header values.

cache-control: no-cache – passing this header tells our system not to cache this request
cache-control: max-age – this header tells our system to cache this request for X amount of seconds

You can also use the nocache_headers()core WordPress function to bypass cache.

A minute and 24 seconds is a significant delay.

If the logs do not help, it might be better to check this by accessing the site itself (or a staging copy) so we can see more details. If the site is hosted with us, please submit a ticket describing the issue, and we will check it.

Hello Stef,

There is some overhead when the plugin is activated, as it performs various checks when the login is submitted. Still, these are usually relatively quick, and the additional loading time of over 1 second is unusual.

I checked and tried to recreate the case on my end. The loading times with or without the plugin were relatively the same, with just a few ‘ms’ differences. Still, the site I was testing on is a test one without significant traffic towards it and, respectively, more entries in the activity log.

You can see if disabling or reducing the time the activity log is preserved will help. You can do this through your Admin page >> SG-Security >> Activity log >> Log Settings