[mostafasoufi]

Found in a fresh-install test of the connect flow. Pairs with monoranks/monoranks#302 (sign-up and sign-in screens from the plugin; the "Allow" link below works best with its sign-in redirect on the approve step). Not merged, not tagged, not released: for local review first.

Changes

1. After activation the next admin page is MonoRanks → Settings (Overview when already connected): once, for the user who activated it, only for single-site, single activation from the Plugins screen. No redirect on bulk activation, network activation, WP-CLI, AJAX, or for users without manage_options (activated_plugin + transient). The Plugins row gets Connect while not connected, Settings after.
2. Honest fixes status. Settings::data() now reports whether a MonoRanks Application Password exists for any admin (matched by MonoRanks' app id, or the name "MonoRanks" for old ones; the current user first). Only then: "Fixes written with: App password · Revoke" (Revoke goes to the right user's profile). Otherwise: "Fixes: Not set up · Allow". Allow goes to MonoRanks' approve step for this website (/api/wordpress/start?site=…&wp=…&connect=1&return=…&state=…), which opens WordPress's own approve screen and comes back to Settings. The connect page would only say "Already connected" for a site connected by code or key. Hidden when Application Passwords are off.
3. Quieter first load of "What to do next". After one failed or slow pull the cards show a muted "Checking…", not "MonoRanks could not be reached. The plugin tries again within the hour." The first pull (no cache yet) gets 10 s per request and a 20 s budget (was 5/12). Failed pulls retry after 2 min, then 10 min, then hourly (fails counter in the cache), through one scheduled WP-Cron event, plus the existing lock, so MonoRanks is not hammered. The screen re-asks the plugin up to 4 times, a minute apart, while a card is checking. After repeated failures: "Could not reach MonoRanks. Retrying soon."
4. Paste-key button: Save key (was a second "Connect").
5. A stale or reused connect link no longer shows "Could not connect. Please try again." above "Connected".
6. Connect opens in the same tab (target="_self", Settings and Overview), so the return lands in the same tab. The visibilitychange/poll refresh is kept for people who open it in a new tab anyway.

Version 0.1.25 in the header, constant, readme Stable tag and both changelogs (owner style). New strings translated in fa_IR; languages/ rebuilt with bin/i18n.sh; build/ rebuilt with npm run build.

WordPress.org readme deploy on merge

readme.txt changes, so .github/workflows/assets.yml will run on merge to main, but its guard step checks gh release view v<Stable tag>. Stable tag is now 0.1.25, which has no release yet (latest is v0.1.24), so the step sets ok=no and the asset update step is skipped. The readme goes to WordPress.org only with the v0.1.25 release (deploy.yml).

Tests

• Unit: vendor/bin/phpunit: 129 tests OK. New: activation redirect (set, skipped for other plugins, network, bulk, multisite, non-admins, AJAX; used once, same user only), row link, hidden contradiction notice, app password detection (app id, name, other admin, revoke link), Allow URL, Grow retry backoff, fails counter, scheduled retry, first failure reads as "pending", longer first-pull timeout.
• Integration (real WordPress): phpunit -c phpunit-integration.xml.dist --exclude-group tsf,yoast: 13 OK, incl. new AppPasswordTest (real Application Passwords, another admin's password counts, other apps don't).
• npm run typecheck, npm run build (bundle committed).
• e2e spec updated: "Save key" button; new check for the Plugins row link and Connect target=_self.

Local end-to-end (headless, fresh WordPress on :8091, app branch on :3200)

Activation → Settings, row shows "Connect | Deactivate"; Connect stays in the same tab; sign-up shows "Connect localhost"; switch to sign-in works; (a) one-time-code path → "Fixes: Not set up · Allow"; Allow → WordPress "Yes, I approve" → back to Settings with "Fixes written with: App password · Revoke"; (b) direct approve from a new account → same truthful status; no "Could not connect" after a stale link; first Overview load with failing reads shows "Checking…".

[mostafasoufi]

Follow-up commit fae8aa2:

• Pairing (direct approve) starts the first content send in WP-Cron right away; it no longer waits for MonoRanks' background job. Fixes "Content: Not sent yet" after connecting.
• Overview Content row: "Sending…" while the first send runs; "Not sent. Use "Sync content now"." only after a failed send.
• /ping now reports connected (whether the plugin holds a key). monoranks/monoranks#302 uses it to offer Connect again after a Disconnect here (Disconnect already tells MonoRanks via /api/connector/disconnect).
• New integration tests (ConnectFlowTest): ping, pairing starts the send, failed-send line, Disconnect tells MonoRanks. Unit 129 OK, integration 17 OK, build matches.
• Changelog: two more Fix lines under 0.1.25. Stable tag is still 0.1.25 (not released), so the assets workflow still skips on merge.