Query Loop: Add Page Order (menu_order)

[brnhrst]

What?

This PR adds the possibility to the query loop block to output pages according to the order set in the backend (menu_order). For this purpose a new option is added to the existing dropdown menu. Since by default only pages have this sorting option, this option is only visible if Page is selected under Post Type.

Why?

The current sorting options by creation date and title are not sufficient for most use cases. To build overview pages that automatically display and link to the appropriate subpages or specific pages, you often need to set an order that is not alphabetical.

According to this list, this was probably on the agenda anyway: #24934

How?

I have added a new option to the OrderControl component. The array orderOptions, which was static before, now has to be in the function, because we want to change it depending on the PostType and only show it when the PostType is Page.

In the parent component we extend the call of the OrderControl by the variable postType, so that the currently selected PostType is always passed to the OrderControl.

If the PostType is changed to Post or something other than Page, we have to reset the value to the default, because our new option is not available.

For this to work, we need to allow the menu_order option in the enum of the corresponding REST API call.

Theoretically, it would be even better if we don't check for postType === page, but check if the selected postType supports page-attributes. Then this option would also appear for CPTs that support this sorting. But since this is my first PR, I wanted to keep it as simple as possible for now.

Testing Instructions

1. create several pages and sort them manually in the page list
2. create a query loop block and configure it so that the post type Page is selected
3. change the Order by option to the new Page Order option
4. verify that the pages are sorted in the previously set order.
5. change the Post Type option to Post and verify that the Order by option changes to Newest to oldest and the new Page order option is no longer displayed.
6. verify that these changes to the order are also identical on the frontend

Screenshots or screencast

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @brnhrst! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[paulwilde]

Just wondering if there's any movement on this one?

At the very least it would be nice if a filter were to be added allowing for developers to extend the options which are available, then other options (such as specific one for products, or custom post types) could be implemented without being tied to only 4 of the ones built into core.

Passing along the postType would also be valuable as you could adjust the available options based on the selected postType.

Something simple like this:

let orderOptions = [
	{
		label: __( 'Newest to oldest' ),
		value: 'date/desc',
	},
	{
		label: __( 'Oldest to newest' ),
		value: 'date/asc',
	},
	{
		/* translators: label for ordering posts by title in ascending order */
		label: __( 'A → Z' ),
		value: 'title/asc',
	},
	{
		/* translators: label for ordering posts by title in descending order */
		label: __( 'Z → A' ),
		value: 'title/desc',
	},
];
orderOptions = applyFilters(
    'blocks.queryLoop.orderOptions',
    orderOptions,
    postType,
);

Of course you need to make sure the value matches a valid ordering or adjust the query on the PHP side where needed.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @brnhrst, @paulwilde.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: brnhrst, paulwilde.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[brnhrst]

Thank you for your feedback! Unfortunately, I didn't get any response to this PR and then forgot about it myself. A filter would be an equally good solution, even if it wouldn't do much for the normal user.

I've switched to using Ryan Welcher's Advanced Query Loop Block, which maps these and a few other features that I think actually belong in the core: https://wordpress.org/plugins/advanced-query-loop/

In general, I don't understand why such "little things" don't get into the core faster or are implemented from the start. I mean, if I develop a query block that is based on WP_Query, why don't I directly offer all the sorting options of WP_Query?