#
If you’ve updated a plugin or theme to a patched version but Solid Security keeps notifying you about an old vulnerability, it usually means one of the following:
- A cached data or a scheduling hiccup is causing the scan to show outdated results
- The email notification is coming from an older version of the site (eg., staging site from a previous host)
To clear cached data, follow these steps:
1) Run a Manual Site Scan
Go to Security > Site Scans and confirm that running a manual scan returns “Clean”. If the manual scan is clean, but the next scheduled scan still shows outdated results, continue with the steps below.
2) Clear All Caches
Old cache files can make scans show stale data, so try to clear these caches:
- Server Cache: Use your hosting panel’s cache tool. If you’re not sure where to find this, contact your hosting provider for help.
- Caching Plugin: If you have a caching plugin installed and activated, clear your site cache there.
- CDN Cache: If you use a CDN (like Cloudflare), purge the CDN cache, too.
- Browser Cache: Clear your browser’s cache to make sure you’re seeing the latest results.
3) Clear Site Transients
WordPress uses transients to store temporary data, and sometimes these hold outdated scan info that can reflect in scans.
Use a plugin like Transients Manager or WP CLI to safely clear all expired transients.
For an in-depth guide on clearing caches and transients, see: How to clear caches and transients (step-by-step)
4) Reset Solid Security’s Scheduler
Resetting Solid Security’s scheduler can help stop the scan from pulling old data. Here’s how you can reset it:
- Enable Debug Mode by following this guide: Security Debug.
- Once Debug Mode is on, go to Security ? Debug.
- Find the Scheduler table.
- Click the Reset button.
- Wait for the next scheduled scan to run.
If you’ve done all these steps but still get incorrect notifications, check whether there’s an old copy of your site (such as a staging or dev site) still running Solid Security, or an old server that may still be holding leftover data or a cron job related to the plugin.
#
Yes!
Solid Security works with Multisite installations. Note: It must be Network Activated.
The SolidWP licensing system is domain-based, meaning that each domain name requires a separate license. So you’d need only one license for example.com/site1 and example.com/site2. This is commonly referred to as subdirectory multisite.
If instead you are using what’s called subdomain multisite, which looks like site1.example.com, site2.example.com (etc), you’d need an additional license per site, as that registers as a totally different domain for licensing purposes.
#
Yes!
The best way to stop spam registrations in WordPress is using Solid Security’s CAPTCHA. Read more about CAPTCHA here.
#
It’s a common problem in helping to prevent unauthorized access to your site that you might accidentally lock yourself out. Don’t fret: there’s a simple solution (that just requires one small bit of expertise)
To temporarily disable Solid Security’s features and regain access to your site, add the code snippet below into your site’s wp-config.php file anywhere between the first line ( <?php ) and the line that says / That’s all, stop editing. Happy Publishing /
define('ITSEC_DISABLE_MODULES', true);
Learn to confidently edit the wp-config.php file in this article.
Remember to quickly log in, change the setting in question that locked you out, and then remove that line from the wp-config file.
#
Yes! Similarly to regaining access to your entire site, if you need to temporarily disable Two-Factor to log in to your site, add the following code to your wp-config.php file.
define('ITSEC_DISABLE_TWO_FACTOR', true);
This works similarly to the previous command, but instead of disabling all modules, it targets specifically the 2FA module.
Learn to confidently edit the wp-config.php file in this article.
#
Yes!
Solid Security’s translation is handled in two different ways: one for the Basic version and another for the Pro version.
The Solid Security Basic plugin available on the wordpress.org directory is translated by volunteers on the official WordPress translation platform, which you can find here.
For translation guidance, you may contact the WordPress Slack #polyglots channel mentioned in the Before you get started section.
For translating the text strings that are only found within the Pro version, you can use a tool like Poedit or a translation plugin to generate the translation files (.po and .mo files).
To add your own translations, the files will need to go in their respective directories like the example path listed below.
#
Solid Security comes pre-configured to notify you of security issues as much as possible, and is designed with flexibility in mind. If it errs on one side or the other, it’s often too many notifications, which is intentional. The Solid Security team would rather you be over-informed than under-informed.
An exception to this rule is the Scheduled Site Scan feature, which will now only notify you of newly identified vulnerabilities meeting the priority threshold as defined in your settings, that were not found in the previous scan. This reduces the overall amount of notifications you receive from the site scanner.
You do have full control over how to limit which emails you and your site users want to receive. In Settings > Notifications, many of the notifications are configurable. To be clear, notifications that form the entire basis of the feature (like the magic links lockout bypass notification that is sent to allow users to log in without a password) are not able to be disabled. If you want to disable that message, disable the feature itself.
A common notification to disable is the Inactive User notification, especially on sites that have users who might not interact with the site regularly. There’s a way to programmatically disable that particular notification, by adding a line to your wp-config.php file:
define('ITSEC_DISABLE_INACTIVE_USER_CHECK', true);
That notification can be disabled by “normal” method of unchecking the box in the settings, but if you or a third-party developer has programmatically disabled it in wp-config.php then the settings page will have no effect to re-enable it.
Learn to confidently edit the wp-config.php file in this article.
#
YES! Higher-tech users or folks looking to learn more about troubleshooting issues with Solid Security should check out the documentation on Solid Security’s Debug Screen.
The SolidWP support team is always happy to help, so you should never feel bad about reaching out. But if you want to dig in yourself, give DEBUG mode a try!
#
By default, Solid Security logs are saved into the itsec_logs table in your WordPress database. There’s not a built-in way to export the logs from the database, but if you have need for the logs there are ways to configure Solid Security to make those logs easier to access. In the settings, you can opt to write logs to both the database and to files, and then place those log files anywhere within your site’s file structure. You can also, with the help of someone familiar with WordPress database exports, manually export the database table to have access to the logs that way.
#
In short, you go to the licensing page, put in your SolidWP username and password, and you’re all set. Here’s a longer version of how licensing works.
Of course, the SolidWP support team is more than happy to help with licensing questions as well.
#
First, don’t panic. Like a good security guard on their first day, Solid Security can tend toward being overly cautious. Just because it calls it a problem doesn’t mean you should panic. Next, one fast way to get to the bottom of issues is to check out the Raw Details of the scan results, which you can also pass along to the SolidWP support team if you need additional help.
#
Especially while configuring Solid Security, it’s possible for it to overzealously lock you or other legitimate users out of your site. This documentation walks through the best ways to release those lockouts.
#
If an IP address (or addresses) was banned by Solid Security and you want to manually remove it, follow these steps:
- Open your site’s
.htaccessfile using (S)FTP client or hosting panel. - Search for the IP address you want to remove from the ban list.
- Delete the following entries associated with the IP:
Under the section # Ban Hosts - Security > Settings > Banned Users, remove these 3 lines (example IP: 1.145.241.30):
SetEnvIF REMOTE_ADDR "^1\.145\.241\.30$" DenyAccess
SetEnvIF X-FORWARD-FOR "^1\.145\.241\.30$" DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP "^1\.145\.241\.30$" DenyAccess
Next, remove 1 line containing the IP inside the <IfModule mod_authz_core.c> block
Require not ip 1.145.241.30
Then, remove 1 line containing the IP inside the <IfModule !mod_authz_core.c> block
Deny from ip 1.145.241.30
Lastly, save the .htaccess file to upload the changes.
#
First, purchase a plan that includes Solid Security Pro, like the Solid Suite. Once you’ve purchased, you’ll be able to download Solid Security Pro from the downloads page in your account. Then, install and activate the plugin. Once the Pro version is installed and active, you can deactivate and delete the free version.
If you have any trouble at all, the SolidWP Support team is here to help.
#
Yes! Solid Security is designed for any site running WordPress, where you are able to install and activate plugins. This can be a brand-new website or an established site.
Of course, the power of WordPress itself is that you own the code and data, and that ownership comes with responsibility. Plugins that make changes to the database and files on your server should be treated with care. As with any plugin, before installing and activating it, you should have a data recovery plan that includes backups and restoration. Solid Backups is a great option for this, but any backup solution will do.
Always familiarize yourself with Solid Security’s functionality in ways that you can roll back (via backup) in case of something unexpected.
#
207.246.255.60
207.246.254.118
The Solid Security Scanner IP address is 207.246.255.60, and the Solid Central IP address is 207.246.254.118. You’ll want to add both of those IP addresses as “safe” via your webhost’s firewall or other systems that block bots or other malicious attempts.
#
This is a vague and potentially misleading question, because any plugin can break your site. If it’s running PHP, a plugin can cause errors that “break” sites.
Solid Security, in an effort to make your site more secure, can do things that make your site malfunction. Most of the time this is a result of changes in the Database. The two most common:
- changing the database prefix from the default
wp_to something else - removing the
user_idof 1 which is a method of shoring up one of the common points of reference that attackers might use.
In response to example 1: if you are logged into your site as that admin user with a user_id of 1, and you remove that user… your site is going to appear broken until you add a new admin user with a different ID.
For example 2: if Solid Security makes a change to the database prefix, and that change somehow is not also made within the wp-config.php file, the site will not be able to connect correctly to the database. The prefix in wp-config.php needs to match the prefix of the actual database tables.
Solid Security has labels on these types of features to make sure you don’t inadvertently hose yourself, but it bears repeating: since Solid Security is distributed software that is installed on servers that the SolidWP company has no control over, it’s always best to avoid making changes that you can’t confidently reverse.
As always, the SolidWP Support team is ready to help before or after to you make a breaking change.
#
First, don’t panic. Lockout notifications are evidence that Solid Security is working as intended. It’s just more annoying when somebody (or some bot) is trying to gain access using your username, because now you’re effectively locked out.
A few workarounds. First, if you’ve previously enabled Magic Links, you can still log in using that feature. Visit the login screen, and select the option to send a magic link to bypass the login.
Next, if you don’t have Magic Links enabled, you’ll need to either wait for the lockout to expire and try, or you can temporarily disable solid security to make the change/release the lockout and then reenable things.
To temporarily disable Solid Security’s features and regain access to your site, add the code snippet below into your site’s wp-config.php file anywhere between the first line ( <?php ) and the line that says / That’s all, stop editing. Happy Publishing /
define('ITSEC_DISABLE_MODULES', true);
Learn to confidently edit the wp-config.php file in this article.
Now would be a good time to enable Magic Links while you’re in there.
#
Solid Security relies on making changes to server configuration files to handle certain settings and features.
In server environments using Apache (a widely used web server software that processes HTTP requests), that is handled in the .htaccess file. For NGINX (an alternative web server known for high performance and scalability), that is handled in nginx.conf files.
Some web hosts (notably WP Engine, a popular host for WordPress) have deprecated the use of .htaccess. Other hosts that use NGINX prevent modification of the conf files. In those cases, the hosts handle their own server configurations in ways that WordPress (which is installed on the server) can’t modify.
Practically what that means is that the following Solid Security features may need to be configured separately (or are unnecessary/redundant because the host handles them)
- Security -> Settings -> Features -> Firewall -> Ban Users ->Default Ban List
- Security -> Settings -> Advanced -> System Tweaks -> File Access ->Protect System Files
- Security -> Settings -> Advanced -> System Tweaks -> File Access ->Disable Directory Browsing
- Security -> Settings -> Advanced -> System Tweaks -> PHP Execution ->Disable PHP in Uploads
- Security -> Settings -> Advanced -> System Tweaks -> PHP Execution -> Disable PHP in Plugins
- Security -> Settings -> Advanced -> System Tweaks -> PHP Execution -> Disable PHP in Themes
- Security -> Settings -> Advanced -> WordPress Tweaks -> API Access -> XML-RPC (Disable XML-RPC)
If you find that those features are not working, it may be that your host already handles them, or that you’ll need to reach out to them to request the ability to modify the server configurations in some other way.
Of course, the SolidWP support team stands ready to help clarify for your specific case.
#
The invalid IP returned error when running a security check almost always is an indication that loopback requests are not working on your site.
Loopback requests in WordPress are internal HTTP requests that the site makes to itself (“looping back” to itself). These requests are used for various features, such as running scheduled tasks (WP-Cron), verifying REST API functionality, and testing server configurations. Essentially, they allow WordPress to simulate an external request to the site’s own URL, enabling it to perform background operations or diagnose issues. If loopback requests are blocked by the server or hosting environment, features like automated updates and some plugins may not work as expected.
Solid Security doesn’t use loopback requests in securing your site, but it makes the check to identify the loopback IP so that the Trusted Devices module doesn’t block it.
If loopbacks aren’t working on the site, Solid Security will still function without issue (other than this error in Site Scanning) because nothing will be able to successfully make a loopback request.
But you should speak with your host about what might be blocking loopback requests, as having them disabled could cause other troubles.
#
Solid Security is supported by the world-class help of the SolidWP Support team. The fastest way to access support is to visit the SolidWP Member Panel and create a support ticket. This support is limited to active license holders for Solid Security Pro.
Solid Security is distributed software, which means that it’s installed on servers/web hosts that the SolidWP team does not have full access to. So the more detail you can add to your support request, the faster the team will be able to help you resolve things.
Users of the Solid Security Basic version can receive support on the Solid Security support forum on WordPress.org. These forums are community-based, but the SolidWP support team helps out there as well.
#
There are several reasons you may not be receiving the 2-factor authentication emails. (2FA notifications). To isolate the issue, first determine whether any emails are functional in WordPress more generally, and then work back toward Solid Security and finally specifically the 2FA email.
This exhaustive documentation walks you through troubleshooting email deliverability in WordPress.
In the vast majority of cases, it’s a problem with email more generally when you’re not getting 2FA emails. Reach out to the SolidWP support team if you still need help.
#
Solid Security requires access to the WordPress REST API and if you’re unable to complete the Onboarding process or save the settings, the issue is likely due to restricted REST API access.
Confirm with your hosting provider that all of these REST HTTP methods are allowed on your server: GET, POST, PUT, PATCH, DELETE, and OPTIONS. Some hosts or server security configurations may block these methods, preventing the plugin from working correctly.
If the issue persists, reach out to the SolidWP support team for further assistance, and include the confirmation from your host.
#
In order to receive updates, the Solid Security Pro plugin needs to be licensed.
To license the plugin, go to your WordPress Admin Bar -> Settings -> SolidWP Licensing and on this page, enter your SolidWP username and password, then make sure that the Licensed URL is correct.

#
One security feature of Sold Security is “intrusion detection” which identifies when a certain IP address is hitting too many errors all at once.
Especially on large sites or sites that have ever been compromised, often there are lots of broken links to files that no longer exist, which can create a 404 error. If you’ve got a lot of old posts that reference images that have moved or been deleted, that number can multiply quickly.
When you first install Solid Security or perform a site scan, the combination of those missing files and intrusion detection can cause you to be almost immediately locked out of your own site.
Here’s how to fix it:
If you’re a Solid Central user, you can release this from your Central dashboard. Navigate to either the Overview or Solid Security page, and you’ll see the setting to release the lockout.
If you’re not a Solid Central user, you can manually release the lockout:
Confirm the lockout is due to “intrusion detection.” #
Make sure intrusion detection is causing the problem and not something else.
Using PHPMyAdmin or other tools from your web host, open up your database and find the table wp_itsec_lockouts (replace wp_ with your site’s database table prefix).
In this table, look for your IP address. If your IP is included in the table, intrusion detection is likely the lockout problem.
Clear the lockout. #
In your database, delete the record with your IP address from the wp_itsec_lockouts table. Check to see if you have access to your site again.
Note: In some cases, you may be receiving so many 404 errors that you may immediately be locked out again. If this is the case, check again for your IP address and move on to the next step.
Find out what is causing the 404 errors and fix each error. #
Open your Solid Security Logs, and find the entries with your IP address. Each line represents a file that your site is pointing to that does not actually exist (hence the 404 error).
You will need to manually fix these errors 1 by 1 to prevent lockouts from reoccurring. Once you fix the errors, you should no longer have any problems accessing your site.
You’ll also have the added benefit of fixing them for Google and other search engines, which may penalize you for too many 404 errors.
#
This ties into the previous answer about the whitescreen error. Google scans sites all at once, following links and crawling the site for SEO clues. If a Google bot crawls too many 404 errors, it will be blocked by Solid Security’s intrusion detection. This is further encouragement to limit the 404 errors on your site, and take the time to remove them so that your site can fully be crawl-able by Google and other search engines.
#
Beginning with versions 9.3.2 (Basic) and Solid Security 8.4.1 (Pro), certain Solid Security modules are disabled when an IP Detection method has not been configured in Security Global Settings (set to “Unconfigured”).
In this situation, a “Feature not available” notice (pictured below) will be displayed for the following modules:
- Ban Users
- Local Brute Force
- Network Brute Force

