chore(deps): regenerate connect-helpers vendor

[randhirinsta]

What

Regenerates the vendored instawp/connect-helpers package via composer update, pulling in the core_updater transient-refresh fix.

Why

Bundles connect-helpers PR #18: core_updater() now forces a fresh wp_version_check() before find_core_update().

Previously, a core update performed right after a rollback failed on its first attempt with "WordPress is at the latest version." — the rollback request had rebuilt the update_core transient from a stale wp_get_wp_version() (a per-request static), so find_core_update() returned a stale response='latest' offer. The fix rebuilds the transient in the fresh update request, so the update succeeds on the first try. The downgrade path passes skip_core_check=true (it installs its own doctored offer).

Changes

• vendor/instawp/connect-helpers/src/Updater.php — regenerated with the fix
• vendor/composer/installed.json, vendor/composer/installed.php — composer metadata

Generated output only — no hand-written source changes in this repo.

🤖 Generated with Claude Code

[claude]

Claude finished @randhirinsta's task —— View job

---

PR Review: chore(deps): regenerate connect-helpers vendor

Todo List

• Read and analyze changed files
• Review core_updater fix implementation
• Assess against architectural principles
• Check for security/performance concerns
• Provide comprehensive review feedback

---

Review Summary

This PR successfully addresses a critical timing issue in the WordPress core update flow. The changes are well-implemented and ready to merge.

Key Changes Analysis

The core fix adds transient refresh logic to core_updater() at vendor/instawp/connect-helpers/src/Updater.php:124-127:

// Refresh WordPress's cached core-update offer before resolving the target
if ( empty( $args['skip_core_check'] ) ) {
    delete_site_transient( 'update_core' );
    wp_version_check( [], true );
}

This solves the "WordPress is at the latest version" error that occurred when attempting a core update immediately after a rollback.

Architecture & Code Quality Assessment

✅ Follows Architectural Principles

• Data Layer Abstraction: ✅ Works directly with WordPress transient storage (delete_site_transient())
• Single Source of Truth: ✅ Forces fresh data from wp_version_check() instead of relying on stale cache
• Separation of Concerns: ✅ Cache invalidation is properly separated from the upgrade logic
• Proper Abstraction: ✅ Uses skip_core_check flag to avoid redundant calls in downgrade path

✅ Security Considerations

• No new attack vectors: The fix uses standard WordPress APIs (delete_site_transient, wp_version_check)
• Input validation: The skip_core_check parameter is properly validated with empty()
• No user input handling: This is internal cache management, no external data processing

✅ Performance Considerations

• Efficient caching strategy: Only refreshes when necessary (skipped for downgrades via skip_core_check)
• Minimal overhead: Single network call to WordPress.org, only when actually needed
• Race condition prevention: Eliminates the timing issue between rollback and update requests

✅ Error Handling & Robustness

• Graceful degradation: If wp_version_check() fails, find_core_update() will still run with existing data
• Backward compatibility: The skip_core_check parameter has a safe default (false)
• Clear documentation: Excellent inline comments explaining the technical problem and solution

Code Quality

Strengths:

• Excellent documentation: Comprehensive inline comments explain the root cause and solution
• Clean implementation: Minimal, focused change that solves the specific problem
• WordPress standards compliance: Uses proper WordPress APIs and follows coding conventions
• Smart optimization: Avoids redundant API calls in the downgrade path

No Issues Found:

• No code duplication
• No security vulnerabilities
• No performance bottlenecks
• No backward compatibility concerns

Testing Considerations

The fix addresses a timing-dependent bug that requires specific conditions:

1. Perform a WordPress core rollback
2. Immediately attempt a core update in a fresh request
3. Verify the update succeeds on the first attempt

Manual testing recommended: This race condition is difficult to unit test due to WordPress transient caching behavior.

Recommendation

✅ APPROVE - This is a well-engineered fix for a legitimate technical issue. The implementation is clean, efficient, and follows WordPress best practices. The vendor code update is appropriate and safe to merge.

---

[claude]

Claude finished @randhirinsta's task —— View job

---

Claude finished this review

---

PR Review: chore(deps): regenerate connect-helpers vendor

Todo List

• Load developer context and project guidelines
• Read and analyze changed files
• Review core_updater fix implementation
• Assess against architectural principles
• Check for security/performance concerns
• Provide comprehensive review feedback

---

Review Summary

This PR successfully addresses a critical timing issue in the WordPress core update flow. The changes are well-implemented and ready to merge.

Key Changes Analysis

The core fix adds transient refresh logic to core_updater() at vendor/instawp/connect-helpers/src/Updater.php:124-127:

// Refresh WordPress's cached core-update offer before resolving the target
if ( empty( $args['skip_core_check'] ) ) {
    delete_site_transient( 'update_core' );
    wp_version_check( [], true );
}

This solves the "WordPress is at the latest version" error that occurred when attempting a core update immediately after a rollback.

Architecture & Code Quality Assessment

✅ Follows Architectural Principles

• Data Layer Abstraction: ✅ Works directly with WordPress transient storage (delete_site_transient())
• Single Source of Truth: ✅ Forces fresh data from wp_version_check() instead of relying on stale cache
• Separation of Concerns: ✅ Cache invalidation is properly separated from the upgrade logic
• Proper Abstraction: ✅ Uses skip_core_check flag to avoid redundant calls in downgrade path

✅ Security Considerations

• No new attack vectors: The fix uses standard WordPress APIs (delete_site_transient, wp_version_check)
• Input validation: The skip_core_check parameter is properly validated with empty()
• No user input handling: This is internal cache management, no external data processing

✅ Performance Considerations

• Efficient caching strategy: Only refreshes when necessary (skipped for downgrades via skip_core_check)
• Minimal overhead: Single network call to WordPress.org, only when actually needed
• Race condition prevention: Eliminates the timing issue between rollback and update requests

✅ Error Handling & Robustness

• Graceful degradation: If wp_version_check() fails, find_core_update() will still run with existing data
• Backward compatibility: The skip_core_check parameter has a safe default (false)
• Clear documentation: Excellent inline comments explaining the technical problem and solution

Code Quality

Strengths:

• Excellent documentation: Comprehensive inline comments explain the root cause and solution
• Clean implementation: Minimal, focused change that solves the specific problem
• WordPress standards compliance: Uses proper WordPress APIs and follows coding conventions
• Smart optimization: Avoids redundant API calls in the downgrade path

No Issues Found:

• No code duplication
• No security vulnerabilities
• No performance bottlenecks
• No backward compatibility concerns

Testing Considerations

The fix addresses a timing-dependent bug that requires specific conditions:

1. Perform a WordPress core rollback
2. Immediately attempt a core update in a fresh request
3. Verify the update succeeds on the first attempt

Manual testing recommended: This race condition is difficult to unit test due to WordPress transient caching behavior.

Recommendation

✅ APPROVE - This is a well-engineered fix for a legitimate technical issue. The implementation is clean, efficient, and follows WordPress best practices. The vendor code update is appropriate and safe to merge.

---