I am confused. Modern reporting is turned on per component so how is it effecting a non core component

Well this is exactly what i'm asking to myself. How is it possible that modern routing inject other vars in the request when a random extension is executed???

I think you are going to have to provide a copy of an extension that exhibits this behaviour so others can observe what you are seeing

The particular extension doesn't matter. It happens with all extensions.

For this case i report the OsMap extension and attach screenshots of Zend Debugger.

Using the link: http://joomla37/en/index.php?option=com_osmap&view=html

you notice the additional request variables, they look as having to do with the com_content component itself. Disabling the modern routing, the multilanguage or simply doesn't appending 'index.php' those variables are no more injected.

Using this link: http://joomla37/en/?option=com_osmap&view=html there are no more additional vars as it should always be.

@Hackwar

looks like the router does parse the SEF URL part (which happens to be the homepage) and adds the non-SEF query parts as expected from the homepage menu item and only afterwards the request is dispatched to the component.

Since it is related to multilanguage, this looks like an issue with the language plugin that tries to do stuff it shouldn't do yet before the request is properly dispatched?

Do you get the problematic behavior without the modern routing enabled?

The modern routing is NOT identical to the legacy routing and you should NOT expect it to behave 100% the same. That is why we have the switch between old and new routing in the first case.

@Hackwar without the modern routing enabled there are no problematic behavior obviously.

The question is not discussing 'NOT identical' or 'Identical' to the legacy, the problem is that in no cases an unexpected $_REQUEST variable due to incorrect routing must be present, this simply makes no sense and leads to errors.

If you develop the new routing and then everyone using Joomla has to switch and keep the legacy router because the new ones doesn't work and has a lot of issues, my question is: why did you develop it and pushed in Joomla 3.7?

The question here is understand and fix the issue.

The $_REQUEST array should represent the current request. The additional data that you see in that array right now represents the complete request that Joomla is processing, since the query of the current menu item is part of this current request. Yes, Joomla currently has some broken behavior in that regard in that it does not add those elements to the parsed request data, but that is why the new routing was developed: To clean up the fuckload of broken things in Joomlas routing.

If your code breaks because you switched on an optional feature, then don't blame the optional feature. You should understand and fix the issue in your code. Or not use the optional feature. (Which is why the legacy routing is still enabled by default and will stay that way until 4.0)

@Hackwar i hope you are not serious.
Despite the fact that i've nothing to fix in my code and i'm talking about an issue affecting ALL extensions, i can't believe that you are saying what you say.

The broken behavior is in the new routing not in the currently one, if you think that having a posted 'layout=blog' variable when calling a whatever extension you want is pretty normal, i think you are crazy. Every extension that doesn't post explicitely a 'layout=mylayout' will break.

Please assign this issue to the 3.7 milestone and take actions to fix.

I've explained the reasoning for the behavior. Your URL does not contain an Itemid, so it takes the default menu item. That is still expected behavior and you being angry about this, wont change that.

The nice thing is, that I'm not the one in charge and that those that are, are free to overrule me here. Just don't expect code from me to again break expected behavior.

I'm not angry about this. I'm only saying you that this is not ok and acceptable and must be fixed.
If you don't have an Itemid simply don't process nothing, you can't push variables taken from the home page view!!! This is expected? This can't be expected!

Clearly you don't understand how the menu system works under the hood...

It is 100% expected behavior that when an Itemid is not provided (either because it wasn't part of the supplied URL or couldn't be derived from the active route) that the default menu item (AKA the home page, because screw logical naming) parameters are used. It has always been this way. This is no change in 3.7.

If you find it unacceptable that Joomla uses the default menu item when a menu item cannot be derived from the request, I suggest finding a new platform or rewriting the menu and routing systems in your vision.

I can find acceptable that Joomla uses the default menu item when a menu item cannot be derived from the request. But i can't find acceptable that variables from that menu item are used when a random component is executed.

And this is changed in 3.7. This has not always been this way.

