Plamen M

Hello @dvora ,

Please, provide us with more details:
– Which function is now working?
– Do you see any error related to this function? If “yes” what is the error?
– what are the steps that you are taking?

We expect your reply.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

Hello @hassantafreshi ,

If I understand your request correctly, you are looking for a way for the cached content to be flushed upon changes through the Easy Form Builder plugin. When you are adding a form to a post or a page, the cache is being automatically flushed upon publishing the changes. Another way is to flush the cache manually through the Purge SG Cache button. A third option is to use one of the custom filters. You can check some examples here and adjust them to your needs:

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

Regards,
Plamen.M
Tech Support Team
SiteGround.com

You are most welcome. I am glad that you found a working solution and also thank you for sharing.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

Thank you for the update. You can try with the following .htaccess rule. This configuration will allow access to PHP files within the?excluded-folder?while denying access to PHP files in all other directories.

# Exclude the folder named 'excluded-folder' from the restrictive rule
<Directory "/path/to/your/excluded-folder">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Allow from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all granted
  </IfModule>
</Directory>

# SGS Directory Hardening
<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all denied
  </IfModule>
</FilesMatch>

Replace /path/to/your/excluded-folder with the actual path to the folder you want to exclude from the restrictive rule.

If the folder is within the same directory as your?.htaccess?file, you can use a relative path instead.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

As an alternative, you can also use the exclusion filters described here:

https://eu.siteground.com/tutorials/wordpress/security-optimizer/custom-filters/#Whitelist_a_specific_script_from_Lock_and_Protect_System_Folders

I also updated my first reply with this, to make it easier for others who come across this thread here.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

Hello @sflwa ,

The feature “Lock and Protect System Folders” works through .htaccess rules. For example, in the .htaccess file added within the /wp-content folder. If you need to enable access to a particular file or folder, you can either tweak or comment out the rules in that particular .htaccess file.

Alternatively, you can also apply these exclusion filters:

https://eu.siteground.com/tutorials/wordpress/security-optimizer/custom-filters/#Whitelist_a_specific_script_from_Lock_and_Protect_System_Folders

Regards,
Plamen.M
Tech Support Team
SiteGround.com

• This reply was modified 3 months, 3 weeks ago by Plamen M.

Hello @torgrim,

The plugin is designed to automatically flush the server sided cache when an article or a post is created or updated in the back end.

To see the changes, your editors would also need to remember to flush the cache in their browsers.

If you continue experiencing issues, please post a support ticket through the User Area in your Site Ground hosting account. We will then be able to further check and investigate the case on the spot.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

Hello @generosus ,

I Installed a fresh instance of WordPress 6.5.5. I set the PHP Version to PHP 8.2. Then I uploaded an .avif image to the fresh site without any edits to the default .htaccess file. The Firefox browser properly showed the image and inspecting it properly shows the type as an avif image:

https://prnt.sc/9xuVDnW8NH4Y

The inbuilt avif support is working as expected when the latest versions of WordPress are running on our server with PHP 8.1 and above set for the site.

If you continue facing issues, please post a support ticket through the Helpdesk section in your User Area account with SiteGround. We can then check the issue directly on the site where you see it occurring.

Thank you.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

Hello Cecilia,

I am sorry that you had a poor experience with our plugin. Upon removing the plugin, it only cleans up its files and database entries, nothing else from your site. This is why, removing the plugin should not cause your site to go down. In most cases, clearing the cache in your browser should bring your site back immediately.

We will be more than happy to look into the issues that you are having with the plugin. If you are a SiteGround customer, please post a support ticket through the Helpdesk section in your User Area. There, please describe the issues that you had in details.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

Thank you for the recommendation. I will include it as a suggestion to our Site Tools developers.

As for the software version. The reason why we choose to step on older stable releases and patch and enhance them with the latest code patches is not our hardware, but older client applications, which, if they “see” memcached version 1.6.28 would fail to work and effectively get the entire site down. On the other hand, both old and new software code is proven to work great with version 1.6.9 of memcached.

I hope this brings more clarity to the reason why we choose this approach to the software versions on our servers.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

Our years of experience hosting millions of sites and thousands of different applications had proven that latest versions are a good approach only in a closed, testing environment. In a hosting environment which needs to provide both stability and compatibility with older code, latest versions more often cause problems for the site owners. At the same time, keeping a version which is widely compatible both with new and older code, but is patched to the latest patch levels, is the best approach for both directions and all involved parties. In short, do not look at the software version. It is kept at an older version on purpose – for compatibility reasons. However, the actual code of the service is up to date.

In this regard, if you have any particular real life use case scenario where a piece of code that you are using is not compatible with the reported version of the service, please post a support ticket, so that we can check the case and the relative server logs in details.

Thank you.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

• This reply was modified 5 months, 1 week ago by Plamen M.

Hello @generosus,

Thank you for your question. The version of the service can be located through telnet after logging into the hosting account via SSH. The current major stable release on the servers is 1.6.9.

$ telnet 127.0.0.1 11211
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is '^]'.
version
VERSION 1.6.9

However, as it is with almost all software installations on our servers, we keep a stable version which is compatible with most applications – both new and older, but the code is further patched by our security and administrator teams with the latest security patches and releases. This makes the software both widely compatible, but also up to date with the latest code release of the software as of today.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

Hello @truffolo ,

I checked the reported issue on a test site of mine. The cron tasks on the site were not disabled after I installed the SiteGround Optimizer plugin.

Disabling the WebP support in the plugin will delete all the existing WebP images in the site (both manually uploaded and generated by the plugin), as the warning message explains. However, if you would re-enable it, the system will generate new WebP images off the existing images, supported for convertion.

I might suppose that you had had manually uploaded WebP images in the site. Disabling the WebP support in the plugin might had deleted them and then re-enabling the support would generate WebP versions only of supported JPEG and PNG files (up to 1 MB in size). This way, places in the site which had WebP images, might be missing them, because there are no “standard” images which the plugin can convert into WebP.

If you continue facing issues, you may want to post a support ticket through the Help Desk section in your SiteGround User Area.

Plamen.M
Tech Support Team
SiteGround.com

I fully understand your point, but the dictionary definition of “immediately” applied to IT workflows, especially when referring to releases of new software integrations, would almost always result in: “Generous wrote: Why is my site down?! Get it up immediately! Here is the dictionary definition of the word.”.

We would rather take the time to avoid that instead of reading dictionaries.

Regards,
Plamen.M
Tech Support Team
SiteGround.com

We can not provide and ETA for the final implementation. Yes, we stand by “immediately” – immediately after the tests for a flawless implementation of the final stable release within our systems finish.

Stand by for a blog post announcement.

Regards,
Plamen.M
Tech Support Team
SiteGround.com