First of all, thanks for this feature!! :)

I tested the integration with com_content, com_newsfeeds and com_content in the following way:
1) Go to the front-end and look at the url of a single item with id
2) Apple the new url routing and set the option Remove IDs from URLs to "yes"
3) Check if the id is removed and the same item is displayed.

For com_content I tested the is PR successful.

For com_contact I can't find the parameter under the tab "Integration".

In com_newsfeeds there is a undefined language string (not sure if that is something for this PR).

Maybe it is also an idea to hide this parameter till the "Use new router" is set on "yes"

Not able to apply patch on latest staging site.

Error

The file marked for modification does not exist: libraries/cms/component/router/rules/menu.php

Make sure you've checked out the 3.7.x branch as this PR is targeted against it, not staging.

hmm I found out something else.
When disable the new url routing you can do something like this: http://joomla-cms.dev/index.php/17-first-blog-post. At that moment you see the article "First blog post".
When the new url routing is enabled, I don't see this article, but the home page instead.

I think this is a bug (or is it just normal behaviour with a good reason?)

I have tested this item ? unsuccessfully on 6159beb

It is working for com_content but not for other two.
"Remove IDs from URLs" option not visible in com_contact.
Clicking on Single News Feed gives "Page not found" error. [Error: No registered feed parser for type html.]

See results below (Joomla! 3.7.0-dev):

com_contact:

com_newsfeed:

Error on news feed link visit:

I have tested this item ? unsuccessfully on 6159beb

• Installed Joomla 3.7.x of today.
• Checked testing datas during installation.
• Applied this patch (Is this sufficient????)
• Enabled Use new URL routing and Remove IDs from URLs for com_content.
• Concerning following errors it makes no difference if Use URL Rewrite is enabled in global configuration or not.
• Unpublished all menu items in menu Fruit Shop to be sure to have articles with leading id in URL in category views.

• Opened in FE menu All Front End Views > Article Categories.

• Error: See 3 categories but 2 categories links are pointing on the current page /article-categories instead of on the category. (See image: red arrows)

• Deactivated only setting Remove IDs from URLs in com_content. Same error.

• Deactivated Use URL Rewriting in global.
  and deactivated Remove IDs from URLs
  Same error.

Whenever Use new URL routing is activated in com_content same error.

After removing the patch: Behavior as expected.

Confirm this issue. When the crappy 'New URL routing' is activated every links not only in com_content but even in com_contact, etc are no working anymore. Basically nothing works with this new router, all websites links get broken. Categories links point to the same page instead of that the category itself, etc i can't find anything working as of now.

Is there still interest in this? It's an important feature that was one of the top rated ideas that people want to see in Joomla.

Its a lot of work going into this router project. Hope it finally can get into J 3.7. And its needed to replace the crappy old Joomla router.

Its a lot of work going into this router project. Hope it finally can get into J 3.7. And its needed to replace the crappy old Joomla router.

Then test it. Report any problems and if possible submit PRs. Thank you.

Seems I forgot to set array_reverse() to keep the array keys. This should all work now. But since the 3.7.x branch currently is broken in terms of unittests, those fail spectacularly. ? ?

Anyway, maybe you can test this again and then blame the rest on those unittests.

Please also test and merge #11936. When that one is merged, the unittests wont fail anymore.

@bertmert I checked the system based on your error description and with the latest commits, those should be fixed. Can you please check again?

@Hackwar I've manually merged the category fixes into 3.7 directly. Can we merge back in staging here and I'll get some more tests going :)

Done

It doesn't seem like the problem with the categories is fixed completely. If you follow @bertmert steps to reproduce (#11320 (comment)) but additionally change the "Select a Top Level Category" option to "Root" for the "Article Categories" menu item the links in the frontend are still broken.

@hackwar we need to do something in the UI for this as currently you can set it to use Legacy routing AND Remove IDs from URLs which obviusly doesnt work. I would suggest just adding a showon to the field

Done

Thanks

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Currently using the latest branch of J 3.7 with this PR and did not see an option for the new URL's nor do the ID's go away. Tested with both com_patchtester V2 and V3. Made sure Joomla cache and host cache were disabled. .htaccess and SEO settings are configured properly. Am I missing something?

In each component there is an option Legacy and Modern routing
If you enable Modern routing then you should see the option

On 21 September 2016 at 12:40, Josh Lewis notifications@github.com wrote:

