kuzmanstoyanov

Hello @fatcacky ,?

By default, only Editor and Administrator roles are included in the Two-factor Authentication. 

There is a special filter you can use to force other user roles to use the feature.

In this particular case, you should add the following filter in the functions.php of your active theme:

add_filter( 'sg_security_2fa_roles', 'add_user_roles_to_2fa' );
function add_user_roles_to_2fa( $roles ) {
	$roles[] = 'shop_manager';
	return $roles;
}

Best Regards,
Kuzman Stoyanov

Hello @suba89,?

We would not be able to investigate properly without having access to the website and without being able to recreate the error from our side. 

I would advise you to disable the following Frontend Optimization features one-by-one and verify which one is causing the error:

Combine JS files
Defer Render-blocking JavaScript?

Based on that, there are different filters you can use to exclude the script from being combined/deferred. You can preview all of the exclude filters here.?

You may also refer to this thread, which explains how to properly use the filters.?

If you are a SiteGround client, please, submit a support inquiry from your SiteGround Client Area. The technical support team will be able to assist if the error is caused by SiteGround Optimizer or the hosting environment.

Best Regards,
Kuzman Stoyanov

Hello @danatimofte,

Thank you for reporting the issue. 

I was able to recreate it and passed the report to our developers.?They will consider implementing a fix in some of the next releases of the plugin.

Best Regards,?
Kuzman Stoyanov

Hello @iang1980,

You can try to resolve the issue by enabling the “Browser-Specific Caching” feature:

https://www.siteground.com/tutorials/wordpress/sg-optimizer/supercacher/#How_to_Enable_Browser-Specific_Caching

After enabling this option the server will start storing separate cache data for different user agents, which may resolve the issue you are referring to.?

Best Regards,?
Kuzman Stoyanov

Hello @fabiovito83,

Skipping the cache when a cookie is present in the headers is expected behavior and it is how the caching is designed to work. Note that the cookies may store visitor’s sensitive data. The presence of a cookie in the header is instructing the server that there is private information on the page.?

Bypassing the cache on such pages is how we are ensuring that this private data would not be served to other visitors. Note that this is not controlled by the SiteGround Optimizer plugin itself, but by the SiteGround Nginx configuration. That being said, there is no option to exclude a cookie within the settings of the plugin and activate the caching while the same cookie is present in the headers.  

In regard to woocommerce_recently_viewed, it is a cookie added by a WooCommerce widget. I did some research online, but I could not find a way to disable the cookie except for disabling the Recently Viewed Products. I would advise you to get in touch with the WooCommerce team for additional instructions on how to disable the cookie. 

Best Regards,?
Kuzman Stoyanov

Hello @marymaru,

Note that the SiteGround caching and optimization mechanisms are disabled when you are logged in to the WordPress backend. This is why the page looks fine when you are logged in as administrator.

The plugin allows the option to exclude specific CSS files from being combined/minified:

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

If you can not find the CSS script listed in the Exclude drop-down menu, you can still exclude it by adding a filter in the functions.php of the active theme:

add_filter( 'sgo_css_combine_exclude', 'css_combine_exclude' );
function css_combine_exclude( $exclude_list ) {
	// Add the style handle to exclude list.
	$exclude_list[] = 'style-handle';

	return $exclude_list;
}

Where you should replace “style-handle” with the actual handle of the CSS you wish to exclude.

If you are unable to exclude the script yourself, do not hesitate to contact the SiteGround support team for assistance on the matter. Our team will gladly help you to identify and exclude the problematic script.

Best Regards,
Kuzman Stoyanov

Hello @faiiprst,

According to the Page Speed report, there are a lot of unused CSS and JS scripts loaded on your site’s pages and this is one of the main reasons for the slow loading times. It is recommended to preview all your plugins and uninstall the ones which are not actively in use.

On a side note, the Dynamic cache is not working due to Set-Cookie headers added by Nitropack and WooCommerce plugins:

x-proxy-cache: MISS
x-proxy-cache-info: 0 NC:000000 UP:SKIP_CACHE_SET_COOKIE

Enabling the Dynamic cache will improve the overall performance of your website. Please, check if the cookies could be disabled completely or at least partially for some of the pages. Nitropack is another optimization plugin and using more than one caching plugin is not recommended. Overlapping functionalities can cause certain optimization tools to not work as expected.

If the Dynamic cache isn’t working after you disable the cookies, please contact the SiteGround Technical Support team for further assistance on the matter.

Best Regards,?
Kuzman Stoyanov

Hello @tictubso,

Yes, it is safe to delete the content from this folder. Note that siteground-optimizer-assets/ contains all the minified and combined JS/CSS scripts as well as assets from other optimization features.

Deleting the files in this folder will remove the optimized assets and the plugin will have to generate them anew.

You can easily delete all assets and empty the folder by clicking on the Purge SG Cache button, which you will find on your WordPress admin toolbar.

Best Regards,
Kuzman Stoyanov

• This reply was modified 1 year, 8 months ago by kuzmanstoyanov.

Hello @guyinpv

The reason why you can not find the script in the exclusion list is that the Google tag is added as an inline script. According to the ID of the script, you are using the Google Sitekit plugin. I was able to recreate the issue and reported it to our developers.

