I would like a parameter to change the bullet to number the list of children, so that the children appear like this:

1. Child A
2. Child B
3. Child C

For those who have posted before. I think some of this functionality has been added, since there is a sort parameter that can sort by "creation", and "modified" dates. Also, it automatically sorts by the order of the pages in the space tree.

On the other hand, I still need more sorting functionality. I am using the children macro in combination with the live-template scaffolding macro, so it will appear in many places. I can't go through and manually change every space's page order, and even if I did, making a change to this order would be a large hassle. I would like to have a more granular sorting option.

For instance, maybe I could do something like this:

Any word on this one? I need the children order on on the parent page to match a manual sort order of pages in the TOC.

Need to make sure that the children macro respects Confluence's page order (new in 2.8).

I agree that adding an attribute would work, sort of. Ideally, users should not have to add and manage an artificial attribute just to get the order they want. I can't be as solution-oriented as David, but I imagine Confluence would have to generate and manage its own metadata for this option. Is there any fundamental reason that would not work?

I would like to see a feature like that too.
An option to specify the sorting by "last edit" date would be enough for me. I'm maintaining a FAQ (every question is a child of a category page) and with a growing number of questions, it is harder for the users to see which questions are new.
(And don't forget the ascending/descending option

I would second this. It would also be good for items which are sorted by date. While you can use the 'yyyy-mm-dd' format (eg. '2005-01-15' to have them sorted, it would be much nicer if we could call it 'January 15 2005', but still have it sorted correctly.

And, intuiting the API docs, Page has a nice looking method called 'getNameForComparison()' which looks like a good suspect for adding a fairly simple bit of code to check for a specially-named property, which wouldn't be a lot of code either. Then, all you need is a

macro which stores XXXXX into the pages properties, and you're done!

Or, it could turn out to be horribly complicated. I have no idea what the performance hit is for accessing page properties, and I'm guessing that page name comparison is a pretty common activity. Perhaps you would have to add it to the database structure, which could get messy...