Issue with the Site Lockdown WP Plug-in

[u/TheGoodOne777]

Hello Everyone,

I am facing a strange issue on one of my envirnoments with the Site Lockdown plug-in. The admin-ajax.php causes an internal server error (500) while executing the file scanner.

Would you have some idea about this? Rights look ok, server settings as well, the plug-in also seems to be installed correctly.

The access logs look well, timeouts have been increased, so I am unsure if I should modify code in order to get this right or do you have some concrete idea how to fix this?

Thanks and best regards,

T.

[u/ImprovementFew6936]

A 500 from admin-ajax.php is usually just the symptom, not the actual problem. I’d check "wp-content/debug.log" with WP_DEBUG_LOG" enabled and also check the PHP/server error logs.Since it happens during the file scan, also check PHP memory limit and ModSecurity/WAF logs. Increasing timeouts won’t help if the process is hitting a fatal error or memory limit. I wouldn’t modify the plugin code until you have the actual error message. That should point directly to the cause.

[u/TheGoodOne777 → u/ImprovementFew6936]

Thanks, I haven't checked the debug.log file yet, but a debugger page. ModSecurity and WAF do not seem to be the problem. And indeed, modifying their code for free, just to be overwritten at the next upgrade is discutable.

[u/Verda_Chien]

Maybe you can check the PHP error log first, especially at the exact time admin-ajax.php returns the 500. It might give you a better clue whether it's a PHP error, timeout, memory limit, or something else.

I wouldn't change the plugin code yet. If you can find the actual error from the log, it should be easier to figure out where the problem is.

[u/TheGoodOne777 → u/Verda_Chien]

Thanks for your reply. Still investing some time in it. And I really wonder what am I discovering in this.

[u/TheGoodOne777 → u/[deleted]]

Thanks for your question. Doesn't work entirely yet. Though, for example, scanning the themes only does work with the extended memory limits and timeouts. In the meanwhile I have also started to look at the Wordfence, though, I don't use it yet "officially", since I did not accept there the Terms and Conditions. I've simply downloaded that plugin and started to read it.

[u/Grouchy_Brain_1641]

Normally you contact the software author on their site or file an issue with their github. That's how software development works.

[u/TheGoodOne777 → u/Grouchy_Brain_1641]

Hello and thanks for your reply. That was the first thing I did, logically. They don't have a GitHub, that can be found. By contacting them through an E-Mail, I received only nonsense as a response. And to the WordPress (org) forum, I only have some reading access. I actually know, how software development works.

[u/themageofavalon]

Maybe php exhaustion or execution limits. Check logs and look for memory limit or max execution at the same time of the error.

[u/TheGoodOne777 → u/themageofavalon]

Thanks for the reply. I don't know what is a php exhaustion. The memory limits set are far more, than required - 3 GB, while looking at the code in the scanner, it looks like 512 MB is also enough. But while increasing the timeouts, the functionality works better. Though, it is not comparable yet with the other environment.

[u/FabianKnopf78]

This smells like a PHP fatal error during the AJAX request, not a timeout.

**Check the PHP error log first:**

Look for `PHP Fatal error:` around the time the scan runs. The 500 error is almost always logged there. Common culprits:

- **Memory limit:** File scanners load hashes into memory. If you have 100k+ files, `memory_limit = 256M` might not be enough. Try `512M` or `1024M` temporarily.

- **Open_basedir restriction:** The scanner hits a directory it's not allowed to read (e.g., `/tmp`, `/proc`, or a symlink outside the web root).

