Title: Fleet Agent Site Manager – Securely Connects Your Sites to a WPMgr Dashboard Author: Mosamlife Published: Август 6, 2026-ж. Last modified: Октябрь 14, 2026-ж. --- Плагиндерди издөө ![](https://ps.w.org/fleet-agent-site-manager/assets/banner-772x250.png?rev=3636102) ![](https://ps.w.org/fleet-agent-site-manager/assets/icon.svg?rev=3636102) # Fleet Agent Site Manager – Securely Connects Your Sites to a WPMgr Dashboard Автору [Mosamlife](https://profiles.wordpress.org/mosamlife/) [Жүктөө](https://downloads.wordpress.org/plugin/fleet-agent-site-manager.0.61.166.zip) * [Кенен маалымат](https://ky.wordpress.org/plugins/fleet-agent-site-manager/#description) * [Сын-пикирлер](https://ky.wordpress.org/plugins/fleet-agent-site-manager/#reviews) * [Орнотуу](https://ky.wordpress.org/plugins/fleet-agent-site-manager/#installation) * [Development](https://ky.wordpress.org/plugins/fleet-agent-site-manager/#developers) [Колдоо](https://wordpress.org/support/plugin/fleet-agent-site-manager/) ## Сүрөттөө **Fleet Agent Site Manager securely connects the WordPress sites you look after to a WPMgr dashboard, so backups, updates, caching, security and performance for every one of them run from a single screen.** **You need a WPMgr dashboard as well as this plugin.** Run one on your own server for free (it is open source: https://github.com/mosamlife/wpmgr), or use the hosted service at https://manage.wpmgr.app. Until you enter a dashboard address and complete a signed pairing, this plugin has no endpoint, opens no outbound connection and sends nothing anywhere. Every action the dashboard can ask for is on a closed, named list compiled into the plugin, and each one is verified against an Ed25519 signature tied to that pairing before it runs. There is no eval, no remote include and no remote PHP execution of any kind. #### What you can do once a site is connected **Backups and restore.** Full and incremental backups of the database and files, scheduled per site or run on demand. An incremental run uses a content-addressed chunk store so only changed blocks move. Send them to storage the dashboard manages, a folder on your own server, or your own S3-compatible bucket. Restore a whole site or pick components, with a health check afterwards and an automatic rollback if the site does not come back. **Updates you can undo.** Core, plugin and theme updates across every connected site, applied by WordPress’s own Upgrader against WordPress.org packages. A snapshot is taken before each one, so a bad release is one click back rather than a restore from last night’s backup. A watchdog recovers a site whose update died mid-write. **Speed.** Disk page cache with an nginx and Apache fast path that serves a hit without booting PHP. Optional Redis object cache. Remove Unused CSS, CSS and JavaScript minification, deferred JavaScript, speculation rules, CDN rewriting, lazy iframes, and self-hosted Google Fonts, Gravatars and third-party scripts. **Images and fonts.** Convert the media library to WebP and AVIF, keep the originals, and put them back if you do not like the result. An unused-image cleaner finds files nothing references. TTF, OTF and WOFF are transcoded to WOFF2. **Security.** Hardening switches that stay off until you turn them on: file editor, XML-RPC, REST, author enumeration, SSL and HSTS, directory browsing, PHP execution in uploads. Login protection with per-site IP, CIDR and user-agent bans enforced at earliest boot. A hidden login address. File-integrity scanning against WordPress. org checksums and a learned per-site baseline. **Two-factor for your site’s own users.** Authenticator app, emailed code or single- use backup codes, with guided enrollment once you require it for a role. **Password policy.** Minimum strength, reuse blocking, optional expiry, and a breach check that never lets the password or its full hash leave the site. Policies target the roles your site actually has, including roles added by WooCommerce, membership and LMS plugins. **Database tools.** Scan for revisions, transients, spam and orphaned metadata, preview exactly what will go before anything is deleted, take a snapshot before any change, and run a serialization-aware search and replace. **File manager.** Browse, read, write, rename, delete, chmod, search, upload, archive and extract, with a version history on writes and a restore. Guarded against executable writes and protected roots. **Site email.** Route this site’s outgoing mail through Amazon SES, SendGrid, Mailgun, Postmark or SMTP, with per-sender routing, automatic fallback, suppression of known- bad addresses and a full send log. **Real User Monitoring.** Off by default. Turn it on and Core Web Vitals come from your actual visitors, page by page, instead of one lab score. Cache purge reaches the layer in front of WordPress too, detected automatically: Varnish, Kinsta, WP Engine, SiteGround, Cloudways, RunCloud, GridPane, SpinupWP, CloudPanel, Rocket.net and WP Cloud, plus Cloudflare once you add its API credentials to wp-config.php. The expensive work runs on the dashboard rather than on your server: unused-CSS computation, image and font encoding, vulnerability matching against a managed feed, uptime probing and site screenshots. This plugin is MIT-licensed and the dashboard is AGPL-3.0. Source for both: https:// github.com/mosamlife/wpmgr ### Privacy / What data is sent and where This plugin contacts nothing until you connect it to a WPMgr control plane you choose, self-hosted or the hosted service at https://manage.wpmgr.app. There is NO default endpoint: it is inert until you supply a control-plane URL and complete a one-time, signed enrollment. Once connected, the agent communicates only with the control-plane URL you configured. It sends the following, only to that endpoint, and only for the management actions you or your schedules initiate: * Site and environment metadata: site URL, WordPress, PHP and server versions, active theme and plugins, and Site Health diagnostics. The metadata also includes the parent theme of a child theme and, on a site running Elementor, whether Elementor’s Atomic editor is switched on. Sent on connect, on a periodic heartbeat, and when you click Re-run checks. Used to display your site’s status in the dashboard. * Update inventory: the list of available core, plugin and theme updates. Sent when inventory is refreshed. Used to show and apply updates. * Backup archives (not encrypted by this plugin): when you run or schedule a backup, the agent archives your database and/or files and uploads them to the storage destination your control plane configured. Protection at rest comes from that destination. Archive contents may include your site’s content and personal data. * Rendered HTML: for CSS optimization (used-CSS generation), the agent submits rendered HTML of selected pages so unused CSS can be computed. Used only to produce optimized stylesheets. * Diagnostics and activity logs: error logs, performance and cache statistics, and a record of management actions, sent so they can be surfaced in the dashboard. * AI requests from an assistant you connect to your WPMgr dashboard: the results of the reads it asks for, such as published page and post text, titles and excerpts, media details and what reviewed abilities on the site return, and previews of the drafts and changes it proposes. The agent does not sell or share this data with third parties. **Real User Monitoring (when you enable it)** Real User Monitoring (RUM) is off by default and must be enabled per site. It is the one exception to the agent-as-sole-transmitter model above: the agent adds a small, public measurement script to HTML it already serves, and your visitor’s own browser, not the agent, then sends anonymous performance measurements directly to the control plane. What the visitor’s browser sends: * Core Web Vitals (LCP, INP, CLS) plus TTFB and FCP, and page-load timing. * The page path only. Query strings are stripped before transmission, so tokens, emails, and order IDs in URLs are never sent. * Coarse, non-identifying context: browser and device type derived from the User- Agent, connection type, and an approximate country code. What is never collected: cookies, localStorage, cross-site identifiers, or the visitor’s full IP address. The IP is used only transiently for rate-limiting and coarse country lookup, then discarded and never stored. This data originates from your visitors’ browsers, so you (the site owner) are its data controller and must disclose it in your own site’s privacy policy. If you self- host the control plane, RUM data stays entirely on your own infrastructure and never reaches WPMgr. If you use the hosted service at https://manage.wpmgr.app, that service processes the measurements on your behalf. Disable RUM at any time in the Performance settings; the script is removed from newly cached pages immediately. If you connect to the hosted WPMgr service, its Terms of Service (https://manage. wpmgr.app/terms) and Privacy Policy (https://manage.wpmgr.app/privacy) apply. If you self-host the control plane, you operate the receiving service and your own policies apply. You can stop all data transmission at any time by disconnecting the agent (Disconnect in the agent admin screen) or deactivating the plugin. **How it works / security** Commands arrive from the control plane over HTTPS. Each carries an Ed25519 signature produced with the key established at enrollment, and the agent verifies it before executing any action. The allow-list of permitted commands is compiled into the plugin, no mechanism exists to add new command types at runtime, and there is no eval, remote include, or remote PHP execution. Core, plugin, and theme updates are applied using WordPress’s own Upgrader against wordpress.org packages only. ### External services This plugin contacts external hosts only after you connect it to a control plane, and only for the specific features you enable. The plugin is inert until connected. This build contains no self-update client; updates arrive through the WordPress. org directory only. **WPMgr control plane (the URL you supply)** What is sent: site URL and name, WordPress and PHP versions, active plugin and theme inventory, Site Health results, rendered HTML of selected pages (for used-CSS computation), backup archives, transcoded font bytes, and cache and performance statistics. When: on enrollment, diagnostics, heartbeat, backup progress, cache and performance operations, Remove Unused CSS, autologin token consumption, database clean, font transcoding, and password breach checking. Always triggered by an action or schedule you initiate, never autonomously. Why: this is the dashboard that manages the site. Hosted at https://manage.wpmgr.app, its terms and privacy policy apply. Terms: https://manage. wpmgr.app/terms Privacy: https://manage.wpmgr.app/privacy Self-hosted, you operate the receiving service and your own policies apply. **Have I Been Pwned (https://haveibeenpwned.com), reached via the WPMgr control plane** What is sent: the first 5 characters of the SHA-1 hash of a candidate password, a k-anonymity range query. The site sends that prefix to the WPMgr control plane, which relays it to the Have I Been Pwned range API (https://haveibeenpwned.com/API/ v3#searchingPwnedPasswordsByRange) and returns the matching hash suffixes. The password itself, the full hash and the user’s identity never leave the site; the agent compares the remaining 35-character suffix locally. When: only while the optional password- policy breach check is enabled, and only when a site user sets or changes a password. Off by default. Why: to refuse a password already known to be breached. Terms: https:// haveibeenpwned.com/TermsOfUse Privacy: https://haveibeenpwned.com/Privacy The control- plane hop is covered by the WPMgr terms above. **Object storage (configured by your control plane)** What is sent: backup archives (not encrypted by this plugin), restored backup chunks, optimized media files and transcoded font bytes, over short-lived presigned URLs the control plane supplies. No storage endpoint is hardcoded in this plugin. When: during backup, restore, and media or font optimization operations that you initiate. Why: this is where your backups and optimized assets are stored. The hosted service uses Google Cloud Storage (storage.googleapis.com) by default; a self-hosted operator may configure any S3-compatible destination. For the hosted default, Terms: https:// cloud.google.com/terms Privacy: https://policies.google.com/privacy **ipify (https://api.ipify.org), operated by ipify (https://www.ipify.org)** What is sent: nothing. A plain GET request carrying no site data; the response is this server’s public outbound IP address, cached locally for 8 hours. When: during diagnostics collection, which you run or schedule. Why: to infer which host the site runs on. Terms: https://geo.ipify.org/terms-of-service Privacy: https://geo. ipify.org/privacy-policy **Cloudflare API (https://api.cloudflare.com), operated by Cloudflare, Inc.** What is sent: the configured Cloudflare zone ID and the API credentials you placed in wp-config.php. When: on a cache purge, and only while the Cloudflare integration is active. It stays inactive unless you define CLOUDFLARE_EMAIL and CLOUDFLARE_API_KEY, or CLOUDFLARE_API_TOKEN, in wp-config.php. Why: to purge the Cloudflare edge cache so visitors do not keep an old page. Terms: https://www.cloudflare.com/website-terms/ Privacy: https://www.cloudflare.com/privacypolicy/ **Google Fonts (https://fonts.googleapis.com, https://fonts.gstatic.com), operated by Google LLC** What is sent: the font-family request derived from the page, the same request a browser would otherwise make. When: on cache build, and only while the self-hosted fonts optimization is enabled and a page uses Google Fonts. Why: to download the CSS and WOFF2 files server-side and serve them from your own domain instead. Terms: https://policies.google.com/terms Privacy: https://developers.google.com/fonts/faq/ privacy **Gravatar (https://gravatar.com, https://secure.gravatar.com), operated by Automattic** What is sent: the avatar hash derived from the page. When: on cache build, and only while the self-host Gravatars optimization is enabled. Why: to download avatar images server-side and serve them from your own domain instead. Terms: https://wordpress. com/tos/ Privacy: https://automattic.com/privacy/ **Third-party asset hosts referenced by your own pages** What is sent: a plain GET request to a cross-origin script or stylesheet URL that your page already references. When: on cache build, and only while the self-host third-party assets optimization is enabled. Why: to serve those assets from your own domain instead. There is no single provider. The hosts depend entirely on what your own pages embed, and the applicable terms and privacy policies are whichever of those hosts publish. **Email delivery providers (only the one you select, if any)** What is sent, for every provider below: sender address, recipient addresses (To, Cc, Bcc), subject, message body (HTML and/or plain text), and attachments or attachment metadata. When: only when that provider is the active email transport for this site and an outgoing email is sent. No provider is active until you configure one. Why: to deliver this site’s outgoing mail through a provider rather than the server’s own mailer. * Postmark, operated by Wildbit LLC. Endpoint: https://api.postmarkapp.com/email Terms: https://postmarkapp.com/terms-of-service Privacy: https://postmarkapp. com/privacy-policy * Amazon SES (https://aws.amazon.com/ses/), operated by Amazon Web Services, Inc. Endpoint: https://email.{region}.amazonaws.com/ where {region} is your configured AWS region, for example us-east-1. The message is sent as raw MIME signed with AWS Signature Version 4. Terms: https://aws.amazon.com/service-terms/ Privacy: https://aws.amazon.com/privacy/ * Mailgun, operated by Sinch Email (formerly Mailgun Technologies, Inc.). Endpoints: https://api.mailgun.net/v3/{domain}/messages (US region) or https://api.eu.mailgun. net/v3/{domain}/messages (EU region). Terms: https://www.mailgun.com/legal/terms/ Privacy: https://www.mailgun.com/legal/privacy-policy/ * SendGrid, operated by Twilio Inc. Endpoint: https://api.sendgrid.com/v3/mail/ send Terms: https://www.twilio.com/en-us/legal/tos Privacy: https://www.twilio. com/en-us/legal/privacy * SMTP: whichever server you configure. Your own provider’s terms and privacy policy apply. ### Third-party / Credits **matthiasmullie/minify (MIT)** CSS and JavaScript minification uses matthiasmullie/minify (^1.3, MIT), a pure-PHP library in the plugin’s Composer dependencies. Copyright (c) 2012 Matthias Mullie. Source: https://github.com/matthiasmullie/minify **matthiasmullie/path-converter (MIT)** matthiasmullie/path-converter (~1.1, MIT) is minify’s own Composer dependency, rewriting relative paths in minified CSS, installed into the same vendor tree. Copyright ( c) 2015 Matthias Mullie. Source: https://github.com/matthiasmullie/path-converter **bjeavons/zxcvbn-php (MIT)** Password-strength scoring in the password policy uses bjeavons/zxcvbn-php (^1.4, MIT), a pure-PHP port of zxcvbn in the plugin’s Composer dependencies. Copyright( c) 2013-2014 Benjamin Jeavons. Source: https://github.com/bjeavons/zxcvbn-php **symfony/polyfill-mbstring (MIT)** symfony/polyfill-mbstring (>=1.3.1, MIT) is zxcvbn-php’s own Composer dependency, providing mbstring functions where the extension is absent, installed into the same vendor tree. Copyright (c) 2015-present Fabien Potencier and contributors. Source: https://github.com/symfony/polyfill-mbstring No other third-party PHP libraries are bundled beyond those credited above. Image encoding and WOFF2 font transcoding run on the control-plane service, not inside this plugin. The bundled Real User Monitoring JavaScript also carries a third-party library; see Source code below. ### Source code This plugin ships two minified JavaScript files. Their human-readable source and build tooling are in the public repository at https://github.com/mosamlife/wpmgr * **assets/wpmgr-rum.min.js** is the Real User Monitoring collector. The readable, non-minified build ships alongside the plugin at assets/wpmgr-rum.js. TypeScript source: apps/tracker/src/index.ts and apps/tracker/src/vitals.ts. Build: cd apps/ tracker && npm install && npm run build (esbuild IIFE bundle, which also bundles Google web-vitals under its Apache-2.0 license; the same build produces both the minified and readable outputs). * **assets/wpmgr-delay.min.js** is the deferred-script runtime. The readable source ships alongside the plugin at assets/wpmgr-delay.js in the same repository. ## Орнотуу 1. Install and activate this plugin on the site you want to manage. 2. Get a dashboard, if you do not have one yet. Either run WPMgr on your own server( source and install guide at https://github.com/mosamlife/wpmgr) or sign in at https:// manage.wpmgr.app. Both give you the same dashboard. 3. In the dashboard, add the site. It gives you a pairing code. 4. Back on this site, open Fleet Agent Site Manager in the WordPress admin menu. Put your dashboard’s address in the **Control-plane URL** field and click **Save URL**. 5. Paste the pairing code into the **Pairing code** field and click **Enroll**. The site appears in your dashboard, and every management action runs from there. #### What you need before you start * WordPress 6.2 or newer * PHP 8.1 or newer * A WPMgr dashboard to connect to, self-hosted or hosted #### How to disconnect Click **Disconnect** on the same settings screen, or deactivate the plugin. All outbound communication stops immediately. ## FAQ.KG ### Do I need anything besides this plugin? Yes. This plugin is the agent that runs on your site, and it needs a WPMgr dashboard to talk to. That is either a WPMgr instance you run yourself (open source, https:// github.com/mosamlife/wpmgr) or the hosted service at https://manage.wpmgr.app. On its own the plugin does nothing at all. ### Why is this called Fleet Agent Site Manager when the dashboard is called WPMgr? WPMgr is the project. This plugin is its agent, listed in this directory under the name the plugin directory approved, and the project’s own code and documentation call it the WPMgr agent. One plugin, one repository: https://github.com/mosamlife/ wpmgr ### Is self-hosting a cut-down version? No. The dashboard is AGPL-3.0, has no site limit when you run it yourself, and nothing in it is gated behind a paid tier. Running it does mean running the control-plane service, PostgreSQL and object storage, plus the encoder service if you want image, font and unused-CSS optimization, and a free Wordfence Intelligence API key if you want vulnerability matching. The install guide is in the repository. ### How many sites can one dashboard manage? Self-hosted, as many as your server will carry. The hosted service has per-plan limits, listed at https://wpmgr.app/pricing ### Will it work on shared hosting? Yes. The work that needs real CPU runs on the dashboard, not on your server. Long jobs such as backups acknowledge the request and continue in the background instead of holding a connection open. ### Does it conflict with my existing cache or security plugin? Every feature is separately optional, so you can connect a site and use only the parts you want. Leave the page cache off and keep the caching plugin you already have; backups, updates and the rest work regardless. ### What happens if the dashboard is unreachable? Your site carries on serving. Work the dashboard schedules, such as backups, waits until it can reach the site again. Nothing on the site depends on the dashboard being up. ### What runs on my server, and what runs on the dashboard? This plugin listens for the dashboard’s signed commands, carries them out, and sends a heartbeat and environment metadata so the dashboard knows the site is alive. That is all it does on your server. Everything expensive runs on the dashboard: Remove Unused CSS is computed there, image and font encoding happen there, vulnerability matching against a managed feed happens there, and uptime is probed from there rather than from inside your site. Your server never needs a headless browser or an image library. ### Where are my backups stored, and can I use my own bucket? Per site, choose storage the dashboard manages, a folder on your own server, or any S3-compatible bucket. Your storage credentials stay on the dashboard and never reach the site; the dashboard signs each transfer. ### Does this plugin phone home? No. The plugin contains no default endpoint and makes zero outbound connections until you connect it to a control plane that you supply. It is completely inert on activation. ### Do I need a WPMgr account? Only if you use the hosted service at https://manage.wpmgr.app. You can also self- host the entire WPMgr control plane, and the agent works identically either way. The plugin itself has no dependency on any specific account or service. ### Is my data sent anywhere by default? No. Without an active connection to a control plane you configured, no data is sent anywhere. All transmission is initiated by commands from the control plane you enrolled, never autonomously. ### How are updates handled? Updates to this plugin are delivered via the WordPress.org plugin directory and applied through the standard WordPress update mechanism. There is no separate update channel in this build. ### Can the control plane execute arbitrary code on my site? No. The command dispatcher accepts only a closed, named allow-list of commands. Every command is verified against an Ed25519 signature tied to the enrollment key. There is no mechanism to execute arbitrary PHP, SQL, or shell code. ### What happens if I deactivate the plugin? All outbound communication stops immediately. The control plane can no longer reach the site. Stored cache files, optimized images, and backup archives that already exist on disk are not automatically removed, and you can clean those up from the plugin settings before deactivating. ### Does this plugin write any files outside its own folder? Only for a small number of opt-in features that must run before WordPress finishes loading your other plugins. Enabling the optional Error Monitor writes a small must- use plugin file to wp-content/mu-plugins/ so a fatal error occurring during another plugin’s own startup can still be captured and reported; disabling Error Monitor removes that file. The same pattern is used by the optional login-protection ban list (a must-use file that enforces IP and user-agent blocks at the earliest possible point in the request) and by the automatic update-safety watchdog, which is present only while a site is connected to a control plane (it is inert until an update is actually in progress, and is removed if you disconnect the site). No other feature writes outside the plugin’s own folder. ## Сын-пикирлер ![](https://secure.gravatar.com/avatar/7400db5f5950e968dca5901a93d2aa368f67386583ee74af58a75fafda472837? s=60&d=retro&r=g) ### 󠀁[Full support](https://wordpress.org/support/topic/full-support/)󠁿 [Iacopo](https://profiles.wordpress.org/iacopoincerpi/) Октябрь 6, 2026-ж. Full support for this project ![](https://secure.gravatar.com/avatar/f76770711cb8d80030d62ece393a69b863bb8a16856e2843bff3ed829199257d? s=60&d=retro&r=g) ### 󠀁[Absolutely brilliant](https://wordpress.org/support/topic/absolutely-brilliant-117/)󠁿 [webbbio](https://profiles.wordpress.org/webbbio/) Октябрь 2, 2026-ж. First day using it after years of mainwp and I can already see the potential. This is gonna be huge once it gets more mature. I hope they move "Fleet Agent Site Manager" admin menu link to under "Tools" where it belongs, as you use it once and it does not belong in wp main menu for clients to see.Looking forward to updates and community extensions. [ Read all 2 reviews ](https://wordpress.org/support/plugin/fleet-agent-site-manager/reviews/) ## Contributors & Developers “Fleet Agent Site Manager – Securely Connects Your Sites to a WPMgr Dashboard” is open source software. The following people have contributed to this plugin. Мүчөлөрү * [ Mosamlife ](https://profiles.wordpress.org/mosamlife/) [Translate “Fleet Agent Site Manager – Securely Connects Your Sites to a WPMgr Dashboard” into your language.](https://translate.wordpress.org/projects/wp-plugins/fleet-agent-site-manager) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/fleet-agent-site-manager/), check out the [SVN repository](https://plugins.svn.wordpress.org/fleet-agent-site-manager/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/fleet-agent-site-manager/) by [RSS](https://plugins.trac.wordpress.org/log/fleet-agent-site-manager/?limit=100&mode=stop_on_copy&format=rss). ## Өзгөртүүлөр The entries below summarize the notable changes since 0.61.78. This project ships frequently and not every intermediate patch release is listed here. Full history: https://github.com/mosamlife/wpmgr/blob/main/CHANGELOG.md #### 0.61.166 * Added: A connected AI can read the site’s Elementor widgets and their settings, and add, change, duplicate, move and remove Elementor’s own widgets on a page. Each edit follows the site’s approval settings in WPMgr and can be undone. * Changed: Undo restores a page’s data rows in place. * Changed: A site whose Elementor version builds widget settings only in the editor gets a plain explanation that those settings are unavailable. #### 0.61.165 * Added: A connected AI can create a designed Elementor page with sections and ready-made parts: a hero, features, stats, logos, testimonials, pricing, FAQ and a call to action. It uses the colours, fonts, spacing and corner style the AI chooses for it and is saved as a draft. On a block theme, the page fills the screen without the theme’s header and footer. * Added: The AI can edit a designed page: change any part’s text, add or replace sections in the same design, and undo the change. * Changed: Saving a designed page refreshes its stylesheet once and keeps its template and page settings. Undo restores the template and page settings exactly. #### 0.61.164 * Added: Reading the structure of an Elementor draft the AI can edit now also says whether someone has it open in an editor (Elementor or the WordPress editor) or has unsaved changes to it. A published page is not checked, so its status is not reported. The read changes nothing on the site. * Changed: An edit or an undo that is refused because someone has the page open in an editor (Elementor or the WordPress editor) now tells WPMgr it can be tried again once the editor is closed. A refusal for unsaved changes, or for a page that changed since the AI read it, is not marked that way. * Fixed: An edit of an Elementor draft that someone has previewed now goes through. Where Elementor keeps a style record for each page, the site used to count Elementor’s own update of the page’s entry as a change outside the page, refuse the edit and put the page back. A change to any other page’s entry, or to anything else outside the page, still refuses the edit. #### 0.61.163 * Added: An AI connected through WPMgr can now read the structure of a page built in Elementor and edit a draft it created there, in one batch: set text, insert, replace, remove or move elements. Each edit waits for your approval in WPMgr and nothing is published. A published page or post built in Elementor can be read this way too, but never changed. WPMgr needs this version on the site for it. * Added: An edit is refused, and changes nothing, when someone has the page open in Elementor or has unsaved changes to it, when the page changed after the AI read it, when it would remove or replace anything that holds an element the AI cannot edit, or on a site whose database tables cannot roll back a failed change. If Elementor’s save does not leave exactly the approved page, the site puts the page back as it was. * Added: Each edit can be undone from WPMgr, newest first. An undo puts back only what that edit wrote, so later changes such as a featured image stay. The site keeps a copy of the page from before each edit for 15 days and deletes expired copies hourly. * Changed: Undoing an Elementor draft the AI created now also works after the AI has edited it through WPMgr, as long as nobody else has changed it. #### 0.61.162 * Changed: The agent now needs an explicit instruction from WPMgr before it downgrades WordPress core. A core rollback without it is refused and changes nothing. Plugin and theme rollbacks are unchanged. * Changed: A site that disallows file changes no longer gets core updates from WPMgr, the same as WordPress itself. * Fixed: On a site where Composer manages WordPress core, a core update is now skipped and reported as not changing core, with a note to update core in composer. json and redeploy. A core update that fails before any core file is replaced now says core was not changed. After a core update or rollback the agent reports the version installed on disk, where it used to report the old version as up to date. * Fixed: A backup makes up to three attempts at a chunk upload when the storage reports a temporary problem, and waits up to 120 seconds for each. When an upload still fails, the message names the storage host and the status or network error. * Fixed: A site that refuses a signed command now says which check refused it, such as a site clock out of step with WPMgr’s, instead of one general invalid- token answer. * Fixed: Deleting the plugin now removes everything the agent saved under its wpmgr_agent_ option names on that site and, on multisite, in the network settings. A setting whose name differs only in letter case or accents is left alone. * Fixed: A restore that fails after swapping in files or the database keeps what the automatic rollback needs. A restore that has ended keeps none of its run settings. * Fixed: A plugin or theme update is reported as already up to date only when WordPress’s update check covered it. A rejected rollback or update no longer clears maintenance mode another update put in place. A wp-config.php that mentions a framework only in a comment no longer stops the agent adding its constants. Image address rewriting leaves a value with no address to change exactly as it was. * Fixed: The listing, and the Re-enroll and Disconnect text in WordPress admin, no longer say backup archives are encrypted. This plugin does not encrypt them. The privacy section now lists the data AI requests carry. #### 0.61.161 * Added: An AI connected through WPMgr can now create a draft page or post in Elementor from an outline, with your approval for each request in WPMgr. The outline can use headings, paragraphs, lists, quotes, tables, separators, buttons, spacing, sections and columns, and images that are already in the site’s media library. The draft is built from Elementor’s own classic widgets, in containers or in sections and columns, whichever the site’s Elementor is set up for. Nothing is published, and undo moves the draft to the trash while nobody has edited it. * Added: A page built in Elementor this way needs Elementor 3.20 to 4.3. A request for Elementor’s Atomic editor is refused, and so are a button in the outline style and an image whose alt text differs from the one saved in the media library. After Elementor saves the page, WPMgr checks that it holds exactly the approved layout and that nothing outside the page changed, and moves the draft to the trash if not. #### 0.61.160 * Added: An AI connected through WPMgr can now create a draft page or post from an outline with real layout, with your approval for each request in WPMgr. The outline can use headings, paragraphs, lists, quotes, tables and separators, and images that are already in the site’s media library. In the block editor it can also use buttons, spacing, sections and columns. Nothing is published, and undo moves the draft to the trash. * Fixed: When one cache purge starts another, each purge’s report of what it cleared stays separate and accurate. #### 0.61.159 * Added: The agent now includes two read-only facts in the site details it sends to WPMgr: which parent theme a child theme uses and, on a site running Elementor, whether Elementor’s Atomic editor is switched on. It changes nothing on the site. #### 0.61.158 * Added: An AI connected through WPMgr can read the site’s published pages, posts, media, categories and tags through WordPress’s own REST API, as the dedicated WPMgr content user. With per-request approval in WPMgr it can change a page or post title or excerpt, with undo, and it refuses pages whose other content the WPMgr user may not save. * Added: It can use reviewed read tools that other plugins register with the WordPress Abilities API (WordPress 7.1 or later). A read that tries to change settings or contact other servers is refused, and admin-rights changes are put back. #### 0.61.157 * Improved: AI page creation. Page titles and text can contain “&” and bracketed numbers such as [1] and are stored as literal text. A draft left behind by an interrupted AI request can be moved to the trash from WPMgr as long as nobody has edited it. #### 0.61.156 * Added: AI page creation, off by default. When you turn it on for a site from its Content tab, an AI connected through WPMgr can request a new draft page ( headings, paragraphs and lists, in the block editor or the classic editor), and a person approves each request in WPMgr. The page is always created as a draft by a dedicated WPMgr content user that cannot log in, and it can be moved to the trash while nobody has touched it. #### 0.61.155 * Added: a signed command the control plane uses to list the tools (abilities) a site registers, and to run WPMgr’s own read-only abilities: list the site’s abilities, report site facts, and read the text of a published page. It changes nothing on the site. It sends the names, labels and descriptions of registered abilities, with each one’s owner type, site facts (WordPress and PHP versions, theme and active plugin names), and, for a published page without a password that the control plane asks for, that page’s title and text. #### 0.61.154 * Added: a read-only check the control plane can run to see which editor owns each page (the classic editor, the block editor, or a page builder) and whether it is a special page such as the blog index. It changes nothing on the site. It does not send page body text or stored builder data; it sends published page titles, and for a single page, the display name of the last editor and of anyone currently editing it. #### 0.61.153 * Added: the plugin can now carry out a cache purge limited to this site’s own page cache, skipping hosting and CDN cache integrations, and report which detected integrations ran and which were skipped, when the control plane requests it. * Fixed: clearing the cache for a page address that uses a non-default port now targets the same cache entry that page was stored under. #### 0.61.152 * Fixed: the plugin now checks whether each key it has stored still opens under this site’s current encryption key. If some do not, the WordPress admin screen shows a notice naming which keys cannot be read and what to do about it. When the backup key cannot be used, a backup is refused with a clear explanation instead of failing later. Status is reported to the dashboard along with the rest of this site’s metadata. A missing backup key is only created while this site’s own key pair still opens, or on a site with no stored keys yet. #### 0.61.151 * Fixed: a router log line that carries an exception message now escapes control characters, so a command failure is always one readable line in the debug log, instead of one that could break across lines or lose part of its own text. What is sent back to the control plane is unchanged. #### 0.61.150 * Fixed: a command that fails now reports back what broke: the kind of error, where in the plugin it was thrown, and a short reason, instead of a generic failure message. The reason passes through a redactor that removes recognised key material and absolute paths, and is withheld entirely if that cannot be done safely. The same failure is written to this site’s debug log on one line, with recognised key material redacted and the path kept, so a failure can be diagnosed from the dashboard or the log without reproducing it. * Added: a new content-update command can change the title and/or body of an existing post or page by id. It keeps a retained copy of what it overwrites before writing, refuses to touch a document built in the block editor, and requires a fingerprint of the content it expects to replace, so a conflicting write is reported as a conflict rather than silently applied. Nothing in the dashboard uses this yet. #### 0.61.149 * Fixed: restoring a file from media quarantine no longer overwrites a file that has since been recreated at the same path. A file that cannot be put back safely is now left in quarantine and reported with a reason, instead of being removed after a restore that did not happen, so nothing is lost when a restore cannot complete in full. The quarantine folder is now cleared only once every file it recorded has been accounted for and a scan confirms nothing is left behind. * Fixed: every path the page cache reads or writes is now kept inside the cache folder. * Fixed: creating a folder on this site now stays inside the WordPress installation even when the parent folder does not exist yet. * Fixed: the snapshot taken before an update now tells apart “nothing was here before” from “the snapshot could not be taken”. Both previously looked the same to the code that decides whether an automatic rollback is possible, so a rollback could be skipped when it was available, or attempted when there was nothing to restore. A snapshot that could not be completed is also no longer left behind as a partial copy. * Changed: every command this plugin accepts now declares what a successful run does to the site and whether running it again is safe. This is descriptive information for the dashboard’s approval and audit screens; no command behaves differently because of it. #### 0.61.148 * Fixed: this plugin no longer fatals with a white screen on Enroll on a host without the native libsodium PHP extension. A memory-wiping call was made unconditionally, and WordPress’s bundled polyfill throws rather than perform it; every call site now degrades to a best-effort overwrite instead. This affected shared hosting broadly, cPanel and CloudLinux hosts especially, where the plugin installed and activated normally but enrollment could not be completed. * Changed: removed a settings-screen section that asked you to paste a minted connection key into a dashboard flow that was never built. The underlying mechanism is unchanged; only that dead, confusing step is gone. #### 0.61.147 * Fixed: on a multisite network, a plugin activated for the whole network is now reported as active in this site’s metadata. It was reported inactive, so it was missing from the plugin inventory and from everything that reads it, including update and vulnerability checks. * Changed: this plugin is licensed MIT, and now says so consistently on every surface that declares a licence (the plugin header, the mu-plugin headers, this readme, composer.json and the bundled licence file). Some of those previously declared GPLv2 or later. No functional change. #### 0.61.146 * Security: the application-password two-factor control now actually runs. It was registered against a name that is a core WordPress function, not a hook anything fires, so it silently never took effect on any site. Breaking change for integrations: a site with two-factor authentication enabled will have application passwords stop working for a user who has a second factor enrolled or whose role requires one, returning HTTP 401. That is the intended fix. * Fixed: a database restore could silently drop the dump’s last SQL statement while still reporting success, when the restorer could not tell whether the very end of the dump was nothing but comments. It now aborts the restore instead of finishing on an uncertain guess. * Fixed: a database restore could also write straight into this site’s live tables while still reporting success, when the step that stages a restore under a temporary table prefix could not tell which table a statement named. It now aborts the restore instead of guessing, proven end to end against a live database. * Fixed: resending an email could send a different message than the one selected, after this site’s database was restored, because the row id a resend uses is a local auto-increment counter that a restore rolls back. This site now confirms the row before sending and refuses the resend on a mismatch. An older version of this plugin still resends exactly as it always has; it simply cannot be confirmed. * Fixed: the database tools’ orphaned-data scan could fail with a fatal error every time it ran, calling a function that does not exist outside of $wpdb. It now calls the correct one. * Fixed: editing a user’s profile in wp-admin no longer fails with a critical error. WordPress does not always hand this plugin’s hooks the object type they expect on a profile edit, and this plugin assumed one unconditionally. * Fixed: the disk-size probe behind Site Health’s Directory sizes panel, this plugin’s own daily size walk, and every media upload on a multisite network no longer crash when the size cache is cold, which is any fresh install, any cache flush, or the first read after either. * Fixed: a generic, operator-defined user-agent ban could 403 this site’s own login page, with no recovery path, because the ban matched as an unbounded substring with no minimum length or genericity check. The login page (and a hidden login address, if configured) is now exempt, and an overly short or generic pattern is now refused outright. * Fixed: the documented recovery constant for an admin locked out by this plugin’s own auth policy (`WPMGR_DISABLE_SITE_2FA`) now also releases the unique-nickname rule and the automatic login lockout, instead of leaving those two still blocking recovery. #### 0.61.139 * Added: this site now also reports an email delivery failure detected through WordPress’s own mail-failure signal, not only failures on mail this site routes through WPMgr. Sites sending through their own SMTP setup are now covered too. * Added: a detected failure is recorded even when this site’s email log is turned off. That setting controls whether successful sends are kept for review; a failure is recorded regardless, and the recipient, subject, sender and message body are withheld from the record unless email logging is on. * Fixed: `wp_mail()` reported success on a failed send, so a contact form or password reset could tell a visitor the message went out when nothing was delivered. ` wp_mail()` now returns false on a failed send and fires WordPress’s own mail- failure hook, so plugins and themes that check the result learn the truth. #### 0.61.131 * Fixed: sending email from this site could silently stop working days after it had been set up and used successfully, showing as “SMTP Error: Could not authenticate”( GH #380). Saving, testing or syncing this site’s email settings from the dashboard could send an empty password, and the site read that as an instruction to delete the working password it already had. This site no longer deletes a stored password unless the dashboard actually sends a real replacement, and it now refuses an email settings update it cannot make sense of instead of acting on the part it understood. If this site lost its password this way, the dashboard restores it the next time it syncs this site’s email settings, with nothing for you to re- enter. * Security: a password belonging to your dashboard account is no longer sent to a mail server you choose from this site’s own settings page, and a stored password is no longer carried over automatically when you point this site’s email at a different mail server, mailbox user or provider. #### 0.61.127 * Fixed: a password policy can now target the roles the site actually has, not only the five roles a stock WordPress install ships with. On a WooCommerce store the roles that matter are the ones the store added, and a shop manager who can edit orders, refund customers and read every buyer’s address could not be required to hold a strong password, because that role could not be selected. The same applied to membership, LMS and booking plugins, and to roles an agency created by hand. Enforcement was never the problem: the agent has always applied a policy to whatever role a user really holds. What was missing was any way to write the rule. Role names now also read the way they read on the site itself, in the site’s own language, while the rule stays bound to the underlying role identifier, so renaming or translating a role never changes who it covers. #### 0.61.114 * Fixed: two updates could be dispatched to the same site at once, for example two plugins in one bulk run, or an update and a rollback overlapping, which ran more than one WordPress installer against the same site at the same time (GH # 328). A second installer can delete files the first one is still using. Updates and rollbacks on a single site now run strictly one at a time. * Fixed: when an update fails before it has touched anything on the site, for example a corrupted download, the site no longer runs an automatic restore over a plugin or theme directory it never modified. #### 0.61.112 * Fixed: outgoing email failed completely whenever a plugin set a Reply-To header in the ordinary “Name [email@example.com](https://ky.wordpress.org/plugins/fleet-agent-site-manager/email@example.com?output_format=md)” form, which WooCommerce, Fluent Forms and many others do by default (GH #312). The whole string, display name included, was handed to the mail transport as if it were the address; the transport rejected it, and one bad address aborted the entire message, so nothing was sent. Addresses are now parsed properly wherever a bare address is required, the display name is kept, and a single bad address costs that one recipient instead of the whole email. The same defect applied to To, Cc and Bcc on the SMTP and SendGrid providers, including headers carrying more than one address. #### 0.61.95 * Fixed: a failed backup left its working files behind on the site (GH #256). One reported site was holding roughly 1.4 GB of upload parts, copied plugins and themes, and a database dump. All four paths that can give up on a backup now reclaim that working directory, and each one takes the same lock a live backup holds before deleting anything, so a backup that is merely slow is never touched. The routine cleanup of old working directories and of leftover restore files no longer depends on WP-Cron, so it also runs on a site where WP-Cron never fires. #### 0.61.87 * Fixed: an interrupted backup now resumes cleanly instead of failing on a missing local chunk (GH #283). The agent deleted each chunk from local disk right after uploading it but only recorded its progress once the whole upload finished, so a worker stopped partway through resumed, was correctly told to send chunks it had already uploaded and deleted, then failed looking for them. Upload progress is now recorded durably as it goes, and no local chunk is deleted until that progress is safely persisted. #### 0.61.85 * Fixed: full backups on slow servers no longer fail at the upload stage (GH #279). A large backup could go quiet during the archiving stage for long enough that the control plane wrongly marked it failed while it was still working. The agent now sends progress heartbeats during long archive and encryption passes, reports the exact control-plane status when a callback is rejected, and removes its local working files when a run ends in failure. #### 0.61.84 * Fixed: backups no longer time out on OpenLiteSpeed and LiteSpeed servers (GH # 274). The agent acknowledges a backup request and continues the work in the background; it previously released that acknowledgment using a PHP-FPM-only mechanism, which OpenLiteSpeed’s PHP does not provide, so the connection stayed open for the entire backup. The agent now releases the acknowledgment using whichever mechanism the site’s server actually supports. #### 0.61.82 * Fixed: the “disable file editor” hardening toggle could fatal every request on a Roots/Bedrock site (GH #268). Roots/Bedrock manages that constant through its own config layer and throws when it is defined a second time; the agent now checks whether it is already defined (or the config file is otherwise framework-managed) before writing anything, so nothing is written in that case and the toggle still reports success. Standard WordPress installs are unaffected. The full-page cache’s WP_CACHE constant is protected the same way. #### 0.61.81 * Fixed: control-plane commands could fail on sites running a third-party plugin that globally decodes the Authorization header on every request, for example as part of its own JWT-based auth (GH #269). The agent now moves its own signed Authorization value out of the request before any other plugin’s code runs, so this class of conflict can no longer occur. #### 0.61.80 * Changed: the WordPress.org distribution build no longer adjusts WordPress’s own upgrader working-directory handling during a plugin, theme, or core update. Self- hosted installs are unaffected. * Fixed: reworded a documentation comment in the file-manager write guard that quoted an example attack payload verbatim, so security scanners no longer report a false-positive match on the plugin’s own file (GH #266). No behavior changed. #### 0.61.79 * Fixed: on a site installed from a plain git clone or a GitHub source download( no `composer install` run), activating the plugin could fail immediately with a fatal error (GH #262). The plugin’s own class loader could not find a handful of its own files; it now resolves every one of them without depending on any other tool being present. #### 0.61.78 * Fixed: the plugin could fail to set up its encryption key on some managed hosts( for example Hostinger and other CloudLinux/CageFS hosts), leaving it active but unable to connect (GH #257). It now tolerates a wp-config.php with missing or partial secret salts, tries the uploads folder as an additional fallback file location, and as a last resort can store a dedicated encryption key in the database when no file location is writable. Key setup is now safe against two requests racing to set it up at the same time and against a write interrupted partway through. Already-connected sites are unaffected. ## Мета * Нуска **0.61.166** * Акыркы жаңыртуу **2 күн мурун** * Активдүү орнотуулар **100+** * WordPress нускасы ** 6.2 же андан жогору ** * Tested up to **7.1.3** * PHP нускасы ** 8.1 же андан жогору ** * Тил * [English (US)](https://wordpress.org/plugins/fleet-agent-site-manager/) * Тег: * [backup](https://ky.wordpress.org/plugins/tags/backup/)[performance](https://ky.wordpress.org/plugins/tags/performance/) [security](https://ky.wordpress.org/plugins/tags/security/)[site management](https://ky.wordpress.org/plugins/tags/site-management/) [updates](https://ky.wordpress.org/plugins/tags/updates/) * [Advanced View](https://ky.wordpress.org/plugins/fleet-agent-site-manager/advanced/) ## Рейтинг 5 out of 5 stars. * [ 2 5-star reviews ](https://wordpress.org/support/plugin/fleet-agent-site-manager/reviews/?filter=5) * [ 0 4-star reviews ](https://wordpress.org/support/plugin/fleet-agent-site-manager/reviews/?filter=4) * [ 0 3-star reviews ](https://wordpress.org/support/plugin/fleet-agent-site-manager/reviews/?filter=3) * [ 0 2-star reviews ](https://wordpress.org/support/plugin/fleet-agent-site-manager/reviews/?filter=2) * [ 0 1-star reviews ](https://wordpress.org/support/plugin/fleet-agent-site-manager/reviews/?filter=1) [Your review](https://wordpress.org/support/plugin/fleet-agent-site-manager/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/fleet-agent-site-manager/reviews/) ## Мүчөлөрү * [ Mosamlife ](https://profiles.wordpress.org/mosamlife/) ## Колдоо Комментарийлер барбы? Жардам керекпи? [Колдоо форумун көрүү](https://wordpress.org/support/plugin/fleet-agent-site-manager/)