There is an idea on having a GSoC Project on router improvements. And @wilsonge is also working on that.

Menu creation is a duplicate work because we are first creating categories then defining menu items based on category structure.
On the other hand Joomla site's category structure may not be consistent with that of menu and that is why site map extensions are generating very problematic maps.
Text separators are causing issues in search engine's SEO approaches.
I think menu items can in some way read from category table. In fact the field 'path' in category table can do this job and thus we can avoid a second job by creating menus/menu items.

"

Menu creation is a duplicate work because **we are first creating categories then defining menu items based on category structure.

**" And this is something I have discussed/asked for 10 years of Joomla and still doesnt understand my self still. It started with the section/categories debated. I am frustrated to see this still not explained.

W h y do Joomla need both categories and menus? Isn't this a problem that is clear also from the router/SEF/SEO perspective?

Why don't merge the functions/logic of categories/menus and only use menus to structure/plan and use for Joomla?

Still after 10 years doesn't understand this double work and inconsistency for end users that need to create their articles in front end attached to the categories instead the visible logic menus in the site where they can browse and understand the site menu UX logic.

So pls explain why we need both categories and menus?

that's not the place to discuss having a menu or not, I am trying to fix the bugs in the new routing and for that we need to know what is right in the current system

How do you build non-category structured navigation for other components then? You can't just drop the menu system unless you're saying the only way to use Joomla is with com_content.

Commenting on this...

Articles/Categories without specific menu items

This headline (and the missing explanatory text) is ambiguous. Are you saying that a category or article that has no specific menu item to that category or article is going to get such a URL? Or really just those items where neither the item nor a parent has a menu item? What does the given URL mean? Is it relative to the root of the site or do we prepend it with /component/com_content? Keep in mind that we have no clue which component (and thus which router) to load if you gave Joomla the adress domain.tld/cat-1-l1/cat-1-2-l2/cat-1-2-1-l3/article-1. Not all websites have com_content as home menu item and since this is supposed to describe behavior not only for com_content, but for all hierarchical (core) components, you wouldn't know the difference between an article, a contact or a newsfeed.

Quite frankly, regarding completely unlinked content items, I'd stick to the old system of /component/<component>/<view>/<id[:slug]> That does not unnecessarily spill information about your internal data structure and it allows you to easily find items without menu association.

With specific menu items for categories or articles

• Menu	Type	Item	Link
  Menu-1-L1	Separator	x	x
  Menu-1-1-L2	Article	Article-2	menu-1-l1/menu-1-1-l2/article-2
  Menu-1-2-L2	Category	Cat-1-3-L2	menu-1-l1/menu-1-2-l2
  Menu-1-2-L2	Category	Articles	menu-1-l1/menu-1-2-l2/article-[4,5,6,7]

  Row 2: Why should a menu item of type article get an additional suffix with the items slug, while a menu item of type category doesn't? If a menu item fits 100% to a content item, it should never add more parts to the URL.

• Menu	Type	Item	Link
  Menu-2-L1	Category	Cat-1-L1	menu-2-l1
  Menu-2-L1	Category	Article-2	menu-2-l1/menu-2-1-l2/menu-2-2-l2/article-2
  Menu-2-1-L2	Category	Cat-1-2-L2	menu-2-l1/menu-2-1-l2
  Menu-2-1-L2	Category	Article-2	menu-2-l1/menu-2-1-l2/menu-2-2-l2/article-2
  Menu-2-2-L2	Category	Cat-1-2-2-L3	menu-2-l1/menu-2-1-l2/menu-2-2-l2
  Menu-2-2-L2	Category	Article-2	menu-2-l1/menu-2-1-l2/menu-2-2-l2/article-2

  Rows 2, 4 and 6 are all describing the same thing to me....

• Menu	Type	Item	Link
  Menu-2-L1	Separator	x	x
  Menu-2-3-L2	Category	Cat-1-3-L2	menu-2-l1/menu-2-1-l2/menu-2-2-l2/article-2
  Menu-2-3-L2	Category	Article-[4,6,7]	menu-2-l1/menu-2-3-l2/article-[4,6,7]
  Menu-2-3-L2	Category	Article-5	menu-3-l1/article-5
  Menu-3-L1	Article	Article-5	menu-3-l1/article-5

  Row 2 is wrong the way it is. It would have to have the link menu-2-l1/menu-2-3-l2/
  Row 4 and 5 don't make sense either.

The new router has a pretty straight forward structure: If the menu item fits, take the path of the menu item as URL. For everything else, follow the path from the content node that you are at to the root of the content tree and find the best matching menu item. Then take the path of the menu item and add the path that you traversed so far to the end of it, from the last item that did not match a menu item back to the node that we started from.
All of that also works pretty well, except that someone quite some time ago thought, that it would be a good idea to always add an Itemid to the URL, even if the URL fit to nothing and thus we fell back to the home menu item. That however means, that in the component router we can't see if we now correctly discovered the Itemid of the item or if the application router simply botched the home menu item falsely onto us. Due to backwards compatibility, we can't change that now. However, I will not advocate to change that anyway, because I don't want to be blasted by another shitstorm like last time when I proposed that, when all the people complained that they actually had to set up all those menu items and that adding the default itemid was such a good solution to not having to do all that work. The same people later on complained that their URLs looked so wonky...

@Hackwar is there a documentation how the new router implements routing?

Just as far as I have posted it on the mailinglists and in issues here. I guess I will create a document on docs.joomla.org

Ok, so the short answer is no. Just wondering how we should decide, if something is a bug or intended behaviour.

Then let me help you with my guidelines how I decide if it is a bug or intended behavior:

• Rule 1: Can you describe the behavior in a reasonably simple paragraph?
• Rule 2: Is the behavior logically consistent?
• Rule 3: How close is it to the current behavior?
• Rule 4: Does it solve issues that we currently have with the router?
• Rule 5: Does the behavior not contain something like this: "Step 1: Categories, Step 2: Magic, Step 3: Route"

The new router does adhere to those rules and in 4.0 the code is even readable! Yeay!

@Hackwar anything from this readability we can backport into 3.7? :-)

Nope, not backwards compatible. Feel free to look at the code and then compare it to our current application router. It is pretty neat, but the cleaned up version, while functionally the same or even better, is not backwards compatible to the current application router code.

Dear colleagues -
thank's for raising all these issues. At the code sprint on Monday, the SEO team also met in Amsterdam, discussing with developers about the router issues raised. We have heard you all and we are reading what you write.

We are currently in the process of creating a document and a video with a project example (which we hope will be done by mid to end next week). We are also going to address how it needs fixing, why it needs fixing and what additional router features we would like to see from a technical SEO perspective.

We hope, that everyone can see the good in the community starting this process and we understand that there is guidance and information required from us.

Please give us the time to provide you with what we feel is needed. Let's all help in moving this forward.

And again: doing SEO for a living, I cannot even begin to tell you, how glad I am that we start working on these issues!

Kind regards
Christopher Wagner
Team Lead Joomla Optimization Team

It's been 20 days. Any news?

@rdeutz is this still valid?

might be valid bur not longer relevant I guess