Repository navigation
FAQ
No. The host embeds a pinned version. Use the host plugin’s normal installation and update steps.
No. Public repositories remain unauthenticated. Only configured private repositories need credentials.
Yes. The host must enable private mode and provision a repository-bound provider. A fine-grained PAT with Contents read and Metadata read supports the tested release and archive endpoints.
No. It supports the normal WordPress update engine. Automatic-update preferences remain with WordPress and the host.
Yes, with guarded loading. The first loaded class wins; check the private/translation capabilities and coordinate deployed versions.
No. Updater strings are merged into the host’s catalogs and translated through a host callback.
Private downloads are rejected even if metadata is still cached. A rejected download does not replace the installed plugin; activation behavior remains the responsibility of the calling host workflow.
Successful metadata is cached for 30 minutes, failures for 10 minutes. WordPress schedules checks; manual refresh and the host’s cache invalidation can trigger another lookup.
The engine uses the release’s repository source archive when valid. The host must still validate the archive as an installable plugin.
The engine checks the main file and normalizes directories. Full identity, offered version and platform checks are host responsibilities, including the special Core bulk context.
In protected installation configuration, read by the provider at request time. It must not be embedded in plugin files, public repositories, ZIPs, URLs or metadata.
No. Catalog discovery and installed-plugin updates are separate responsibilities. A Library catalog display cache must not dictate the host updater’s refresh interval.
Repository · Copyright © 2026 David Decker — DECKERWEB · GPL-2.0-or-later