Well if you address #3, it'll take care of #2 and #1 naturally, wouldn't it? Then the only issue that remains would be the no-JS users, for whom I think it would be okay to completely disable sorting by hit count (if we really feel like it is "revealing too much") and also not enable sorting for the columns added in #1.

In the light of that analysis, I am inclined to either close this task as a dup of #3, or make it a parent task to all those three.

Yeah, but sorting client-side has troubles also for JS-users, since you need to take into account values not shown in the current page. And yes, my intention was to make this parent task but forgot to add it :)

If we were to go the JS route, then we should also use JS-based pagination.

Indeed, but I don't know how much JS could be handy here. BTW, thanks to @valerio.bozzolan I learned that to address (2) we may use ORDER BY af_hidden ASC, IF( af_hidden = 0, af_hit_count, NULL). This is however hard to achieve using IndexPager. We may get relatively close by overriding getIndexField and getExtraSortFields , but we still have a wrong order, and would need to override the sorting method as well, since in this case we don't want to put ASC or DESC next to every column (just the last one). There may also be other problems, my testing was only partial. My thought is that we'd better avoid overriding everything for what might be a temporary fix, and just wait for a more robust solution to solve everything at once without dirty tricks.

This will also be DB-specific; it may not work in Postgres or SQLite, for instance.

@Huji is right. Anyway we can also try to achieve this using the CASE structure instead of the IF function.

True, but since we're only using an IF and not some highly esoterical method, it should be easy to adapt. Cross-DB compatibility is IMHO the last of our problems for this task at the moment.

Here an example using the CASE structure that should be not DB-specific:

ORDER BY af_hidden ASC, CASE WHEN af_hidden = 0 THEN af_hit_count ELSE NULL END