[kurtisbradley]

Fixes #859

wp_cache_replace_line() adds a missing line above the first define it finds. Kadence Security (formerly Solid Security, and iThemes Security before that) keeps its settings at the top of wp-config.php between marker comments:

// BEGIN Kadence Security - Do not modify or remove this line
// Kadence Security Config Details: 2
define( 'DISALLOW_FILE_EDIT', true );
// END Kadence Security - Do not modify or remove this line

The first define is inside that block, so WP_CACHE and WPCACHEHOME are written into it and erased the next time the security plugin rewrites its block. Caching then silently stops until the settings page is visited again.

The fix

Treat a // BEGIN / # BEGIN marker comment as an insertion point too, so the new line goes above the block rather than into it. It is a one-line change to the existing regex. Files without marker blocks are written exactly as before, and replacing or removing an existing line is untouched.

I kept it generic rather than matching the plugin by name: it has been renamed twice since the issue was opened, and other plugins use the same marker convention. Happy to narrow it or take a different approach if you prefer.

Testing

Added tests/php/smoke/WpCacheReplaceLineTest.php: Kadence Security, Solid Security, iThemes Security and #-style blocks, plus the no-marker case to show existing behaviour is unchanged. The four marker cases fail on trunk and pass with this change. composer test-php and composer lint pass.

Also verified on a live site running Kadence Security Basic 10.0.5:

• 3.1.4: WP_CACHE and WPCACHEHOME were written inside the Kadence block and erased the next time Kadence Security saved its settings.
• This branch: WP_CACHE was written above the block, and both constants survived repeated Kadence Security rewrites.

Release Notes

• Fix: WP_CACHE and WPCACHEHOME are no longer added inside another plugin's marker block in wp-config.php (e.g. Kadence Security, formerly Solid Security / iThemes Security), where they were being erased.