Stoyan Georgiev

Hello there @seoservicesbristollimited,

Let’s say you have a WordPress application and a domain hosted elsewhere.

If you wish to migrate the application to a SiteGround Server, you can do the following steps.

1. You can do this simply by clicking the New Website button inside SiteTools and following the steps. You can select the existing domain option, then follow the steps and select Migrate Website. This will create the site space and will generate a migration token. Copy that token.

2. Download the Migrator plugin on the website you wish to transfer. Go to the plugin page, paste the migration token and start the transfer.

3. After the transfer is complete, you will receive a temporary URL, where you can check if everything with the migration was okay. You will also receive the DNS addresses to which you have to point your domain name after the migration is complete.

4. Proceed to point your domain to the new server.

After the DNS Propagation is complete, and the domain is pointing to the new server, your website will be loaded from the SiteGround. As for the domain transfer, you can always transfer your domain name and manage it from SiteTools. The benefit of this is that you will be managing your website and domain from the same place.

If you have any other questions, feel free to reach out to us.

Kind regards,
Stoyan

Hey there @giammaball,

I checked the product you’ve mentioned and was not able to replicate the issue you’ve mentioned. If there are specific ways to replicate that issue, please provide the steps in this thread. For example – go on that specific page, click that button.

As for the product you’ve mentioned, if I try to add the product without first selecting 300 or 1000 ml variation I get a message that I should first select a specific variation. However, this is normal behavior. If you wish you can set a default value for that product variation.

If you have any other issues, feel free to reach back to us.

Kind regards,
Stoyan

Hello there @generosus,

Thank you for the suggestions! We will consider adding them in future plugin releases.

Kind regards,
Stoyan

Hey there @avviano,

Most probably your files and folders permission are set differently and the necessary archives could not be created. I would suggest double-checking your files and folder permissions. Files should be set to 644 and folders to 755. Also, make sure that a security plugin is not blocking the SiteGround Migrator.

If you have any issues after that, feel free to contact us right away.

Kind regards,
Stoyan

Hey there @bouncern,

Thanks for the report! We will fix this issue in the upcoming versions of the plugin.

Kind regards,
Stoyan

Hey there @marslabsolution ,

We’ve done an investigation and located the issue causing the malformed ipv6s that are being recorded.

We will provide a fix for that in the upcoming version. The issue is not preventing the work of the plugin and it should be working without interfering with the security optimizations that are provided.

Kind regards,
Stoyan

Hey there @generosus,

The wp-admin pages should not be cached by default. Would it be possible to provide a site URL? Also, are you using any additional Cloudflare rules or other caching plugins?

Kind regards,
Stoyan

Hey there @marslabsolution,

Would it be possible to provide a site URL?

Kind regards,
Stoyan

Hey there @adriders,

The sgs_log_events table logs specific events in your WordPress Application. You can monitor in detail the activity of registered, unknown, and blocked visitors. If your site is being hacked, a user, or a plugin was compromised, you can always use the quick tools to block their future actions.
By default, the table is automatically cleared every 12 days.

If you need to decrease the log lifetime you can use the following filter we have provided for that purpose and set it in a specific range between 1 and 12 days.

add_filter( 'sgs_set_activity_log_lifetime', 'set_custom_log_lifetime' );
function set_custom_log_lifetime() {
    return 'your-custom-log-lifetime-in-days';
}

Kind regards,
Stoyan

Hey there @themifyme,

In my previous comment, I’ve meant that scripts that have a specific media query, like the one you’ve mentioned are automatically excluded from the CSS combination, so they do not cause issues with the page styling. When a CSS script is automatically excluded or excluded by the end-user, it will be loaded as normal, meaning that it will be used when it hits the specified breakpoint.

Kind regards,
Stoyan

Hey there @verysiberian,

Increasing the login attempts to such high numbers may lead to data breaches. The idea behind the login attempt is to restrict brute force attacks. By increasing that number, you risk a potential password match and therefore leading to a security breach.

For example, a weak password can be breached with fewer attempts. Giving more attempts to a potential attacker will make things easier for them.

Kind regards,
Stoyan

Hey there @kemeng,

Duplicating plugin functionalities can sometimes lead to unexpected behavior, so make sure you are not using multiple plugins for one thing.

If you are adding rules to the htaccess file, make sure the rules are not misspelled as mentioned by the error.

I would suggest disabling overlapping functionalities. For example, if you wish to use a custom login URL, disable all other plugins doing the same and enable it through the SiteGround Security plugin interface. The same goes for the other optimizations.

If you have issues after that, you can always reopen the thread so we can further investigate.

Hey there @themifyme,

The script you’ve mentioned should be skipped from combination since it is for a specific media screen. Adding it to the combined script will lead to unexpected behavior such as loading CSS for a tablet on a desktop screen which is not wanted.

Kind regards,
Stoyan

Hey there @dimitrisv,

With this optimization, we’re changing the default way to load Google fonts in order to save HTTP requests. In addition to that, all other fonts that your website uses will be properly preloaded so browsers take the least possible amount of time to cache and render them.

We do not add additional charsets or specify them. I did a check and it looks like Roboto supports greek characters, so if the font is not showing some of them the issue may be caused by something else. I would suggest double-checking the way you’ve added the Webfont. If you refer to a local font, please make sure that its version supports the specific charset.

Kind regards,
Stoyan

Hey there @baldguy,

I am afraid that it is not possible to change the loading position of the combined CSS. It is also not recommended since it may lead to unexpected behavior.

Kind regards,
Stoyan