Vladimir Trandev

Hello @visureclic,

The plugin can be used on any hosting, not only on sites hosted at Siteground servers.

As far as I understand, you experience some compatibility issues with a specific plugin. If so, you can try to disable some of the available options and to check if there will be any difference:

https://www.siteground.com/tutorials/wordpress/sg-security/site-security/

If this is the case, you can leave the particular setting disabled and still benefit from the rest of the features offered by our plugin.

Regards,
Vladimir

Hello @pautgn,

The website is copied at the new destination and no changes are made to the original destination.

However, you can also share the additional details in the mentioned support ticket and we will be glad to clarify the situation in the particular case.

Regards,
Vladimir

Hello @pautgn,

For our SG Migrator and Site Tools -> WordPress -> Search & Replace tool we use WP-CLI to do a serialized search-replace on the database. However, some hardcoded URL’s may mess up.

Regards,
Vladimir

Hello @shred101,

I would recommend you to try tweaking the frontend optimization options in our plugin and to check if there will be any difference:

https://www.siteground.com/tutorials/wordpress/sg-optimizer/frontend-optimization/

If this is the case, you can leave the particular setting disabled and still benefit from the rest of the features offered by our plugin.

Regards,
Vladimir

Hello @generosus,

In some cases, the wp-cron.php file may become a target of a DOS attack, or caching plugins can interfere with its execution which can cause either a lot of server load or the scheduled tasks may not execute properly and timely. This is why you can substitute this constant file execution with a real cron job.

Regards,
Vladimir

Hello @generosus,

In case, you deactivate the “Use WebP Images” option, this will delete all existing WebP files including images generated by the plugin and manually uploaded ones. The mentioned behaviour has been also described by a warning message when you switch this option in the plugin’s settings.

Regards,
Vladimir

Hello @ameephillips,

Have in mind that the “Scheduled Database Maintenance” hook is:

siteground_optimizer_database_optimization_cron

You can verify the above information by activating/deactivating the mentioned option in your dashboard.

However, if this is not the case, please provide us with your domain.

Regards,
Vladimir

Hello @pautgn,

The “siteground-migrator.log” is indeed located in the wp-content folder. However, make sure that you are checking the wp-content folder of the source website.

Regards,
Vladimir

Hello @dizzybuddha,

We have not observed similar behaviour and I was not able to replicate it on my end.

However, it might be related to a specific plugin/theme on your application.

Could you please provide us with your domain?

Regards,
Vladimir

Hello @kanten,

If the “Back up all original images” option is enabled, we first create a backup of the original image and save it with “.bak.” prefix before the image extension. For example:

image.jpg -> original image
image.bak.jpg -> backup of the original image

If you wish to restore the original images, you should simply choose:

Media -> Image Compression -> Edit -> Compression Level -> None

You can try to modify your images again with the desired compression level but I would recommend you to check for other activated optimization plugins on your application. In case, you use separate image compression plugins at the same time, this may lead to unexpected results during the optimization process.

Regards,
Vladimir

Hello Cynthia,

I would recommend you to try tweaking the frontend optimization/caching options in our plugin and to check if there will be any difference:

https://www.siteground.com/tutorials/wordpress/sg-optimizer/frontend-optimization/

If this is the case, you can leave the particular setting disabled and still benefit from the rest of the features offered by our plugin.

Regards,
Vladimir

Hello @jdo300,

It seems that you have a plugin/theme or other script that creates sessions for your pages:

set-cookie: PHPSESSID=5e46dc3d2372c4aa67bf732d8ea1177e; path=/

so the following header is also set:

cache-control: no-store, no-cache, must-revalidate

There is not much our developers can do in such cases. Sessions should never be cached and I would recommend you to discuss the matter further with your local website developer.

Regards,
Vladimir

Yes, the caching should be working for such resources.

Regards,
Vladimir

If you mean optimization or performance, we actually optimize all images that are uploaded via WordPress Media uploader.

If the images are manually uploaded or if they are part of the theme/plugin files, then we do not optimize them.

Regards,
Vladimir

Hello @pautgn,

We do not have particular plans about the mentioned feature request. If we make such implementation in future, it will be included in the changelog.

Regards,
Vladimir