WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#8729 closed defect (bug) (fixed)

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

Reported by: miqrogroove Owned by: nbachiyski
Milestone: 2.8 Priority: high
Severity: major Version: 2.8
Component: I18N Keywords: has-patch commit dev-feedback
Focuses: Cc:

Description

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

Attachments (6)

wpwtf.jpg (96.1 KB) - added by miqrogroove 5 years ago.
Dashboard Screenshot
2008-12-12_060542.png (27.7 KB) - added by miqrogroove 5 years ago.
Screenshot by Erunafailaro
updatewp27im4.png (87.0 KB) - added by miqrogroove 5 years ago.
Copied from http://wordpress.org/support/topic/240008
2.7 to 2.7.1 View of update-core.gif (12.3 KB) - added by miqrogroove 5 years ago.
I'm not sure if this is relevant between version numbers, but I found the update-core screen mentioned by nbachiyski
filter-core-update-locale.diff (456 bytes) - added by nbachiyski 5 years ago.
local-upgrade-hint.diff (1.5 KB) - added by nbachiyski 5 years ago.

Download all attachments as: .zip

Change History (48)

miqrogroove5 years ago

Dashboard Screenshot

comment:1 miqrogroove5 years ago

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

miqrogroove5 years ago

Screenshot by Erunafailaro

comment:5 mrmist5 years ago

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.

comment:6 miqrogroove5 years ago

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.

comment:7 miqrogroove5 years ago

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.

comment:8 DD325 years ago

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

comment:9 miqrogroove5 years ago

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

comment:10 miqrogroove5 years ago

Current Workaround

Find this line in wp-includes/update.php

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

Replace with

	$local_package = $locale;

comment:11 ryan5 years ago

  • Owner changed from anonymous to nbachiyski

comment:12 ryan5 years ago

  • Component changed from General to i18n

comment:13 miqrogroove5 years ago

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().

comment:14 nbachiyski5 years ago

  • Status changed from new to assigned

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.

comment:15 follow-up: miqrogroove5 years ago

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.

comment:16 in reply to: ↑ 15 ; follow-up: nbachiyski5 years ago

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?

comment:17 in reply to: ↑ 16 miqrogroove5 years ago

Replying to nbachiyski:

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

Locale is a per-user setting.

comment:18 nbachiyski5 years ago

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.

comment:19 miqrogroove5 years ago

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.

comment:20 nbachiyski5 years ago

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

comment:21 miqrogroove5 years ago

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

miqrogroove5 years ago

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

comment:22 nbachiyski5 years ago

  • Keywords has-patch added

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

comment:23 ryan5 years ago

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

comment:24 ryan5 years ago

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

comment:25 nbachiyski5 years ago

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

comment:26 nbachiyski5 years ago

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.

comment:27 nbachiyski5 years ago

  • Milestone changed from 2.7.2 to 2.8

comment:28 Denis-de-Bernardy5 years ago

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

comment:29 nbachiyski5 years ago

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

comment:30 follow-up: Denis-de-Bernardy5 years ago

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.

comment:31 Denis-de-Bernardy5 years ago

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. ;-)

comment:32 in reply to: ↑ 30 ; follow-up: xibe5 years ago

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 :)

comment:33 in reply to: ↑ 32 ; follow-up: Denis-de-Bernardy5 years ago

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.

comment:34 in reply to: ↑ 33 xibe5 years ago

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

Agreed, then :)

comment:35 Denis-de-Bernardy5 years ago

  • Keywords dev-feedback added

comment:36 Denis-de-Bernardy5 years ago

  • Milestone changed from 2.8 to Future Release

punting to future, pending feedback

comment:37 nbachiyski5 years ago

  • Milestone changed from Future Release to 2.8

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.

comment:38 Denis-de-Bernardy5 years ago

  • Keywords commit added

true. :-)

comment:39 ryan5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:40 michelvaldrighi5 years ago

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…

comment:41 follow-up: piouPiouM5 years ago

  • Cc piouPiouM added
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 2.7 to 2.8

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();

comment:42 in reply to: ↑ 41 nbachiyski5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.