In the meantime, you should be able to exclude the script by adding the following filter to the functions.php of the active theme:

add_filter( 'sgo_js_async_exclude', 'js_async_exclude' );
function js_async_exclude( $exclude_list ) {
	$exclude_list[] = 'google_gtagjs';

	return $exclude_list;
}

With this code added to functions.php, you can safely activate the “Defer Render-blocking JavaScript” feature.

Best Regards,
Kuzman Stoyanov

I confirm that SiteGround Security supports WordPress websites installed in subfolder. I tested the same setup with our plugin and TwentyTwentyThree theme installed and verified that the custom login page works properly. 

Also, In the provided example, the default WordPress admin URLs redirect to 404 pages, which is expected behavior:

Kuzman-Stoyanov:~ kuzman.stoyanov$ curl -I https://computeplant.s2-tastewp.com/wp-login.php
HTTP/2 302
date: Mon, 06 Mar 2023 03:37:55 GMT
content-type: text/html; charset=UTF-8
location: https://computeplant.s2-tastewp.com/404

The same is expected to work for a website installed in a subfolder. 

Have in mind that wp-login.php is only accessible for visitors that have accessed the custom login URL once. Still, if you try to login directly through wp-login.php as administrator, you will see the error below:

ERROR: You are trying to login with an administrative account. Please, use the Custom Login URL instead.

That being said, logging into the admin dashboard is only possible through the custom login URL.

Regards,
Kuzman Stoyanov

Hello @brucewp,

The issue could also be caused by a plugin conflict. It usually occurs if there is another plugin setting up a different custom login URL – security plugins or plugins that customize your WordPress login page.

But this is definitely not expected behavior with only SiteGround Security and TwentyTwentyThree installed. I was unable to recreate it on my end.

If you are a SiteGround customer, please contact our Technical Support team. This way we will able to access your website and investigate in detail.

Regards,
Kuzman Stoyanov

Hello @lochievaughan, ?

When a Custom Login URL set, it changing the default WordPress login URLs (/wp-admin, /wp-login.php) to the custom URL of your choice. When enabled, all requests to the default login addresses will be redirected to 404 Not Found.?

The way the issue is described, it looks like the login page of the membership plugin is trying to redirect the users to wp-admin or wp-login.php, instead of the custom URL. This could also happen if there are 2 different custom login URLs created with different plugins.?

I am afraid it would not be possible to advise you properly since we have no access to the website. If you are a SiteGround customer, you can contact our Technical Support team so we can investigate in detail.?

Best Regards,?
Kuzman Stoyanov

Hello @zudie,?

We will need more information in order to assist you properly. Would you please let us know which is the website you noticed the warnings on?

If you are a SiteGround client, please open a support request through your Client Area and the issue will be investigated by the Technical Support team.

Best Regards,
Kuzman Stoyanov

Hello?@mattsexsmith,

I was able to recreate the issue on your “Contact Us” page. I noticed errors about a few JS files in the dev console in Google Chrome. Currently, the JS Combine feature seems to be disabled for your website. The other feature that could be causing the JS errors is “Defer Render-blocking JavaScript“. 

I previewed the HTML source code of the page and verified none of the Elementor scripts was deferred by our plugin. There are however 2 WordPress core files that produce errors on the page. I would advise you to exclude the following scripts from Defer Render-blocking JavaScript:

/wp-includes/js/jquery/jquery.min.js
/wp-includes/js/jquery/ui/core.min.js?

This tutorial will help you exclude the scripts.?Then clear the cache and verify the results. If the issue persists, I would suggest that you contact the SiteGround Technical Support team for further assistance.?

Regards,?
Kuzman Stoyanov

@uriahs-victor ,?

I installed the latest version of your plugin to an empty WordPress site with only SiteGround Optimizer and WooCoomerce installed. Then I added the exact same filters I provided in my previous response. Exclude the handles from Combine JS Files

add_filter( 'sgo_javascript_combine_exclude', 'js_combine_exclude' );
function js_combine_exclude( $exclude_list ) {
$exclude_list[] = 'lpac-base-map';
$exclude_list[] = 'lpac-checkout-page-map';
return $exclude_list;
}

Exclude the handles from Defer Render-blocking JavaScript:

add_filter( 'sgo_js_async_exclude', 'js_async_exclude' );
function js_async_exclude( $exclude_list ) {
$exclude_list[] = 'lpac-base-map';
$exclude_list[] = 'lpac-checkout-page-map';
return $exclude_list;
}

The result was the same – the base-map.js and checkout-page-map.js scripts have been excluded from the combined JS script created by SiteGround Optimizer. Here is a screenshot of the HTML source code of the checkout page of my test WordPress site. You can see that the combined JS file is loaded at the bottom (deferred), while base-map.js and checkout-page-map.js load separately. The same was the result on a temp site created with https://tastewp.com/ – screenshot

I confirm the filters work as expected with your plugin’s JS files, but I am unable to tell you what is causing the issue on your site without having access to the application. If you are a SiteGround client, I would recommend that you contact our Technical Support team, so they can investigate in detail.?

Regards,?
Kuzman Stoyanov