It was supposed to be a SELECT LIST like this (You can select more than one location)

When I switch it back to SELECT LIST, it disappears from the SORTBAR in front-end and back-end DIRECTORY ADMIN > MANAGE OPTIONS > LISTINGS > Sortbar Fields
-
This reply was modified 9 years, 7 months ago by
CarolLeung.
Hi Carol,
Sorry for any confusion here. The reason for this is a limitation on how a query can be generated from the data. See below:
Because the sort bar is not used for filtering, just sorting, and there’s no clear way or method to sort listings by a multivalued fields (checkbox, multiselect, tags, categories).
If Listing A has tags “restaurant,place” and Listing B has tags “science,teaching”, which ones comes first? What’s does it even mean to sort listings ASC or DESC by the tag field?
I know Carol is not talking about tags (it’s about regions) but the logic is the same.
For single-valued fields it’s obviously clear what to do. With just sort listings ASC or DESC according to the value of the field, because it can be compared across all listings.
You may say that “you can do that alphabetically” but in practice, that isn’t always the right answer. Since the list doesn’t contain a reasonable sort order, we can’t use it for sorting at this time. That’s why you don’t see it available.
Actually, it’s just a single selection, we are using SELECT LIST for the Location Area (Sorry about the confusion) It can be used as the title, but it can’t be sorted or used in the Sortbar?
More than one location/selection would be MULTISELECT LIST
We’re just trying to sort all the Downtown listings together and all the uptown listings together
Hi Carol,
My apologies for any confusion here. The problem is that we are a custom post type. Because we are a CPT, we use WP taxonomies (essentially categories) as they require us to do. Because we use these, the internal representation of things like tags, regions and categories are not as “simple” as you might think. They are considered “multi-valued” internally, and as such, the SQL can’t be easily generated by looking at the listing data…
My developer goes into this in more detail here:
Fields with a single-select value seem really simple, but it turns out they aren’t really single-valued at all internally. Categories, tags and regions are WP taxonomies and, as such, are internally always multivalued (regardless of how we display the selection). The result of the JOIN in this case can’t be guaranteed to be always single-valued, so the behavior would be undefined if the site contains a listing that is in two categories or has two tags. And “undefined” is probably a broken SQL query returning no results.
The case of regions is even more problematic: when a listing is inside a particular region (say “NYC”) it is assigned the full region hierarchy (North America -> United States -> NY) so these fields are always multi-valued (internally). We also don’t currently have a way to obtain (via SQL) the region for a listing in a particular field (or region level).
I apologize for the confusion on that–it’s basically WP limiting us in this case.