No, this has not changed in 3.7. This changes, when you consciously switch from legacy to modern routing. And as I've explained numerous times, "modern" routing has been developed to fix all the longstanding bugs in routing and is explicitely NOT backwards compatible. It tries its best to be backwards compatible, but it has to stop at one point, since otherwise it would negate the whole effort of writing the new routing.

This is a bug and you refuse the fact that it's a bug.

If i execute this URL: http://joomla37/en/index.php?option=com_osmap&view=html
or this URL: http://joomla37/en/?option=com_osmap&view=html

results must be identical! You can't have additional $_REQUEST vars taken from the home page com_content when executing com_osmap using the first URL and not the second.

This is simply a bug.

How many times do we have to explain before it is understood THAT IS THE JOOMLA CORE BEHAVIOR AND ALWAYS HAS BEEN!?

Unsubscribing and blocking this troll. Clearly this guy has no freakin' idea how Joomla works.

I'm not a troll! How do you permit to label me?
I just provided screenshots of this erroneous behavior and proof of concept that it's happening only with the new routing. So why you go on and on to say 'always has been' ?

I would have not open this issue in such case i'm not stupid.

You are missing the point. As I've said before: The new routing is NOT identical to the old routing. Don't expect it to behave the same.

I got the point and i don't expect to behave the same, i simply expect to behave correctly.
If com_xxx gets variables from the home menu item com_content it's not conceptually correct and leads to errors and B/C breaks.

As of @mbabker i could say that i've idea about how Joomla works, because i developed dozens of extensions starting in 2004 when it still was Mambo. So think twice before talking to me and offending.

for there being a break in B/C there would have to be something before this and there wasn't. This is new code. This is code that is new and thus can not have a break in B/C. You want your component request not be messed with by the default menu item? Add the right Itemid to your request.

there are cases when extensions don't do a request routing simply because an itemid is not required

In the frontend, you ALWAYS, ALWAYS, ALWAYS!! have an itemid. If you didn't set one so far, you got away with it because Joomla didn't follow rules strictly. But that has been almost everything that we have been doing in the last 11 years: Get this codebase to finally stick to sane rules. 4.0 will be another BIG move in that direction.

When you call a raw link such as:
index.php?option=mycomponent&view=myview&format=raw

or simply
http://www.wbesite.com/component/contact

you have no worries about to get an Itemid and it makes no sense too

Sorry that is just plain wrong!!!!

You refuse repeatedly to post an example extension - this is your final opportunity to do so before I have no choice but to close and lock this issue

But this is another question.
Nothing to do with this issue. This issue is about variables routed from a component A inside the execution of a component B
And this must not happen. Period.

@brianteeman i posted the example of 'OSMAP' extension.
You should clearly see it above.

I also posted screenshots, what else?

@joeforjoomla I think you don't really understand the nature of the problem here. The extra variables you see there are created automatically by Joomla as it didn't found an itemId and used the fall back to the home page (I think this is the logic). So THESE VARS COMES FROM YOUR HOME PAGE.

@Hackwar

In the frontend, you ALWAYS, ALWAYS, ALWAYS!! have an itemid.

Agreed with the above, doing it already, longtime, yes, but

When you call a raw link such as: index.php?option=mycomponent&view=myview&format=raw

I was thinking of the above too

• what about URLs that do not need an itemId like raw / json AJAX requests ?

An example of com_finder:

index.php?option=com_finder
 &task=suggestions.suggest
 &format=json&tmpl=component
 &lang=el&q=a

it does not have an itemId, right ?
so if i have a random menu item as home page the above URL will get some random request variables, that of course depend on the type of the home page menu item

So i guess it will be a requirement that we add a menu item id to the **raw / json AJAX requests too ? to avoid "rare" conflict problem ?**

or the above will not be needed ?

I have spend a huge amount of time myself on routing of my component to optimize it and fix all the cases and of course will try to adapt and use the new routing, (just i have not spend time yet, will do)

