Recently, while organizing a WordPress website on the server, I noticed some highly unusual filenames in the site’s root directory, such as:
insert_id
post_tag,
ids
name
--max-time
-D
-o
tail
0
0,
false,
,
There was even a regular expression that clearly originated from a log filtering command, which had been turned directly into a filename.
Most of these files were 0 bytes. Given my past experience executing and pasting long commands in the SSH terminal, I concluded that some of these files were likely created accidentally during a command paste or execution.
However, the WordPress directory itself also contains a number of legitimate 0-byte files. Blindly deleting every empty file you see can easily damage the WordPress core, plugin cache protection files, or historical tools.
Therefore, instead of performing a direct batch deletion this time, I conducted a fairly comprehensive cleanup of the entire website directory using an approach of “scan first, confirm next, prioritize isolation, and delete only as a last resort“.
The website directory is:
/data/wwwroot/www.shuijingwanwq.com
1. First discovering a batch of clearly anomalous 0-byte files
When I initially viewed the website root directory using ls -la, I saw several items that did not look like normal WordPress files at all.
For example:
,
0
0,
ids
insert_id
name
post_tag,
--max-time
-D
-o
There was also a filename that almost certainly came from a Shell command:
^\[13-Jul-2026 21:(20|21|22|23|24|25|26):.*(execution timed out|terminating|SIGTERM|too slow)
The common characteristics of these files were quite obvious:
- A large number of files were 0 bytes in size;
- The filenames resembled commands, parameters, variable values, or SQL fields;
- Some even started with
-; - They were completely unrelated to the normal WordPress directory structure.
During the initial count, there were a total of 63 0-byte regular files across the entire site.
However, I could not simply execute:
find . -type f -size 0 -delete
Because subsequent checks proved that WordPress core, W3 Total Cache, WPCode, SyntaxHighlighter, Organize Series, and other components already contain legitimate empty files.
So I only picked out 16 high-confidence anomalous files and moved them to a quarantine directory instead of deleting them outright.
After the isolation was completed:
moved=16
skipped=0
The number of 0-byte files on the site also dropped from:
63
down to:
47
2. Why the remaining 0-byte files cannot be batch deleted
After checking the remaining empty files one by one, I found that many of them had legitimate origins.
For example, the WordPress core includes:
wp-includes/js/swfupload/license.txt
wp-includes/js/swfupload/swfupload.js
wp-includes/js/swfupload/handlers.js
wp-includes/js/swfupload/handlers.min.js
wp-includes/js/swfobject.js
Although these files are 0 bytes, after running the WordPress core checksum verification:
wp --allow-root core verify-checksums
The result was:
Success: WordPress installation verifies against checksums.
This proved that they are part of the current official WordPress release package and should not be deleted just because their size is 0.
In addition, there were:
- W3 Total Cache’s cache directory protection
index.html; - Placeholder files in plugins like WPCode;
logreport/no_delete;logreport/show/no_delete;- SyntaxHighlighter’s built-in
clipboard.swf; - Files belonging to plugins like Organize Series and Microsoft Clarity.
Therefore, “0 bytes” can only serve as a clue for investigation, not as a basis for deletion.
3. Discovering a leftover temp-write-test file from 2019
Among the remaining files was:
wp-content/temp-write-test-1565457605
After further tracing the source code, I found that WordPress’s own:
wp-admin/includes/file.php
creates temporary files like:
temp-write-test-*
to check directory write permissions and file ownership.
Under normal circumstances, the file should be deleted after the test ends.
The modification time of this file traced back to 2019. I later found it mentioned in an old blog post from February 19, 2021:
This means it had existed since at least 2021 and was not a file generated by a recent terminal mishap.
The final conclusion was:
This is a historical WordPress write permission test temporary file that was not cleaned up properly for some reason at the time.
Therefore, instead of deleting it outright, I moved it into the quarantine directory as well.
After handling this, the total number of 0-byte files on the site further decreased from:
47
down to:
46
This number remained unchanged until the final check.
4. Cleaning up the unused Hueman theme and Hueman Addons along the way
While checking historical files, I also noticed that the unused Hueman theme and addons were still kept on the server:
hueman inactive
hueman-addons inactive
The website currently uses Twenty Twenty-Five, so I deleted the Hueman theme first via WP-CLI:
wp --allow-root theme delete hueman
Deletion was successful.
However, when deleting Hueman Addons, I encountered:
Error: Cannot do 'launch': The PHP functions proc_open() and/or proc_close() are disabled.
Further inspection revealed that the current PHP 8.5 global disable_functions had disabled:
proc_open
proc_get_status
Considering that the website’s production environment still uses PHP-FPM, I did not modify the global PHP security configuration just for WP-CLI.
The approach I ultimately adopted was:
Only temporarily enable the specific PHP functions required by WP-CLI during its execution, while keeping the global security restrictions for PHP-FPM and the standard PHP CLI unchanged.
Using this method, Hueman Addons was also successfully deleted:
Deleted 'hueman-addons' plugin.
Success: Deleted 1 of 1 plugins.
Subsequently, I added a wp() Bash function to the root user’s .bashrc so that future WP-CLI executions would automatically use this temporary configuration.
This way, when cleaning up plugins or themes in the future, there is no need to retype a long string of PHP parameters every time, nor does it lower the restrictions of the entire PHP-FPM environment for WP-CLI.
5. Continued inspection: checking if anomalous files have “non-zero-byte versions”
After dealing with the 0-byte anomalous files, another thought occurred to me:
What if past terminal mis-pastes not only created empty files, but also created anomalous files with actual content?
Therefore, I scanned all file sizes again, focusing on finding:
- Files starting with
-; - Filenames containing Shell metacharacters;
- Command-style filenames in the root directory;
- Filenames with leading or trailing abnormal whitespace;
- Abnormal characters like newlines or tabs.
The result was:
suspicious_count=0
This meant that after isolating those 16 files, no other high-confidence Shell command fragment files of the same type were found.
6. The second scan briefly produced thousands of lines of results
Later, I broadened the rules to check for:
- Irregular files in the website root directory;
- Abnormal characters in filenames;
- Scripts like PHP within
uploadsandcache.
The output suddenly became very large.
The reason was not that thousands of trojans were discovered, but rather:
wp-content/cache/object/
There were a massive number of W3 Total Cache object cache files underneath it, for example:
wp-content/cache/object/term_language_relationships/.../*.php
These files are cache data by nature.
Therefore, I readjusted the scan rules:
The entire
wp-content/cache/is excluded from this round of anomalous file detection.
After all, W3 Total Cache’s old cache files, garbage collection, and _old file issues were already slated for a separate audit later; there was no need to mix them with this website root directory cleanup.
After the adjustment, only 23 items remained that warranted manual review.
7. Among the 23 irregular files, few actually needed cleanup
This scan turned up some files that clearly showed their age:
Adobe AIR_3.6.exe
nginx-1.10.1.zip
hosts
make_sql.php
wp-config.php.bak-slytranslate-debug-2026-07-14-100437
In addition, there were:
fix-en-chinese-tags.php
polylang-batch-zh-to-en-tags.php
merge-tags.php
nginx.conf
cdn-test.html
ads.txt
As well as verification files for Google, Baidu, Sogou, IndexNow, and others.
This once again proved:
Just because a file looks strange does not mean it should be deleted.
So instead of batch processing them, I verified their purpose one by one.
8. The three PHP files turned out to be tag maintenance tools I still use daily
The following three files initially looked like one-off maintenance scripts:
fix-en-chinese-tags.php
polylang-batch-zh-to-en-tags.php
merge-tags.php
But in reality, they are WordPress / Polylang tag processing tools that I still use today.
After examining the entry code, I found that all three files begin with:
if (php_sapi_name() !== 'cli') {
die("❌ 请在命令行运行\n");
}
Only after that do they load:
require __DIR__ . '/wp-config.php';
Some of these scripts even support:
--dry-run
--all
and other command-line parameters.
Therefore, they are explicitly PHP CLI dedicated maintenance scripts.
Even if accessed directly via a browser, they will terminate before loading WordPress and executing database logic.
So the final decision was:
fix-en-chinese-tags.php
polylang-batch-zh-to-en-tags.php
merge-tags.php
All kept.
This was also a very important point during this cleanup process: you cannot judge a file as abandoned based solely on its name and location.
9. Tracing the origin of make_sql.php through an old blog post
Regarding:
make_sql.php
I searched for the filename directly on my blog and found an old record dated April 30, 2026:
At the time, this script was used to generate view count import SQL based on historical Nginx access logs, and then import those historical view counts into WordPress.
It was inherently a one-time data processing workflow.
Now that the related task is complete, there is no need to continue accessing it via the public internet:
https://www.shuijingwanwq.com/make_sql.php
Therefore, I moved it out of the website root directory. Instead of permanently deleting it, I saved it in:
/root/swq-webroot-cleanup-quarantine-20260808/
If I need to reference the processing logic from back then later, it can still be retrieved.
10. Prioritizing moving the wp-config.php backup file out of the public directory
Among the files discovered this time, I felt the one that should be prioritized for handling was:
wp-config.php.bak-slytranslate-debug-2026-07-14-100437
Although it is just a backup left over from debugging, the wp-config.php might contain:
- Database connection credentials;
- WordPress security keys;
- Other sensitive configurations.
Moreover, the backup file’s extension is no longer the standard .php.
There is no reason for such a file to remain in the web root directory.
So I immediately moved it to:
/root/swq-webroot-cleanup-quarantine-20260808/
instead of leaving it in:
/data/wwwroot/www.shuijingwanwq.com/
11. The 2013 Adobe AIR and 2016 Nginx ZIP were also found
Two other very typical legacy files:
Adobe AIR_3.6.exe
nginx-1.10.1.zip
had modification times tracing back to:
2013
2016
The timeline for nginx-1.10.1.zip also perfectly matched the Nginx 1.10.1 version I used in my past Windows local development environment.
These files are clearly not required by the current WordPress, Linux, PHP-FPM, or Nginx production environment.
However, considering they are materials left over from many years ago, I still opted for isolation rather than immediate permanent deletion.
12. hosts also turned out to be a leftover from local development in 2017
There was also another file in the website root directory:
hosts
It was only 110 bytes.
Its contents were:
127.0.0.1 localhost
::1 ip6-localhost
172.28.28.18 default.interact.shenzhen.localhost
Combined with past blog records, I confirmed this was a hosts file left over from previous Windows / Android / Genymotion local development, not the one actually used by the server now:
/etc/hosts
Therefore, it was also moved into the quarantine directory.
13. The nginx.conf in the root directory, however, must not be deleted
Another file that is easy to misjudge is:
nginx.conf
It is not the currently active:
/usr/local/nginx/conf/nginx.conf
Their SHA256 hashes are different:
929e8a834bd2494c42f12a8f7cb12795409c6aa7e23e5576b7b9e63ec0d6390b nginx.conf
6bd4e466bbcc629ee076386b54949a35ead6e22213faaa614191b878de751d7e /usr/local/nginx/conf/nginx.conf
An inspection via nginx -T also revealed no explicit reference to this file in the website root directory within the current Nginx configuration.
But upon viewing its contents, I immediately noticed:
# BEGIN W3TC Page Cache cache
...
# END W3TC Page Cache cache
# BEGIN W3TC Browser Cache
...
# END W3TC Browser Cache
# BEGIN W3TC Page Cache core
This meant it was a Nginx rules file generated by W3 Total Cache.
So even though it was not directly found to be loaded by the main Nginx configuration, it should not be casually deleted during this directory cleanup.
W3TC will be audited separately later; for now, it is kept.
14. Verification files should not be deleted just because they look old
There were also quite a few verification files in the root directory, for example:
google6ef993c34e9a65a9.html
baidu_verify_U5mywj2jTv.html
baidu_verify_codeva-LyBgT68D0O.html
baidu_verify_codeva-0D6Gn3P4Mk.html
sogousiteverification.txt
1311aeca4e764c48afb3665fb02f3537.html
ed840343aa968ef81a2d8c6d432b7abc.txt
Most of these files were only a few dozen to just over a hundred bytes.
I specifically checked the access counts in the current Nginx logs, and the results were all 0.
But this does not directly mean they are useless.
The reason is simple:
- Search engines might not re-request website verification for years;
- There is currently a CDN in front of the website, so requests might not necessarily enter the current origin server logs;
- Deleting verification files could cause issues when re-verifying site ownership in the future.
Therefore, the relevant files for Google, Baidu Search Resource Platform, Sogou, and IndexNow that are currently in use were all kept.
15. Baidu Union, Alimama, and 360 WebScan have been disabled, so their corresponding verification files were directly deleted
However, three files were definitively confirmed to have no reason to be kept any longer.
Baidu Union
bdunion.txt
Baidu Union is no longer used, so it was directly deleted.
Alimama / Taobao Alliance
root.txt
The corresponding platform is also no longer in use, so it was similarly deleted.
360 Website Security Detection
webscan_360_cn.html
This was a website verification file previously used by 360 Website Security Detection / WebScan.
This service is definitively no longer in use, so it was also directly deleted.
Final confirmation:
CLEAN: bdunion.txt
CLEAN: root.txt
CLEAN: webscan_360_cn.html
16. ads.txt only has Google AdSense, so it is kept
There was also in the root directory:
ads.txt
Checking the contents:
google.com, pub-8392190980622725, DIRECT, f08c47fec0942fa0
Currently, it only contains the Google AdSense authorization record, with no records for Adsterra or other disabled ad platforms.
Therefore, ads.txt is kept.
17. Final cleanup results
Finally, I checked the files that had already been processed again:
CLEAN: bdunion.txt
CLEAN: root.txt
CLEAN: webscan_360_cn.html
CLEAN: hosts
CLEAN: make_sql.php
CLEAN: Adobe AIR_3.6.exe
CLEAN: nginx-1.10.1.zip
CLEAN: wp-config.php.bak-slytranslate-debug-2026-07-14-100437
The current quarantine directory:
/root/swq-webroot-cleanup-quarantine-20260808
retains:
Adobe AIR_3.6.exe
hosts
make_sql.php
nginx-1.10.1.zip
wp-config.php.bak-slytranslate-debug-2026-07-14-100437
The total size is approximately:
2.0 MB
Additionally, the 16 Shell command fragment files discovered at the very beginning are saved in:
/root/swq-zero-byte-quarantine-20260808
Both quarantine directories will not be deleted immediately; they will be kept for a period of time first.
18. The final baseline after cleanup is complete
Final statistics:
网站根目录普通文件：32
全站 0 字节文件：46
Most importantly:
高置信度命令碎片异常文件：0
At the same time, the WordPress Core checksum has passed.
Therefore, the remaining 46 0-byte files can no longer be interpreted as “46 junk files”.
The vast majority of them have already been confirmed to belong to:
- Official WordPress core files;
- Empty files bundled with plugins;
- Directory protection files for W3 Total Cache / WPCode;
- Historical log directory marker files;
- Other placeholder files with clear purposes.
Continuing to clean up just to reduce the number to 0 might actually lead to deleting legitimate files.
19. The biggest takeaway from this cleanup
This investigation initially started just to handle a few empty files generated by mis-pasting Shell commands, but following this thread, I ended up discovering:
- 16 obvious command fragment files;
- A WordPress
temp-write-testleft over for years; - The unused Hueman theme;
- The unused Hueman Addons;
- A
wp-config.phpdebug backup exposed in the web root directory; - A
make_sql.phpthat had served its historical purpose; - An Adobe AIR installer from 2013;
- An Nginx Windows archive from 2016;
- A local development
hostsfrom 2017; - Verification files for the disabled Baidu Union, Alimama, and 360 WebScan.
But at the same time, I avoided mistakenly deleting:
- Three tag maintenance scripts still in daily use;
- The
nginx.confgenerated by W3 Total Cache; - The W3TC preload Sitemap;
- The
ads.txtfor Google AdSense; - Search engine and IndexNow verification files;
- Legitimate 0-byte files bundled with WordPress and plugins.
So for a WordPress site that has been running for over a decade, gone through multiple migrations, theme changes, plugin adjustments, and server environment shifts, the real difficulty of directory cleanup is not:
“How to batch delete files?”
But rather:
How to prove that a file is genuinely no longer useful.
My approach ultimately became:
Discover anomaly → check file attributes → check source code → check old blog posts → check current configuration → determine if still in use → prioritize isolation → delete only as a last resort.
Although this is much more cumbersome than directly executing a single find ... -delete, for a production site, this approach is clearly more secure.
The cleanup can temporarily conclude here.
If I continue organizing later, I will handle W3 Total Cache’s historical page cache, _old files, and garbage collection mechanism as a separate issue, rather than mixing it with the website root directory cleanup again.