WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 17 hours ago

#19755 assigned enhancement

Redundant blog_versions table

Reported by: johnbillion Owned by: whyisjake
Milestone: 5.3 Priority: normal
Severity: minor Version: 3.0
Component: Multisite Keywords: has-patch
Focuses: multisite Cc:

Description

As part of the Multisite installation process, a blog_versions table is created. This table is never read from (except immediately prior to updating it), it's only ever inserted into or updated. It is not used to determine which blogs need to be upgraded.

This table was introduced in 3.0 when the WPMU schema was merged (#11644) and it appears the table has never been used in core and is therefore redundant and may as well be removed.

Attachments (3)

19755.patch (2.9 KB) - added by johnbillion 8 years ago.
19755.2.patch (2.3 KB) - added by spacedmonkey 3 years ago.
19755.3.diff (2.0 KB) - added by whyisjake 7 days ago.

Download all attachments as: .zip

Change History (30)

@johnbillion
8 years ago

#1 @johnbillion
8 years ago

  • Keywords has-patch dev-feedback added

Patch just in case, and because I've not done a patch which changes the DB schema before. Hopefully it's all present and correct.

#2 @ryan
8 years ago

I believe wordpress.com and some other big multisite hosts use it for managing upgrades. That's not necessarily a reason the keep the table, but core might someday find blog_versions valuable if we ever improve the currently very lame network upgrade process.

#3 @nacin
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

That's not necessarily a reason the keep the table, but core might someday find blog_versions valuable if we ever improve the currently very lame network upgrade process.

Agreed.

#4 @nacin
7 years ago

  • Component changed from Database to Multisite

#5 @spacedmonkey
3 years ago

  • Keywords needs-refresh added
  • Resolution maybelater deleted
  • Status changed from closed to reopened

I think a better way forward for blog_versions table is to not create it on new WordPress installs. Then put a checks in place for the one place in core that writes to the table to check if the table exists before writing to it. This also means that if you have an existing site that you want to get rid of this table, then you can manually delete it.

This is a nice solution as it is backwards compatible but also means you can removed blog_versions if you want as well.

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


3 years ago

#7 @johnjamesjacoby
3 years ago

See also #37923.

Imagine that global wp_blogmeta table, and this feature being saved there, with a db_version meta_key and that same numeric value.

#8 @SergeyBiryukov
3 years ago

  • Milestone set to Awaiting Review

#9 @spacedmonkey
3 years ago

  • Focuses multisite added
  • Keywords needs-testing added; needs-refresh removed

I updated the patch for this. The new patch is very simple.

  • Don't create table on new sites installs
  • Check to see if table exists before writing to it.

This needs testing. Both creating a new site, an existing site with the table and with the table manually removed.

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


3 years ago

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


19 months ago

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


4 months ago

#18 @spacedmonkey
4 months ago

  • Keywords dev-feedback needs-testing removed
  • Milestone changed from Awaiting Review to 5.3

This ticket was mentioned in Slack in #core by david.baumwald. View the logs.


7 days ago

#20 @davidbaumwald
7 days ago

  • Keywords needs-refresh added
  • Owner set to whyisjake
  • Status changed from reopened to assigned

@whyisjake
7 days ago

#21 @whyisjake
7 days ago

  • Keywords needs-refresh removed

#22 @whyisjake
7 days ago

  • Keywords needs-testing added

#23 @whyisjake
19 hours ago

@johnjamesjacoby can you take a look at this refresh?

#24 @johnjamesjacoby
19 hours ago

  • Keywords commit added; needs-testing removed

@whyisjake looks good to me.

In addition, since WordPress 5.0 and #39723, anyone wanting to save Site versions to a shared global database table should explore using wp_blogmeta.

#25 follow-up: @spacedmonkey
19 hours ago

  • Keywords commit removed

@johnjamesjacoby The patch 19755.3.diff is not what was agreed in the multisite chats. My patch 19755.2.patch was. 19755.3.diff is a breaking change as it removes the code the writes to this table. My patch just doesn't install the table on new sites and still writes to the existing table if it existing. This is much safer way of doing this.

But this goes in, I would like to see 41685 go in first.

#26 in reply to: ↑ 25 @johnjamesjacoby
19 hours ago

Replying to spacedmonkey:

@johnjamesjacoby The patch 19755.3.diff is not what was agreed in the multisite chats. My patch 19755.2.patch was.

I’m OK with either, but I prefer @whyisjake’s approach of simply removing support for it.

@johnbillion’s point is that this table hasn’t been used in core since 2010 (nine years of dead code.) If anyone (wpcom) is still using this table, they’d need to be using the hook immediately after it or rolling their own support for it.

I’m also OK with 41685 fwiw.

Similar to global terms, this is a multisite feature that hasn’t worked nor seen any requests for it to in nearly a decade. If someone feels more strongly about keeping it, that’s OK too.

Cc @bazza for a wpcom consult?

#27 @whyisjake
17 hours ago

Got confirmation from @bazza that the table isn't used on WPCOM.

Note: See TracTickets for help on using tickets.