I think @joeforjoomla have a valid point. When the default menu item (home menu item in this case) is linked to a different component with the component being executed in the current request, we should not merge vars from the menu item to the request.

what about URLs that do not need an itemId like raw / json AJAX requests ?

The routing cares for itemId only for the html part ( @Hackwar can you confirm this?)

The routing cares for itemId only for the html part

hhmm, i have lost some episodes on the new routing, or i have forgotten some details of it

so if there is &format=raw, the (new?) routing is happening differently ?
i will need to look at it, and do my homework ))

Finally someone is going to agree with me, thanks @joomdonation and thanks @ggppdk

I perfectly agree that the home item id can be used as a fallback by the new routing, but in all cases such as:

index.php?option=com_finder
&task=suggestions.suggest
&format=json&tmpl=component
&lang=el&q=a

when an Itemid is NOT required at all there should never happen that extra variables from the menu item id are pushed in the $_REQUEST

indeed i found this issue due to a B/C break in an extension using a link with tmpl=component without specifying a layout and Itemid, simply not needed in such cases.

The layout was so overwritten with 'blog' instead of 'default', causing the extension breaking that obviously had not a 'blog' layout.

Th new router should at least avoid this issue when format is different than html or the templ=component is used.

I've been offended by @Hackwar, @mbabker and @brianteeman and i don't like this.
We are all here to discuss and improve our beloved CMS, there is not a valid reason to threaten people.

It wasn't me who started with insulting other people.

You may report your offense to https://volunteers.joomla.org/teams/joomla-code-of-conduct-working-group so those with a politically correct mind may tell those of us who are blunt that we are hurting people's feelings and can't be so blunt.

And to complete my point:

1) There is not a backward compatibility break in this code; it has been said since day one it is an opt-in behavior, an entirely new approach to routing, and is not 100% compatible with the existing code and conventions. Stop spreading FUD. This is in part why I have written you off as a troll.

2) Coming in here and demanding that releases are held up and that everyone drop everything to fix your issues does NOT gain you anything in these parts. You have done this at least three times. This is in part why I have written you off as a troll.

3) You have demanded that existing broken behavior be implemented into the new routing code and have implied that allowing broken configurations to work without masking their issues is a bug when it is clearly a case of broken behavior. This is in part why I have written you off as a troll.

4) It has taken 18 freakin' hours to get to a scenario where one MIGHT be able to analyze this for a potential issue. Therefore your original report and follow on commentary has proven inadequate to communicate your point and has only furthered my frustration with this joke of a project that I can't leave because nobody has the trust or capabilities to assume my responsibilities (my open offer still stands if someone's stupid enough to step up; BTW when you do so you're usually used and abused until you're burned out and pissed off at the world then written off as a troll and toxic to the community).

5) This should be enough for the CoC team to act on on your behalf since you're offended. You're welcome.

I'm here to fix an issue not to discuss about controversy and that was not my intention. I've even not time for controversy. So let's back to the issue to reproduce it.

1. Open the file Joomla37/components/com_mailto/mailto.php

2. At the line 18 add: var_dump($_REQUEST);

3. Open this link:
   http://joomla37/en/index.php?option=com_mailto&tmpl=component&template=protostar&link=b65b881996cd1311fde1ec62efaacf08af3da29a

4. This is the result:
   array(10) { ["option"]=> string(10) "com_mailto" ["tmpl"]=> string(9) "component" ["template"]=> string(9) "protostar" ["link"]=> string(40) "b65b881996cd1311fde1ec62efaacf08af3da29a" ["language"]=> string(5) "en-GB" ["Itemid"]=> string(3) "101" ["view"]=> string(6) "mailto" ["layout"]=> string(4) "blog" ["id"]=> string(1) "9" ["lang"]=> string(5) "en-GB" }

5. Open this link:
   http://joomla37/en/?option=com_mailto&tmpl=component&template=protostar&link=b65b881996cd1311fde1ec62efaacf08af3da29a

