Gravity Forms 3.1.1.1 removes an extra slash from the Jetpack Autoloader file path used to include the canonical WordPress MCP Adapter package. On a site with several Composer-based plugins, a path mismatch can surface as a missing class, duplicate package, wrong package version, fatal error, absent MCP endpoint, or a problem that appears only after opcache or deployment layout changes.
Use this for sites running Gravity Forms MCP with Jetpack, WooCommerce, Composer plugins, must-use plugins, deployment symlinks, Bedrock-style paths, read-only releases, network activation, or more than one package that ships Jetpack Autoloader metadata.
Quick answer
Inventory every installed copy of the MCP Adapter and Jetpack Autoloader before updating. Capture the resolved class file, package version, real path, endpoint registration, WordPress user, application-password scope, and one read-only MCP call. Update to 3.1.1.1 on staging, restart PHP or clear opcache through the normal hosting workflow, and repeat the same call. One expected package should load from a canonical path, the endpoint should register once, permissions must stay least privilege, and no duplicate-class warning or alternate path should appear.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Single package | Normal plugin path | One canonical class |
| Duplicate package | Different versions | Supported version selected |
| Symlink release | Current points to build | Real path resolves |
| MCP request | Read-only user | Endpoint works, writes denied |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Inventory package copies | Record WordPress, PHP, Gravity Forms, Jetpack, Composer plugin, MCP Adapter, and autoloader versions plus document root, release path, symlink target, and opcache state. | Reflection and package metadata identify one expected MCP Adapter implementation. |
| Capture the resolved class | Search plugins and must-use plugins for duplicate package manifests, vendor directories, Jetpack Autoloader files, MCP Adapter namespaces, and path strings with repeated separators. | Web, CLI, cron, REST, and MCP requests load without duplicate-class, missing-file, or path warnings. |
| Update and restart workers | Capture the resolved class location with reflection, loaded package map, REST route list, Gravity Forms MCP settings, user role, application-password name, and endpoint response. | A read-only MCP identity can inspect allowed objects but cannot create, edit, or delete content. |
| Verify the MCP route | Test normal path, symlinked release, multisite network activation, plugin activation order, cache warmup, CLI load, REST request, and a process restart after the update. | A rollback to the previous release restores the prior known state without leaving stale workers or credentials. |
What to check first
- Record WordPress, PHP, Gravity Forms, Jetpack, Composer plugin, MCP Adapter, and autoloader versions plus document root, release path, symlink target, and opcache state.
- Search plugins and must-use plugins for duplicate package manifests, vendor directories, Jetpack Autoloader files, MCP Adapter namespaces, and path strings with repeated separators.
- Capture the resolved class location with reflection, loaded package map, REST route list, Gravity Forms MCP settings, user role, application-password name, and endpoint response.
- Test normal path, symlinked release, multisite network activation, plugin activation order, cache warmup, CLI load, REST request, and a process restart after the update.
- Confirm errors and support bundles do not reveal application passwords, authorization headers, absolute private paths, user data, or full configuration prompts.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison far more useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, OAuth refreshes, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp plugin get gravityforms --field=version
wp eval 'echo (new ReflectionClass("WpOrg\Mcp\Adapter"))->getFileName();'
wp rest route list | grep -i mcp
find wp-content -path '*/vendor/*' -type f -iname '*autoload*' | head -40
Why this usually happens
- Two packages normalize a path differently and produce separate autoloader identities for the same file.
- A stale PHP worker still holds the previous package map after files were deployed.
- Plugin activation order changes which compatible package version is selected.
- The endpoint failure is blamed on credentials even though its classes never loaded.
Decision rule
Approve the fix when the expected MCP Adapter package resolves once from a canonical path across web, REST, CLI, and deployment contexts, while endpoint permissions and credential handling remain unchanged.
Production verification checklist
- Reflection and package metadata identify one expected MCP Adapter implementation.
- Web, CLI, cron, REST, and MCP requests load without duplicate-class, missing-file, or path warnings.
- A read-only MCP identity can inspect allowed objects but cannot create, edit, or delete content.
- A rollback to the previous release restores the prior known state without leaving stale workers or credentials.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Inventory package copies
- Capture the resolved class
- Update and restart workers
- Verify the MCP route
- Retest least privilege
Mistakes to avoid
- Changing production before recording plugin versions, WordPress version, PHP version, UTC time, the exact fixture, and a tested rollback point.
- Accepting one successful admin screen while the public form, stored record, API response, accessibility tree, cache, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving test accounts, broad credentials, debug logs, temporary compatibility filters, or synthetic customer data active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, caching stack, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I know the result is not a cache artifact?
Record the origin response, purge only the affected paths, and repeat the test in a private session and a normal session. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When can I close the test?
Close it when the primary path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test a WordPress MCP integration.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references