"WordPress 2.7 is available! Please update now." Displayed in WordPress 2.7 Dashboard.

[miqrogroove]

Something seems terribly wrong here. WordPress 2.7 is telling me to upgrade to WordPress 2.7. :o

[miqrogroove]

Dashboard Screenshot

[miqrogroove]

For reference: Same problem reported by TK009 at ​http://wordpress.org/support/topic/228444

[miqrogroove]

See also ​http://wordpress.org/support/topic/224440

[miqrogroove]

See also ​http://wordpress.org/support/topic/224582

[miqrogroove]

Screenshot by Erunafailaro

[miqrogroove]

Possible workaround, see ​http://wordpress.org/support/topic/225686

[mrmist]

I suspect this is a locale issue, as it seems to be affecting German and Spanish users.

I haven't been able to reproduce it yet though, even against a German install.

[miqrogroove]

Hi mrmist. I'm afraid I don't have much to add about the cause of the problem. Reproducibility appears to be "random" even on my own website. I happen to be using multiple locales through the qTranslate plugin, but I don't see how this should affect the equality of 2.7 and 2.7.

[miqrogroove]

Aha! If I'm reading wp_version_check() correctly, then the problem is in the API Server, not WordPress.

 * The WordPress version, PHP version, and Locale is sent. Checks against the
 * WordPress server at api.wordpress.org server. Will only check if WordPress
 * isn't installing.

I will attempt to analyze the $url value and server response to see what is going on.

[DD32]

hmm... You dont have that crazy paranoid plugin installed which is designed to block the WordPress version from being shown are you?

[miqrogroove]

I think I have confirmed a problem with the API Server.

Request:

​http://api.wordpress.org/core/version-check/1.3/?version=2.7&php=2.5.8&locale=en_US&mysql=5.0.67-community-log&local_package=

Response:

latest
http://wordpress.org/download/
http://wordpress.org/wordpress-2.7.zip
2.7
en_US

Request:

​http://api.wordpress.org/core/version-check/1.3/?version=2.7&php=2.5.8&locale=zh_CN&mysql=5.0.67-community-log&local_package=

Response:

upgrade
http://cn.wordpress.org/
http://cn.wordpress.org/wordpress-2.7-zh_CN.zip
2.7
zh_CN

[miqrogroove]

Current Workaround

Find this line in wp-includes/update.php

	$local_package = isset( $wp_local_package )? $wp_local_package : '';

Replace with

	$local_package = $locale;

[miqrogroove]

Copied from ​http://wordpress.org/support/topic/240008

[miqrogroove]

Mark A. reports the above workaround did not resolve the issue for him at ​http://wordpress.org/support/topic/240008#post-977857

This suggests to me there is more than one flaw in wp_version_check().

[nbachiyski]

What do you see when you go to Tools -> Upgrade? If there the only suggested version is a local one you will be able to hide it. Some more clarifications follow.

There are two ways to localize WordPress:

1. Drop some translation files.
2. Install localized package.

Whenever possible we try to enforce the 2nd way.

So, here is how the whole thing works:

1. Both the current locale and the current localized package, installed, are sent to the API.
2. If a localized package for the user's locale is available and the user doesn't have the localized package, the user is prompted to upgrade or to hide updgrade.

I would be happy if somebody proposes a better way to communicate this behaviour interface-wise.

[miqrogroove]

I would be happy if somebody proposes a better way to communicate this

Actually, none of that made any sense to me. I can only read English, so "Interface-wise" I would never need or want to know aboutt localized packages.

[nbachiyski]

Replying to miqrogroove:

I would be happy if somebody proposes a better way to communicate this

Actually, none of that made any sense to me. I can only read English, so "Interface-wise" I would never need or want to know aboutt localized packages.

If you are using only English how come your blog's locale is zh_CN?

[miqrogroove]

Replying to nbachiyski:

If you are using only English how come your blog's locale is zh_CN?

Locale is a per-user setting.

[nbachiyski]

The multi-language plugins need to be able to control what locale is used for version checks. Here is a patch, which adds a filter for it.

miqrogroove, could you try the patch and something along this line in your multilanguage plugin:

add_filter( 'core_version_check_locale', create_function( '$_', 'return "en_US";' ) );

That should do the trick.

In order to force an update, delete the update_core option or see #9108.

[miqrogroove]

nbachiysk, I think I have reached the limit of my ability in this matter. I reported a math error (2.7 != 2.7) and attempted to diagnose it. Talk of filters and plugin patches must be either off topic or way over my head.

[nbachiyski]

miqrogroove, at least -- what plugin are you using to allow users to set their language?

[miqrogroove]

I'm using qTranslate. I can't speak for everyone else though.

[miqrogroove]

I'm not sure if this is relevant between version numbers, but I found the update-core screen mentioned by nbachiyski

[nbachiyski]

Here's the patch, mentioned in the previous comment.

[ryan]

(In [10772]) Add core_version_check_locale filter. Props nbachiyski. see #8729

[ryan]

(In [10773]) Add core_version_check_locale filter. Props nbachiyski. see #8729 for 2.7

[nbachiyski]

I wrote to the Gengo and qTranslate authors and asked them to filter it and set it to en_US.

[nbachiyski]

Talking to users, the most common problem is that they are confused why do they have to upgrade to the same localized version, if theyt already have WordPress translated. Here is a patch, which adds a hint.

[Denis-de-Bernardy]

-1 on the last patch. Imo, WP (or a plugin) should hide the upgrade if the locale are not up to date. Ot something like that. Basically, it shouldn't confuse the user in the first place.