6. Expected result
   array(8) { ["option"]=> string(10) "com_mailto" ["tmpl"]=> string(9) "component" ["template"]=> string(9) "protostar" ["link"]=> string(40) "b65b881996cd1311fde1ec62efaacf08af3da29a" ["language"]=> string(5) "en-GB" ["Itemid"]=> NULL ["lang"]=> string(5) "en-GB" ["view"]=> string(6) "mailto" }

Self explaining.

For the last time - please provide a copy of an extension that is broken.

If this is not provided then this will be closed- we want to help but you
are making it imposible

On 26 October 2016 at 13:17, JoeforJoomla Boy notifications@github.com
wrote:

@Hackwar https://github.com/Hackwar i hope you are not serious.
Despite the fact that i've nothing to fix in my code and i'm talking about
an issue affecting ALL extensions, i can't believe that you are saying what
you say.

The broken behavior is in the new routing not in the currently one, if you
think that having a posted 'layout=blog' variable when calling a whatever
extension you want is pretty normal, i think you are crazy. Every extension
that doesn't post explicitely a 'layout=mylayout' will break.

Please assign this issue to the 3.7 milestone and take actions to fix.

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

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

an example of your component!!!

On 26 October 2016 at 14:55, JoeforJoomla Boy notifications@github.com
wrote:

I also posted screenshots, what else?

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

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

And this is changed in 3.7. This has not always been this way.

For the last time - please provide a component to prove/demonstrate this

On 26 October 2016 at 13:43, JoeforJoomla Boy notifications@github.com
wrote:

I can find acceptable that Joomla uses the default menu item when a menu
item cannot be derived from the request. But i can't find acceptable that
variables from that menu item are used when a random component is executed.

And this is changed in 3.7. This has not always been this way.

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

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

OsMap is broken, it's free everyone can download it. I was talking about it since the beginning.
By the way the point is not helping me, is fixing a Joomla issue.

Also my examples demonstrate that the issue is happening with every extension, so there is no reason to request a specific extension broken. Potentially all extension using certain links could face errors to this issue.

What i don´t understand in this discussion is, is the extension built like it should be according to the NEW routing, or is this error appearing with renewed code according to the new routing?

I can confirm the issue and I really think it is a valid one. However it is not related to the new routing, it's only related to the language filter plugin as far as I see.

Normally, the request parameters from the menu item indeed are not added to $_REQUEST/JInput. At least not if the requested option doesn't match the menu item (which makes perfectly sense).
Eg http://localhost/joomla/en/?option=com_sermonspeaker works fine with or without modern routing.
Now if you use http://localhost/joomla/en/index.php?option=com_sermonspeaker, it will explode and give you a "View not found [name, type, prefix]: article, html, sermonspeakerView". It is because the view (and id) from the homepage menu item is added to the request, but that "article" view doesn't exist in the requested component (SermonSpeaker in my case).

The only difference between those two URLs is that the second has "index.php" in it.

If I disable the language filter plugin, it again works as expected with the following URLs:
http://localhost/joomla/index.php?option=com_sermonspeaker
http://localhost/joomla/?option=com_sermonspeaker

So @joeforjoomla found a valid issue, but tracked it down to the wrong place (imho).

On a sidenote, it's also already present in Joomla 3.6.4, so not related to 3.7 and the new routing at all.

Thanks @Bakual. Indeed despite the fact that other people said this, i'm still not stupid.

The fact is that at least in Joomla 3.7, if i disable the 'modern routing' in the com_content, the issue is not more present. I've faced an extension that throws "View not found [name, type, prefix]: article, html, ..." as in your case because of this issue.

The fact is that at least in Joomla 3.7, if i disable the 'modern routing' in the com_content, the issue is not more present.

