Adding a filter to WP_List_Table::months_dropdown() to allow overriding the list of months displayed

[geoffguillain]

In WP_List_Table::months_dropdown(), a query is run to determine the months that have post items.

This query can be expensive for large posts/custom posts listing, so it may be desirable for sites to override this behavior. I am monitoring around 500ms for 500k+ posts.

The filter available, disable_months_dropdown, only allows removing the dropdown not overriding the query.

A similar filter (media_library_months_with_files) has been set previously for the media library. I was expecting a similar behavior for the month dropdown on post listing pages

In WP_List_Table::months_dropdown(), a query is run to determine the months that have post items.
This query can be expensive for large posts/custom posts listing, so it may be desirable for sites to override this behavior. I am monitoring around 500ms for 500k+ posts.
The filter available, disable_months_dropdown, only allows removing the dropdown not overriding the query.

This modification will enable to override the query. A similar filter (media_library_months_with_files) has been set previously for the media library.

Trac ticket: https://core.trac.wordpress.org/ticket/51660

Hi @geoffguillain! 👋

Thank you for your contribution to WordPress! 💖

It looks like this is your first pull request to wordpress-develop. Here are a few things to be aware of that may help you out!

No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.

Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making.

More information about how GitHub pull requests can be used to contribute to WordPress can be found in ​this blog post.

Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the ​Automated Testing page in the handbook.

If you have not had a chance, please review the ​Contribute with Code page in the ​WordPress Core Handbook.

The ​Developer Hub also documents the various ​coding standards that are followed:

• ​PHP Coding Standards
• ​CSS Coding Standards
• ​HTML Coding Standards
• ​JavaScript Coding Standards
• ​Accessibility Coding Standards
• ​Inline Documentation Standards

Thank you,
The WordPress Project

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the ticket and the PR.

Yes, I think a filter makes sense there. It would need a documentation block as per the ​documentation standards, looks good to me otherwise.

[geoffguillain]

A documentation block has been added to the PR.

[Hareesh Pillai]

Thanks for the update. It would be great if we could maintain consistency with the doc block for media_library_months_with_files filter.

[geoffguillain]

Thanks for pointing this out @hareesh-pillai.
The documentation block has been updated to be more consistent with the media_library_months_with_files filter.

[hellofromTonya]

Adding a code suggestion to the PR ​https://github.com/WordPress/wordpress-develop/pull/767#discussion_r567882010:

The 1st argument passed to apply_filters should be the value being filtered. In this case, the filter is filtering months, not the post type.

[TimothyBlynJacobs]

The naming for this feels like it'd be filtering the returned months. Should this instead be named like our other short-circuit filters and use pre in the name?

Trac ticket: https://core.trac.wordpress.org/ticket/51660

Updates PR #767 to modify the added filter to be a short-circuit for the query.

[hellofromTonya]

Notes from today's scrub:

We agreed the intent of this ticket is to bypass/skip the query. A filter already exists for filtering the months result, i.e. months_dropdown_results.

To expedite this ticket to be included in tomorrow's 5.7 Beta 1, I created PR 967 to capture the changes.

[hellofromTonya]

Tested before and after applying PR 967 along with a callback to modify the months. Works as expected.

[hellofromTonya]

Testing information:
See the attached gif for before and after.

Step 1: Log into your test site.

Step 2: Go to the Posts.

Step 3: Select the "All dates" dropdown.

Step 4: Apply the PR by doing:

npm run grunt patch:https://github.com/WordPress/wordpress-develop/pull/967

Step 5: Add the following code to a must-use file or in the theme:

add_filter(
	'pre_months_dropdown_query',
	function( $months, $post_type ) {
		if ( 'post' !== $post_type ) {
			return $months;
		}

		return array(
			(object) array( 'year' => 2020, 'month' => 10 ),
			(object) array( 'year' => 2020, 'month' => 11 ),
			(object) array( 'year' => 2020, 'month' => 12 ),
			(object) array( 'year' => 2021, 'month' => 1 ),
			(object) array( 'year' => 2021, 'month' => 2 ),
		);
	},
	10,
	2
);

Step 7: Refresh the Posts page.

Step 8: Select the "All dates" dropdown. Notice the selections have changed.

[hellofromTonya]

PR reviewed and approved by Timothy. Marking this one for commit.

[whyisjake]

In 50163:

Administration: New filter ahead of the months drop-down.

As this can cause large, long running queries on sites with many posts, this filter allows the query to be modified, bypassing entirely if needed.

Fixes #51660.

Props geoffguillain, SergeyBiryukov, hareesh-pillai, hellofromTonya, TimothyBlynJacobs, whyisjake.

Closed with changeset https://core.trac.wordpress.org/changeset/50163

Closed with changeset https://core.trac.wordpress.org/changeset/50163

[SergeyBiryukov]

With [50163], the months_dropdown_results filter is no longer applied if the new pre_months_dropdown_query filter is used. I think it should only short-circuit the query and not the other filter.

[hellofromTonya]

Restores the "months_dropdown_results" filter back into main logic flow for it to be applied.

[hellofromTonya]

Replying to SergeyBiryukov:

With [50163], the months_dropdown_results filter is no longer applied if the new pre_months_dropdown_query filter is used. I think it should only short-circuit the query and not the other filter.

51660.diff restores/reverts the logic position of the months_dropdown_results filter. It will be applied regardless of whether the $months array of objects is sourced from the pre_months_dropdown_query filter or db query.

Marking for commit.

[TimothyBlynJacobs]

I'm not strongly opposed. But the reason I recommended it behave this way is that the vast majority of core pre_ short-circuit filters I saw did not have their "standard" filter applied.

[SergeyBiryukov]

Replying to TimothyBlynJacobs:

I'm not strongly opposed. But the reason I recommended it behave this way is that the vast majority of core pre_ short-circuit filters I saw did not have their "standard" filter applied.

Ah, good point. At a glance, there are some that immediately return without any other filters applied, and some that just short-circuit the query or heavy processing and continue to other filters. I can circle back after a closer review.

[SergeyBiryukov]

Replying to SergeyBiryukov:

Replying to TimothyBlynJacobs:

I'm not strongly opposed. But the reason I recommended it behave this way is that the vast majority of core pre_ short-circuit filters I saw did not have their "standard" filter applied.

Ah, good point. At a glance, there are some that immediately return without any other filters applied, and some that just short-circuit the query or heavy processing and continue to other filters. I can circle back after a closer review.

I still don't have a full list at this point, but the pre_months_dropdown_query filter seems closer to the latter pattern (also used by the pre_move_uploaded_file filter, for example), so I think 51660.diff​ would be preferred here.

[SergeyBiryukov]

In 50362:

Administration: Apply the months_dropdown_results filter separately from pre_months_dropdown_query.

Follow-up to [50163].

Props hellofromTonya.
Fixes #51660.

[audrasjb]

Dev note published: ​https://make.wordpress.org/core/2021/02/23/miscellaneous-developer-focused-changes-in-wordpress-5-7/