v3.2.2

New Features

• None.

Improvements

• The settings screen keeps the active tab after saving. Tab state lives in the URL fragment, which never reaches the server, so every save previously redirected back to Event API regardless of which tab you were on. The active panel is now carried through _wp_http_referer so the redirect returns to the tab you were editing.
• Copy buttons confirm what they did. Each button swaps its label for two seconds on success, falls back to a synchronous copy when navigator.clipboard is unavailable, and shows a keyboard hint if both paths fail. Feedback strings are translatable.
• Copy buttons no longer use inline onclick attributes, so the settings screen works under a Content Security Policy that disallows inline script.
• Test coverage for the authorization surface. The unit suite now walks every registered eventonapify/v1 endpoint and asserts each one is administrator-gated and refuses to run while the API is disabled or EventON is absent, so a route added later is covered without anyone remembering to add a case.
• Test coverage for the wp/v2 compatibility guards, which are the only part of the plugin a non-administrator can reach. The new cases pin the fail-closed behavior of the request filter, the REST index stripping, the types and taxonomies response redaction, and the search-query exclusions.
• The WordPress integration test now dispatches real requests through the REST server and covers authorization, the disabled-API response, parameter rejection, pagination clamping, and both create payload shapes. It also asserts that a failed write restores taxonomy assignments and EventON's shared taxonomy metadata, not just post fields and post meta.
• Repository docs record the REST authorization contract, the architecture entry points, the test harness conventions, and the limits of the phpcs ruleset.

Bug Fixes

• Fix the MCP discovery route ignoring the API master switch. GET /wp-json/eventonapify/v1/mcp-schema served the full field contract even with the Event API toggle off, because it was the one handler that skipped the shared readiness check. It now returns 403 when the API is disabled and 500 when EventON is unavailable, matching every other route. Clients that fetch the manifest to decide whether to integrate will now receive an error instead of a contract while the API is switched off.
• Fix the settings screen printing "Settings saved." twice. add_options_page() places this screen under options-general.php, where WordPress already renders settings notices, and the page called settings_errors() a second time.
• Remove a do_settings_sections() call that could never render anything. It was passed a settings group where WordPress expects a page slug, and the panels on this screen are deliberately hand-rolled rather than registered through the Settings API.
• Fix the WordPress 7 integration job failing on every push since 3.0.1. The job asserted that the create route marks title and start_date as required at the argument layer, but those fields are intentionally not required there: a client may supply them inside the fields wrapper, and an argument-level requirement would reject that before normalization runs. The assertion now exercises the real behavior by dispatching requests. No plugin behavior changed; the check was stale.

Full Changelog: v3.2.1...v3.2.2