I could still reproduce it with modern routing disabled, and on 3.6.4. Which means it's not related to that. (see http://sermon.hopto.org/en/index.php?option=com_sermonspeaker which is a 3.6.4 site).
Not sure why it did change something in your case.

Mmm very weird... let me do some more tests on Joomla 3.6.4 too. However this issue happened only on 3.7 with new routing enabled. That's why i noticed the problem, an extension stopped working on 3.7 with new routing, while it's still perfectly working on 3.6.4

You are right @Bakual, this issue is already present in Joomla 3.6 or legacy router on 3.7, additional vars are added to the $_REQUEST

The only difference is that when new routing is enabled even the 'layout' var is added and this caused the view/layout not found breaking extensions.

In more details, with legacy routing or Joomla 3.6 i get vars as 'view=article' and 'Itemid=101' (home page) even if the home page links a category blog (incorrectly)

With new routing i get vars as 'view=category' , 'Itemid=101' and 'layout=blog' that would be correct because the home page links indeed to a category blog... only those vars should not be there at all in such cases discussed above.

@Bakual
Does this mean we have to change all instances of index.php? to ? in the language filter?
Ir is it more complex than that?

IMHO i would try to find a way to not inject any additonal vars to the request taken from a component A when the component B is executed, despite the fact that the URLs contain index.php? or simply ?
Such a thing may always lead to unexpected behavior, who knows

Does this mean we have to change all instances of index.php? to ? in the language filter? Or is it more complex than that?

I don't know yet, I haven't tracked it down to the code causing it. The language filter plugin is just my first suspect based on the testing.

The language filter plugin probably is where the problem occurs.

If you disabled it or bypass it for example using http://sermon.hopto.org/index.php?option=com_sermonspeaker&lang=en
the problem doesn't occur at all, debugging there are no additional and unexpected vars added to the $_REQUEST by the router.

Waiting for the apology for your rant that this was all about the NEW code
in 3.7

On 26 October 2016 at 20:42, JoeforJoomla Boy notifications@github.com
wrote:

You are right @Bakual https://github.com/Bakual, this issue is already
present in Joomla 3.6 or legacy router on 3.7, additional vars are added to
the $_REQUEST

The only difference is that when new routing is enabled even the 'layout'
var is added and this caused the view/layout not found breaking extensions.

In more details, with legacy routing or Joomla 3.6 i get vars as
'view=article' and 'Itemid=101' (home page) even if the home page links a
category blog (incorrectly)

With new routing i get vars as 'view=category' , 'Itemid=101' and
'layout=blog' that would be correct because the home page links indeed a
category blog... only those vars should not be there in such case.

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

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

Instead of worrying about apology, It would be better to focus on the issue that i've discovered. The fact that it's related to the old or new routing makes no difference after all, the new routing is what made the problem bubbling up. Do you want my apologies? You have it, now i wait yours and all other members that attacked me.

So can we change the title to show it is NOTHING to do with NEW MODERN routing then?
If you had accepted that it was nothing to do with that much earlier it woudl have saved everyone a lot of wasted time

Please folks, just cool down.
We do have an issue here that nobody remarked UNTIL the use of the new router. Therefore this topic was useful and I do hope we can solve as, for the moment, we do not have a PR as we are not sure where precisely it comes from.

Thanks.

Thanks @infograf768 . You are very nice as always. As of @brianteeman , please cool down.

unsubscrbed

@joeforjoomla,

you remember that i supported that adding random URL variables to REQUEST that depend (come from) the home page menu item is an issue

• but your last comment does not help the purpose of "cooling down",

plus it seems that you were 50% wrong,
since the issue (thanks to @Bakual findings) comes from a different place than you originally suggested,

i have been wrong-guessing several times about code issues in the past,
and now i first try to find the offending code before posting an issue to any issue tracker (i mean for users that are programmers too)

@ggppdk i already did apologize because i was wrong to point out where the issue comes from. Would it be possible to stop this controversy please? Sorry for that.

See #12600. That should fix the issue.

Closing as we have a PR.