Fix: Replace symfony/cache with WordPress-native PSR-16 implementation for SSO#357
Fix: Replace symfony/cache with WordPress-native PSR-16 implementation for SSO#357superdav42 wants to merge 1 commit intomainfrom
Conversation
…n for SSO This commit resolves a fatal error caused by incompatibility between symfony/cache v5.4 and psr/simple-cache v3.0+. Changes: - Add WordPress_Simple_Cache class implementing PSR-16 CacheInterface using WordPress transients (get_site_transient, set_site_transient) - Update SSO class to use WordPress_Simple_Cache instead of symfony/cache - Remove symfony/cache dependency from composer.json (reduces 3 packages) - Add comprehensive unit tests for WordPress_Simple_Cache - Add standalone integration tests for PSR-16 compliance Benefits: - Eliminates PSR-16 compatibility error in SSO functionality - Reduces dependency footprint (removed symfony/cache, symfony/cache-contracts, symfony/var-exporter) - Better WordPress integration using native transient APIs - Maintains full PSR-16 compatibility required by jasny/sso library Fixes: Fatal Error 'psr/simple-cache 3.0+ is not compatible with symfony/cache v5.4' Note: PHPCS warnings about 'default' parameter name and direct database calls are acceptable as they follow PSR-16 standard and are necessary for cache clearing functionality.
📝 WalkthroughWalkthroughThis PR migrates the SSO module's caching backend from PSR-6/PSR-16 file-based storage to a WordPress-native transient-backed implementation. External dependencies (hashids, symfony/cache) are removed, and a new WordPress_Simple_Cache class is introduced with comprehensive test coverage. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
composer.json (1)
32-68:⚠️ Potential issue | 🔴 CriticalRe-add
hashids/hashidsbefore merge.
inc/helpers/class-hash.phpimports and instantiatesHashids\Hashidson lines 45 and 61, but the dependency is missing fromcomposer.jsonrequire. Production will fail with a fatal class-not-found error whenHash::encode()orHash::decode()are called.Suggested fix
"require": { "php": ">=7.4.1", + "hashids/hashids": "^4.1.0", "automattic/jetpack-autoloader": "^5.0.0", "wp-ultimo/autoloader-plugin": "dev-main",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@composer.json` around lines 32 - 68, The composer.json is missing the hashids/hashids package used by inc/helpers/class-hash.php (it instantiates Hashids\Hashids and calls Hash::encode() and Hash::decode()); add the hashids/hashids requirement to composer.json's "require" (pick a compatible semver such as ^4.0) and run composer update/install so the Hashids\Hashids class is available at runtime.
🧹 Nitpick comments (2)
tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Test.php (1)
216-230: TTL tests don’t validate expiration behavior.Current assertions only check “set + immediate get.” They won’t catch TTL conversion bugs (especially
DateInterval). Add assertions against timeout metadata or time-controlled expiry behavior.Also applies to: 250-261
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Test.php` around lines 216 - 230, The TTL tests (e.g., test_ttl_with_integer_seconds) only assert set+get and miss verifying the actual expiration metadata, so update these tests to assert the stored transient timeout matches the expected expiry and/or simulate time progression to confirm expiration; specifically, after calling $this->cache->set($key, $value, $ttl) assert that the underlying timeout option (the _transient_timeout_{key} option or equivalent returned by wp_get_transient_timeout / get_option) equals time() + $ttl (or within a 1-second tolerance), and add a complementary assertion that the cached value is no longer returned after advancing simulated time or by manually setting the timeout to a past timestamp and calling $this->cache->get($key) to ensure expiration behavior is enforced (apply the same changes to the other TTL test referenced around lines 250-261).tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php (1)
87-93: TTL integration tests are non-functional with current mock storage.
$expirationis ignored inset_site_transient()mock, so TTL assertions can’t validate expiry behavior.Also applies to: 304-320
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php` around lines 87 - 93, The mock set_site_transient currently ignores $expiration so TTL tests fail; update set_site_transient to store both the value and an expiry timestamp in the global $_site_transients (e.g. store an array ['value'=>..., 'expires_at'=> time() + $expiration] or null for no TTL) and update the corresponding get_site_transient (and any delete_site_transient logic) to check $_site_transients[$key]['expires_at'] and treat expired entries as missing (remove them and return false/null) so TTL assertions work; change references to $_site_transients in both set_site_transient and get_site_transient to the new shape.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@inc/sso/class-wordpress-simple-cache.php`:
- Around line 83-92: The clear() method currently returns true unconditionally;
change it so it checks the result of $wpdb->query and returns failure when the
DB operation errored: capture the query call (the DELETE using $wpdb->prepare
and $wpdb->esc_like) then if $wpdb->last_error is non-empty return false,
otherwise return true (this ensures clear() reports failure on DB errors while
still treating zero affected rows as success).
- Around line 169-173: The DateInterval handling mutates $now because
DateTime::add() returns the same instance, so $future and $now end up identical
and the TTL becomes 0; fix this in class-wordpress-simple-cache.php by creating
a separate DateTime instance (e.g., clone $now or instantiate a new DateTime)
before calling add() so $future != $now, then compute and return
$future->getTimestamp() - $now->getTimestamp(); ensure this change is applied to
the code handling $ttl when it's an instance of \DateInterval (references: $ttl,
$now, $future, DateTime::add).
- Around line 46-49: The get() and has() methods currently treat WordPress
transient return value false as a cache miss, so legitimately cached boolean
false cannot be stored; update the caching layer (methods get(), has(), and the
corresponding set()/set_site_transient usage) to wrap stored values in a
sentinel structure (e.g., ['hit' => true, 'value' => ...]) before calling
set_site_transient, and on retrieval in get() unwrap that structure to return
the original value (including false) while has() should check for the wrapper
and return true only when the wrapper is present; ensure existing consumers of
get() keep receiving the raw unwrapped value and that miss handling still
returns the $default.
In `@tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php`:
- Around line 325-331: The test runner fails because the included class file
exits when ABSPATH is undefined and the cache clear() method expects a global
$wpdb that the test doesn't provide; before requiring
'inc/sso/class-wordpress-simple-cache.php' (in
WordPress_Simple_Cache_Integration_Test runner) define a minimal ABSPATH
constant and inject a mocked global $wpdb with stubbed methods query(),
prepare(), and esc_like() (and any used properties) so clear() can run; also
ensure mock_wordpress_functions() remains in place and is called before
inclusion so get_site_transient()/set_site_transient()/delete_site_transient()
and the $wpdb mock exist when the class file is loaded and when clear() is
invoked during tests.
In `@tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Test.php`:
- Around line 332-335: The local variable $user_id is declared but never used;
remove the unused declaration (the line setting $user_id = 42) from the test to
avoid dead code, or if the test should assert on the user id, instead use
$user_id in the relevant assertion or call; locate the declaration near
$broker_id and $session_id in the test and either delete the $user_id line or
wire it into the test expectations where appropriate.
---
Outside diff comments:
In `@composer.json`:
- Around line 32-68: The composer.json is missing the hashids/hashids package
used by inc/helpers/class-hash.php (it instantiates Hashids\Hashids and calls
Hash::encode() and Hash::decode()); add the hashids/hashids requirement to
composer.json's "require" (pick a compatible semver such as ^4.0) and run
composer update/install so the Hashids\Hashids class is available at runtime.
---
Nitpick comments:
In `@tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php`:
- Around line 87-93: The mock set_site_transient currently ignores $expiration
so TTL tests fail; update set_site_transient to store both the value and an
expiry timestamp in the global $_site_transients (e.g. store an array
['value'=>..., 'expires_at'=> time() + $expiration] or null for no TTL) and
update the corresponding get_site_transient (and any delete_site_transient
logic) to check $_site_transients[$key]['expires_at'] and treat expired entries
as missing (remove them and return false/null) so TTL assertions work; change
references to $_site_transients in both set_site_transient and
get_site_transient to the new shape.
In `@tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Test.php`:
- Around line 216-230: The TTL tests (e.g., test_ttl_with_integer_seconds) only
assert set+get and miss verifying the actual expiration metadata, so update
these tests to assert the stored transient timeout matches the expected expiry
and/or simulate time progression to confirm expiration; specifically, after
calling $this->cache->set($key, $value, $ttl) assert that the underlying timeout
option (the _transient_timeout_{key} option or equivalent returned by
wp_get_transient_timeout / get_option) equals time() + $ttl (or within a
1-second tolerance), and add a complementary assertion that the cached value is
no longer returned after advancing simulated time or by manually setting the
timeout to a past timestamp and calling $this->cache->get($key) to ensure
expiration behavior is enforced (apply the same changes to the other TTL test
referenced around lines 250-261).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 92669a09-ba40-48cd-8dd8-3544b7a26bbc
⛔ Files ignored due to path filters (1)
composer.lockis excluded by!**/*.lock
📒 Files selected for processing (5)
composer.jsoninc/sso/class-sso.phpinc/sso/class-wordpress-simple-cache.phptests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.phptests/WP_Ultimo/SSO/WordPress_Simple_Cache_Test.php
| public function get($key, $default = null) { | ||
| $value = get_site_transient($this->prefix . $key); | ||
| return false !== $value ? $value : $default; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
WordPress get_site_transient() return value cache miss PSR-16
💡 Result:
get_site_transient( $key ) returns false on a cache miss (not set / no value / expired). So false is WordPress’s “miss sentinel.” [1]
In PSR-16, CacheInterface::get($key, $default = null) must return the cached value, or $default on a miss (defaulting to null). [2]
So, when wrapping WordPress site transients behind PSR-16, the usual mapping is:
public function get(string $key, mixed $default = null): mixed {
$value = get_site_transient($key);
return ($value === false) ? $default : $value;
}Important limitation: with WordPress transients you can’t reliably cache the literal boolean false, because it’s indistinguishable from a miss/expired transient. If you need to cache “false” as a real value, store a sentinel structure instead (e.g., ['hit'=>true,'value'=>false]) and unwrap it on read. [1]
Sources: [1] WordPress get_site_transient() reference; [2] PSR-16 CacheInterface::get() contract.
🏁 Script executed:
# First, let's locate and examine the file
find . -name "class-wordpress-simple-cache.php" -type fRepository: Ultimate-Multisite/ultimate-multisite
Length of output: 123
🏁 Script executed:
# Get the full context of the file to see lines 46-49 and 154-156
if [ -f "inc/sso/class-wordpress-simple-cache.php" ]; then
wc -l inc/sso/class-wordpress-simple-cache.php
fiRepository: Ultimate-Multisite/ultimate-multisite
Length of output: 125
🏁 Script executed:
# View the relevant sections with context
if [ -f "inc/sso/class-wordpress-simple-cache.php" ]; then
echo "=== Lines 40-60 (get method) ===" && \
sed -n '40,60p' inc/sso/class-wordpress-simple-cache.php && \
echo -e "\n=== Lines 150-165 (has method) ===" && \
sed -n '150,165p' inc/sso/class-wordpress-simple-cache.php
fiRepository: Ultimate-Multisite/ultimate-multisite
Length of output: 1453
Cannot cache boolean false values—WordPress transients use false as a miss sentinel.
get_site_transient() returns false for cache misses, making it impossible to distinguish a legitimately cached false from missing data. This violates PSR-16 behavior, where such values should be cacheable and retrievable unchanged. Both get() and has() exhibit this limitation.
To cache boolean false, wrap it in a structure (e.g., ['hit' => true, 'value' => false]) and unwrap on retrieval.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@inc/sso/class-wordpress-simple-cache.php` around lines 46 - 49, The get() and
has() methods currently treat WordPress transient return value false as a cache
miss, so legitimately cached boolean false cannot be stored; update the caching
layer (methods get(), has(), and the corresponding set()/set_site_transient
usage) to wrap stored values in a sentinel structure (e.g., ['hit' => true,
'value' => ...]) before calling set_site_transient, and on retrieval in get()
unwrap that structure to return the original value (including false) while has()
should check for the wrapper and return true only when the wrapper is present;
ensure existing consumers of get() keep receiving the raw unwrapped value and
that miss handling still returns the $default.
| $wpdb->query( | ||
| $wpdb->prepare( | ||
| "DELETE FROM {$wpdb->sitemeta} WHERE meta_key LIKE %s OR meta_key LIKE %s", | ||
| $wpdb->esc_like('_site_transient_' . $this->prefix) . '%', | ||
| $wpdb->esc_like('_site_transient_timeout_' . $this->prefix) . '%' | ||
| ) | ||
| ); | ||
|
|
||
| return true; | ||
| } |
There was a problem hiding this comment.
clear() always returns success even on DB failure.
Line 91 returns true unconditionally. If $wpdb->query() fails, callers won’t know clear failed.
Proposed fix
- $wpdb->query(
+ $result = $wpdb->query(
$wpdb->prepare(
"DELETE FROM {$wpdb->sitemeta} WHERE meta_key LIKE %s OR meta_key LIKE %s",
$wpdb->esc_like('_site_transient_' . $this->prefix) . '%',
$wpdb->esc_like('_site_transient_timeout_' . $this->prefix) . '%'
)
);
- return true;
+ return false !== $result;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@inc/sso/class-wordpress-simple-cache.php` around lines 83 - 92, The clear()
method currently returns true unconditionally; change it so it checks the result
of $wpdb->query and returns failure when the DB operation errored: capture the
query call (the DELETE using $wpdb->prepare and $wpdb->esc_like) then if
$wpdb->last_error is non-empty return false, otherwise return true (this ensures
clear() reports failure on DB errors while still treating zero affected rows as
success).
| if ($ttl instanceof \DateInterval) { | ||
| $now = new \DateTime(); | ||
| $future = $now->add($ttl); | ||
| return $future->getTimestamp() - $now->getTimestamp(); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
PHP DateTime::add() mutate object return same instance
💡 Result:
Yes. DateTime::add() mutates the existing DateTime object and returns the same instance (so assignments just create another reference to the same object), mainly to allow method chaining. To avoid mutation, use DateTimeImmutable::add() (returns a new object) or clone before adding. [1], [2]
$dt = new DateTime('2026-03-05');
$dt2 = $dt->add(new DateInterval('P1D'));
var_dump($dt === $dt2); // true (same instance)$dt = new DateTime('2026-03-05');
$dt2 = (clone $dt)->add(new DateInterval('P1D')); // $dt unchanged$dt = new DateTimeImmutable('2026-03-05');
$dt2 = $dt->add(new DateInterval('P1D')); // new instanceSources: PHP manual for DateTime::add() and DateTime mutability, plus DateTimeImmutable::add() behavior. [1], [2]
[1] https://www.php.net/manual/en/datetime.add.php
[2] https://www.php.net/manual/en/class.datetime.php
🏁 Script executed:
# Check the actual file and surrounding context
find . -name "class-wordpress-simple-cache.php" -path "*/inc/sso/*" | head -5Repository: Ultimate-Multisite/ultimate-multisite
Length of output: 123
🏁 Script executed:
# Read the file to see the complete context around lines 169-173
cat -n inc/sso/class-wordpress-simple-cache.php | sed -n '160,185p'Repository: Ultimate-Multisite/ultimate-multisite
Length of output: 611
DateInterval TTL currently collapses to 0 (no expiration).
On line 171, DateTime::add() mutates $now and returns the same instance, so $future references the identical object. Line 172 then subtracts identical timestamps, yielding 0. This causes DateInterval entries to become non-expiring.
Proposed fix
if ($ttl instanceof \DateInterval) {
- $now = new \DateTime();
- $future = $now->add($ttl);
- return $future->getTimestamp() - $now->getTimestamp();
+ $now = new \DateTimeImmutable();
+ $future = $now->add($ttl);
+ return max(0, $future->getTimestamp() - $now->getTimestamp());
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if ($ttl instanceof \DateInterval) { | |
| $now = new \DateTime(); | |
| $future = $now->add($ttl); | |
| return $future->getTimestamp() - $now->getTimestamp(); | |
| } | |
| if ($ttl instanceof \DateInterval) { | |
| $now = new \DateTimeImmutable(); | |
| $future = $now->add($ttl); | |
| return max(0, $future->getTimestamp() - $now->getTimestamp()); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@inc/sso/class-wordpress-simple-cache.php` around lines 169 - 173, The
DateInterval handling mutates $now because DateTime::add() returns the same
instance, so $future and $now end up identical and the TTL becomes 0; fix this
in class-wordpress-simple-cache.php by creating a separate DateTime instance
(e.g., clone $now or instantiate a new DateTime) before calling add() so $future
!= $now, then compute and return $future->getTimestamp() - $now->getTimestamp();
ensure this change is applied to the code handling $ttl when it's an instance of
\DateInterval (references: $ttl, $now, $future, DateTime::add).
| // Auto-run if this file is executed directly (not included by PHPUnit). | ||
| if (php_sapi_name() === 'cli' && !defined('PHPUNIT_COMPOSER_INSTALL')) { | ||
| // Load autoloader. | ||
| require_once dirname(dirname(dirname(__DIR__))) . '/vendor/autoload.php'; | ||
| require_once dirname(dirname(dirname(__DIR__))) . '/inc/sso/class-wordpress-simple-cache.php'; | ||
|
|
||
| WordPress_Simple_Cache_Integration_Test::run_all_tests(); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify ABSPATH guard and clear() DB dependency in cache class
rg -n "defined\\('ABSPATH'\\) \\|\\| exit|function clear\\(|global \\$wpdb" inc/sso/class-wordpress-simple-cache.php
# Verify standalone runner path and clear() usage in integration test
rg -n "require_once .*class-wordpress-simple-cache.php|run_all_tests|->clear\\(" tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.phpRepository: Ultimate-Multisite/ultimate-multisite
Length of output: 1013
🏁 Script executed:
#!/bin/bash
# Check ABSPATH guard in cache class
echo "=== Checking for ABSPATH guard in class file ==="
rg "ABSPATH" inc/sso/class-wordpress-simple-cache.php -A 2 -B 2
echo ""
echo "=== Checking clear() function definition ==="
rg "function clear" inc/sso/class-wordpress-simple-cache.php -A 10
echo ""
echo "=== Checking for $wpdb usage in class file ==="
rg "wpdb" inc/sso/class-wordpress-simple-cache.php -nRepository: Ultimate-Multisite/ultimate-multisite
Length of output: 916
🏁 Script executed:
#!/bin/bash
# Check for setUp, bootstrap, or $wpdb mocking in the test file
echo "=== Checking for setUp/init methods ==="
rg "function setUp|function __construct|global \\\$wpdb|\\$GLOBALS\[|mock|Mock" tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php -n
echo ""
echo "=== Checking file header and class definition ==="
head -50 tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.phpRepository: Ultimate-Multisite/ultimate-multisite
Length of output: 1451
🏁 Script executed:
#!/bin/bash
# Find and display the mock_wordpress_functions method
rg -n "mock_wordpress_functions" tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php -A 30Repository: Ultimate-Multisite/ultimate-multisite
Length of output: 2030
🏁 Script executed:
#!/bin/bash
# Get the complete mock_wordpress_functions method
rg -n "private static function mock_wordpress_functions" tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php -A 60Repository: Ultimate-Multisite/ultimate-multisite
Length of output: 1846
Standalone CLI runner cannot execute due to unmet WordPress dependencies.
The included cache class file exits when ABSPATH is undefined (line 2: defined('ABSPATH') || exit;), and the clear() method requires the global $wpdb object which is not mocked in the test setup. The mock_wordpress_functions() method only provides get_site_transient, set_site_transient, and delete_site_transient—it does not mock $wpdb. Since clear() is called 21 times throughout the test suite and directly executes database queries via $wpdb->query(), $wpdb->prepare(), and $wpdb->esc_like(), the standalone runner will fail immediately upon inclusion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php` around lines
325 - 331, The test runner fails because the included class file exits when
ABSPATH is undefined and the cache clear() method expects a global $wpdb that
the test doesn't provide; before requiring
'inc/sso/class-wordpress-simple-cache.php' (in
WordPress_Simple_Cache_Integration_Test runner) define a minimal ABSPATH
constant and inject a mocked global $wpdb with stubbed methods query(),
prepare(), and esc_like() (and any used properties) so clear() can run; also
ensure mock_wordpress_functions() remains in place and is called before
inclusion so get_site_transient()/set_site_transient()/delete_site_transient()
and the $wpdb mock exist when the class file is loaded and when clear() is
invoked during tests.
| $broker_id = 'test_broker_123'; | ||
| $session_id = 'session_abc_456'; | ||
| $user_id = 42; | ||
|
|
There was a problem hiding this comment.
Remove unused local $user_id.
$user_id is declared but never used in this test.
🧰 Tools
🪛 PHPMD (2.15.0)
[warning] 334-334: Avoid unused local variables such as '$user_id'. (undefined)
(UnusedLocalVariable)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Test.php` around lines 332 - 335,
The local variable $user_id is declared but never used; remove the unused
declaration (the line setting $user_id = 42) from the test to avoid dead code,
or if the test should assert on the user id, instead use $user_id in the
relevant assertion or call; locate the declaration near $broker_id and
$session_id in the test and either delete the $user_id line or wire it into the
test expectations where appropriate.
1 participant
Summary
This PR resolves a fatal error in SSO functionality caused by incompatibility between
symfony/cachev5.4 andpsr/simple-cachev3.0+.Problem
The SSO feature was experiencing a fatal error:
This occurred because:
symfony/cachev5.4.x has a compatibility check that rejectspsr/simple-cache3.0+symfony/cache6.0+ requires PHP 8.1+ (not compatible with our PHP 7.4 requirement)CacheInterfaceSolution
Created a WordPress-native PSR-16 cache implementation that:
Psr\SimpleCache\CacheInterface(PSR-16 standard)get_site_transient,set_site_transient,delete_site_transient)Changes
New Files
inc/sso/class-wordpress-simple-cache.php- WordPress transient-based PSR-16 implementationtests/WP_Ultimo/SSO/WordPress_Simple_Cache_Test.php- Comprehensive PHPUnit test suite (20+ tests)tests/WP_Ultimo/SSO/WordPress_Simple_Cache_Integration_Test.php- Standalone integration testsModified Files
inc/sso/class-sso.php- Updated to useWordPress_Simple_Cacheinstead ofPsr16Cachecomposer.json- Removedsymfony/cachedependencycomposer.lock- Updated (removed 3 packages: symfony/cache, symfony/cache-contracts, symfony/var-exporter)Benefits
Testing
All PSR-16 interface methods tested:
get(),set(),delete(),clear(),has()getMultiple(),setMultiple(),deleteMultiple()Notes
$defaultparameter name are acceptable (required by PSR-16 standard)clear()method are necessary for bulk transient deletionMigration
No migration needed - the change is backward compatible. Existing SSO sessions will continue to work as the cache implementation is transparent to the SSO logic.
Fixes: Fatal error "psr/simple-cache 3.0+ is not compatible with symfony/cache v5.4"
Summary by CodeRabbit
Bug Fixes
Chores