Disable wp_options autoload for inactive widgets

[ComputerGuru]

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.

[westonruter]

I think this will be solved by #35669.

[pbearne]

In #61103 the widget are set to not auto-load

[pbearne]

TODO: toggle options autoload with inactive status

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.

[pbearne]

I can't figure out how to do this with the new block widget, and they are all saved in a single option.

[pbearne]

@debarghyabanerjee did you add your patch to the wrong ticket?

[debarghyabanerjee]

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.

[pbearne]

@debarghyabanerjee love to see your code for this I could not see how to do this for the new blocks widget version

[pbearne]

in #61103 I use wp_use_widgets_block_editor() to toggle if widgets are active

I feel this good be a way forward

​https://github.com/WordPress/wordpress-develop/pull/6465/files#diff-00b47823ca3f69b67f1d676b107347fbca7423c68b2172d850b57953ffe2750fR601

[mukesh27]

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

[audrasjb]

Note: the attached PR was mistakenly assigned and is not relevant to this ticket.

Concerning the alternative proposed in #35669, on my side I would probably be more inclined to just remove the autoload. Switching to a post type looks like a probable breaking change for extenders.

[flixos90]

There hasn't been any actual updates on this ticket since it was punted to the 6.8 milestone. It seems quite complicated to address, and there's no PR yet.

Based on this, I think it makes sense to move this to an undefined future release for now. It makes sense as an enhancement (FWIW it's not a bug), but it may be a huge rabbit hole to get lost in. If @pbearne you or anyone else is up for the challenge, it could be milestoned again once someone has come up with a proposed solution and/or PR.

[pbearne]

I agree that this is not an easy fix and will need a rewrite of the way widget blocks are coded