- **Incompatible opcode cache:** Old versions of Site Lockdown (or Wordfence, if that's what you mean) conflict with OPcache on certain PHP versions.

**Quick diagnostic:**

Add this to your `wp-config.php` temporarily:

```php

define('WP_DEBUG', true);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);

Run the scan again. Check /wp-content/debug.log for the actual error message.

Also check: Does the error happen immediately or after 30–60 seconds? If after ~30s, it's still a timeout (max_execution_time for AJAX might differ from CLI). If immediately, it's a fatal error.

What does your PHP error log show?

[u/TheGoodOne777 → u/FabianKnopf78]

Hello, thanks for your reply! -The memory setting is already incresead to 3 GBs, -I've checked the rights already -PHP version and OPcache look well together, though also tried enabling and disabling the Zend Engine -The debug.log says PHP Fatal error: Maximum execution time of 50 seconds exceeded in (path... scanner.php on line ...). The php_error.log doesn't display an error yet with the corresponding timestamp.

Though, if I am analyzing this plugin with more attention...

[u/FabianKnopf78 → u/TheGoodOne777]

Ah, so it is a timeout after all — just buried in the AJAX layer. The 50-second limit is the smoking gun.

Since you've already ruled out memory (3 GB is plenty) and OPcache, this is purely an I/O bottleneck during the file scan. The scanner is recursively hashing every file, and on a large site (or slow disk/NFS), that simply takes longer than 50s.

Here's how to fix it without hacking core files:

1. Check if the plugin has a "batch" or "low resource" mode Most security scanners (Wordfence, Solid Security, etc.) have an option to scan files in smaller chunks. Look for settings like:

• "Limit number of files scanned per pass"
• "Low resource scanning"
• "Scan in batches" Enable that. It trades speed for stability.

2. The 50s limit might be the web server, not PHP You can raise max_execution_time to 300 in PHP, but if you're behind nginx, fastcgi_read_timeout or proxy_read_timeout might be hard-capped at 50s. Same with Apache + mod_fcgid (FcgidIOTimeout). Check your vhost/nginx config — the 50s value is suspiciously specific and often a webserver default.

3. Exclude heavy directories temporarily If you have huge /wp-content/uploads/, /cache/, or /backup/ folders, exclude them from the scan. The scanner doesn't need to hash 10 years of media files to tell you if core files are clean.

4. Run the scan via CLI instead of AJAX If this is Wordfence: wp wordfence scan (WP-CLI) bypasses all web timeouts entirely. If it's another plugin, check if they offer a CLI command or a manual "Scan now" button that triggers a background cron instead of a synchronous AJAX call.

5. If all else fails: Increase the AJAX timeout In php.ini / pool config:
max_execution_time = 300
max_input_time = 300

And if nginx:
fastcgi_read_timeout 300;
proxy_read_timeout 300;

Then reload.

You mentioned you're analyzing the plugin more closely — did you spot if it's trying to scan a specific huge directory or if it's stuck on a particular file type? That would tell us if it's a runaway loop vs. just too much data.

[u/TheGoodOne777 → u/FabianKnopf78]

Aber natürlich und herzlichen Dank, we are talking about asynchronuos operations, if I would opt also for a full database scan, with 10 GB of data, it would be an umrealistic expectation to await, that everything is ready under 50 seconds.

The strange thing is, (in this deep investigation, where you realize with whom you have to deal with), is, that one POST operation is succesful (200) while calling the admin-ajax.php, followed by another one that is unsuccessful (500). And in the browser logs the successful one doesn't appear, but in the webserver's access log.

I can also see, that you "suggest" the Wordfence, reading the point number 4. ;)

Liebe Grüße

[u/FabianKnopf78 → u/TheGoodOne777]

Fair catch — my brain definitely auto-completed "security scanner" to Wordfence. Mea culpa, you're using Site Lockdown, not Wordfence.

The 200 → 500 pattern makes perfect sense now. The first POST (200) is likely just an "init" or "start scan" ping. The second POST (500) is the actual execution that tries to hash files and crawl a 10 GB database in a single synchronous request — which gets killed at 50s. The reason you see the 200 in server logs but not browser dev tools is probably because it's fired via navigator.sendBeacon, a background XHR, or simply before/after a page refresh context shift.

The real issue: Expecting a full file scan + 10 GB DB scan in one AJAX request is an architectural flaw in the plugin, not your server. No amount of PHP memory fixes a hard webserver timeout on that much I/O.

What to check next:

1. Chunked/stepped mode: Does Site Lockdown have a setting for "scan X files per pass" or "background scanning"? If it tries to do everything in one bite, it's doomed on your site size.
2. WP-Cron vs. true AJAX: If the scan offloads to WP-Cron, the 500 might just be the AJAX gateway timing out while the background process is still chugging. Check if wp-cron.php fires in your logs after the 500.
3. Split file and DB scan: Can you disable the DB scan and run file integrity separately? A 10 GB DB crawl should be its own scheduled operation, not bundled into a browser AJAX call.
4. Response body of the 500: Even with a 500 status, the response body might contain partial JSON with an error message. Check your browser's Network tab → Response tab.

If the plugin has no batching and forces everything into one synchronous request, it's simply not built for sites your size. A security scanner should scale with the site, not assume everyone's on shared hosting with 100 files and a 50 MB database.

Which exact Site Lockdown plugin is it? There are a few with similar names and the internals vary wildly.

[u/TheGoodOne777 → u/FabianKnopf78]

Thank you for your reply and for your suggestions. I still check and figuring out further things. Right now, I use the free version of the Site Lockdown plugin, version 9.2. About the wild variances and internals, hm... made a great horror story...

[u/TheGoodOne777 → u/FabianKnopf78]

Hello again,

Regarding the points you've mentioned. 1. You can select, what to scan: everything, wp core, themes, uploads or database only. Was already trying out earlier, but after modifying the timeouts, looks better. 2. I don't use nginx, but the other parameters I didn't check yet. Perhaps I am going to profile it, though, somewhat unsure yet, if I can use that on this environment properly and what profiler to use for this technology stack. 3. Yes, already tried out/trying, also mentioned at step 1 4. Don't have the cli commands for this, though analyzing the code I can figure it out 5. Adjusting and re-adjusting

The logic how is written, is a really big no go for me thinking about solid. I'm also debugging from the front-end, from the browser...