Make WordPress Core

Opened 2 months ago

Closed 2 months ago

Last modified 2 months ago

#60518 closed defect (bug) (fixed)

Plugin Dependencies: Avoid unnecessary DB writes

Reported by: joemcgill's profile joemcgill Owned by: joemcgill's profile joemcgill
Milestone: 6.5 Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: has-patch needs-testing
Focuses: performance Cc:


The Plugin Dependencies feature adds additional DB queries to every request by saving the list of dependencies that were deactivated to a new transient, wp_plugin_dependencies_deactivated_plugins with an expiry time of 10 seconds.

In most cases, when there are no plugins to deactivate, these extra DB operations seem to be unnecessary. We could check whether the array is empty in WP_Plugin_Dependencies::deactivate_dependents_with_unmet_dependencies and return early if we know there are no plugins that need to be disabled.

Change History (10)

This ticket was mentioned in PR #6093 on WordPress/wordpress-develop by @joemcgill.

2 months ago

  • Keywords has-patch added

This PR returns early if in WP_Plugin_Dependencies::deactivate_dependents_with_unmet_dependencies() if there are no plugins to deactivate, which avoids unnecessary DB operations related to saving the list to a transient for use in WP_Plugin_Dependencies::display_admin_notice_for_deactivated_dependents().

In my tests, this takes the number of DB queries run on a homepage of Twenty Twenty-four from 29, down to 25.

Trac ticket:

#2 @joemcgill
2 months ago

  • Focuses performance added
  • Keywords needs-testing added
  • Owner set to joemcgill
  • Status changed from new to accepted

@joemcgill commented on PR #6093:

2 months ago

The performance test results for this PR look promising, and in line with the measurements I've taken locally. In all cases shown in that summary, the wpBeforeTemplate metric, which measures the amount of time spent before the templates are rendered, have all decreased by several ms.

@afragen commented on PR #6093:

2 months ago

Just remember the idea for this was to deactivate plugins with unmet dependencies that changed by any means.

@costdev commented on PR #6093:

2 months ago

@afragen True, though if none are detected by the loop, there shouldn't be any reason to perform DB operations, yeah?

#6 @joemcgill
2 months ago

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

In 57617:

Upgrade/Install: Avoid unnecessary db operations for plugin dependencies.

The Plugin Dependencies feature saves a list of any plugins that have been disabled due to unmet dependencies to a transient in order to give user feedback in the admin about what has taken place. This ensures that the DB operations to write this transient is skipped if there are no dependent plugins to deactivate.

Props joemcgill, costdev, afragen.
Fixes #60518.

@youknowriad commented on PR #6093:

2 months ago

Looking at the summary of the performance job of this PR. It's promising (wpBeforeTemplate metric)

@youknowriad commented on PR #6093:

2 months ago

Looking at the summary of the performance job of this PR. It's promising (wpBeforeTemplate metric)

This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.

2 months ago

#10 @costdev
2 months ago

In 57658:

Plugin Dependencies: Remove auto-deactivation and bootstrapping logic.

Automatic deactivation of dependents with unmet dependencies requires a write operation to the database. This was performed during Core's bootstrap, which risked the database and cache becoming out-of-sync on sites with heavy traffic.

No longer loading plugins that have unmet requirements has not had a final approach decided core-wide, and is still in discussion in #60491 to be handled in a future release.

The plugin_data option, used to persistently store plugin data for detecting unmet dependencies during Core's bootstrap, is no longer needed.

Follow-up to [57545], [57592], [57606], [57617].

Props dd32, azaozz, swissspidy, desrosj, afragen, pbiron, zunaid321, costdev.
Fixes #60457. See #60491, #60510, #60518.

Note: See TracTickets for help on using tickets.