Siteward Child
| 开发者 | omniswp |
|---|---|
| 更新时间 | 2026年11月3日 05:12 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
- Signed, replay-protected REST endpoint (verified against your dashboard's public key).
- Reports core, plugin and theme updates.
- Reports UpdraftPlus backup history and status.
- Reports basic site health (WP-Cron, load).
- Safe updates: keeps the previous version of each plugin or theme your dashboard updates for 7 days, and puts it back automatically if the update breaks the site. You can also roll back yourself under Settings, Siteward Connection, Rollback.
- Applies updates and, for fleet plugin management, activates, deactivates or uninstalls plugins, but only when instructed by your signed, paired dashboard.
- Known vulnerabilities: when your dashboard finds a plugin on this site with a known vulnerability, a warning row appears under that plugin on the Plugins screen, with the version that fixes it. Only people who can update plugins see it, and your dashboard can switch it off.
安装:
- Upload the
siteward-childfolder to/wp-content/plugins/, or install it from the Plugins screen. - Activate the plugin through the Plugins screen.
- Go to Settings → Siteward Connection, copy the site's REST URL and its one-time connection key, and paste them into your Siteward dashboard's Add Site screen.
常见问题:
Does this plugin do anything by itself?
It only acts on requests from a paired Siteward after a secure handshake. The one exception is a daily clean-up that deletes saved previous versions older than 7 days, and that only runs while there are some to delete.
What does it store on my site?
The pairing details (the dashboard's public key and address) in the options table. When the dashboard updates a plugin or theme, the version being replaced is saved as a zip file in a folder with a random name inside your uploads folder, and listed under Settings, Siteward Connection, Rollback. Each is deleted after 7 days, or replaced at that item's next update. Very large items (over 300 MB) and sites without PHP's zip extension are updated without a saved copy. Deleting the plugin removes the folder and its settings.
Can the dashboard roll back an update?
Yes. A paired dashboard can list the saved previous versions and roll one back over the same signed connection, which restores the copy saved on this site and checks the site afterwards. Nothing is downloaded. The site's administrators can do the same under Settings, Siteward Connection, Rollback.
How does safe updating decide an update broke the site?
Before and after each update it loads this site's own homepage and admin-ajax.php, as a logged-out visitor would. If the homepage or admin area starts returning a server error, the homepage shows WordPress's critical error page, or the updated plugin can no longer be activated, the previous version is put back straight away and the dashboard is told why. These checks only ever go to this site. If the site was already showing errors before the update, or cannot load its own pages, nothing is rolled back and the dashboard is told. WordPress core updates are not covered (WordPress restores a failed core update itself). A rollback puts the previous files back; changes an update made to the database are not undone. Plugins that contain symbolic links are updated without a saved copy.
Where do the vulnerability warnings come from?
From your paired dashboard. It matches this site's plugins against the vulnerability data it already downloads (built from the Wordfence Intelligence database by Defiant, Inc.) and hands the matches to this site during its regular status check. This plugin fetches nothing itself. The list is stored in one option and removed when the plugin is deleted. A warning shows only while the plugin is still on the version that was checked, so updating it clears the warning straight away. Wordfence terms: https://www.wordfence.com/wordfence-intelligence-terms-and-conditions/
Is the connection secure?
Yes. Every request is verified against the dashboard's stored public key, with timestamp and nonce replay protection.
Why does the dashboard ask this site to check for updates?
Premium plugins only report an update when their licence is active at the moment WordPress checks, and that check is cached for hours. When you press "Check for updates" on the dashboard, this plugin asks every licence server again straight away, so a licence you have just renewed is picked up without waiting for the cache to expire.
How do I disconnect?
Disconnect the site from the dashboard, or deactivate this plugin. The stored public key is removed on disconnect.
Can the dashboard manage plugins on my site?
Yes, once paired, your Siteward dashboard can activate, deactivate or permanently uninstall plugins on this site, but only over the cryptographically-signed connection (every request is verified against the stored dashboard public key, with timestamp and nonce replay protection). This plugin does not install new plugins from uploaded packages; uninstalls permanently delete an existing plugin's files. This plugin never contacts any other server.
更新日志:
- New: known-vulnerability warnings on the Plugins screen. When your dashboard (Siteward 0.17.1 or later) finds a plugin on this site with a known vulnerability, a row under that plugin says so, with how serious it is and the version that fixes it. Only people who can update plugins see it, it disappears as soon as the plugin is updated, and the dashboard can switch it off. The data comes from your dashboard; this plugin still contacts no other server.
- New: safe updates. Before your dashboard updates a plugin or theme, the current version is saved. After the update the site checks its own homepage and admin area, and if the update broke the site (a server error, WordPress's critical error page, or a plugin that can no longer be activated), the previous version is put back automatically and the dashboard is told why. A plain server error is checked again a few times over about 25 seconds before anything is undone, so a slow or busy host catching up after an update is not mistaken for a broken site; WordPress's critical error page still triggers a rollback straight away.
- New: Rollback tab under Settings, Siteward Connection. Lists the previous versions saved in the last 7 days, with a button to roll back to any of them. A paired dashboard can list and roll back the same saved versions remotely.
- Saved versions are zip files in a randomly named folder inside uploads, deleted after 7 days or at the item's next update, and removed when the plugin is deleted.
- Safety: the dashboard can no longer deactivate or uninstall Siteward Child itself (or Siteward Advanced Child) through plugin actions, which would cut the site off from the dashboard and, for an uninstall, delete the pairing.
- Fix: uninstalling a plugin from the dashboard now runs its own deactivation cleanup before its files are deleted, so a security plugin can remove its firewall setting first.
- Fix (multisite): a subsite no longer deactivates a network-active plugin for the whole network, and plugins are not deleted from a single subsite, since their files are shared. Both are left for Network Admin.
- Security: each signed request's single-use code is now claimed in one atomic database write, so two copies of the same request arriving at the same moment can no longer both be accepted.
- Security: the account Siteward Advanced Child's AI access runs as can never sign in (password, cookie, application password or one-click login), in either edition, and loses its role if AI access is removed. Uninstalling removes it, with AI access's settings, log and backups.
- New: a Settings link on the Plugins screen, straight to Settings, Siteward Connection.
- Fix: the Siteward logo on the Siteward Connection page is now a crisp vector image, instead of a text character that looked thin and fuzzy on some screens.
- Change: the Siteward Connection page can show more than one tab, for editions that add a screen of their own. Nothing changes on this plugin's page.
- Change: the connection page is slightly wider.
- Fix: "Sync now" could time out on sites behind a CDN or reverse proxy such as Cloudflare. The health check ran WordPress's REST API availability test, which calls the site back through its own public address and can hang for 10 seconds when the server cannot reach itself that way. That test is now skipped, as WordPress itself does for scheduled checks, which also removes a false "REST API encountered an unexpected result" warning it reported on every site.
- New: theme update checks now run in the same simulated admin context that plugin checks already used, so a licensed theme such as Divi can report its update to the dashboard instead of only showing it to someone who happens to open the site's own admin.
- Fix: "Check for updates" was deleting the pending update for licensed themes such as Divi instead of finding it. The check clears the theme update list before rebuilding it, and a background request can only rebuild the WordPress.org part, so the one button you would press when a theme update is missing was the thing removing it.
- Fix: activating, deactivating, uninstalling or updating any plugin no longer discards the pending updates for every other plugin on the site. WordPress clears its whole update list whenever the plugin list changes, which for plugins sold with a licence means an update that cannot be found again from a background check. Updating one plugin could quietly hide a real update for another.
- Fix: theme updates now get the same protection as plugin updates. A licensed theme's update was being discarded by the routine check in exactly the same way.
- Fix: updates for licensed plugins such as Perfmatters and ACF Pro no longer disappear from the dashboard. Plugins sold with a licence register their update checker only during an admin request, so the routine check, which runs over the REST endpoint, rebuilt the list from WordPress.org alone and deleted the entry the site had already learned about. An update could show on the dashboard, install correctly, and then vanish for no visible reason. A pending update is now kept unless the plugin has been removed or the version on disk shows it was actually applied.
- New: answers a "check for updates" request from the dashboard by asking every licence server again, ignoring the usual throttle. Premium plugins whose licence was just renewed can otherwise keep reporting no update until their cached answer expires.
- New: reports the installed theme list to the dashboard, so theme vulnerabilities can be matched as well as plugin ones. Read-only, like the rest of the reporting.
- Reports this site's server IP address to its paired dashboard, so the dashboard can group sites that share a server. Nothing is sent anywhere else; the dashboard still initiates every request.
- Critical fix: 0.7.1 could stop itself on load, leaving the site with no connection to its dashboard, no settings page, and a notice that could not be dismissed. This affected normal single installs, not only sites with two editions. Updating to 0.7.2 restores the connection and the settings page automatically; no action is needed on your part.
- Fix: deleting this plugin no longer removes the stored connection when another edition of Siteward Child is still active on the site and using it. Previously that silently unpaired the site from its dashboard.
- Housekeeping: uninstall now also removes the update-snapshot option it creates.
- The plugin inventory response now reports which edition is installed, so a dashboard sees a switch between editions straight away instead of at the next scheduled sync.
- Removed installing plugins from a dashboard-uploaded package, for WordPress.org guideline compliance. This plugin now only updates, activates, deactivates and uninstalls existing plugins. Dashboard-driven installation of new plugins is available in the separately-distributed Siteward Advanced Child.
- Housekeeping: internal option and transient names now share the plugin's prefix.
- Housekeeping: the direct filesystem method is now forced only during install and uninstall (the actions that write to disk), not on read-only actions like inventory, activate or deactivate.
- Removed the install-from-URL option for WordPress.org guideline compliance. Plugins are now installed only from a ZIP package your dashboard uploads. Updating, activating, deactivating and uninstalling are unchanged.
- Premium/licensed plugin updates (for example Perfmatters or ACF Pro) now show as available on every managed site, not only ones an administrator has recently opened. The status sync and fleet inventory run the same admin-context update check as the apply path, throttled so routine syncs do not hammer licence servers.
- Fix: updating a premium/licensed plugin (for example Perfmatters or ACF Pro) from the dashboard could report "the plugin is at the latest version" and skip the update. Such plugins only publish their update during an admin-context check; the child now forces a genuine, throttle-bypassing update check so the licensed updater runs and the update installs.
- Fleet plugin management: signed actions to inventory, activate, deactivate, uninstall and install (from an uploaded ZIP) plugins from the dashboard. Every slug is traversal-guarded.
- Hardening: constrain update/reactivate targets to installed plugins/themes (validate_file + membership checks); restrict the auto-login redirect to a known allow-list of admin screens.
- Update reliability: keep active plugins active through updates (define DOING_CRON so core never deactivates mid-update), snapshot/restore the active set with a shutdown reconciler, and dependency-order reactivation so WooCommerce and its extensions come back together.
- Fix: plugins could be left deactivated after an update in unattended runs.
- Public release.