WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 7 weeks ago

#27832 new defect (bug)

All sites automatically marked as archived after upgrade

Reported by: pavelevap Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.7
Component: Networks and Sites Keywords: needs-patch needs-testing
Focuses: multisite Cc:

Description

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

Change History (10)

#1 @ocean90
4 years ago

From which version have you updated?

Maybe an issue with [25448]/#12832.

#2 @SergeyBiryukov
4 years ago

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.

#3 @pavelevap
4 years ago

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?

#4 @wonderboymusic
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

#5 @chriscct7
2 years ago

  • Keywords needs-testing added

#6 @jeremyfelt
2 years ago

  • Milestone changed from Future Release to Awaiting Review
  • Version changed from 3.8.3 to 3.7

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.

#8 @jeremyfelt
7 weeks ago

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.

#9 @jeremyfelt
7 weeks ago

#39325 was marked as a duplicate.

#10 @jeremyfelt
7 weeks ago

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

Note: See TracTickets for help on using tickets.