Not invalidating files in opcode cache after core update

[Krstarica]

Although #36455 is implemented and it properly invalidates files in Zend OpCache when doing plugin updates, it seems it does not work properly when doing core updates.

When installing the latest version of WordPress using wp-admin/update-core.php or being auto-updated, it shows like nothing has happened, meaning it is still pulling things from Zend OpCache.

[SergeyBiryukov]

Related: #51281

[kirasong]

Thanks for the report!

This worked for me in testing ahead of the update, so I'd love to figure out why it's not working in practice there.

Would you mind providing some details about the configuration on the site, so that I can try to reproduce?

Things like the host, PHP version, opcache configuration, and how the upgrade occurred (Was it started by core? The host? WP-CLI, etc) would be really helpful.

Thanks much!

[Krstarica]

Thanks for getting back to me Mike.

It happens both (1) when auto-update is triggered by WordPress itself and (2) when manually click update button at wp-admin/update-core.php. The same thing occurs in all previous versions of WordPress, too. After the upgrade is finished, it again shows prompt that the new version is available. systemctl reload php-fpm doesn't fix things.

OS: CentOS Linux release 7.8.2003 (Core)

PHP 7.3.24 (cli) (built: Oct 27 2020 11:01:59) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.24, Copyright (c) 1999-2018, by Zend Technologies

OPCache configuration in php.ini:

opcache.memory_consumption=640
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1
opcache.enable_cli=0
opcache.revalidate_freq = 60
opcache.max_accelerated_files=30000

Trac ticket: https://core.trac.wordpress.org/ticket/51686

[stodorovic]

It looks that version.php isn't invalidated because it isn't copied until everything else is verified. The function copy_dir invalidates other files, but version.php is still cached (because it's copied later with different method) . I've created PR 976: ​https://github.com/WordPress/wordpress-develop/pull/976 which will invalidate version.php from OPcache.

For testing, it's enough to add following line into php.ini:

opcache.validate_timestamps = 0

[kirasong]

Commented on #51281 about this, but thanks much @stodorovic for the patch!
Great catch.

I'll work on getting this in.

[kirasong]

Move one invalidation call after chmod, per @SergeyBiryukov's recommendation, and add comments.

[kirasong]

Example of how to test this change. Includes allowing the testing of dev update-core.php rather than the update package's one.

[kirasong]

This was tricky to test, so figured I'd document it here.

Assuming I haven't missed anything, this does look to solve both this problem and #51281.

This is how I ended up fixing it (​from Slack):
I was able to verify this by commenting out the overwriting of src/wp-admin/includes/update-core.php within src/wp-admin/includes/class-core-upgrader.php which let the patched version run against an otherwise equal update.

I've attached the diff​ of the test environment for using the WordPress built-in Docker environment, in case it helps anyone in the future.

[kirasong]

In 50475:

Upgrade/Install: Invalidate OPcache for version.php during update.

Invalidate OPcache for wp-content/version.php on update individually, since it’s copied separately.

Props stodorovic, krstarica, cenay, desrosj, pbiron, sergeybiryukov, mikeschroder.
Fixes #51686, #51281.
See #36455.

[kirasong]

Reopening for 5.7 consideration per @SergeyBiryukov.

[SergeyBiryukov]

[50475] looks good to backport.

[kirasong]

Thanks much! I'll take care of it.

Per our conversation in Slack, also going to add [50460], since the comments in this one were changed to match that change.

[kirasong]

In 50477:

Upgrade/Install: Invalidate OPcache for version.php during update.

Invalidate OPcache for wp-content/version.php on update individually, since it's copied separately.

Props stodorovic, krstarica, cenay, desrosj, pbiron, sergeybiryukov, mikeschroder.

Reviewed by mikeschroder, SergeyBiryukov.
Merges [50460] and [50475] to the 5.7 branch.
Fixes #51686, #51281.
See #36455.

https://core.trac.wordpress.org/changeset/50475

[kirasong]

Replying to mikeschroder:

In 50477:

<snip>

Invalidate OPcache for wp-content/version.php on update individually, since it's copied separately.

A quick note, pointed out by @stodorovic, that this should say wp-includes/version.php.
It was a mistake in the commit message, but the path is correct in the committed code.

Sorry about that, and thanks again!

[Krstarica]

Just experiencing the same issue after got email notification that WordPress was auto-updated to 5.7.1.

/wp-admin/update-core.php shows Current version: 5.7.1 and You have the latest version of WordPress.

On all other admin pages there is a notice WordPress 5.7.1 is available! Please update now.

/wp-includes/version.php contains $wp_version = '5.7.1';

It's the same even after systemctl reload php-fpm which supposed to clear opcache. Even systemctl restart php-fpm didn't help.

[stodorovic]

@Krstarica It works for me. I didn't see same issue after automatic updates (5.7 -> 5.7.1). Did you set opcache.restrict_api or opcache.file_cache? Did you try to run wp core version?

There is cli utility - ​https://github.com/gordalina/cachetool which can help to you see more details about OPcache.

PS: It's possible that admin pages are somehow cached by NGinx FastCGI cache. Did you try to clear this cache?

[Krstarica]

opcache.restrict_api => no value => no value
opcache.file_cache => no value => no value

No change after systemctl restart nginx

I am confused that update-core.php shows WordPress is up-to-date, but still seeing notice to update it. Does it pull such information from database?

BTW, I opened #53039 because this ticket is closed.