• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

In Cairo, order="created" sorted with older topics first, newer topics after, so if one wanted to show newer topics first, reverse="on" was needed.

In Dakar, order="created" sorts with newer topics first, older topics after.

Was this intended to happen?


This is a serious bug which breaks several of my Twiki applications in my Cairo installations.

I just noticed and was about to raise a bug when I saw that AT had done it already.

Search is a vital feature in any serious TWiki installation and it is important that existing features are enhanced in a way that adds new features but leaves the existing features backwards compatible with the 10000s of TWiki topics created in the many Cairo TWikis. Otherwise upgrading becomes too difficult.

So this one should be fixed. I changed status to Urgent.


Order="modifed" is also wrong and reversed compared to Cairo. Both "created" and "modified" must be made working like in Cairo and also what is the most logical way: oldest first ascenting to newest last. "topic" and "editby" seems to be still correctly ascenting from a to z.

If you look at the TWikiVariables under SEARCH and look at the reverse option it also clearly says that the default (reverse not defined) is ascenting and reverse="on" changes it to descenting. So it is a bug in Dakar.


I have nailed down the bug to this code in lib/TWiki/Search.pm line 1012

# RE for a full-spec floating-point number
my $number = qr/^[-+]?[0-9]+(\.[0-9]*)?([Ee][-+]?[0-9]+)?$/s;

sub _compare {
    if( $_[0] =~ /$number/o && $_[1] =~ /$number/o ) {
        # when sorting numbers do it largest first; this is just because
        # this is what date comparisons need.
        return $_[1] <=> $_[0];
    } else {
        return $_[0] cmp $_[1];

I wonder if it is a plain misunderstanding on how the sorting is supposed to work or there is some other feature that needed this. In any case the code is doing things wrong for dates in SEARCH

if you correct the code so that you swap 1 and 0 for the number compare the searches become right (line 1019)

return $_[0] <=> $_[1];


Note that I have attached a patch. And also note that I do not have SVN write access so someone need to do the actual patching and commit to SVN for me.


SVN 7843

Thank you, Kenneth.


When I tested this one I had a number of topics that was less than the search limit. But after having seen the result of this one on the bugs web I see that the fix is not doing what we want. You get all the oldest topics instead of the latest with this fix. My fault sorry. Please revert back and I will see where the correct fix should be. Probably reverting the logic for reverse="on" for dates is the right way. Changing the _compare is not the way. Sorry about that.


Kenneth, sorting with older topics first is the way Cairo works. Older dates are less than newer dates.

Although I think it was right, I reverted the change until you go deeper on it: SVN 7845.


The problem with my poor fix is this. Let us say we have 100 topics and do a search with a search limit of 10. I am then supposed to get.

1 2 3 4 5 6 7 8 9 10

And with reverse="on"

100 99 98 97 96 95 94 93 92 91

With my poor patch we got

10 9 8 7 6 5 4 3 2 1

which is useless. When people sort with reverse="on" they want the newest 10. Cairo works correctly showing 100 99 98 ... with reverse="on".


If only life were that simple. See TestCaseAutoSearchOrder for Dakar expectations. Kenneth patched behaviour back to what was in Cairo. In Cairo, if you ordered by modified, it showed the oldest (least recently modified) first. If you then set limit="10" it would show you the ten least recently modified topics. I reversed that order in Dakar so that modified and created show the most recent topics first, so that limit="10" shows you the most recently touched topics, which is rather more useful. I think there was a bug report against Cairo regarding this.

If Cairo compatibility (i.e. broken behaviour) is critical in this case, you are invited to provide a revised testcase that tests for the reverse order.


Is is now a requirement that I learn to write test cases to report bugs? I do not understand how those pages work.

The bug is none the less a bug. The functionality of reverse="on" and "off" is correct except they are reversed when you sort by date.

With reverse="on" and limit="10" you must get the 10 latest in descenting order.

With reverse="off" and limit="10" you must get the 10 oldest in ascenting order.

I am playing with some other code fix now but not successful yet in making it work in all cases. And this time I want to test more before I propose a new fix.


SVN 7862 reverses the order. I guess the bug will be reported again; at least there is some history now. Note that this issue can't be closed until the testcase is updated (TestCaseAutoSearchOrder is currently failing)


OK. One thing fixed. Two others broken.

The sorting of plain text fields is now reversed.

And sorting for modified date with many topics and a limit is now also broken.

I have attached a zip file with the files that make up a test case. You need the ,v files for the creation date to work. So I had to make some new topics.

So in order to fix this bug you need to both pass the test cases AND use the WebChanges topic. I removed the limit="99" to make it work just reasonable. Add it again to see how it fails and to verify the fix.

I have made the same testcase topic in a Cairo version (same but with reverse="anything" removed where it is meant to be off ).


And the Dakar version

http://merlin.lavrsen.dk/dakar/bin/view/TestCases/TestCaseAutoSearchOrderKenneth which is the one in the zip file.


The WebChanges topics in all webs also needs to be corrected when the feature is brought back to Cairo functionality. This just shows how much the reverting of the sort order will destroy for sites that are migrated from Cairo to Dakar. These searches are used everywhere and would have been broken everywhere if this bug had not been raised by me.


I have created a Codev topic where the feature in general can be discussed. This bug report is a bad place for long principle arguments.



Thanks for the updated testcase. Shame it doesn't test the optimisation (which is of questionable value anyway) but from my visual check of WebChanges it is correct now.

SVN 7867


Summary order="created" in %SEARCH{}% is incompatilbe with Cairo
ReportedBy AntonioTerceiro

SVN Range Thu, 08 Dec 2005 build 7810
AppliesTo Engine

Priority Urgent
CurrentState Closed

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2005-12-15 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback