Not invalidating files in opcode cache after core update (cont’d)

[Krstarica]

This is a follow-up to #51686.

After got email notification that WordPress was auto-updated to 5.7.1, still seeing a notice WordPress 5.7.1 is available! Please update now. on admin pages.

The exception is /wp-admin/update-core.php showing Current version: 5.7.1 and You have the latest version of WordPress.

/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.

[Krstarica]

Nag is displayed based on the output of get_preferred_from_update_core():

$cur = get_preferred_from_update_core();

if ( ! isset( $cur->response ) || 'upgrade' !== $cur->response ) {
	return false;
}

get_preferred_from_update_core() calls get_core_updates() which contains:

$from_api = get_site_transient( 'update_core' );

Dumped this variable:

from_api: stdClass Object
(
    [updates] => Array
        (
            [0] => stdClass Object
                (
                    [response] => upgrade
                    [download] => https://downloads.wordpress.org/release/sr_RS/wordpress-5.7.1.zip
                    [locale] => sr_RS
                    [packages] => stdClass Object
                        (
                            [full] => https://downloads.wordpress.org/release/sr_RS/wordpress-5.7.1.zip
                            [no_content] => 
                            [new_bundled] => 
                            [partial] => 
                            [rollback] => 
                        )

                    [current] => 5.7.1
                    [version] => 5.7.1
                    [php_version] => 5.6.20
                    [mysql_version] => 5.0
                    [new_bundled] => 5.6
                    [partial_version] => 
                )

        )

    [last_checked] => 1618478516
    [version_checked] => 5.7.1
    [translations] => Array
        (
        )

)

It clearly shows that current and available versions are the same.

So it should contain:

[response] => latest

instead of

[response] => upgrade

So it seems there are two issues:
1) Bug: 'update_core' transient is not set to appropriate value after upgrade, i.e. [response] => latest
2) Feature to implement: update-core.php should update 'update_core' transient, too

[stodorovic]

It looks as an issue related to object caching. I don't think that's OPcache root of cause. It seems that
$wp_version points to correct version - 5.7.1 (global variable in wp-includes/version which was properly invalidated after update). Which object cache (Redis,Memcache,...) has installed?

I just checked transient via wp-cli:

# sudo -u www-data wp shell
wp> get_preferred_from_update_core();
=> object(stdClass)#12003 (11) {
  ["response"]=>
  string(6) "latest"
  ["download"]=>
  string(65) "https://downloads.wordpress.org/release/en_GB/wordpress-5.7.1.zip"

Did you try to delete all transients of flush object cache?

If you have installed ​https://wp-cli.org/ then you can try:

# sudo -u www-data wp shell
wp> delete_site_transient( 'update_core' );
=> bool(false)
wp> get_core_updates();
=> bool(false)
wp> wp_version_check();
=> NULL
wp> get_core_updates();
=> array(1) {
  [0]=>
  object(stdClass)#12003 (11) {
    ["response"]=>
    string(6) "latest"
    ["download"]=>
    string(65) "https://downloads.wordpress.org/release/en_GB/wordpress-5.7.1.zip"

[Krstarica]

There is no object cache.

wp> get_preferred_from_update_core();
=> object(stdClass)#16499 (11) {
  ["response"]=>
  string(7) "upgrade"
  ["download"]=>
  string(65) "https://downloads.wordpress.org/release/sr_RS/wordpress-5.7.1.zip"
  ["locale"]=>
  string(5) "sr_RS"
  ["packages"]=>
  object(stdClass)#16500 (5) {
    ["full"]=>
    string(65) "https://downloads.wordpress.org/release/sr_RS/wordpress-5.7.1.zip"
    ["no_content"]=>
    string(0) ""
    ["new_bundled"]=>
    string(0) ""
    ["partial"]=>
    string(0) ""
    ["rollback"]=>
    string(0) ""
  }
  ["current"]=>
  string(5) "5.7.1"
  ["version"]=>
  string(5) "5.7.1"
  ["php_version"]=>
  string(6) "5.6.20"
  ["mysql_version"]=>
  string(3) "5.0"
  ["new_bundled"]=>
  string(3) "5.6"
  ["partial_version"]=>
  string(0) ""
  ["dismissed"]=>
  bool(false)
}
wp> delete_site_transient( 'update_core' );
=> bool(true)
wp> get_core_updates();
=> bool(false)
wp> wp_version_check();
=> NULL
wp> get_core_updates();
=> array(1) {
  [0]=>
  object(stdClass)#16504 (11) {
    ["response"]=>
    string(7) "upgrade"
    ["download"]=>
    string(65) "https://downloads.wordpress.org/release/sr_RS/wordpress-5.7.1.zip"
    ["locale"]=>
    string(5) "sr_RS"
    ["packages"]=>
    object(stdClass)#16505 (5) {
      ["full"]=>
      string(65) "https://downloads.wordpress.org/release/sr_RS/wordpress-5.7.1.zip"
      ["no_content"]=>
      string(0) ""
      ["new_bundled"]=>
      string(0) ""
      ["partial"]=>
      string(0) ""
      ["rollback"]=>
      string(0) ""
    }
    ["current"]=>
    string(5) "5.7.1"
    ["version"]=>
    string(5) "5.7.1"
    ["php_version"]=>
    string(6) "5.6.20"
    ["mysql_version"]=>
    string(3) "5.0"
    ["new_bundled"]=>
    string(3) "5.6"
    ["partial_version"]=>
    string(0) ""
    ["dismissed"]=>
    bool(false)
  }
}

[stodorovic]

I just compared objects between various websites and "your response" is same as on version 5.7.

Could you check:

• "About wordpress" (/wp-admin/about.php) ?
• You can install QM (query monitor plugin), there is WP version under Enviroment (the easiest way to confirm "wp_version" on particular admin pages).
• wp-cli:

  $ wp core version
  5.7.1
  $ wp shell
  wp> $GLOBALS['wp_version'];
  => string(5) "5.7.1"
  
  

If everything shows 5.7.1 then it's pretty strange.

[dimadin]

Hi @Krstarica! I am administrator of WordPress sr_RS locale that you seem to use. After reading this ticket and your comments on #51686 (starting from comment:22:ticket:51686), I suspect that issue might related to the specific way WordPress.org API treats sr_RS locale, and not related to the cache or your site.

Could you please tell me exact time when you got automatic email notification from your site about automatic upgrade it performed? It's very important to me to know exact time when upgrade was done, so please pay attention to timezones. (You are probably in the same one as I am, CET, so you can tell me local time you are seeing.)

[Krstarica]

/wp-admin/about.php shows WORDPRESS 5.7.1.

Query Monitor plugin shows Version 5.7.1.

wp-cli shows:

wp> $GLOBALS['wp_version'];
=> string(5) "5.7.1"

But how to be sure that all files are really updated? Maybe new feature "File health check" should be implemented, i.e. to validate checksum for all system files every day?

All sr_RS instances have the same issue and got auto-updated starting with Thu, 15 Apr 2021 06:14:46 +0000 (that's 08:14:46 CEST) and ending with Thu, 15 Apr 2021 10:39:58 +0000.

en instance is auto-updated on Thu, 15 Apr 2021 03:20:03 +0000 and does not have this issue.

This happens every time for months or even more. We usually then manually update every instance, but often we need to do it several times in a row, until the version changes.

[dimadin]

@Krstarica Did you have the same issue after version 5.7.2? Was anything different?

[Krstarica]

@dimadin Automatic upgrade to 5.7.2 worked just fine.

Did you make any changes?

[stodorovic]

I've checked WP core auto-updates (5.7.1 -> 5.7.2) in previous weeks and I didn't find any issues (various locales including couple sr_RS installations).

[stodorovic]

It looks that's same issue with WP 5.8. I just checked "responses":

$ curl -X POST "https://api.wordpress.org/core/version-check/1.7/?version=5.8&php=7.4.21&locale=sr_RS&initial_db_version=49752"
{"offers":[{"response":"upgrade","download":"https:\/\/downloads.wordpress.org\/release\/sr_RS\/wordpress-5.8.zip","locale":"sr_RS",...
$ curl -X POST "https://api.wordpress.org/core/version-check/1.7/?version=5.8&php=7.4.21&locale=fr_FR&initial_db_version=49752"
{"offers":[{"response":"latest","download":"https:\/\/downloads.wordpress.org\/release\/fr_FR\/wordpress-5.8.zip","locale":"fr_FR",...
$ curl -X POST "https://api.wordpress.org/core/version-check/1.7/?version=5.8&php=7.4.21&locale=en_US&initial_db_version=49752"
{"offers":[{"response":"latest","download":"https:\/\/downloads.wordpress.org\/release\/wordpress-5.8.zip","locale":"en_US",...

[dimadin]

@stodorovic When did you upgrade to the version 5.8? Was it before 1AM CEST?

[stodorovic]

Yes, it was at Jul 20 (maybe around 23:00 CEST). It still shows notice about update.

I tried update on another website (few hours ago) and it looks that works.

[dimadin]

If your sites autoupdated from 5.8 to 5.8.1 before now, 0640 AM (CEST), my guess is that you should see that new version is released. If they didn't update, my guess is that you shouldn't see once your sites are updated.

[dimadin]

If your sites autoupdated from 5.8.1 to 5.8.2 between 0715 PM and 0730 PM (CET), my guess is that you should see that new version is released. If they didn't update, my guess is that you shouldn't see once your sites are updated.

[Krstarica]

@dimadin

WordPress sites were updated to 6.4.1 on 9 November.

On 13 November on instances using Serbian locale started seeing messages that the new version is available ("Vordpres 6.4.1 je dostupan! Molimo vas da odmah ažurirate"), although that version is already installed.