At first, I thought this would be easy to fix by providing an order by providing an order by option to Joomla\CMS\Categories\Categories class instead of hard code order by clause by c.lft (ordering) https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Categories/Categories.php#L297 . Sadly, that won't work. Look like categories needs to be ordered by ordering like that to have the categories tree built properly

So look like the only way to implement this ordering setting is using usort function to sort the data before it is displayed (doing that in the layout or inside the Categories model). Not sure if it is something which we should try to implement.

@HLeithner @joomdonation Just tested in a J3.9 and it did not work there either. Or am I missing something?

@chmst Looking at our current code, I would say that this feature never worked !

The option you refer to is not for changing the order of the categories on the first page of this menu item,

Change "Blog Layout" -> "Category Order" to "Title Alphabetical"

These options are also used when you select one of the category links, on the first page and/or thereafter, unless they are changed for a specific menu item.

@brianteeman Shouldn't the order (if could be implemented) be applied for categories from all of these layouts? I mean it should be moved to Shared tab, same with in component Options

Anyway, from what I see from the code, we don't handle this parameter in our code.

i am still trying to work out how you use the blog and list layouts

Sorry, I don't understand your last comment.

Yesterday I spent a huge amount of time with this issue.
What I think now: The categories are displayed as a tree. No ordering is here possible and never was possible.

The categories which are shown in this tree are links to a category blog.
The whole bunch of params determines how this category blog is built. The ordering of articles, columns and so on.

Maybe this issue is not an issue but expected behaviour? Maybe I am missing something.

You're right that it never was possible. However, it is still a bug. When you have that parameter set to a custom order, users would expect that categories in the list follow that custom order. Right now, it is always ordered by ordering, and that's not what people expect to see (assume they use that parameter).

From my understanding there are several different but related issues here.

1. There is no ability to sort the categories listed on the first page
2. Links from the first page go to a blog view and use the settings in the blog tab
3. the list view tab is never used at all

Regarding your finding #2 and #3: What layout used when users click on a category from first page (List/Blog) is determined in the component options (a bit strange that we do not allow determining that layout parameter from the menu item setting like other parameters)

ah ok thanks for the explanation.

So to rewind back to the original report. @HLeithner was changing a setting in the blog tab expecting it to change the order on the front page but this was the wrong option.

However the correct option to sort the categories which should be in the categories tab is missing

Actually, when you click on a category from the first page, that category could contains sub-categories and these sub-categories can be displayed on category page, too

So that sorting option should be carried out to category page, too. In short, the setting should be in Shared tab (same with in Component options)

But that setting never worked, and there is no nice way to solve it using SQL query (at least from what I see), I wonder if we really need to find a way fix it (we can already control ordering of categories by ordering anyway).

I see no possibility via sql.
It is a challenge and I don't know how to resolve it except catching the whole tree and rebuild it in the view with correct ordering.

Looking at this issue again, I see that the parameter here is used to control ordering of children categories of a category, not ordering of the categories on the first page. And for that, we already have it works as expected already (except that it is not locale aware as reported here #28643 )

So I would say that this issue is invalid and will close it in the next days if no-one against it.

Closing as stated in my comment above #34866 (comment)