First,
Links have "Name", categories have "Title"
$LINKS{build_sort_order_search} = "Title DESC";
to sort on a Link title.
Second, and the biggest problem.... is that the same logic error in search.pm that has caused the searching problem has forced the return of links to be in only "score" order, meaning the most relavent first.
The only way around this is to rewrite the search query routine, and no one has undertaken that yet.
$link_hits = $linkdb->query ( { query => $query, mh => $mh, nh => $nh, filter => \%filter, ww => $ww } );
Rewriting the query routine is a non-trival task.
This was a problem pointed out early on with the 1.11 release. Somewhere in the rush to get the requests for "score" order to work, the non-score order and 'AND/OR' searching (passed parameters) got short circuited.
If you are wanting to use some other sort of search criteria, you can write your own routines, but you lose the in depth seaching of the query routine.
For instance, most people who search on "love and romance" want to find the most relative links -- not links in alphabetical order. When this logic was added, other stuff broke.
While this has been a frustrating thing with the 1.11 version, the search module having these problems, hopefully all these and more are fixed in the next version. Remember, searching is doing a lot of different things, and all sorts of short cuts and tricks have to be used to make it a real-time process. Then, support for different languages had to be added, and by the time you mixed all of the basics, with all the stuff everyone wanted, the module just didn't work right.
There are a lot of things a search module can -- and should -- do, but it has to be written from the ground up, and has to take all the things people want into consideration. Then, it has to be extensible. Meaning, all the various actions encapsulated into function calls that can be strung together to return whatever query values are asked for.
http://www.postcards.com FAQ:
http://www.postcards.com/FAQ/LinkSQL/