Make WordPress Core

Opened 12 years ago

Closed 5 years ago

Last modified 4 years ago

#19755 closed enhancement (fixed)

Redundant blog_versions table

Reported by: johnbillion's profile johnbillion Owned by: whyisjake's profile whyisjake
Milestone: 5.3 Priority: normal
Severity: minor Version: 3.0
Component: Networks and Sites Keywords: has-patch has-dev-note
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 (4)

19755.patch (2.9 KB) - added by johnbillion 12 years ago.
19755.2.patch (2.3 KB) - added by spacedmonkey 7 years ago.
19755.3.diff (2.0 KB) - added by whyisjake 5 years ago.
19753.4.diff (2.1 KB) - added by whyisjake 5 years ago.

Download all attachments as: .zip

Change History (36)

@johnbillion
12 years ago

#1 @johnbillion
12 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
12 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
12 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
12 years ago

  • Component changed from Database to Multisite

#5 @spacedmonkey
7 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.


7 years ago

#7 @johnjamesjacoby
7 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
7 years ago

  • Milestone set to Awaiting Review

#9 @spacedmonkey
7 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.


7 years ago

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


7 years ago

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


7 years ago

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


7 years ago

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


7 years ago

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


7 years ago

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


6 years ago

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


5 years ago

#18 @spacedmonkey
5 years 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.


5 years ago

#20 @davidbaumwald
5 years ago

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

@whyisjake
5 years ago

#21 @whyisjake
5 years ago

  • Keywords needs-refresh removed

#22 @whyisjake
5 years ago

  • Keywords needs-testing added

#23 @whyisjake
5 years ago

@johnjamesjacoby can you take a look at this refresh?

#24 @johnjamesjacoby
5 years 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
5 years 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
5 years 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
5 years ago

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

#28 @whyisjake
5 years ago

In 46193:

Networks and Sites: Save database version in site meta (Multisite)

Currently there is there a table in multisite called blog_versions. All this table stores is the database version as number and the date updated. With plans to add site meta in #37923 this new table should be used. This has a number of benefits, including functions to CRUD these values in the database. Once this data is in the blogmeta, table, the blog_versions table can be removed all together. If require a SQL view can be used blog_versions from data stored in blogmeta.

Props spacedmonkey, leogermani.

Fixes #41685. See #19755.

@whyisjake
5 years ago

#29 @whyisjake
5 years ago

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

In 46194:

Multisite: Remove the redundant blog_versions table.

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.

Props johnbillion, nacin, ryan, johnjamesjacoby, whyisjake.

Fixes #19755. See #41685.

#30 @spacedmonkey
4 years ago

  • Keywords needs-dev-note added

This is a big change that requires a dev note.

#31 @spacedmonkey
4 years ago

  • Component changed from Multisite to Networks and Sites
Note: See TracTickets for help on using tickets.