Georgi Ganchev

@devfirst,

I see that you edited your post while I was writing my reply.

The reported issue cannot be replicated on our end. We are testing with a brand new vanilla installation. There are no such problems reported by other users since the last update of the plugin which happened on 4-th of March.

The issue should be related to some specific setup you are using, for us to test the same we would need to have the means to replicate it.

What I advise you to do is to check the health status of your WordPress from Tools > Site Health and let us know if any issues are reported. Please verify that you are using the latest SG Optimizer plugin version and provide us with a screenshot of the exact error that you encounter.

In case you have set up the new installation in a subdirectory, please make sure that there are no .htaccess files with restrictive rules in the previous directories.

We will review the details that you provide in a new thread.

Best regards,
Georgi Ganchev

Hello @devfirst,

There is no specific problem with the SIteGround Optimizer plugin that could be causing this issue. Such Rest API errors are usually related to restrictive rules or a conflict caused by another plugin.

I advise you to open a new thread and provide us with the URL of the website where you are testing this behavior.If there are any specific steps that should be followed to encounter the problem, we would appreciate if you provide them.

Please also enlist the plugins and the themes that are present under your application. You mentioned that it is vanilla, but testing with such installation on our end, we could not encounter similar issues.

In case you have set up the new installation in a subdirectory, please make sure that there are no .htaccess files with restrictive rules in the previous directories. It is important that the

If you are a SiteGround client you are also welcome to open a Help desk request and we will be checking things further on our end.

Best regards,
Georgi Ganchev

Hello @drhnews ,

As mentioned by Stoyan, the table is cleared based on the defined period. 12 days is the default period and using the filtering you are able to reduce that timeframe.

The table is cleared along with all entries present in it. Meaning the log starts from 0 based on the defined period.

Best regards,
Georgi Ganchev

Hello @speakoutenglish ,

We noticed that this error was already reported a few months ago and it was related to a .htaccess rule that is applied by your All in One WP Security & Firewall plugin. A forum thread was opened and a solution was suggested on their end.

The thread can be found here:
https://www.ads-software.com/support/topic/siteground-optimizer-v6-and-6g-blacklist-firewall/

Please apply the suggested fix and the issue would be resolved.

Best regards,
Georgi Ganchev

Hello @kimball31 ,

We have reviewed the feature request and for now, we have decided that such an option would not be implemented.

By default, the database maintenance is executed through a cron event scheduled to be performed every week. Once the event is performed it gets automatically scheduled to be executed in 7 days.

If you would prefer to control the execution this can easily be done through WP-Cli

You can enlist the scheduled cron events with this command:
wp cron event list

If you want to execute the cron event on demand you can execute this command:
wp cron event run siteground_optimizer_database_optimization_cron
This action will run the event and basically allow you the control that you require.

Best regards,
Georgi Ganchev

Hello @smc2935 ,

We have released a new version of our SiteGround Optimizer plugin that addressed the problems with the Automatic cache purge functionality.

Please update the plugin to its latest version and test if the problems reported would persist.

Best regards,
Georgi Ganchev

Hello @richhickson

We have released a new version of the SiteGround Optimizer plugin. Out developers had worked on improving the Automatic purge functionality and I would like to invite you to update the plugin and see if there will be any difference observed on your end.

Best regards,
Georgi Ganchev

Hello @alalehweb97 ,

We have released a new version of the SiteGround Optimizer plugin which addresses the aforementioned File-based caching issues. You may update the plugin and enable all layers of caching. The cache should be automatically purged upon post updates.

In case there is still a problem in that aspect, let us know and we would review it.

Best regards,
Georgi Ganchev

Hello @confusedneedhelp,

Please be informed that we have released a new version of our SiteGround Optimizer plugin.

You can update the plugin and enable File-based caching again. The automatic purge has been improved in the new version and the problem should no longer occur. Let us know if you still encounter any issues.

Best regards,
Georgi Ganchev

Hello @alexdalzovo,

We thank you for the suggestion. We will evaluate the demand for such requests and consider introducing such options in the future.

Currently, you can disable comments from Settings ? Discussion from the left sidebar of your WordPress admin panel. On this page, you need to uncheck the option that says “Allow people to post comments on new articles” and then click on the Save Changes button to store your settings. This will disable comments on all your future posts.

Best regards,
Georgi Ganchev

Hello @blueazure000

You should check if the Automatic purge functionality of the plugin is activated. This option is present under the Caching tab within the SG Optimizer plugin.

In addition, you can exclude your URLs from being cached.

If the above actions don’t improve the situation, we can check things further if you provide us with URL of your application and the steps we should follow to replicate the product update sequence.

Best regards,
Georgi Ganchev

Hello @richhickson,

When the Automatic Cache Purge is enabled, the plugin starts monitoring certain WP Hooks and purges cache when some of those fires.

There is a hook that triggers upon updating a post and if this doesn’t happen we would need to check things on our end. Could you please let us know the URL of your website hosted with us? If there are any specific steps taken we would appreciate it if you list them as well.

Please let us know if this happens for specific users as well or the same applies to the administrator user roles as well.

Best regards,
Georgi Ganchev

Thank you for the provided information.

We can assure you that the WPML was tested against all functionalities of the SG Optimizer plugin in a fresh installation and there were no REST API issues encountered. If you have an account with SiteGround you are welcome to open a support request and we can try to replicate your tests.

The imagick and ioncube are extensions that are not set by default and require php.ini in order to be enabled. If your application works as expected with those removed, then you should not be worried. Usually, some themes or plugins may require the extensions to be enabled but those are not mandatory for a standard WordPress installation.

Best regards,
Georgi Ganchev

Hello @talkiewalkie

It is likely that you are deferring the wpmGoogleInlineScripts.js script, which you shouldn’t, because with the new update it is required to be loaded before the inline scripts. You can exclude JS scripts from deferring from the plugin Frontend settings.

The other warnings you see are due to the Fonts preload functionality. Since you have enabled that option intentionally there is nothing to worry about.

If you do not want the fonts to be preloaded you can remove them from the list under SG Optimizer –> Frontend –> General –> Font preloading.

You should experiment with the available options and see how they reflect on your website. If conflicts occur you can discuss them with your developer and consider which to turn on and off.

Best regards,
Georgi Ganchev

Hello @jwink123 ,

I was able to find the account associated with the website https://la-modique.com and there are no tickets submitted on your end, where the issue was described or reported.

I checked your website and I see that you are using WP Rocket plugin for serving your cache and caching headers. What I would advise you is to consider removing the duplicate caching functionalities as they can be causing issues with your website caching. Then I advise you to test again and if the problem persists we would be glad to review it further over a ticket that you can post from your Client Area.

Best regards,
Georgi Ganchev