Latest "Web Server" files
Workshop » Reference Section » Grimoires » IT » Platforms » Linux » Packages » SQL

SQL query to list all WordPress post revisions for archiving

Here's the SQL query to get all post revisions, which I do prior to cleaning them out of the database, which seems to make it much faster:

SELECT p.*
FROM [posts table name] p
WHERE (p.post_type = 'post' OR p.post_type = 'page') -- Include posts/pages
AND (p.post_date BETWEEN '2020-01-01' AND '2029-07-01') -- Adjust date range
OR (p.post_type = 'revision' AND p.post_parent IN (
SELECT ID FROM [posts table name]
WHERE post_date BETWEEN '2024-01-01' AND '2024-07-01'
));

To get just a count of revisions, change SELECT p.* to SELECT count(*).

Workshop » Reference Section » Grimoires » IT » Troubleshooting log » Web Server

Performance troubleshooting & settings changes 2025aug29

Following several days of frequent freezes, I tried changing the following settings

updated in :

[opcache] original settings
;recommended by https://vpsfix.com/14433/virtualmin-post-installation-configuration-and-server-optimization-guide/
opcache.enable=
opcache.memory_consumption=
opcache.interned_strings_buffer=
opcache.max_accelerated_files=
opcache.validate_timestamps=
opcache.revalidate_freq=
opcache.save_comments=
;end recommendation

to

[opcache]
;recommended by https://vpsfix.com/14433/virtualmin-post-installation-configuration-and-server-optimization-guide/
opcache.enable=
opcache.memory_consumption=
opcache.interned_strings_buffer=
opcache.max_accelerated_files=
opcache.validate_timestamps=
opcache.revalidate_freq=
opcache.save_comments=

-
added var_dump(opcache_get_status()) to php status page to be able to monitor opcache usage

-
changed warning logs from E_ALL & ~E_DEPRECATED & ~E_STRICT to
----
noticed contained a LOT of processes being stopped for tracing
turned off request_slowlog_timeout by setting to 0s in
had been 4s
---
I had turned on lightspeed at 1:45 am est , aug 26. Seems like more problems since then.

None of the above seem to help, still getting freezes maybe every 30 minutes. Next…

Workshop » Reference Section » Grimoires » IT » Platforms » Linux » Packages » rsync & rsnapshot

Resolving an rsnapshot error — “rsync: –delete does not work without –recursive (-r) or –dirs (-d). rsync error: syntax or usage error (code 1) at main.c(1795)”

I discovered rsnapshot hadn't run in a few days. Checking /etc/rsnapshot.log, I found every recent day had this:

rsync: --delete does not work without --recursive (-r) or --dirs (-d). rsync error: syntax or usage error (code 1) at main.c(1795) [client=3.2.7]

A few days ago I had added the line rsync_short_args -W to /etc/rsnapshot.conf in an effort to get rsync to run without putting such a load on my system. Removing this and running rsnapshot -v hourly from the command line shows that without it, the first line of the rsync command was /usr/bin/rsync -ax --delete --numeric-ids --relative --delete-excluded \, but with it, the first line was /usr/bin/rsync -Wx --delete --numeric-ids --relative --delete-excluded \.

Changing the line rsync_short_args -W to rsync_short_args -Wa, with an a flag explicitly included, solved the problem. Apparently specifying custom short flags overrides at least one of the default flags.

Also: remember, when you run an…