Pavel Dosev

Hello Reüel,

Our developers are still working on the issue. We’ll update this thread as soon as we have a resolution.

Hello @joshmacd,

We are sorry to hear about the issues you experienced. It’s possible that the problem stems from a plugin conflict or a restriction on the destination server.

If you would like us to investigate this further, please submit a Helpdesk ticket through your SiteGround Client Area, and we will check it further.

Hello @generosus,

There is no built-in filter in WordPress that allows you to exclude a JavaScript file like jquery-core on a per-page basis, such as only for the WP-Admin and WP-Login pages. The filter you’ve mentioned (sgo_js_async_exclude) applies site-wide and cannot be limited to specific URLs or pages within the admin area.

Hello @mwelwa,

It would be better to open a Helpdesk request through your SiteGround Client Area so we can investigate the problem further and in detail.

Since this forum is centered on WordPress, we can’t go into details about Siteground here.

Our security plugin offers security features that could help stop such attacks. Additionally, our servers have protections against different types of attacks, including brute-force attempts.

Hello @westhillsweb,

Thank you for your feedback. We’ve forwarded your suggestions to our development team for further review.

Hello @generosus,

Our plugin, Security Optimizer – The All-In-One WordPress Protection Plugin, comes installed with some security options turned on by default, and additional options can be activated to strengthen the site’s security further and prevent brute-force attacks toward the website. From the login section, you can also allow access to the admin page only from certain IPs or change the default URL.

There are also additional systems in place to protect sites hosted on our servers from such and other attacks.

Hello @egn145,

The error you encountered with the Speed Optimizer plugin seems to be due to a restriction on your hosting server. The plugin requires a function called exec(), which is probably not enabled on your server. This function is essential for some of the plugin’s features to work properly.

To address this, the first step is to reach out to your hosting provider and ask if they can enable the exec() function for your website. It’s worth noting that this function is commonly disabled for security reasons, so they might not allow it. The function itself uses wp-cli and executes this command, which is part of the HTTPS force and is changing the URLs in the database to use HTTPS:

            // Build the command.
            $command = sprintf(
                    "wp search-replace '%s' '%s' --all-tables",
                    $from . $site_url_without_protocol,
                    $to . $site_url_without_protocol
            );

            // Execute the command.
            exec(
                    $command,
                    $output,
                    $status
            );

Hello @painlessseo),

The WebP Images feature on SiteGround works by generating and then serving WebP images directly from the server without altering the HTML <img> tags on your site. This means you won’t see the <picture> element in your code, but WebP images are still being delivered to supported browsers.

To confirm that WebP images are being served, you can check the network requests in your browser’s Developer Tools. Look for the ‘Type’ column in the Network tab when you reload your page; it should indicate ‘webp’ for images if they are being served in that format.

Hello @painlessseo,

Yes, external images added to your post are also lazy-loaded. You can use the browser’s dev tools and right-click>> Inspect element, and there you should see ‘lazy loaded’ for the image, like this:

img decoding="async" class="alignnone size-medium lazyloaded" src=....

Hello @edmovius,

The theme you are using might have mobile and desktop versions of your site. This may be causing the problem. If this menu is cached in our dynamic cache and then requested from a desktop browser, the menu will not appear.

We have a setting in the WordPress admin>>SiteGround Optimizer >> Caching >>Browser-specific Caching. Toggling on this setting will create a separate cache for mobile and desktop users, and the problem should no longer occur. After toggling the feature, you must clear your website’s cache.

I want to clarify that the WordPress forum is intended for support-related requests to the plugin.

PageSpeed Insights scores can’t be discussed or addressed here. You might consider contacting us through your User area or other professional services for broader performance optimization issues.

Hello @coderswift,

I checked the site requests now, and there is no such cookie. The dynamic cache is also working for your website at the moment:

pavel.dosev@Pavel-Dosev:~$ curl -IX GET https://pos.royal4you.com/ -s| grep x-proxy-cache
x-proxy-cache: HIT

Hello @dackl,

You can provide the purge cache capabilities by adding this code snippet to your theme’s function.php file:

add_filter( 'sgo_purge_button_capabilities', 'sgo_add_new_role' );
function sgo_add_new_role( $default_capabilities ) {
  // Allow new user role to flush cache.
  $default_capabilities[] = 'delete_others_posts'; // For Editors.
  $default_capabilities[] = 'edit_published_posts'; // For Authors.

  return $default_capabilities;
}

You can see this one, as well as other custom filters available for the plugin, in the article below:

https://eu.siteground.com/tutorials/wordpress/speed-optimizer/custom-filters/#Control_which_user_roles_have_permission_to_do_a_manual_cache_purge

Hello @barretd,

We’re sorry to hear about the issue you’re experiencing. To address this, could you please provide specific details about the conflict? Knowing exactly what’s happening will help us pinpoint the cause.

Our plugin is compatible with Forminator and works correctly with it. If the problem is related to caching, you can disable the cache for Forminator forms through the form Settings >> Rendering >> Prevent caching.