{
  "name": "Manifest Updater",
  "slug": "manifest-updater",
  "version": "1.1.1",
  "download_url": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/manifest-updater/manifest-updater-1.1.1.zip",
  "homepage": "https://gitea.mulligan.casa/mmulligan/manifest-updater",
  "requires": "6.1",
  "tested": "7.0",
  "requires_php": "8.1",
  "last_updated": "2026-06-23 19:02:05",
  "icons": {
    "1x": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/manifest-updater/icon-128x128.png",
    "2x": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/manifest-updater/icon-256x256.png"
  },
  "author": "Mike Mulligan",
  "author_homepage": "https://gitea.mulligan.casa/mmulligan",
  "tags": [
    "updates",
    "plugin updates",
    "theme updates",
    "self-hosted",
    "update uri"
  ],
  "sections": {
    "description": "<p>A tiny, universal, self-hosted updater for <strong>plugins and themes</strong>. Network-activate it once; any project that opts in via its <code>Update URI</code> header gets WordPress-native update notifications, \"View details\", and one-click / auto updates — network-wide, with no per-project updater code and no tokens.</p>\n<p>It's \"Git Updater meets PUC,\" but thin: WordPress already does the hard part (scanning every installed project's header, routing by host, building the update transient, rendering the row, running the install). This plugin only supplies the piece core can't — reading <em>your</em> JSON manifest and returning the update.</p>\n<p><strong>Opt in — the <code>#</code> fragment is the trigger.</strong> Append a fragment to the project's <code>Update URI</code> header; the fragment is the only trigger (paths are never sniffed), so it can't collide with a project that updates some other way:</p>\n<ul>\n<li><code>Update URI: https://your-host/path/my-plugin.json#manifest-updater.json</code> — a plugin.</li>\n<li><code>Update URI: https://your-host/path/my-theme.json#manifest-updater.json</code> — a theme (in <code>style.css</code>).</li>\n</ul>\n<p>The part before <code>#</code> is the manifest URL; <code>#manifest-updater.json</code> opts the project in and selects JSON-manifest mode. The <code>Update URI</code> header also earns the project automatic protection from being overwritten by a same-named wordpress.org plugin or theme — for free, from core.</p>\n<p><strong>Network-wide, so everything else can be site-active.</strong> <code>get_plugins()</code> / <code>wp_get_themes()</code> return every installed project regardless of activation, and the update transients are network-level on multisite — so updates surface and install network-wide while the projects themselves stay site-active, network-active, or inactive. Only Manifest Updater needs to be network-active.</p>\n<p><strong>Same-origin image proxy.</strong> Icons and banners are re-served from your own site, so the browser never makes a cross-origin request to the update host — which sidesteps Private Network Access blocks, NAT hairpin, CORS, and service workers that otherwise leave the icon blank on the Updates screen.</p>",
    "installation": "<ol>\n<li>Upload to <code>wp-content/plugins/</code> and <strong>Network Activate</strong> it (it is <code>Network: true</code>).</li>\n<li>Give each project you want updated an <code>Update URI</code> header ending in <code>#manifest-updater.json</code>, pointing at its JSON manifest.</li>\n<li>That's it — updates appear on the normal Plugins / Updates screens, network-wide.</li>\n</ol>",
    "faq": "<p><strong>Does the project have to be network-active to get updates?</strong></p>\n<p>No. Only Manifest Updater is network-active. Opted-in projects can be site-active, network-active, or inactive and still receive updates.</p>\n<p><strong>Where do manifests come from?</strong></p>\n<p>Any URL you control, returning the PUC (\"Plugin Update Checker\") JSON format. Only <code>version</code> and <code>download_url</code> are required; everything else enriches the row and the details modal. Manifests are cached in a network site-transient for 12h; the Updates screen's \"Check again\" busts the cache.</p>",
    "changelog": "<p><strong>1.1.1</strong><br />\n* \"View details\" sections now come from readme.txt (the WP-native source) rather than README.md; changelog version markers render bold (no clear:both modal gap); base/config renamed to .mu-manifest.yaml + .mu-release.yaml.</p>\n<p><strong>1.1.0</strong><br />\n* Same-origin image proxy for plugin/theme icons + banners — fetched server-side, re-served from this site, so cross-origin/private-network/CORS/service-worker hurdles never blank the icon. SSRF-contained (same host as the manifest, no redirects), raster-only, content-type allow-listed, cached, size-capped.<br />\n* <code>tags</code> passed through to the \"View details\" modal sidebar.<br />\n* Self-hosting via the shared update channel + a reusable release pipeline (<code>.ci/</code>) mirrored to the channel on release.</p>\n<p><strong>1.0.0</strong><br />\n* Initial release: network-wide self-hosted updates for plugins and themes via the <code>Update URI</code> header + a <code>#manifest-updater.json</code> fragment. Full PUC manifest field support, 12h manifest cache, self-update.</p>"
  }
}