PatchOn Agent vs WP-DBManager

PatchOn is an AI service that runs your WordPress plugin, theme, and core updates for you. It reproduces your production site in a staging environment, lets AI verify whether each update can be applied safely, and applies only the updates that pass every check to production. If an update ever fails, one click restores your site. This plugin acts as the agent connecting your WordPress site to PatchOn. Getting Started This plugin requires the PatchOn service (patchon.jp) and does not function on its own. Activation alone performs no external communication and does not redirect you. Clicking “Start PatchOn” on the welcome screen opens a consent dialog describing the data that will be sent; confirming it with “Agree and Start” registers your site anonymously and, if updates are available, starts the first inspect-and-update run. No account is required to get started — you need one only to: view detailed inspection results configure automatic updates use paid features Main Features Pre-inspection — in a staging environment, AI compares before / after screenshots of your site to detect layout breakage and fatal errors Inspect and update — a manual run goes from inspection to production rollout in one action, applying only updates that passed every check Automatic updates with inspection — the site is inspected on a schedule and only updates that passed every check are applied Backups — taken automatically right before each update and downloadable for a plan-based retention period One-click restore — if an applied update fails, one click puts your site back to the pre-update backup This plugin (the free distribution on WordPress.org) does not write patched code to your site files, even when it detects a problem. AI auto-repair, which fixes the code causing a problem found during a pre-inspection, is provided by the separately distributed PatchOn Agent Pro extension plugin (available to paid plan subscribers). This plugin writes to your site files in only two cases: applying the updates themselves through the standard WordPress upgrader, and the one-click restore, which runs only on your explicit request and writes your own backed-up plugins, themes, MU plugins, and wp-content drop-ins (and your database) back to the site. Data Sent Once you have consented on the consent screen, running a “Pre-inspection” or “Apply update” sends the following data to PatchOn and related external services. See the Privacy Policy for details. Site URL / WordPress version / PHP version / DB version List and versions of installed plugins, themes, and MU plugins List of available updates (names and versions of plugins, themes, and WordPress core). While the site is connected, this is sent automatically once a day Site files prior to update application, used for the pre-update backup: wp-config.php, active and to-be-updated plugins and themes, MU plugins, and wp-content drop-ins (such as object-cache.php) Contents of WordPress debug.log (used to detect issues) A full copy of your site’s database, taken during a pre-inspection and reused as the pre-update backup. It may include personal data stored on your site, such as member accounts or contact-form submissions External services This plugin depends on the following external services. No external communication is performed merely by activating the plugin; it starts only after you explicitly click the “Agree and Start” button on the consent screen shown on first use. PatchOn API (https://patchon.jp and its subdomains) The backend for all inspection, repair, update, and database-dump operations. Two host names are used, both operated by Rocketa Inc. and routed to PatchOn’s infrastructure: https://patchon.jp/api/* — site registration, pre-inspection control, apply-update control, billing https://dump.patchon.jp/* — database-dump control endpoints and signed-URL chunk uploads for pre-inspections and pre-update backups Provider: Rocketa Inc. (rocketa.co.jp) When data is sent: On click of the “Agree and Start” consent button (one-time): anonymous site registration and UUID issuance Once a day while connected (daily check-in): the list of available updates and plugin version When the user runs a “Pre-inspection”, or when automatic updates run their scheduled inspection: list of plugins / themes, debug.log, full database copy When the user runs an “Apply update”, or when automatic updates apply an update that passed every check: a backup (site files and a full database copy) and the application result When the user runs the one-click restore after a failed update: restore control requests and progress status (the backed-up files and database themselves are downloaded from cloud storage at that time, not sent) What is sent: see the “Data Sent” section above Terms of Service: https://patchon.jp/terms Privacy Policy: https://patchon.jp/privacy-policy Subprocessors: https://patchon.jp/subprocessors AWS S3 (Tokyo region, accessed via PatchOn) Storage destination for the site backup (zip) and the database copy (uploaded in chunks). Uploads and downloads are performed only against pre-signed URLs issued by PatchOn on a per-request basis. The customer site does not hold any S3 credentials. During a one-click restore, the backed-up site files and database chunks are downloaded from S3 in the same way. Provider: Amazon Web Services, Inc. Endpoint: https://*.s3.ap-northeast-1.amazonaws.com (pre-signed URLs only) When data is sent: when the user runs a “Pre-inspection” (database copy) or an “Apply update” (backup: site files and database copy) What is sent: site files (zip) and a full copy of the database AWS Privacy: https://aws.amazon.com/privacy/

WP-DBManager looks after the database behind your site: it backs it up, restores it, optimizes and repairs it, empties or drops tables and runs queries you write, all from wp-admin rather than from a shell or phpMyAdmin. Backups, optimization and repair can be left to run on a schedule, and the backup can be emailed to you when it finishes. Donations I spent most of my free time creating, updating, maintaining and supporting these plugins, if you really love my plugins and could spare me a couple of bucks, I will really appreciate it. If not feel free to use it without any obligations. Usage Securing The Backup Folder A database backup contains everything, including your users table. Anyone who can guess a backup file name can download the lot, so the folder must not be served over HTTP. The reliable option, on any server: set Path To Backup under WP-Admin -> Database -> Settings to a folder outside your web root, for example /var/www/example.com/backup-db when WordPress lives in /var/www/example.com/public_html. Nothing served, nothing to configure. If the folder has to stay inside the web root: Apache — move htaccess.txt from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/.htaccess IIS — move Web.config.txt from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/Web.config nginx — nginx does not read .htaccess files, so the file above does nothing. Add this to your server block and reload nginx: location ^~ /wp-content/backup-db/ { deny all; } Move index.php from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/index.php as well, so the folder cannot be listed. The Backup DB page requests a file from the folder and reports what the server actually returns, so you can confirm the folder is closed rather than assume it. WP-CLI wp dbmanager tables wp dbmanager backups wp dbmanager backup --yes wp dbmanager backup --no-gzip --yes wp dbmanager restore --yes wp dbmanager delete ... --yes wp dbmanager email [email protected] --yes wp dbmanager optimize --all --yes wp dbmanager repair wp_options --yes wp dbmanager empty ... --yes wp dbmanager drop ... --yes Everything that changes anything asks first, so a script has to pass --yes. That includes backup, which deletes the oldest backups to stay inside Maximum Backup Files, and email, because a dump holds your users table and a sent message cannot be recalled. tables and backups only read, and take a --format of table, csv, json, yaml, count or ids; their sizes are in bytes rather than the KiB and MiB the screens print, because a shell is better at arithmetic than at parsing 1.2 MiB. optimize and `repair` take table names or `--all`. `empty` and `drop` take names only: emptying or dropping every table in a database is not maintenance, and the screen at least shows you the list before you tick it. There is no run subcommand. WP-CLI already ships wp db query, which reaches the same database through the same client, so the Run SQL Query screen has no command counterpart. That screen is unchanged and still works. wp dbmanager checks no capability. WP-CLI has no logged-in user unless you ask for one with `--user`, and whoever can run it can already read the credentials in `wp-config.php`, so a check would refuse every scheduled backup script while protecting nothing. The `install_plugins` gate on the admin screens is unchanged.