WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#7431 closed enhancement (fixed)

Allow posts to be ordered by meta_key

Reported by: AaronCampbell Owned by:
Milestone: 2.7 Priority: high
Severity: normal Version:
Component: General Keywords: has-patch needs-testing
Focuses: Cc:

Description

You can specify a meta_key and meta_value when you are getting posts/pages, but you can't then sort those posts by that key. It seems like this is a common need. It's a relatively simple patch, so here it is.

This will work with this patch:

$args = array(
	'meta_key'	=> 'wpo_feedid',
	'orderby'	=> 'wpo_feedid'
	);
$myQuery = new WP_Query();
$myQuery->get_posts($args);

Attachments (2)

7431.001.diff (2.0 KB) - added by AaronCampbell 6 years ago.
7431.002.diff (2.5 KB) - added by AaronCampbell 6 years ago.
Add ability to specify a comparison operator for meta_value

Download all attachments as: .zip

Change History (17)

AaronCampbell6 years ago

comment:1 mdawaffe6 years ago

+1

You can do this now with the posts_orderby filter.

Also note that if you're trying to sort by numeric data, meta_value is stored as a string. That means you'll either have to store all your numeric data in a fixed width format (left pad with zeroes, YYYY-MM-DD, ...) or use the posts_orderby filter (even if the patch gets applied) to ORDER BY 0 + meta_value (or some similar trick).

comment:2 westi6 years ago

  • Milestone changed from 2.6.1 to 2.7

Looks like a good idea.

More 2.7 than 2.6.1 material IMHO.

comment:3 AaronCampbell6 years ago

  • Cc aaron@… added

Strange, I don't seem to be getting E-Mail notifications of comments on here. I'm going to try to add me as a CC again.

Westi: I don't know what the schedule is like for 2.6.1 vs 2.7, but I'll definitely admit that my reasoning for 2.6.1 is selfish. I think I'm going to implement this patch into a major site that I'm working on (it's part of the Harvard site), and I was trying to avoid having to re-patch each upgrade between now and whenever it's added.

However, from a more technical standpoint, it doesn't really affect anything that currently exists, so it shouldn't be too big of a deal.

comment:4 westi6 years ago

Aaron while I understand you selfish reasons. For me a point release is about fixing bugs not adding features.

You should be able to package this functionality up in a plugin for now until 2.7 arrives using the port_orderby filter and probably the same query_vars - although you may not be able to re-use orderby and get it parsed out still that would need some testing.

That way you just drop the plugin when you go to 2.7 :-)

comment:5 AaronCampbell6 years ago

I think it would be nice to also allow not only a meta_value to be specified, but a meta_compare ('=', '>', '>=', '<', or '<=') that would let the user get posts where the meta_value is greater than . It would be used like this:

$args = array(
	'meta_key'	=> 'wpo_feedid',
	'orderby'	=> 'wpo_feedid',
	'meta_value'	=> '2',
	'meta_compare'	=> '<'
			  );
$myQuery = new WP_Query($args);

My patch doesn't currently allow for ranges (> ? AND < ?), but it works pretty well to allow just a single choice. It also depends on this patch, so I was wondering if I should start a new ticket, or modify this one. I'm adding 7431.002.diff as a patch that includes this (it's inclusive of the 001 patch, so only 002 is needed). If it should be in another ticket, just let me know.

comment:6 AaronCampbell6 years ago

And westi, it's not quite as simple as using posts_orderby. That filter passes you $qorderby?, but not until after it has been cleaned (forced to be only 'author', 'date', 'category', 'title', 'modified', 'menu_order', 'parent', 'ID', or 'rand') and turned into an SQL order by statement, which means you can't tell what the user originally requested so you don't know whether they wanted to order by meta_value or not.

At least, I don't see any good way to find out what the user actually requested.

comment:7 mdawaffe6 years ago

You should be able to see what the query originally intended by looking at the pre_get_posts action.

comment:8 AaronCampbell6 years ago

mdawaffe: True. I'd have to hook into that, store the user's request ($q), then hook into posts_orderby, use the data I got from the previous hook, then expunge the data so I don't accidentally use it on another request. It's doable. Thanks (I had missed the pre_get_posts hook)

comment:9 follow-up: mdawaffe6 years ago

And what about != ?

AaronCampbell6 years ago

Add ability to specify a comparison operator for meta_value

comment:10 in reply to: ↑ 9 AaronCampbell6 years ago

Replying to mdawaffe:

And what about != ?

Definitely should have been there. I re-uploaded 002 with it included.

comment:11 AaronCampbell6 years ago

Has anyone had the chance to test this? I'm using it on my 2.6 install with no problems. I don't have a trunk install set up at the moment.

comment:12 AaronCampbell6 years ago

I applied the patch (002) to my 2.6.1 install and it's working great. I'd still like to see this submitted to trunk. What do we still need to do to make that happen?

comment:13 AaronCampbell6 years ago

I'm now running this on a few blogs and it seems to work great. Are there any specific tests I could run on it to get the process moving? I'm working real hard to get things committed so I don't have so much to worry about every time I upgrade.

comment:14 jacobsantos6 years ago

  • Type changed from defect to enhancement

comment:15 azaozz6 years ago

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

(In [8922]) Allow posts to be ordered by meta_key, props AaronCampbell, fixes#7431

Note: See TracTickets for help on using tickets.