Yoast updates delete opcache for non-Yoast and non-WordPress PHP files

[csurtyoung]

[x] I've read and understood the contribution guidelines. [x] I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened

In wp-seo-main.php, function wpseo_init() contains the following code:

        if ( version_compare( WPSEO_Options::get( 'version', 1 ), WPSEO_VERSION, '<' ) ) {
                if ( function_exists( 'opcache_reset' ) ) {
                        // phpcs:ignore WordPress.PHP.NoSilencedErrors.Discouraged -- Prevent notices when opcache.restrict_api is set.
                        @opcache_reset();
                }

                new WPSEO_Upgrade();
                // Get a cleaned up version of the $options.
        }

Especially in complex environments with many sites running Yoast and other PHP applications present, dumping cache for the entire server repeatedly is harmful and poor practice. We have tracked an intermittent server stability issue to Yoast updates.

Please consider replacing the opcache_reset() call with opcache_invalidate() applied to the plugin files only. If this is not possible, please consider adding an advanced configuration option that disables the opcache_reset() call.

Previous discussion of this issue is present in https://github.com/Yoast/wordpress-seo/issues/9315. The issue was closed without being resolved at that time (2018) despite complaint from several users.

Further information can be viewed in Wordpress.org support thread (https://wordpress.org/support/topic/yoast-updates-delete-opcache-for-non-yoast-and-non-wp-php-files/)

To Reproduce

Step-by-step reproduction instructions

1. Update Yoast
2. Observe opcache state

Expected results

1. opcache entries for Yoast files are invalidated, forcing refresh of cached versions of these particular files.

Actual results

1. Entire opcache is reset, impacting non-Yoast and non-WordPress PHP code coexisting with Yoast on the server.

Technical info

• If relevant, which editor is affected (or editors):
• [ ] Block Editor
• [ ] Gutenberg Editor
• [ ] Elementor Editor
• [ ] Classic Editor
• [x] Other: NA. Problem is with the update process, not with any particular editor.

• Which browser is affected (or browsers):
• [ ] Chrome
• [ ] Firefox
• [ ] Safari
• [x] Other: Not browser-specific - impact is on web server itself

Used versions

• Device you are using: Linux/Apache platform on virtual servers running in a rack-mount environment
• Operating system: CentOS 7
• PHP version: 8.0.29 (prior versions affected)
• WordPress version: 6.3.1 (prior versions affected)
• WordPress Theme: custom, based on _s
• Yoast SEO version: 21.2 (prior versions affected)
• Gutenberg plugin version:
• Elementor plugin version:
• Classic Editor plugin version:
• Relevant plugins in case of a bug:

[jeroenrotty]

Hey @csurtyoung,

Thank you so much for creating this issue. I'll take it to the dev team and discuss, we might look into using wp_opcache_invalidate_directory() available since WP 6.2. (link)

[csurtyoung]

Thanks, Jeroen. I'll stay tuned and definitely appreciate that you and your team are receptive to this suggestion.

[enricobattocchi]

Reopening the issue since the solution was reverted in 21.9.1

[hadamlenz]

the opcache resetting for each subsite in a large multisite corrupts the cache. Variable letters start shifting, mostly in the require functions in wp-settings.php, which leads to white screen errors. Resetting the entire cache is a bit greedy. please stahp