This is very confusing. What is strictly 404 handling. Why would someone ever choose that

Feel free to come up with better terms. strict 404 handling means, that the whole routing pipeline has to process the URL and every parsed part of the URL gets removed. If at the end of the parse pipeline some part of the URL path is left, then we were unable to parse that and we got an invalid URL, throwing a 404. However, this is not backwards compatible to all routers out there. In the past we did not enforce that rule and thus there are lots of component routers and additional routing code, which behaves differently and would erroneously throw a 404 even though "everything is alright". So we have 3 options right now: Add this option that makes the 404 behavior of Joomla near perfect, don't add this option and accept that the new router does not throw a 404 in all cases or remove the new router and live with the complaints from users that the old router is just bullshit and have 3PD keep on writing bad routers.

Thanks to autocorrect my original comment lost its meaning. As it is
currently described in the options it is unclear why someone would not
chose the strict option. Which from my limited understanding of the issue
with your router code is absolutely not what someone should be doing at all.

On 20 Mar 2017 1:15 p.m., "Hannes Papenberg" notifications@github.com
wrote:

Feel free to come up with better terms. strict 404 handling means, that the
whole routing pipeline has to process the URL and every parsed part of the
URL gets removed. If at the end of the parse pipeline some part of the URL
path is left, then we were unable to parse that and we got an invalid URL,
throwing a 404. However, this is not backwards compatible to all routers
out there. In the past we did not enforce that rule and thus there are lots
of component routers and additional routing code, which behaves differently
and would erroneously throw a 404 even though "everything is alright". So
we have 3 options right now: Add this option that makes the 404 behavior of
Joomla near perfect, don't add this option and accept that the new router
does not throw a 404 in all cases or remove the new router and live with
the complaints from users that the old router is just bullshit and have 3PD
keep on writing bad routers.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#14803 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8R7bzzA431vJ41SxslhbpRu6AS8_ks5rnnv7gaJpZM4MiXBL
.

Which from my limited understanding of the issue with your router code is absolutely not what someone should be doing at all.

I don't know what you are trying to say with that.

Should we not also revert the test that Georges changed with his PR. If i understand you correct the tests needs to pass now in the old state?

Just an idea.
Can't we combine the two switches (modern router and this one) into one?
So either you have new routing with strict 404 or no new router at all. I know we miss the option of someone with new router and old 404 system to keep compatible some 3rd party extension that would like to use the new router but i think it worths it.
1 switch to turn new router on and whatever 3rd party is not compatible due to the 404 system could just say its not compatible! We have lived with the old router for years it's not so bad for some sites to still live cause of an incompatible extension.
On the other hand managing a lot of switches for the majority of sites just to turn new routing on could be troblesome.

No, we can not combine these switches. Not as long as we give a fuck about our promise of backwards compatibility and SemVer. If we didn't care about B/C, all of this work could have been oh-so-much easier. We could simply take the code from 4.0 and be done with it. But we promised to be a serious project, something that is good for more than just your WoW Clan homepage, and then for fucks sake we have to stick to our promises and the biggest promise that we made was, that we wouldn't break your site with every update. So, no, we can not drop that switch.

Technically, the new router isn't B/C anyway as old links may not be valid anymore and site structure may be incompatible.
You maintain B/C by making the new router optional. That's all.
Once the new router is enabled, it isn't really B/C. Otherwise you would have to automatically redirect the incoming old URLs to the new URLs.

And please revert the change you did to the name of the routing option. It's out of scope for this PR.

Since the 404 feature is part of the application router, the B/C switch between old and new routing is in the component router, without this additional switch the whole thing is NOT B/C the way you guys merged it in now.

I will not revert the changes to the language files.

I will not revert the changes to the language files.

looks like you do not want this pr to be merged and justify some issues of the "Experimental" router by saying so. this behavior does not look good to me. understatement.

So let me recap:

• This project took 8 years to get to the place we currently are at. Not because it is so complicated or because the code wasn't ready, but because it was actively ignored and sabotaged
• People are badmouthing this project, despite that this code has the best test coverage and code quality of all of Joomlas code (in the confines of our B/C and SemVer promises) If I were to start listing all the features that did not come even close to that and still were merged prematurely without (unit) tests and with mesaurable detrimental effects on peoples websites, we would sit here for a long time.
• Parts of the production leadership seem to actively try to sabotage all of this by giving it the bad name of "Experimental routing". Nobody called the tags "experimental tags" or the custom fields feature "experimental" and boy would they deserve that name. (Yes, the custom fields improved a lot. But again only because I had to be a pain in the ass and explain over and over again, that you were breaking B/C)
• So far, no one from those critical towards the router have contacted me and worked on potential issues with me. You know, like in a team. Instead actions were taken, like the one described above.
• The following people have claimed that the router has issues, but so far were unwilling to name them: @infograf768, @rdeutz, @joeforjoomla, @gwsdesk (Those are just the most recent ones. Might have forgotten some.)
• The people loudly advocating against the new router have very obviously never read the code or thought about our current and the new concept.

And after all of this, you are saying to me that apparently I'm sabotaging this PR? That is truely a way to keep contributors.

Unless you are adding something useful to this pull request, let's keep the dissertations and opinions of each other to a minimum.

I would like to make these options understandable by the user but i still am confused at the purpose and real world behaviour of these options so i cant help. Sorry.

The newer router code can't throw 404s consistently without a B/C break. So this is adding a user switch to be able to control whether the B/C breaking portion of this is applied (see Hannes' quick demo from #14542 as a use case where this looks like a user would need to turn off raising 404s with the new router).

I don't know how to make the strings usable either at a glance, but hopefully that explains it a bit.

To be honest, backward compatibility is broken as soon as you enable the new router.
Example: If you look at the testing sample data in the "Article Category List" menuitem, there is an entry for a "Getting Started" article. That article also has a menu item associated to it, so the correct link would be /getting-started.html. Now for some (not so) funny reason the legacy router creates /getting-started/19-sample-data-articles/joomla/22-getting-started.html for that article.
So the old router creates two different URLs for the same link, which obviously is bad and is fixed with the new router correctly.

However the old router is able to parse both URLs and give you the expected page. The new router will give you a 404 error for the wrong link.
While you can argue that this is the right behaviour, it isn't B/C and will break many links, bookmarks and Google results where that "wrong" link is stored. I doubt people expect that and will be pleased if they find out.

So if we're talking about B/C here, we need to be aware that B/C is already broken as soon as you enable the new router (or update to 4.0 in future).

Thanks @mbabker but that really doesnt help make these strings understandable or go towards helping to change them to have real meaning

• "Don't use strict 404 handling"
• "Use strict 404 handling only for modern routers"
• "Use strict 404 handling everywhere"

For example does this strict 404 only apply when you have the modern router enabled? If yes then option 3 above makes no sense. If no then what can I as a user expect to see change on my site if I enable option 3.

Finally, assuming I understand correctly and I am not convinced I do, we should be explaining to users that they are currently not using strict 404 and what the benefits of enabling it are.

@mbabker the example you are talking about is about removing duplicated content isnt't and not about generating 404

/me more confused the more I look

Specific example: You have a category blog menu item and in there, you go into a subcategory and onto the second page. The default Joomla URL would be www.domain.tld/fruits/23-a?start=8

The application router now parses that URL and first sees the menu item (/fruit/) and then hands over to the component router, which parses the "23-a" to point to the subcategory 23 (for all fruits starting with an A). The component router is the part that is aware of modern or legacy routing. When parsing the URL, both the component and application router remove the parts that they parsed, resulting in the end in an empty path and thus we've successfully parsed all parts of the URL.

Now we install a plugin that extends our application router and changes the ?start=8 to /page-2 instead, resulting in the URL www.domain.tld/fruits/23-a/page-2 However, when parsing that URL, that plugin does not remove the part it parsed (hey, its the last part of the URL anyway, so why bother...) and thus our path is not empty anymore at the end of the router. In 4.0 we will throw a 404 in that case. In 3.x we have to stay B/C and thus can not throw one.

Now the described plugin registers in the application router and thus will work for all components, no matter what. com_content, com_contact, some forum or a shop. However the option for modern routing is component specific. So I can enable modern routing for com_content, but keep the legacy routing for com_contact. (My content structure might rely on the wonky behavior of the old router for com_contact and work fine in com_content with modern routing.) The site would work perfectly fine and still deliver all the right pages, but not throw the right 404s. However, simply enabling the behavior for all modern routing would mean that in this case com_content would fail and throw false 404s, while com_contact works fine. So you have to decide on a case by case basis.

that really doesnt help at all :(

Please try to answer the questions I asked - copied below

For example does this strict 404 only apply when you have the modern router enabled? If yes then option 3 above makes no sense. If no then what can I as a user expect to see change on my site if I enable option 3.

Finally, assuming I understand correctly and I am not convinced I do, we should be explaining to users that they are currently not using strict 404 and what the benefits of enabling it are.

(I am looking for the documentation on the experimental router but cant see any - probably my bad search - could you please point me to the url with the documentation or at least the specification with the intended behaviour)

From reading github it is clear that Hackwar is a very intelligent guy but is being victimised by some members of the development team. Tbh some of you sound like children when I'm sure you're adults?

Option 1: Don't do any 404 handling in the application router. The situation that we had before #14542
Option 2: Only do the 404 handling with components that have modern routing and have modern routing enabled.
Option 3: Do the 404 handling globally for all components. (What we are going to have in 4.0)

Option 1 keeps old code working, option 2 makes the router throw 404 errors for all modern routers and option 3 allows developers to prepare their components and routing code to the new 4.0 situation and if the code of a site is up to spec, site owners can benefit from a more consistent 404 behavior.

I'm still working on the documentation.

thanks - so how about

1. "Default 404 handling"
2. "Enhanced 404 handling when modern router is enabled"
3. "Enhanced 404 handling globally"

sounds good to me.

What about enabling this within in the component instead of globally. We cant enable the new router globally so it sees odd at first glance that this can be done globally

Again, this is an option for the application router, not the component router, while the modern routing is an option of the component router, not the application router.

That might make sense to you as a developer but its all gobbledygook to a user

I changed the language strings.

...NO_404_HANDLING = Default 404 handling?

Thats even worse than the wording before.
Let us call a spade a spade.

...NO_404_HANDLING = No 404 Handling

@dneukirchen That is factually wrong. We are throwing 404s in numerous places.

Yes, i know, but not in all places our users expect them to be thrown.

No 404 handling will inform the users what will happen if they choose the option and sometimes ux is more important than factual correctness.

New users will enable the "modern" routing and will not change the "default" 404 error handling. This will fuck up their site, they will think joomla is crap and install wordpress, because wordpress has this super cool "experimental" feature called "404 error handling".

I dont want joomla to be the first web-cms in history that does not (completely) handle 404s by "default".

Beside the wording, i think this is just another confusing joomla configuration option.

Oh, I fully agree with you that this option is pretty much unintuitive and not really helpfull, but as long as we want to improve our code and not jump to 4.0 directly, we will have to use clutches like this to at least partially solve the issues we inherited from the past.

And Joomla hasn't handled 404s correctly since 1.5.

Closing at this time https://developer.joomla.org/news/674-statement-about-the-new-router-feature-for-3-7-0.html