[nbachiyski]

Denis, let's take the following case: you have a Wordpress 2.7.1 with a German MO file. Then the German local package is released. What should we do?

1. Don't show a upgrade notice at all. This way the user may be running a old MO file and may not know how to get the new translaiton. In this case we won't confuse the user. I don't think that's the acceptable solution. We should encourage users to upgrade to local versions.

2. Show the upgrade notice. Either if we show the Hide button or we don't, we confuse the user. I preferred the former, because it's not so hard to let the user make an informed decision about hiding the local upgrade.

[Denis-de-Bernardy]

Quite honestly, I'd be curious to know how long it takes for the mo file to get updated.

For what it's worth, here's what I do with my customers: I disable WP update notifications entirely. Only when a new version of Semiologic Pro is around (usually a week or two later), do they receive a notification. That way, they're not confused into upgrading WP when the latter can potentially break the plugins that they use. Once I make sure everything works fine do they see a nag in their admin area. And Tools / Upgrade will conveniently let them upgrade WP, and my themes, and my plugins, all in one go.

Now, I arguably don't maintain mo files, but it seems to me that localized versions of WP should behave more or less the same, at least until a reasonably long amount of time has elapsed. As long as their install can potentially "break" (in the sense that it won't show captions in their preferred language), they should not see the nag. When Tools / Upgrade will give the correct mo file alongside WP, they should get the nag.

Arguably, some mo files might be dropped at some point from lack of support by translation teams. For this reason, we could consider that a week or two after the initial WP update is a long enough delay. If the mo isn't done by then, we could consider that nobody is maintaining the mo file.

Along the same lines, it might make sense to only enforce the above-mentioned behavior for major updates (e.g. 2.6 to 2.7), and not for minor ones (2.6 to 2.6.1). After all, minor updates are frequently security related, and it's better to have wrong caption or two than a hopelessly hacked site.

[Denis-de-Bernardy]

With that being said, it's just my $.02 of opinion. If anything, I'd suggest posting a link to this to the localization team list. Their opinions would be the ones we should take into account. ;-)

[xibe]

Replying to Denis-de-Bernardy:

Quite honestly, I'd be curious to know how long it takes for the mo file to get updated.

It depends entirely on each locale's team. Some team try to make sure the locale version is available in the hours following the release of WP, while other teams catch up in the following weeks, even months sometimes.

For this reason, we could consider that a week or two after the initial WP update is a long enough delay. If the mo isn't done by then, we could consider that nobody is maintaining the mo file.

We can't work that way. A team should not be dropped just because they are slower than others. I'd rather have a team working at their pace on a translation, than no team at all. To each his own.

Along the same lines, it might make sense to only enforce the above-mentioned behavior for major updates (e.g. 2.6 to 2.7), and not for minor ones (2.6 to 2.6.1). After all, minor updates are frequently security related, and it's better to have wrong caption or two than a hopelessly hacked site.

Agreed, although I fail to see how not upgrading a locale version can prevent hacking. Maybe I misunderstood you :)

[Denis-de-Bernardy]

Replying to xibe:

Replying to Denis-de-Bernardy:

Along the same lines, it might make sense to only enforce the above-mentioned behavior for major updates (e.g. 2.6 to 2.7), and not for minor ones (2.6 to 2.6.1). After all, minor updates are frequently security related, and it's better to have wrong caption or two than a hopelessly hacked site.

Agreed, although I fail to see how not upgrading a locale version can prevent hacking. Maybe I misunderstood you :)

Somewhat. ;-) I was meaning it was better it have a slightly not up to date .mo file than a hacked site.

[xibe]

Somewhat. ;-) I was meaning it was better it have a slightly not up to date .mo file than a hacked site.

Agreed, then :)

[Denis-de-Bernardy]

punting to future, pending feedback

[nbachiyski]

The hint I want to add is totally harmless and it is worth trying it for 2.8 to see if it will resolve some of the confusion. Otherwise we won't get much feedback.

[Denis-de-Bernardy]

true. :-)

[ryan]

(In [11273]) Add locale upgrade hint. Props nbachiyski. fixes #8729

[michelvaldrighi]

I upgraded a localised svn-less 2.7 installation to 2.8 using the tag in svn and manually placed the .mo and .po files in wp-content/languages/, yet I didn't get the hint about the translation.

Perhaps something peculiar in this install. I'll try to reproduce the problem using a clean room install later.

However, I didn't need to use the fix proposed in ​comment 10.
Adding this line to wp-config.php (and waiting for WP to check versions again) was enough since WP checks for this global without ever setting it:

$wp_local_package = 'fr_FR'; // use your locale string there

To anyone still stumbling on this bug report from the forums, I think it's a nicer workaround than editing core WP files or adding a plugin to sweep the notifications under the carpet…

[piouPiouM]

Why use the global $wp_local_package?
Is it different from the WPLANG constant? (If the constant WPLANG is not empty, WordPress is localized and use a local package.)

If not, we could simply use get_locale() instead of the global $wp_local_package for set the local_package argument required by the version_check API. Plugins can use the filter core_version_check_locale to define the local argument.

Or, if the global $wp_local_package not exists, we could consider that the package used locally is identical to get_locale() returns:

$local_package = isset($wp_local_package) ? $wp_local_package : get_locale();

[nbachiyski]

Replying to piouPiouM:

Why use the global $wp_local_package?
Is it different from the WPLANG constant? (If the constant WPLANG is not empty, WordPress is localized and use a local package.)

It is different. The local package contains other modifications, not only a translation. That's why we need to know whether just the locale is set or it is also a local pckage.