BugWP logo BugWP
Back to Community
Home / Community / Plugin → Security optimizer – the all-in-one protection plugin

Troubleshooting Common Conflicts: Security Optimizer's 'Lock and Protect System Folders'

41 threads Sep 16, 2025 Plugin → Security optimizer – the all-in-one protection plugin

Content

Many users of the 'Security Optimizer – The All-In-One Protection Plugin' report a specific type of conflict: features of their website break when the plugin is active, but work perfectly when it's deactivated. A significant number of these issues are traced back to one powerful security feature: Lock and Protect System Folders.

This article explains why this happens and provides the most common solutions to get your site's functionality back without completely sacrificing security.

Why Does This Conflict Happen?

The 'Lock and Protect System Folders' feature is designed to harden your WordPress installation's core directories (`wp-content/`, `wp-includes/`) against unauthorized execution of PHP scripts, a common attack vector. It does this by adding specific security rules to the `.htaccess` files within those folders.

However, some legitimate plugins and themes operate by directly executing PHP files located within these protected folders (e.g., `/wp-content/plugins/some-plugin/includes/ajax-file.php`). When the security feature is active, it blocks access to these files, resulting in 403 Forbidden errors, broken functionality, or blank white screens. This is not necessarily a 'bug' in either plugin, but a compatibility issue arising from how different software interacts.

How to Identify if This is Your Problem

Before proceeding, confirm that 'Lock and Protect System Folders' is the source of the conflict:

  1. Go to your WordPress dashboard and navigate to SG Security > Site Security.
  2. Find the 'Lock and Protect System Folders' setting and temporarily disable it.
  3. Clear your site and browser cache.
  4. Check if the previously broken functionality now works.

If the issue is resolved after disabling this feature, you've confirmed the source. You can now proceed with the solutions below. Remember to re-enable the feature after testing before applying a permanent fix.

Common Solutions

1. Use the Built-in Whitelist Filters (Recommended)

The most robust solution is to use the PHP filters provided by the Security Optimizer plugin to whitelist the specific file causing the conflict. This allows you to keep the security feature active while excluding the necessary file.

You will need to add a code snippet to your active theme's `functions.php` file. The exact filter you use depends on the location of the blocked file:

  • For files in `wp-content/` (most plugins): Use the `sgs_whitelist_wp_content` filter.
  • For files in `wp-includes/`: Use the `sgs_whitelist_wp_includes` filter.
  • For files in `wp-content/uploads/`: Use the `sgs_whitelist_uploads` filter.

Example: If a plugin like 'TranslatePress' or 'wpDiscuz' has a blocked file at /wp-content/plugins/translatepress-multilingual/includes/trp-ajax.php, you would add the following to your `functions.php` file:

add_filter( 'sgs_whitelist_wp_content', 'whitelist_my_plugin_file' );
function whitelist_my_plugin_file( $whitelist ) {
    $whitelist[] = 'plugins/translatepress-multilingual/includes/trp-ajax.php';
    return $whitelist;
}

Always use a child theme when modifying theme files to prevent your changes from being overwritten by updates.

2. Modify the .htaccess File Directly (Advanced)

Alternatively, you can add an exception directly to the `.htaccess` file located in the folder where the conflict occurs. For the example above, you would edit the `.htaccess` file in the `wp-content/` directory.

You would add rules to allow access to the specific file. A common rule structure looks like this:

<FilesMatch "trp-ajax.php">
  <IfModule !mod_authz_core.c>
    Allow from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all granted
  </IfModule>
</FilesMatch>

Warning: Incorrectly editing your `.htaccess` file can break your site. Only attempt this if you are comfortable with server configuration files and always create a backup first.

3. Disable the Feature for a Specific Plugin

If the conflict is with a specific plugin's functionality (e.g., the WooCommerce app requiring XML-RPC), you may need to disable the related security feature entirely. For the XML-RPC example, you would go to SG Security > Site Security and disable the 'Disable XML-RPC' option.

This is a less secure option but may be necessary for certain integrations.

Conclusion

Conflicts with the 'Lock and Protect System Folders' feature are a common trade-off between heightened security and plugin compatibility. The recommended approach is to use the provided whitelist filters to create targeted exceptions, allowing you to maintain a strong security posture while ensuring all parts of your website function correctly. Always test changes on a staging site before applying them to your live website.

Related Support Threads Support