WPSDK/wp-update-server-plugin
0
0
Fork 0
mirror of https://gh.wpcy.net/https://github.com/superdav42/wp-update-server-plugin.git synced 2026-04-29 10:43:22 +08:00
Code Issues Projects Releases Packages Activity Actions
Enable automatic updates for WordPress plugins sold as Woocommerce downloadable products
44 commits 5 branches 0 tags 917 KiB
Find a file
Exact
David Stone b41875662a feat(paypal): add comprehensive logging to PayPal Connect proxy 
Previously only the deauthorize endpoint logged anything. All other
endpoints (oauth/init, oauth/verify, partner-token) were silent, making
it impossible to debug failed PayPal API calls in production.

This commit adds:
- Protected log() helper with consistent '[PayPal Connect]' prefix and
  JSON-encoded context data
- get_debug_id() helper to extract the PayPal-Debug-Id response header
  from every PayPal API call (the key value PayPal support and the
  integration review team ask for by name)
- Request-received and outcome log entries on all handlers
- Error logging with PayPal-Debug-Id on all failed PayPal API calls:
  - /v1/oauth2/token (partner access token)
  - /v2/customer/partner-referrals
  - /v1/customer/partners/{partner_id}/merchant-integrations/{merchant_id}
- Success logging with debug ID and key response fields

Sensitive values (access tokens, client secrets) are never logged.

Context: the PayPal integration review requires debug IDs from test
API calls. Without server-side logging, the only way to get them was
to instrument the plugin side, which misses proxy-side failures entirely.
2026-04-08 14:38:14 -06:00
assets feat: dashboard overhaul with Chart.js charts, KPI cards, and unified analytics view (#15) 2026-03-27 20:00:33 -06:00
inc feat(paypal): add comprehensive logging to PayPal Connect proxy 2026-04-08 14:38:14 -06:00
templates update 2026-02-02 09:17:58 -07:00
vendor update autoloader 2026-01-23 10:57:23 -07:00
.gitignore chore: add .agents/loop-state/ to .gitignore 2026-03-25 23:57:01 -06:00
AGENTS.md chore: add wp-cli.yml and local dev environment docs 2026-04-06 21:16:44 -06:00
composer.json chore: rename composer package from devstone/wp-update-server-plugin to ultimate-multisite/ultimate-update-server-plugin 2026-03-23 17:14:20 -06:00
composer.lock update autoloader 2026-01-23 10:57:23 -07:00
LICENSE Initial Commit 2025-05-25 16:31:44 -06:00
README.md feat: add site discovery to scrape subsites and network health from discovered domains (#10) 2026-03-27 13:16:53 -06:00
wp-cli.yml chore: add wp-cli.yml and local dev environment docs 2026-04-06 21:16:44 -06:00
wp-update-server-plugin.php feat: add Stripe Connect transaction analytics and revenue dashboard (#12) 2026-03-27 13:57:37 -06:00

README.md

WP Update Server Plugin

This project creates an update server to enable automatic updates for WordPress plugins which are Woocommerce downloadable products.

Requires

Features

Telemetry Dashboard

Opt-in telemetry from Ultimate Multisite installations. Tracks PHP/WP/plugin versions, network types, active addons, and error reports.

Site Discovery (Network Health)

Background scraper that discovers network health signals from domains found via passive install tracking. Runs daily via WP-Cron and processes up to 20 domains per batch.

What it detects:

  • Whether the site is live (HTTP 2xx)
  • Whether it is a production domain (not staging/dev/local)
  • SSL/HTTPS availability
  • Presence of a checkout or registration page (UM shortcodes/blocks)
  • Estimated subsite count (subdirectory path probing + HTML signals)
  • Network type: subdomain vs subdirectory
  • Ultimate Multisite version (from asset URLs or meta tags)

Health score (0–100):

Signal Points
Site is live +20
Production domain +15
Has SSL +10
Has checkout page +15
Detected subsites > 5 +20
Detected subsites > 50 +10
UM version fingerprinted +10

Privacy and ethics:

  • Only scrapes publicly accessible pages (homepage, /register/)
  • Respects robots.txt — skips sites that disallow UltimateMultisiteBot
  • User-Agent: UltimateMultisiteBot/1.0 (+https://ultimatemultisite.com/bot)
  • 10-second timeout per request; unresponsive sites are marked failed and retried next run
  • Stores only aggregate signals, not page content

Dashboard answers:

  • How many production networks have 10+ subsites?
  • How many networks have a checkout page (are selling to customers)?
  • Distribution of health scores across all discovered domains