Skip to content

feat(logging): add WP Engine Updater client - #862

Draft
josephfusco wants to merge 5 commits into
mainfrom
feat/logging-wpe-updater
Draft

josephfusco wants to merge 5 commits into
mainfrom
feat/logging-wpe-updater

Conversation

@josephfusco

@josephfusco josephfusco commented Oct 30, 2026 •

Copy link
Copy Markdown
Member

Adds the WP Engine Updater client so sites installed from the release zip get plugin updates in wp-admin. It does nothing until the wpgraphql-logging slug and its info.json are published to the updater service.

Part of #446

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Assisting with porting the WP Engine updater client.

Port FaustWP's plugin updater into WPGraphQL Logging as
WPGraphQL\Logging\Updates\PluginUpdater and run it on admin_init with
the wpgraphql-logging slug. Point the Update URI header at
wpe-plugin-updates.wpengine.com so WordPress.org never offers updates
for this plugin.
@josephfusco josephfusco added [Type] Task Maintenance, upkeep, and other non-functional work [Area] Logging Issues for the WPGraphQL Logging plugin labels Oct 30, 2026
@josephfusco josephfusco added this to the WPGraphQL Logging Plugin milestone Oct 30, 2026
@github-actions

github-actions Bot commented Oct 30, 2026 •

Copy link
Copy Markdown
Contributor

📦 Plugin Artifacts Ready!

Download from GitHub Actions run

Available plugins:

  • ✅ wpgraphql-logging.zip

See the "Artifacts" section at the bottom of the Actions run page

Review against FaustWP and core's wp_update_plugins():

- Stop writing the remote version into $transient->checked. Core compares
  it with the installed version, so a pending update made every check look
  like a changed plugin and hit api.wordpress.org on each Plugins screen load.
- Report the plugin in no_update when it is current so core can offer
  auto-updates, and remove it from the other list.
- Only cache manifests that decode and validate. A 200 with a bad body was
  cached for five hours and blocked updates.
- Keep the fetched manifest (or failure) for the request. Core saves the
  transient twice per check, which meant two 10s requests when the API was down.
- Look up the installed version lazily instead of calling get_plugins() on
  every admin_init, including admin-ajax.
- Make check_for_updates() idempotent and also run it on the wp_update_plugins
  and wp_maybe_auto_update cron actions, which never fire admin_init, so cron
  checks and auto-updates see the plugin.
- Sanitize manifest fields (text, key, URL, kses for sections) and guard
  against non-scalar values.
Running PHPStan at max level on the updater showed manifest fields were
still read as mixed after validation. Decode the manifest once into an
array of sanitized strings, then have the transient and plugins_api code
read from that array instead of from the raw stdClass. Also guard the
cached expiry and the installed version against non-scalar values.

New wpunit coverage:
- the cron hooks
- check_for_updates() idempotency and unregister()
- one request per page load after a failure
- refetching an invalid cached body and skipping the request on a valid cache
- rejecting non-HTTP download links and non-scalar fields
- sanitized names, sections and optional fields
- moving the plugin between response and no_update
- the filters running through set_site_transient() and plugins_api()
- Add an Updates section and the src/Updates entry to the plugin docs:
  where updates come from, the five-hour cache, and how Composer-managed
  sites should keep updating.
- Drop the redundant trailingslashit() calls when building the manifest URL.
- Share the option names, manifest URL and plugins_api arguments across the
  updater tests instead of repeating the literals.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The updater rejects plugin-detail requests for renamed installations and retains an outdated installed version after upgrades, causing incorrect WordPress.org fallbacks and stale update notifications.

2 open issues
What changed in this PR

Adds a WP Engine updater client so release-zip installations of WPGraphQL Logging can receive updates through wp-admin once the plugin manifest is published.

Changes:

  • Updates the plugin’s Update URI and registers updater hooks for admin and background update checks.
  • Adds manifest fetching, validation, caching, and WordPress update metadata mapping.
  • Adds updater tests and documents update behavior, including guidance for Composer installations.
File Description
plugins/​wpgraphql-logging/​wpgraphql-logging.php Sets the update service URI and registers updater hooks.
plugins/​wpgraphql-logging/​tests/​wpunit/​Updates/​PluginUpdaterTest.php Tests registration, caching, failures, metadata, and update integration.
plugins/​wpgraphql-logging/​src/​Updates/​PluginUpdater.php Implements the WP Engine updater client.
docs/​plugins/​wpgraphql-logging/​index.md Documents the updater structure and usage.

Review effort: Balanced

return $res;
}

if ( ! is_object( $args ) || ! isset( $args->slug ) || $this->plugin_dirname !== $args->slug ) {
Comment on lines +236 to +247
if ( null !== $this->plugin_version ) {
return $this->plugin_version;
}

if ( ! function_exists( 'get_plugins' ) ) {
require_once ABSPATH . 'wp-admin/includes/plugin.php';
}

$version = get_plugins()[ $this->plugin_basename ]['Version'] ?? '';
$this->plugin_version = is_string( $version ) ? $version : '';

return $this->plugin_version;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Area] Logging Issues for the WPGraphQL Logging plugin [Type] Task Maintenance, upkeep, and other non-functional work

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants