As of this writing, %GROUPS% puts members sorted in cUID. The member order may look random and test/unit/Fn_GROUPS.pm would become a bit messy to conform that behavior. So stopping member sorting.
I might have put in the sorting of groups a few days ago. I think it is better to show the group list sorted. Sorting fails though if a group has no corresponding topic in the Main web. By default here is only one, the TWikiBaseGroup, which is OK/good to have at the top.
I think it is better to fix the unit test to be aware of sorting.
This is about the order of members of a group rather the order of groups listed.
As I mentioned, if the members of TWikiBaseGroup are sorted in the cUID order, it looks random.
With an ordinary group defined by a topic, if the members are sorted in the cUID order, the resulting order is different from the order listed in the topic, which may puzzle some users.
As it is coded now, the table is ASCII sorted based on the string of table row, such as
"| [[Main.SomeGroup][SomeGroup]] | [[Main.UserA][UserA]], [[Main.UserB][UserB]] |"
by default. That is, the sorting looks OK as long as the group topics exist. If not, they will be sorted too, but shown before the groups with topic.
The members are currently not sorted. Let me also ASCII sort them based on the resulting string.
I fixed the code so that members are now sorted after
formatting to WikiName, not before as it originally was. Could you test if this fixes the issue?
How about introducing
parameter to %GROUPS% and make the sorting off by default? My concern is that the order of members may be intentional and changing the order on TWikiGroups may puzzle users. For example, the first member of a group may be the head of the group, there might be subgroups within a group and members are bundled together based on the subgroups they belong.
I don't have a strong opinion on this one. The sort parameter sounds good.
I've introduced the sort="on" parameter and made sorting not happen by default.