WordPress MU

I've got the latest MU version on my test server (2.8.5.2), and I notice that in the wp_blog_versions table, the db_version value is 11548--which is consistent with what regular WordPress db version is (at least, according to http://codex.wordpress.org/FAQ_Installation. I did a SQL query to see what my 2.8.4a production instance would show, and it's listing db_version for ALL my blogs as 9842, which according to the aforementioned link is what the verison is for 2.7.

So that begs the question ... did my blogs ever get updated going from 2.7 to 2.8? I used the upgrade site option when we rolled out 2.7 but didn't do so when going to 2.8 because it was explained to me that all blogs would be updated when users next logged in. And didn't the upgrade site feature disappear from 2.7.1 to 2.8 and again reappear from 2.8.4a to 2.8.5? Is this because the "user login" upgrade method never worked?

I'm confused. In any case, if someone can explain what the db_version table is used for, that would be great. I assume this is what gets checked when the application gets flagged for an upgrade ...

Easiest way to check so the numbers don't confuse:

- go to a user blog
- login to the backend
- look at the widgets page

If it's the newer widgets, then yes. You are upgraded.

I work with Lance, so let me follow-up.

Assuming he is upgraded, what problems will this incorrect version number in the database cause for future upgrades? Surely some process uses this when doing upgrades, right?

Has anyone else experienced this bug? It appears that the last time this field was updated was when he upgraded all blogs. Once we went to the new process of upgrading as users log in, it seems that this field was never updated again.

Andrea, our biggest concern is that we want to make sure we're testing upgrades from 2.8.4 to 2.8.5.2 and not something like from 2.7.1 to 2.8.5.2. Trying to avoid unexpected problems when we upgrade our production server, and if we can't clearly determine which version are users are actually on ... anyway, I suppose the widgets look right--they're drag 'n drop, if that helps. Here's a similar thread about this problem: http://mu.wordpress.org/forums/topic/9259?replies=5.

I went and checked one of my installs, and they don't even all have the same number.

MU just looks at it to compare against the current version when it does an upgrade. If the number n the db is the same as new version, then it won't upgrade that blog. If it's lower, it will.

The actual number is almost irrelevant, as a previous issue (blogs showing they needed upgrading when they in fact did not) was fixed when we manually went in and changed this number to something arbitrary. Subsequent upgrades after that were fine.

"If the number n the db is the same as new version, then it won't upgrade that blog. "

Ok, that is what I assumed. However, NONE of our blogs are the same as the new version yet we believe those people who have logged in are upgraded--or appear to be upgraded. The version number in the database is from 2.7 which we went to back in April. If some of those blogs have been updated (and we know they have) then why aren't at least SOME of the version numbers more current? I don't understand.

If it works like you said it should work and since all of our blog version numbers correspond to 2.7, shouldn't EVERYONE be upgraded EVERYTIME they've logged in since April? I just don't think I follow...

The number not being updated doesn't correspond with the blog being updated. I have some in my own install that are 3458, yet when I check the backend, they are clearly running the latest version.

So can we tell what version a blog is on based on some field in the database? How does the upgrade code know whether a not a blog should be upgraded?

There's a serialized array stored in the wp_sitemeta table. Look for meta_key = 'update_core'. It checks the data in that serialized array against what is available at mu.wordpress.org twice a day, by default.