Additionally, the Firewall and CAPTCHA modules will operate with reduced functionality while in this state.
How Can I Restore Full Functionality? #
To re-enable bans and lockouts, navigate to Security > Settings > Global Settings (tab), then scroll to IP Detection and select the Proxy Detection method that matches your server setup.
The simplest option is to choose “Security Check Scan (Recommended)” which causes your site to connect to an API provided by SolidWP.
Note: Users of Solid Security Basic must enable “Security Check Pro” at Security > Settings > Features > Utilities (tab) for the “Security Check Scan (Recommended)” option to appear.

The system then automatically detects the method that works for your current scenario and updates your Solid Security configuration accordingly. This operation then repeats on a regular basis to ensure that the correct configuration is in place even if changes are made to your hosting setup.
Alternatively, if you know how your site connects to the internet, you may choose from the following Proxy Detection options:
- Disabled – choose this option when your site connects directly to the internet and is not behind a proxy.
- Manual – choose this option if your site is behind a proxy and you know which HTTP header format your proxy uses to supply the IP address information for visitors.
Why Does the IP Detection Method Matter? #
Protecting your site from malicious users by banning them and/or locking them out requires that Solid Security is able to accurately determine their IP addresses. This is straightforward as long as your site connects directly to the internet.
If your site is behind a proxy server, however, Solid Security must rely upon IP address information contained in HTTP headers supplied by the proxy.
Proxy servers are commonly used to improve performance, such as caching solutions (e.g. Cloudflare) and load balancers. They are also used for external security, such as web application firewall (WAF) solutions.
Why Not Just Read the Proxy Headers? #
Earlier versions of Solid Security provided an option to read the supplied proxy headers in a predetermined order to discover the IP addresses of visitors. This was labeled “Automatic” proxy detection, and was essentially equivalent to how most other systems worked. Malicious actors ultimately realized that it was trivial to spoof their IP addresses by supplying false HTTP headers, and so, Solid Security added the “Insecure” label to this option.
In order to more accurately provide users a more accurate understanding of the risks and implications of using this configuration, Solid Security now disables lockouts and bans when it has not been configured to detect IP addresses of visitors accurately.
#
When the Magic Links module is disabled before running the MU Plugin Loader tool, it results to a script error that prevents the Firewall screen from displaying correctly.
The script error would look like this:
Page: /settings/configure/lockout
Error: TypeError: Cannot read properties of undefined (reading '0')
at https://www.example.com/wp-content/plugins/ithemes-security-pro/dist/pages/settings.min.js?ver=27190485913c9dad1450:1:15466
at Array.some (<anonymous>)
at ye (https://www.example.com/wp-content/plugins/ithemes-security-pro/dist/pages/settings.min.js?ver=27190485913c9dad1450:1:15440)
at ht (https://www.example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1.1:10:45730)
at Qs (https://www.example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1.1:10:120536)
at wl (https://www.example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1.1:10:88637)
at bl (https://www.example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1.1:10:88565)
at yl (https://www.example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1.1:10:88428)
at fl (https://www.example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1.1:10:85585)
at Nn (https://www.example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1.1:10:32474)
To fix this:
- Go to Security > Tools and run Remove MU Plugin Loader.
- Navigate to Security > Settings > Features > Firewall and enable the “Magic Links” module.
- Return to Security > Tools and run Create MU Plugin Loader again.
After completing these steps, you’ll see a “Feature not available” message under the Magic Links module. This is expected because the Magic Links feature can’t be active while Solid Security is loaded as a MU plugin, since the two features are not compatible.

#
If your site requires information about the data used by Solid Security, including cookies, you can refer to the WordPress Privacy Policy Guide.
To access it, go to WordPress Dashboard -> Settings -> Privacy -> Policy Guide. The generated guide includes details on how Solid Security collects and process data.
For additional details, reach out to the SolidWP support team if needed.
#
By default, the Solid Security email notifications pull the logo that’s been configured on the website. If you want to change it, you can customize the logo in Solid Security emails using the solid_security_mail_site_logo filter.
Here’s a sample code snippet to set a custom logo:
// Use a custom logo for Solid Security email notifications
add_filter( 'solid_security_mail_site_logo', function( $url, $size ) {
// Replace with the URL of your custom logo
$custom_logo_url = 'https://example.com/path-to-your-logo.png';
// Optionally check size and provide a different logo for specific dimensions
if ( $size[0] === 300 && $size[1] === 127 ) {
return $custom_logo_url;
}
return $custom_logo_url;
}, 10, 2 );
You can add this snippet to your theme’s functions.php file (preferably in a child theme) or use a code snippet plugin. This ensures that Solid Security email notifications display your custom logo instead of the default one.
#
When you access the login page using your custom slug (e.g., https://example.com/dashboard-access), a cookie is set for one hour. During this time, you can access https://example.com/wp-login.php or https://example.com/wp-admin on the same browser without needing the custom slug again.
To verify that wp-admin/wp-login.php is hidden from visitors, try opening those URLs in a private/incognito browser.
#
Solid Security is designed to work with most WordPress plugins and themes. However, because it restricts certain WordPress functions to improve site security, some software may experience limited functionality when specific security features are enabled.
If another plugin does not behave as expected while Solid Security is active, it usually indicates that one of its features is blocking access to a required WordPress component (such as the REST API, XML-RPC, or PHP execution in certain directories).
The following steps can help identify and resolve potential conflicts:
- Allow Default REST API Access
Some plugins require unrestricted access to WordPress REST API endpoints.- Go to Security > Settings > Advanced > WordPress Tweaks and set REST API Access to Default Access
More details on REST API settings can be found in the API Access guide.
- Go to Security > Settings > Advanced > WordPress Tweaks and set REST API Access to Default Access
- Enable XML-RPC (if applicable)
In Security > Settings > Advanced > WordPress Tweaks, enable XML-RPC to restore compatibility for plugins or services that depend on remote connections. - Temporarily Disable PHP Execution Restrictions
- Navigate to Security > Settings > Advanced > System Tweaks and disable PHP Execution settings.
- Test each option individually: Uploads, Plugins, and Themes to determine which may be affecting compatibility.
See the System Tweaks guide for more details.
- Disable the Default Ban List
Go to Security > Settings > Features > Firewall, open Ban Users, and temporarily disable the Default Ban List.
For step-by-step instructions, refer to the Ban Users guide.
In addition, here are some known conflicts with the Solid Security plugin:
LiteSpeed Cache plugin #
Solid Security blocks direct execution of PHP files outside of the proper WordPress context (where ABSPATH is defined) through its Disable PHP Execution settings, as a security measure to prevent malicious activity. However, the LiteSpeed Cache’s Guest Mode feature relies on certain PHP files being executed directly, which can trigger this conflict.
If you experience this conflict, we recommend either disabling Guest Mode in LiteSpeed Cache or disabling the Disable PHP in Plugins setting in Solid Security’s System Tweaks.
Broken Link Checker plugin #
When Solid Security is enabled, Broken Link Checker may detect broken links correctly but fail to apply the expected strikethrough formatting on those links in the content.
This conflict occurs when the Enforce SSL setting is enabled in Solid Security, due to running a filter that automatically replaces http:// URLs with https:// URLs. If a site still contains older http:// links, this setting can interfere with Broken Link Checker’s strikethrough function.
To resolve, you can either do the following:
1) Disable the Enforce SSL setting via Security > Settings > Features > Utilities or,
2) Follow these steps:
- Disable the Enforce SSL setting first.
- Next, update old
http://links on your site to usehttps://. - Re-enable Enforce SSL after fixing the URLs.
Once all site URLs are properly updated to HTTPS, both plugins should work together.
Kadence Query Loop Block #
If a site is using the Kadence Query Loop (Advanced) Block, the search results don’t render on the front end when Solid Security’s REST API setting in WordPress Tweaks is set to “Restricted Access”.
The block relies on the REST endpoint /wp-json/wp/v2/kadence_query/query, which gets blocked by the restriction (see here to learn more).
To resolve, you can do either of the following:
1. Set REST API to “Default Access” or,
2. Add this code snippet as a must-use plugin or using a code snippet plugin to keep the REST API setting to “Restricted Access”:
<?php
add_filter( 'rest_dispatch_request', function ( $result, $request, $route_regex, $handler ) {
$route = strtolower( $request->get_route() );
if ( $route === '/wp/v2/kadence_query/query' || strpos( $route, '/wp/v2/kadence_query/query' ) === 0 ) {
if ( is_wp_error( $result ) && $result->get_error_code() === 'itsec_rest_api_access_restricted' ) {
return null; // allow the request to continue
}
}
return $result;
}, 999, 4 );
WooCommerce Mobile App #
When using the WooCommerce mobile app, login may fail if the Hide Backend feature is enabled in Solid Security. This is because the mobile app doesn’t handle the redirect to the custom login URL correctly, which prevents the 2FA prompt from appearing.
Workaround: Disable Hide Backend when you need to log in via the WooCommerce mobile app. According to the WooCommerce documentation, the app should instead open the custom login URL in a web browser.
#
You will see this message if your user is part of a user group that does not have the Enable Passwordless Login setting enabled.
To fix this, make sure to toggle it ON via Security -> Settings -> User Groups.
#
The “Could not save passkey user id” error indicates an issue with the plugin failing to insert the data into your database. Possible causes include the table not existing, which can be caused by a corrupted installation process, or the data type being inserted not matching the expected data type.
Please try deactivating and then reactivating the Solid Security plugin to recreate any missing database tables.
If the issue persists, please navigate to Security -> Logs and search for any log file related to the Passkey issue. Once found, please copy the full contents into a .txt file and attach it to your next reply.
#
On large multisite installations, the Dynamic Highlights module which pull important log events like send_failed run background database queries that can add up and impact database performance.
If disabling the toggles do not work, you can use this code snippet to robustly disable it and add it to a Must-Use Plugin using these steps:
- Access your site’s filesystem and navigate to the
wp-content/mu-pluginsfolder. If there’s nomu-pluginsfolder, create one. - Create a new file and name it to something like:
mu-disable-itsec-highlighted-logs.php - Open the file, paste this code snippet, and save the changes:
/*
Plugin Name: Disable Solid Security Highlighted Logs
Description: Prevents Solid Security (iThemes Security) from registering or displaying highlighted logs, to reduce database load.
Author: Your Name
Version: 1.0
*/
// Remove all highlighted log registrations as early as possible.
add_action( 'muplugins_loaded', function() {
add_action( 'itsec_register_highlighted_logs', function () {
remove_all_actions( 'itsec_register_highlighted_logs' );
}, 0 );
}, 0 );
// Mute all known dynamic highlights to prevent queries for them.
add_action( 'init', function() {
if ( class_exists( 'ITSEC_Lib_Highlighted_Logs' ) ) {
foreach ( ITSEC_Lib_Highlighted_Logs::get_dynamics() as $slug => $highlight ) {
ITSEC_Lib_Highlighted_Logs::mute( $slug );
}
}
}, 20 );
// Optionally, force logging to file (disables highlighted logs entirely)
add_action( 'init', function() {
if ( function_exists( 'ITSEC_Modules' ) ) {
$log_type = ITSEC_Modules::get_setting( 'global', 'log_type' );
if ( $log_type !== 'file' ) {
ITSEC_Modules::set_setting( 'global', 'log_type', 'file' );
}
}
}, 1 );
To confirm the code is working, visit the Security Dashboard, click “Alerts”, and tap the gear icon beside the Security Admin Messages. It should show as blank like this:

#
If you’re still receiving email notifications from Solid Security (such as outdated Site Scan reports) for a site that you no longer manage, or that has been migrated, it usually means that there is still a copy of the site somewhere (most likely a staging site) that is still running the plugin.
When Solid Security is installed, it runs scheduled tasks (cron jobs) and sends reports to the email addresses saved in its settings. If the plugin wasn’t fully removed before the site was rebuilt or migrated, the old installation may still be triggering notifications.
To stop these emails, check the following:
- If you still have access to the old server or site, uninstall and delete the Solid Security plugin there.
- Clear any transient data related to Solid Security using a transients manager plugin or similar. Do this on both your old site and the current one.
- If the site no longer exists but the server remains, make sure any cron jobs related to the plugin are cleared. It’s best to reach out to your host for assistance here.
- If you don’t have access to the old server or site, another option is to create an email filter or rule in your inbox to automatically discard these emails.
#
Solid Security requires the PHP iconv() function to be available on your server. This function is part of the standard PHP iconv extension and is used to handle character encoding conversions, which are essential for properly securing and processing user input.
If you’re seeing a warning or error about iconv(), it likely means the iconv extension is not currently enabled in your PHP environment.
How to enable the iconv extension #
Most modern hosting providers include this extension by default. If it’s missing, you (or your hosting provider) will need to enable it. Here are the typical ways this can be done:
- If your host provides a PHP selector (like in cPanel):
- Navigate to the PHP version or module settings.
- Look for the checkbox labeled
iconvand enable it. - Save your changes and restart PHP if needed.
- If you manage your server:
- Make sure the
php-iconvpackage is installed. On Ubuntu or Debian-based systems, you can run:sudo apt install php-iconv - Restart your web server (e.g.,
sudo systemctl restart apache2orphp-fpm).
- Make sure the
If you’re unsure how to do this, your hosting provider should be able to enable the iconv extension for you. Reach out to their support and mention that the PHP iconv extension is required for Solid Security to function correctly.
#
You can add an allowlist of Cloudflare IP ranges at the top of your .htaccess file so only Cloudflare (and any required host IPs) can reach the origin directly. See the step-by-step in the firewall guide: Force all origin traffic through Cloudflare.
#
If the Solid Security admin pages appear blank after an update, the most common cause is that your browser has cached an older version of the plugin’s JavaScript files. This can lead to JavaScript errors that prevent the pages from loading correctly.
The quickest fix is to perform a hard refresh in your browser. A hard refresh clears the cached versions of the files and forces the browser to load the latest ones from the server.
Use the shortcut for your browser and operating system:
Windows
- Chrome: Ctrl + Shift + R or Ctrl + F5
- Firefox: Ctrl + Shift + R or Ctrl + F5
- Edge (Chromium): Ctrl + Shift + R or Ctrl + F5
- Internet Explorer (legacy): Ctrl + F5
macOS
- Chrome: Cmd + Shift + R
- Firefox: Cmd + Shift + R
- Safari: Option + Cmd + R
- Edge (Chromium): Cmd + Shift + R
After doing a hard refresh, the Solid Security menu should load normally.
#
Some security rules in .htaccess (like HackRepair blacklist or IP denies) can block BunnyCDN from fetching static assets, causing 403 errors on the CDN. To fix this, add a small set of rules above everything else in .htaccess that detects Bunny requests and always allows core static file types. This ensures BunnyCDN can cache and serve your site’s assets without weakening other security protections.
Disclaimer: This is example code that worked in limited testing to resolve BunnyCDN 403 issues. Your server configuration may differ, so review carefully and test before deploying to production.
# --- BunnyCDN / static-assets fast-path (paste ABOVE all other rules) ---
# 1) Detect Bunny and mark request
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:CDN-ServerId} .+ [OR]
RewriteCond %{HTTP:Via} BunnyCDN
RewriteRule ^ - [E=IS_BUNNY:1]
</IfModule>
# Make the env var also visible to authz modules
SetEnvIfNoCase CDN-ServerId ".+" IS_BUNNY=1
SetEnvIfNoCase Via "BunnyCDN" IS_BUNNY=1
# 2) Short-circuit later HackRepair-style [F] rules for Bunny or static assets
# (Stops mod_rewrite processing entirely so later RewriteRule [F] won't fire)
<IfModule mod_rewrite.c>
RewriteCond %{ENV:IS_BUNNY} =1 [OR]
RewriteCond %{REQUEST_URI} \.(?:woff2?|ttf|eot|css|js|mjs|json|map|jpg|jpeg|png|gif|webp|svg|ico)$ [NC]
RewriteRule ^ - [END]
</IfModule>
# 3) Allow authz for static assets explicitly (more specific FilesMatch usually wins)
<IfModule mod_authz_core.c>
<FilesMatch "\.(?:woff2?|ttf|eot|css|js|mjs|json|map|jpg|jpeg|png|gif|webp|svg|ico)$">
Require all granted
</FilesMatch>
</IfModule>
# Apache 2.2 fallback
<IfModule !mod_authz_core.c>
<FilesMatch "\.(?:woff2?|ttf|eot|css|js|mjs|json|map|jpg|jpeg|png|gif|webp|svg|ico)$">
Order allow,deny
Allow from all
Allow from env=IS_BUNNY
</FilesMatch>
</IfModule>
#
If you want to allow a trusted bot like BAnQBot that uses the heritrix crawler, Solid Security’s “Default Ban List” may block it because that list automatically denies any user agent containing heritrix.
You can bypass this by adding a small MU-plugin in your site:
- Create a new file in wp-content/mu-plugins/ called allow-banqbot.php.
- Paste in the snippet above.
- Save the file.
This plugin hooks into Solid Security’s file-writing process and strips any .htaccess rule that contains the word heritrix. After it runs, BAnQBot (or any crawler using that UA string) will be able to access your site while all other blacklist protections remain active.
Usage note: The plugin will automatically run whenever Solid Security rewrites .htaccess (for example, when you change settings). You may need to toggle the Write to Files option in Security > Settings > Global Settings to force an update.
Disclaimer: This is example code that worked in limited testing to resolve a 403 issue. Your server configuration may differ, so review carefully and test before deploying to production.
<?php
/*
Plugin Name: Allow BAnQBot (strip heritrix from HackRepair)
*/
if (!defined('ABSPATH')) exit;
add_action('itsec_lib_write_to_file', function ($file, $contents) {
if (basename($file) !== '.htaccess' || stripos($contents, 'heritrix') === false) return;
// Remove any line that contains "heritrix"
$new = preg_replace('/^.*heritrix.*$/im', '', $contents);
if ($new !== null && $new !== $contents) {
$new = preg_replace("/\n{3,}/", "\n\n", $new);
file_put_contents($file, $new);
}
}, 999, 2);
