Opened 7 years ago
Last modified 2 months ago
#42743 assigned defect (bug)
Disable wp_options autoload for inactive widgets
Reported by: | ComputerGuru | Owned by: | pbearne |
---|---|---|---|
Milestone: | 6.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Widgets | Keywords: | needs-patch early |
Focuses: | performance | Cc: |
Description
Options/settings for all widgets are saved in wp_options with autoload=yes, but autoload is enabled for the wp_options even for deactivated widgets.
On sites with many widgets installed (but not even activated), the size of data transferred from the DB to the PHP host on each and every page request can add significant overhead and introduce noticeable slowdowns.
I can't see a reason why autoload can't be disabled on deactivation of a widget, preloaded on navigation to the widget settings page, and then re-enabled when said widget is activated.
Change History (17)
This ticket was mentioned in Slack in #core-performance by spacedmonkey. View the logs.
15 months ago
#4
@
6 months ago
- Owner set to pbearne
- Status changed from new to assigned
In #61103 the widget are set to not auto-load
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
5 months ago
This ticket was mentioned in PR #7054 on WordPress/wordpress-develop by @debarghyabanerjee.
5 months ago
#8
- Keywords has-patch added
Trac Ticket: Core-55922
## Problem
- The current implementation of the wp_list_comments function restricts the type parameter to a single comment type as either an array or a string, limiting its flexibility for developers who need to query multiple comment types simultaneously.
## Solution
- This enhancement introduces support for both arrays and strings in the type parameter of the wp_list_comments function. This update leverages the capabilities provided by WP_Comment_Query, allowing developers to specify comment types either as an array of types or as a single type string in a single query efficiently.
## Changes Made
Code Enhancement
: Updated the wp_list_comments function to accept both arrays and strings for the type parameter.
Backend Implementation
: Enhanced comment query handling to accommodate arrays and strings passed to the type parameter.
## Impact
Enhanced Flexibility
: Developers can now specify comment types using either an array of types or a single type string in the wp_list_comments function.
Improved Query Capabilities
: Facilitates querying multiple comment types simultaneously, leveraging the capabilities of WP_Comment_Query.
Expanded Usage Scenarios
: Supports a wider range of use cases where querying comments from multiple types is required within a single function call.
Backward Compatibility
: Ensures compatibility with existing usage of the wp_list_comments function by retaining support for single type string parameter.
#10
@
5 months ago
I can't figure out how to do this with the new block widget, and they are all saved in a single option.
#12
in reply to:
↑ 11
@
5 months ago
Replying to pbearne:
@debarghyabanerjee did you add your patch to the wrong ticket?
Hi @pbearne, I had two tabs open I by mistakenly attached this ticket's link on my other PR but changed it back with in a fraction of second, I am currently working internally on this ticket in my local. I tried removing this PR link from here, but didn't get an option of removing it.
#13
@
5 months ago
@debarghyabanerjee love to see your code for this I could not see how to do this for the new blocks widget version
#14
@
5 months ago
in #61103 I use wp_use_widgets_block_editor() to toggle if widgets are active
I feel this good be a way forward
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
4 months ago
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
2 months ago
#17
@
2 months ago
- Keywords early added
- Milestone changed from 6.7 to 6.8
This ticket was discussed in today’s Performance bug scrub.
Per Slack discussion, The widget storage system is a bit complicated, so we need to make sure we don't remove autoloading from something that's still commonly used. I'd feel better not to rush this now, given the lack of reviews on the PR.
Props to @flixos90
I think this will be solved by #35669.