All sites automatically marked as archived after upgrade

[pavelevap]

Strange thing, all sites were automatically marked as archived after automatic upgrade to 3.8.3. Maybe it is not related, but it was the last thing which is time-related to this problem.

I checked database tables and all sites had archived = 1 in wp_blogs, but last_update column was not changed. So, it suggests, that it was not done by administrator. Administrator can archive primary site? Then it is not possible to access administration...

I repaired it by setting 0 for all sites, but I am not sure, how could it happen? Do you have any ideas? There are no plugins which could cause it. I searched code and did not find any clue. Also hosting company is used for many other Multisite installations without problems.

There are also some posts from different forums (usually somehow related to WordPress upgrade), but they are only talking about fixing problem and not about finding why...

​http://wordpress.org/support/topic/site-automagically-archived-or-suspended-on-multisite
​http://wordpress.org/support/topic/after-install-site-has-been-suspended-or-archived
​http://wpgarage.com/tips/unarchive-archived-suspended-site-wordpress-multisite/

Not sure, if it is some kind of bug, incompatibility or security hole...

[ocean90]

From which version have you updated?

Maybe an issue with [25448]/#12832.

[SergeyBiryukov]

This happened to me once too. I guess the second set of queries in [25448] failed.

It seemed like an edge case, so I didn't report it.

[pavelevap]

It is not my website, but user with problems gave me access. It was only automatic update from 3.8.2 to 3.8.3 (only some changed files).

I noticed changes in 3.7.x, but this website was using 3.8.x and why there were no problems with automatic updates from 3.8.1 to 3.8.2? Maybe something with not clicking "Upgrade network" button during automatic upgrade?

[jeremyfelt]

This really only seems plausible when upgrading from pre-3.7 to post-3.7 because of the queries in [25448]. And then, it really only seems like this could happen if the first ALTER query failed and the second ALTER query was successful. At that point, 0 would become 1, 1 would become 2.

ALTER TABLE $wpdb->blogs CHANGE COLUMN archived archived varchar(1) NOT NULL default '0'
ALTER TABLE $wpdb->blogs CHANGE COLUMN archived archived tinyint(2) NOT NULL default 0

The auto upgrade from 3.8.2 -> 3.8.3 only contained a few post status related changes. Unless the database changes from 3.7 had not yet been applied, I'm not sure how the timing would work.

We can probably close this as something very unlikely to happen, though it would be nice to know if a MySQL error was generated at some point during the upgrade as well as the version of MySQL used.

[SergeyBiryukov]

Related: #38856

[jeremyfelt]

In 41700:

Multisite: Use %s when building query for archived sites in WP_Site_Query.

In [25548], the archived column in wp_blogs was changed from ENUM to TINYINT to match other status fields. When WP_Site_Query was written later, it used %d as a placeholder when formatting the archived status.

It is possible that this query will fail for any installations that did not update the schema for wp_blogs as only single quoted values are accepted for the ENUM type. In this case, '0' or '1' rather than 0 or 1.

We can work around this and support both ENUM and TINYINT in the query by using the %s placeholder and casting the value with absint().

Props stephdau.
Fixes #38856. See #27832.

[jeremyfelt]

#39325 was marked as a duplicate.

[jeremyfelt]

#39325 had the same issue as this ticket after an upgrade. Information on the database is in that ticket.

[CoenJacobs]

I experienced the same issue with an update to 5.0 from 4.9.8. All sites, including the main site were set to archived. Haven't been able to investigate properly yet. By the looks of it, the fixes done in this ticket haven't caught all occurances of this bug yet, though.