Make WordPress Core

Opened 8 years ago

Closed 5 years ago

Last modified 5 years ago

#37984 closed enhancement (wontfix)

Relocate either dbDelta() or wp_should_upgrade_global_tables() out of upgrade.php

Reported by: johnjamesjacoby's profile johnjamesjacoby Owned by:
Milestone: Priority: low
Severity: minor Version: 4.3
Component: Database Keywords:
Focuses: performance Cc:

Description

I have a need to use dbDelta() inside a plugin that creates custom global database tables.

I'd like to use wp_should_upgrade_global_tables() before deciding to pull in all of upgrade.php just to use dbDelta(). This is not currently possible, because wp_should_upgrade_global_tables() is located inside of upgrade.php along with dbDelta(), meaning I need to pull in that file on every admin_init, just to check if the environment is right to allow global table upgrades to continue.

In my research of how to best solve this problem for myself, I see 1 of 2 possible outcomes:

  • Move dbDelta(), wp_should_upgrade_global_tables() or both, out of upgrade.php, probably to load.php
  • Leave it alone, deal with plugins burning a few extra CPU cycles, and close this issue as wontfix, because having either of these two functions always included doesn't make much sense either

Change History (3)

#1 @pento
5 years ago

  • Keywords 2nd-opinion removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Upgrading tables in admin_init isn't something I really want to encourage.

Rather, folks should hook into the wp_upgrade action, and upgrade their tables the same time as Core does.

#2 @johnjamesjacoby
5 years ago

folks should hook into the wp_upgrade action, and upgrade their tables the same time as Core does

Erm. Unfortunately for most plugins with their own database tables, this is impossible.

That action only fires when there is a core upgrade, not when there is a plugin needing its own upgrade, for which there is no equivalent – hence why plugins roll their own, hence why there is a need to make these functions more accessible.

Performing a plugin database upgrade on admin_init is not vastly different than core running it’s own repair.php redirect to an unauthorized visitor.

3rd-opinion, possibly? :)

#3 @pento
5 years ago

Ah, I see what you're after.

Is it an option to hook into upgrader_process_complete (which will run after the plugin is upgraded, but still in the process with the pre-upgraded code), and then have a schema.php file in your plugin that you can load, to apply the table updates immediately?

Alternatively:

  • If it's a manual upgrade:
    • Set a flag in your plugin options to run the table upgrade process on the next page load.
  • If it's an auto upgrade:
    • Schedule a single cron event to run the upgrade process the next time cron is fired.
Note: See TracTickets for help on using tickets.