fix(search): default date sorting to descending order (newest first)

[aryan7081]

Fixes #7452

Inside the doSearch function of packages/volto/src/components/theme/Search/Search.jsx, date sorting was incorrectly using ascending order (oldest first) by default instead of descending order (newest first). This happened because the implementation didn't set a default sort_order for date fields and the searchContent function in packages/volto/src/actions/search/search.js used incompatible parameter names with the Plone REST API. The fix adds default descending sort order logic in doSearch when sort_on is present but sort_order is missing, and converts sort_order parameter to sort_reverse in the searchContent function for Plone REST API compatibility, ensuring search results show newest content first by default.

[aryan7081]

@wesleybl @davisagli , can you please help me pass the Acceptance test? I have tried exhaustively from my end, but I am unable to resolve the issue. Thanks and Regards

[aryan7081]

@wesleybl Thanks. I have updated the searchContent logic to convert sort_order, sort_reverse only when sort_on is effective (search page) prevent breaking contents and other search functionality.

[wesleybl]

@aryan7081 When I do:

http://localhost:8080/Plone/++api++/@search?sort_on=effective&sort_order=descending

sorting works. So why doesn't it work with the searchContent action?

[wesleybl]

@aryan7081 The original request is:

http://localhost:3000/++api++/@search?b_size=25&sort_on=effective&sort_order=reverse&use_site_search_settings=1

This doesn't work. But when I remove use_site_search_settings=1, it works correctly. So we need to investigate use_site_search_settings=1.

[aryan7081]

@wesleybl Sorry for the delay. Made convertSortOptions immutable by creating a copy, separated URL/search/API options across methods, and removed the unnecessary sort_reverse URL check. The use_site_search_settings=1 issue is due to Plone's legacy search expecting sort_reverse instead of sort_order for the effective field. Thanks for the review

[wesleybl]

The use_site_search_settings=1 issue is due to Plone's legacy search expecting sort_reverse instead of sort_order for the effective field.

@aryan7081 I'm wondering if the fix here couldn't be simply removing use_site_search_settings=1.

Maybe @davisagli can help.

[aryan7081]

@wesleybl We could remove it, but use_site_search_settings=1 enables site-specific search configurations. The conversion preserves that functionality while fixing the sorting.

[wesleybl]

@sneridagh I think this PR fix ​​#2458. Please check.

[wesleybl]

@sneridagh I think we have this problem with Volto's sorting, because it uses effective and not Date, like in Classic Plone. Since the search control panel only sorts by Date and not by effective, the problem occurs in Volto.

Why was it changed to effective in Volto? I think it makes more sense than Date. But shouldn't it follow the Classic standard? I think if it were to continue with effective, perhaps it would be necessary to add sorting by effective to the search control panel (maybe some extra change would be needed, like in the plone.restapi)?

[aryan7081]

@wesleybl Now we only send use_site_search_settings=1 when the user hasn't explicitly selected a sort, so the control panel doesn't override the user's choice. The backend PR (plone/plone.restapi#1954) fixes the handler removing sort_order when use_site_search_settings=1 is present. Once that's merged, the sorting test should pass. Regarding effective vs Date: this is a separate architectural question. The current fix ensures user selections are respected regardless of the field used.