orderby
is the argument passed to WP_Query
to tell it what column to sort on when it is creating the ORDER BY
clause for its generated SQL. The default value for orderby
is post_date
.
The default sort order for a column in MySQL is ASC
(ascending), with smallest values first. For the reverse, DESC
is used. You can sort on multiple columns, and each column can have its own sort order.
The default value for the order
argument inside WP_Query
is DESC
. ~23% of the internet automatically queries posts in reverse chronological order because of this. order
can only be one of 2 values: DESC
or ASC
.
orderby
accepts a string, representing a column on which to sort:
$q = new WP_Query( array( 'orderby' => 'post_title' ) );
// or an alias
$q = new WP_Query( array( 'orderby' => 'title' ) );
Both will produce an ORDER BY
clause like:
ORDER BY post_title DESC
orderby
will also parse a space-delimited set of columns:
$q = new WP_Query( array( 'orderby' => 'title author' ) );
Prior to 4.0, there was a problem: the value for order
would only be applied to the last value that you passed in that space-delimited list, producing an ORDER BY clause like:
ORDER BY post_title, post_author DESC
Remember that the default sort order for a column in MySQL is ASC
, so queries like that can get weird real fast and produce unexpected/unpredictable results. If no value is passed for order for a column in the generated SQL, the column will be sorted in ASC
order. This was not so clear to all developers. #26042 was a joy to debug.
In 4.0, when you pass a space-delimited set of values, your sole value for order
will be applied to all of your values that are parsed for orderby
. This was fixed in [28541].
So that’s pretty good, but it doesn’t allow you granular control over the sort order for each column. The syntax doesn’t allow itself much room for extending.
Enter [29027].
In 4.0, you can now pass an array to WP_Query
as the value for orderby
. The syntax looks like:
$q = new WP_Query( array( 'orderby' => array( 'title' => 'DESC', 'menu_order' => 'ASC' ) ) );
This allows you to control the generation of the ORDER BY
clause with more specificity:
ORDER BY post_title DESC, menu_order ASC
Pre-4.0, you would have had to use some gnarly filters on the SQL statement or a specific clause. No bueno.
To see the internals, check out the new protected
methods in WP_Query
: ->parse_order()
and ->parse_orderby
.
Happy WP_Query
ing!
Ionel Roiban 5:31 pm on September 10, 2014 Permalink | Log in to Reply
Congratulations, everyone!
Stephane Daury (stephdau) 5:43 pm on September 10, 2014 Permalink | Log in to Reply
4.1 release lead nominations: I’m going to go right in crazy mode and suggest @rmccue.
Note: I have not discussed that with him, so it’ll catch him by surprise.
My logic is as so:
Stephane Daury (stephdau) 5:46 pm on September 10, 2014 Permalink | Log in to Reply
That’s also obviously my vote for the focus in 4.1.![:)](https://webarchive.library.unt.edu/untcsid/20140911223950im_/http://make.wordpress.org/core/wp-includes/images/smilies/icon_smile.gif)
Justin Sainton 6:41 pm on September 10, 2014 Permalink | Log in to Reply
Really great suggestion! I think @rmccue would make an awesome lead, but I just don’t know about it for the release where he’s the lead on such a major component as the WP-API.
Just spitballing here, but I wonder if it wouldn’t be a better situation to have someone as a release lead who can shepherd the whole release, not just that specific component? In my imagination, getting the API in the 4.1 release would require someone like Ryan to be more fully devoted to that specific component than to the whole release.
Just my two cents.
Andrew Nacin 6:41 pm on September 10, 2014 Permalink | Log in to Reply
When the API is merged in, we’d probably be best served with Ryan’s focus to be 100% on the API, and not need to worry about anything else also going on. The release lead is as much a project manager as it is a final arbiter, shepherd, and what not. Also, the API is going to be a big ticket item in the release it’s in, no matter what.![:)](https://webarchive.library.unt.edu/untcsid/20140911223950im_/http://make.wordpress.org/core/wp-includes/images/smilies/icon_smile.gif)
Stephane Daury (stephdau) 7:04 pm on September 10, 2014 Permalink | Log in to Reply
Fair. Works for me.![:)](https://webarchive.library.unt.edu/untcsid/20140911223950im_/http://make.wordpress.org/core/wp-includes/images/smilies/icon_smile.gif)
Rachel Baker 7:26 pm on September 10, 2014 Permalink | Log in to Reply
+1 on allowing @rmccue to have laser focus on the API.
Stephane Daury (stephdau) 5:51 pm on September 10, 2014 Permalink | Log in to Reply
Call to action on feature plugins for 4.1 and beyond: in the same line as my WP API suggestion, and if it does make it in 4.1, I (we?) would like to resume work on the Press This rewrite, with the twist of building it as a WP API client. It could act as a great bundled example.
Michael Arestad 6:11 pm on September 10, 2014 Permalink | Log in to Reply
Yep. We’re in!
Rachel Baker 7:29 pm on September 10, 2014 Permalink | Log in to Reply
We are really hoping to get the JSON REST API into 4.1, and would love the added validation and testing an integration with a Press This rewrite would give the feature.
Andrew Nacin 6:57 pm on September 10, 2014 Permalink | Log in to Reply
Some questions to ask:
Also, if you want to help lead a release or want to suggest someone, be sure to read this post from 4.0.
Stephane Daury (stephdau) 7:08 pm on September 10, 2014 Permalink | Log in to Reply
For #1 and #2: we delayed a move to Backbone.js (propagate) for the plugins browser/modal (updated in last release) in 4.0, under my advice, to focus on functionality rather than getting bogged down in a library switch. Should that be tackled that in 4.1, building on the experiences of the Media Grid et al?
Nick Halsey 7:30 pm on September 10, 2014 Permalink | Log in to Reply
To address several of those points, I’d like to continue iterating on the Customizer. Starting to build out better JS APIs in particular, building up to several features that’ve been delayed due to the lack of structure here.
I’d really like to get media in the Customizer rebuilt (initial patch on #21483), and to officially deprecate and redirect/deep-link the old header and background admin screens. Given Twenty Fifteen’s emphasis on those features, this seems like a good time to finally pull the trigger here.
John Blackbourn 7:31 pm on September 10, 2014 Permalink | Log in to Reply
I think we need to have a think about all the JavaScript which is landing in WordPress these days, and make sure we are documenting it well enough, whether we need to prioritise an action/filters API for this, whether we are doing enough to educate contributors and other developers on the JavaScript APIs, whether we need a better structure for the .js files, etc etc. See also Eric’s post on wp-hackers.
Fix the currently rubbish comment notification settings. See #6286, #14676, #761, Email Alerts plugin.
Ihor Vorotnov 2:01 am on September 11, 2014 Permalink | Log in to Reply
Jumping in here. The feature which is highly anticipated by literally any WP developer outside US and several other english-speaking countries is… some multilingual features in core.
Here’s my idea in details: http://wordpress.org/ideas/topic/native-multilingual-cms-features-one-more-time#post-27185
Basically, even making terms slugs non-unique and adding some super-taxonomy `language` will allow major plugin developers (WPML, Polylang) do the rest. WPML currently allows to have posts and pages with same slugs, but not categories, tags and custom taxonomies.
Right now I’m building a pretty large international website, which will function a s a website and a mobile app platform (backend) – thanks to JSON API. Having urls like `example.com/ru/profile-2/edit` or `example.com/ru/profile-ru/edit/` (just plain simple hierarchical pages) is kind of freaky. Or `example.com/ru/events/country/canada-2/city/toronto-2` and `example.com/ru/events/country/canada-ru/city/toronto-ru`…
Sooner or later, we need to add solid multilingual features to core to become CMS / Framework, not a blog platform.
Zach "The Z Man" Abernathy 7:18 pm on September 10, 2014 Permalink | Log in to Reply
I personally would love to see a little more work in the area of media with respect to actually managing the media items. For instance, being able to group things in folders would be a huge improvement.
Xavier Borderie 8:50 pm on September 10, 2014 Permalink | Log in to Reply
Yes! Folders and/or labels/tags, and possibly date grouping (à la iOS photo library).
Luke Carbis 10:47 pm on September 10, 2014 Permalink | Log in to Reply
Location grouping, too?
Paal Joachim Romdahl 5:40 am on September 11, 2014 Permalink | Log in to Reply
It would be nice to look at ways to improve the media structure.
http://wordpress.org/ideas/topic/improving-the-media-structure
John Blackbourn 7:21 pm on September 10, 2014 Permalink | Log in to Reply
I would like to get the ball rolling on open and closed Multisite networks which didn’t get any traction in 4.0 due to time constraints.
Jeremy Felt 8:13 pm on September 10, 2014 Permalink | Log in to Reply
+1 (well, for any Multisite improvements) – I’ll have more time to allocate to core this cycle and progress here would be great. I wrote up a possibly helpful classification of is_multisite uses in core earlier this year.
It’d be great to figure out what step 1 is.
Boone Gorges 7:23 pm on September 10, 2014 Permalink | Log in to Reply
I won’t be able to make this meeting, but I’d like to spend some time during the 4.1 cycle improving WP_*_Query classes. Improved test coverage (see eg #29560), followed by fixing some of the more egregious bugs (such as #19623), and adding what I see as some missing features (#29181, #29181, and a few others I am cooking up). May also look into abstracting some of the common logic into some sort of base class that the others will extend.
Robert Dall 8:01 pm on September 10, 2014 Permalink | Log in to Reply
I’d like to fix the poor UI In the widgets since they were last updated. Specifically #27180 I know we can do better.
Aaron Jorbin 8:12 pm on September 10, 2014 Permalink | Log in to Reply
I’d like to work on getting our JS unit tests running automatically on multiple browsers. I’d also like to look into some automated tests around front end performance of the admin and finding areas that we can speed things up (and also maintain a benchmark of how things are).
Xavier Borderie 8:16 pm on September 10, 2014 Permalink | Log in to Reply
I’d vote for changing the in-editor image update, making like the one in Confluence. I use this wiki tool at my job, and love that, while WP uploads the file and shows the library, letting me inserting the media, when I really want to directly insert it in place. Makes a huge difference.
Xavier Borderie 8:17 pm on September 10, 2014 Permalink | Log in to Reply
“in-editor image upload*”
Xavier Borderie 8:35 pm on September 10, 2014 Permalink | Log in to Reply
Top notch foreign typography. It’s very hard, for instance, using French quotes or non-breaking spaces in the editor without resorting to copy-paste. The editor tries to hot-swap curly quotes but fails in many cases.
Xavier Borderie 8:39 pm on September 10, 2014 Permalink | Log in to Reply
For translators: mark clearly strings that are used in JS, HTML labels/title tags or e-mail, because some translations use HTML entities to get some local things done, and that obviously does only work in HTML situations, not the others. I’m willing to work on that.
Xavier Borderie 8:29 am on September 11, 2014 Permalink | Log in to Reply
Finally tackling that multilinguism issue — or at least build the foundations in 4.1, because it’d make for a great 4.2 announcement (‘cos, y’know, 42, Hitchhiker’s Guide, the Babel fish, all that
). Allegedly, the SPIP CMS does it very well (see here for their introductory post).
Stephen Edgar 9:50 pm on September 10, 2014 Permalink | Log in to Reply
The Export API was proposed for 4.0 and didn’t make it, would be great for 4.1:
Export API improvements/overhaul #22435
Dan Milward 11:34 pm on September 10, 2014 Permalink | Log in to Reply
I agree with Nick Halsey. For me it’d be something small and scene setting for more socket.io integration in the future – its hard to argue against the technology on the basis that Automattic acquired it right?
Brandon Wamboldt 2:15 am on September 11, 2014 Permalink | Log in to Reply
The last few releases have made great strides in user experience in the admin, but now I think the team should focus on developers a bit for 4.1. As somebody who works frequently in WordPress, a big pain point is still list tables.
I frequently create custom tables for data that really don’t fit the mold of post types, and I often have to duplicate large amounts of code to create a list view that mimics the other list views (posts/pages/etc). If you guys could ease that, it would be awesome!
Shail 5:00 am on September 11, 2014 Permalink | Log in to Reply
For me most awaited feature is taxonomy meta. Is this feature in race? I know this is a very big change but I like to see it in core.
Ryan Boren 12:50 pm on September 11, 2014 Permalink | Log in to Reply
I’ll dump my rough notes.
Mobile and media. Media and mobile.
Context, Trust, Awareness, Flow
Press This. With the mobile improvements to the media modal that landed in 4.0, Press This can use the modal without being crippled on phones. The wordpress.com/post/ editor on wordpress.com has worked through some of the same problems that Press This needed to work through, hopefully smoothing the way. The /post/ editor also showed what you can and cannot get away with. Media, preview, and links are important. wpviews and wplinks are must haves. Media must be visual, not raw html, short codes, or even placeholders. Creating galleries should be possible and easy. Press This has a freedom that the /post/ editor does not. PT doesn’t have to worry with existing content edit flows. It can be tailored to a fairly one way creation flow (akin to Tumblr). It also has an advantage in that it can and does allow escaping to the full editor in the admin when the user needs more than PT provides.
Press This is not just UI. It is bookmarklets, extensions, side-loading, re-blogging, and sharing. It is the sharing mechanism in Android and iOS8. Someday it will be accommodated by the apps. Keep the entire Press This and sharing ecosystem in mind. When dev resumes, prioritize bookmarklets and fleshing out the sharing mechanisms, especially on mobile. Press This the UI is, in part, a trojan horse for getting a decent mobile posting interface on phones, but the sharing big picture should not be lost to new UI fascination.
Press This the UI should be a marquee user of WP API.
Large (full screen-ish) images should be a tap/click away in the media modal. Creating and captioning galleries is difficult when provided only thumbnails. Maybe borrow the attachment details modal from grid view.
Re-think media modal for touch devices. Get rid of tabs, especially in the absence of multi-select. Full images on tap with details below (like the attachment modal) rather than opening the sidebar and presenting another thumbnail sized image. That sidebar is awful on phones.
Re-think the media modal in general. We know more about how it is used than we did back when. We know what plugins are actually rather than speculatively doing with it. Is having a separate gallery flow still a necessary compromise? Is a sidebar the best way for plugins to integrate? Is there anything blocking VideoPress and Dropbox plugins from integrating? Which plugins integrate well with the media modal?
Create gallery and image posts from the media library grid view. Give bulk selection a purpose. This will accommodate mobile flows where images are uploaded to the media lib from a mobile device (via Android’s multi-select capable sharing mechanism, for example) and then gallery posts are later created from a desktop. This is a means of working around our lack of mobile multi-select and gallery creation interfaces.
Phone UX improvements, particularly menus. Is it possible to swipe to open/close side menus on the mobile web? Side menus must have swipe to be usable. Tapping a menu icon in b’ar should dismiss the menu instead of visiting a link. There is often no safe “tap outside” room on a phone, so all menus should dismiss when their icons are tapped. Very aggravating.
When adding links on mobile, don’t require highlighting text to activate link icons. Buggy on phones.
Tweak wplinks for phones. It’s already pretty good and keyboard up/down responsive, but mostly by accident.
Multi-select upload everywhere.
B’ar consistency. The front page b’ar on touch devices is my favorite. Tablets in landscape show the narrower b’ar in the admin, which always disappoints me.
Images uploaded to the media library and then added to a post don’t show up in the “Uploaded to this post” filter. Not being able to filter down to images already on the post makes setting featured images tedious. Uploading from mobile to media lib and then posting later is a common mobile flow.
Fix the image editor on phones.
Lose media-new.php?
Oh wouldn’t it be nice…
Settings that don’t suck.
An index.php featuring Press This and a reader.
Reader views for all list table screens.
Theme switching from the customizer.
Notifications, Stream.