Currently using the latest branch of J 3.7 with this PR and did not see an
option for the new URL's nor do the ID's go away. Tested with both
com_patchtester V2 and V3. Made sure Joomla cache and host cache were
disabled. .htaccess and SEO settings are configured properly. Am I missing

something?

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/11320
https://issues.joomla.org/tracker/joomla-cms/11320.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11320 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8fJggqyhk9m0VG1OOn6t79hQF3Yzks5qsPuagaJpZM4JWUvU
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I have tested this item ✅ successfully on 8905670

Articles work like a charm with the new router! ? Contacts still seem to have an id in the URL even when using the new router option, but at least the contact form works for each person. Someone else expressed interest in making it so that id's are removed from tags.

@JoshuaLewis it is NOT a successful test if it did not work with contacts!!

Are you sure you enabled the option for the contacts component as well as the content component?

Notice how contacts does not have the option "Remove IDs from URLs"? My understanding is that the new routing feature is actually being utilized with contacts but does not have a visible benefit in terms of affecting the URL due to the option not existing. Perhaps for now it's helping performance on some level?

Yes thats a bug. There is only the option to remove the ID from com_content and com_newsfeeds. It is missing from the other components and should be there

I assumed it was an issue instead of a bug. ;-) Well hopefully when a few more commits are put in we can test it, assuming all goes well this PR would then be RTC.

The option was added for com_contacts. com_users does not use IDs in its URLs and com_tags still uses the old router.

Hey folks can we get some tests in here please?

I have tested this item ✅ successfully on 8dc616b

Thanks for the update. Tested with success on contacts as well. :-) @wilsonge @brianteeman Can we get tests from you guys so that we can be RTC?

This does not work at all here, Modern on and whatever the choice for Remove IDs.
I get urls of the type:
http://localhost:8888/infograf768/?view=article&id=1:getting-started
http://localhost:8888/infograf768/?view=category&id=8

Legacy works fine

@Hackwar

I have tested this item ? unsuccessfully on 8dc616b

Let me explain a bit further:
I get these results when, for a given article (displayed as featured in Home page), I have NO menu item displaying that single article AND/OR no menu item displaying its category.

@infograf768 That is actually an expected result. The result that you are getting is an indicator that your routing setup has errors in the form of missing menu items. A featured view can not be the parent view of an article. That is also the reason why we have the legacy routing, so that people can decide to keep their "broken" routing.

The rule based component routers are NOT 100% backwards compatible. I know that. I always communicated it that way. That is the reason why we have the legacy routing in the first place and why legacy routing is enabled by default. Otherwise we wouldn't have the legacy routing at all.

So as long as it works with legacy routing like before and as long as you get to the page that you expected with the new routing, it is the right behavior. If you have an issue like in #12250, where you click a link that should go to some place else and instead it simply reloads the page, then we have indeed a problem. But as far as I understand you, the 3.7-dev branch together with this PR does not show such a problem as described in #12250, right?

But as far as I understand you, the 3.7-dev branch together with this PR does not show such a problem as described in #12250, right?

Indeed, but the links are really bad (article title link and its Category link.
Same for Categories Module category links.

I expect, in case we have no menu item for a specific item link, to fall back to legacy behaviour:
http://localhost:8888/infograf768/8-my-category/1-getting-started.html
and not
http://localhost:8888/infograf768/?view=article&id=1:getting-started

@infograf768 is right. What you say @Hackwar is something not acceptable. A featured/home view must continue to be used as a routing fallback even in the new router if there are no better menu items to route articles to, such as direct category view. Having such links, that look as broke links, is not acceptable. At least it should fallback on the legacy router as @infograf768 pointed out.

I don't agree. This is a new system, it does not have to have 100% feature parity for it to be accepted, especially if that feature parity relates to what could be argued as invalid logic (and in the case of a featured articles menu item, I do think it's broken logic to use that as the "parent" because that view is a bit of a special case and isn't a hierarchical view like the others are in com_content).

I agree.. I don't agree.... what's game are you playing?
A CMS and what is a labelled as a new fabulous router can't generate in any case a shit link like this one:
http://localhost:8888/infograf768/?view=article&id=1:getting-started
There is no further to discuss, there is only to find a fix.

I'm not playing a game. I'm making a statement of fact. If there is broken logic in the existing system, it does NOT have to be carried forward in a new implementation. The featured article view is NOT a hierarchical view so to me it is broken and invalid logic to expect that to be used as a "parent" item for the generation of URLs. Using that menu item's configuration for the rest of the page behavior (because it is the system default, not the incorrectly labeled "Home" as it is in the UI) should continue (i.e. page metadata, module assignments, etc.), but the "issue" being pointed out here is the result of invalid expectations.

I would expect the same broken behavior if the homepage were a single category view and the article being routed to is an article NOT under that category (or if it has child categories one of those too). These are conditions where the system cannot correctly generate URLs because you're in a spot where there isn't a valid path to generate a proper URL.

The only thing that might be an acceptable fix is to generate a URL using the full category path in these cases but this still requires additional checks for every category up the tree to determine if there is a suitable menu item to use.

I would expect the same broken behavior if the homepage were a single category view and the article being routed to is an article NOT under that category (or if it has child categories one of those too). These are conditions where the system cannot correctly generate URLs because you're in a spot where there isn't a valid path to generate a proper URL.

The issue does not only exists for Featured page display indeed, but for ANY link which has not got a menu item. Test Modules categories for example.

@mbabker @Hackwar

Basically, what you are telling us is that we do have absolitely to create hidden menu items for everything if we want to use this new Router.
And that is why I think we should have a fall back.

No, we are not saying that you have to create "hidden" menu items for everything. What we are saying is, that you have to create the right menu items. The same way it has been in Joomla since 1.5. Except that now we don't mask defective setups with unpredictable fallbacks.

IMO you only need menu items for content (generic term, not articles) that otherwise has no other path which can create a proper URL. If you have an article in the Uncategorised category and neither that category or article have a menu item assigned, the result you're seeing is what I expect because there isn't a valid path anywhere in the system to generate that URL (as I noted an acceptable fallback may be to just write the URL using the category path but honestly the more I think of that the more I realize that's pretty error prone too). If the Uncategorised category has a menu item, the article should be correctly routed as /uncategorised/article. And obviously it be routed correctly if the article itself has a menu item.

The way I see it, what this new code does is not try to generate URLs for content which is in essence an orphan in relation to the menu configuration. And that makes complete sense to me.

Spelling out simply the category path is not acceptable, since for example for /uncategorized/foo-bar you wouldn't know which component to choose. com_content, com_contact, com_newsfeed? You would have to at least prepend that with /component/, which we already do if there is no given Itemid. Since the application router right now however ALWAYS adds at least the current Itemid, this again fails horribly. That is what #12168 tries to fix.

Here I have another example of this behaviour:

Create an article tagged to a language (Italian for example). That article is ONLY displayed as a featured article and we do not have a menu item for its category.

Then edit an article tagged to another language (French for example), use the Article button in TinyMCE and select the former article.

The source shows correctly:
<a href="index.php?option=com_content&amp;view=article&amp;id=30&amp;catid=10&amp;lang=it-IT" hreflang="it">new article (Italian)</a>

Display in frontend the French article.

The link to the new article (Italian) is
http://localhost:8888/370/infograf768/it/?view=article&id=30
instead of
http://localhost:8888/370/infograf768/it/10-categoria-it-it/30-new-article-italian.html

Happily, we still get the correct sef tag, but it really looks bad...

Another one on the same page, the button links to the associated articles in the info block give (example for IT)
http://localhost:8888/370/infograf768/it/?view=article&id=3:articolo-it-it

Therefore, the only way to get a quite nice url IS to create hidden menu items at least to each category on the site.

Or to the root category of your content. And that is indeed the right way.

There also was a time when the categories view was not a castrated copy of the category view and listed all categories and it would have been a valid fallback.

@Hackwar
B/C failure:
Using legacy router (no menu item for the contact concerned), I get different results when clicking on Written by creator contact link in info block as well as when entering a link to a user contact in an article (of the type:
<p><a href="index.php?option=com_contact&amp;view=contact&amp;id=3&amp;catid=16&amp;lang=en-GB" hreflang="en">contact en</a></p>)

Staging:
http://localhost:8888/testwindows/trunkgitnew/en/component/contact/contact/3.html

in 3.7.0-dev, the Itemid is added although it is useless
http://localhost:8888/370/infograf768/en/component/contact/contact/3.html?Itemid=102

I have tested this item ✅ successfully on 8dc616b

@rdeutz

This PR title is misinforming.
The ID removal works fine.
BUT it also corrects major bugs in the routers which make it a release blocker.

Although some aspects of this "modern router" may need further discussion (legacy, fall back) and eventually corrections, nothing is possible until this is merged.
Please merge asap.

RTC

? ? THANK YOU SO MUCH!!!