I can NOT confirm this "issue" As can be seen from the attached screenshots I had no problem assigning a different template to one menu item.

Template assigned

Default is protostar

Assigned is beez to contacts menu

I cannot replicate issue but:

This issue was reported some days ago in a German forum.
Several supporters tested if they can replicate the issue.
2 couldn't (relatively new installations).
2 could (older installations updated step by step over the years and the error ocurred somewhere between 3.4.5 and 3.4.8).
1 could but was not sure if reason is a custom plugin (something like a template framework)..
((I'm not native german. I hope I translated the results correctly.)

@Quetzalthefirst
Did you already test without SEF?
Did you already deactivate plugins (I think mainly system plugins but am not sure)?
Are you using a template framework or have activated one "in the silence"?

I strongly suspect this is an issue caused by a template framework and is
not a joomla issue. I have seen far too many badly coded templates

On 11 January 2016 at 16:23, bertmert notifications@github.com wrote:

I cannot replicate issue but:

This issue was reported some days ago in a German forum.
Several supporters tested if they can replicate the issue.
2 couldn't (relatively new installations).
2 could (older installations updated step by step over the years and the
error ocurred somewhere between 3.4.5 and 3.4.8).
1 could but was not sure if reason is a custom plugin (something like a
template framework)..

@Quetzalthefirst https://github.com/Quetzalthefirst
Did you already test without SEF?
Did you already deactivate plugins (I think mainly system plugins but am
not sure)?
Are you using a template framework or have activated one "in the silence"?

—
Reply to this email directly or view it on GitHub
#8878 (comment).

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

@brianteeman
After some investigations together with a friend (from the German forum) we think you're right!
A too early getTemplate() call by plugins before routing or something.

Test qwithout SEF... Yes... Bug Yes...
All plugin desactivate yes... Bug yes
the template is YouTheme... So you can test on it to find the bug...

I think that joomla must be sufficiently idiot proof to by pass bad coding in template!!!

I think that joomla must be sufficiently idiot proof to by pass bad coding in template!!!

Bad coding is bad coding... When a template, specially those with their own framework, is overriding Joomla defaults, then the responsible IS the template and not Joomla!

I think that joomla must be sufficiently idiot proof to by pass bad coding in template!!!

We tried, but it turned out the bad coding practices always win. There is some responsibility on the other side as well.

Closing as not a core issue.

But the fix is available and IN core file of joomla ! Why dont implement it ?

A better question would be why is yootheme writing invalid code and selling
it to you

On 12 January 2016 at 13:38, Normand Brousseau notifications@github.com
wrote:

But the fix is available and IN core file of joomla ! Why dont implement
it ?

—
Reply to this email directly or view it on GitHub
#8878 (comment).

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

But the fix is available and IN core file of joomla ! Why dont implement it ?

Because it's crap (sorry). We've tested it yesterday with 6 testing sites and 2 crashed. These 2 sites with (too) many extensions installed didn't have any problems concerning template styles before hacking it.
On the other hand we needed just 4h to bugfix our badly programmed custom system plugins and found 3 basic solutions to avoid this error. Just had to think a while ;-)

Brianteeman... It's a really good question... Answer too is simple he want cash... ;) I'm not one who bought the template initially ... I'm just caught up with!

Bertmert : I'm not one who code the fix..I just found it on joomla forum. I don't test it on many website nor I have found many site with the bug. But if I remember, youtheme is not the only one with this bug (initial coder of the fix dont have youtheme i think).

So instead of having a sterile debate on "who's fault" or "who has the worst coding habits," can we have an indication of what causes the problem and where to look for the solution

@Solinfo
To clarify: In our case the problems occured also by custom system plugins that have nothing to do with template frameworks. Any plugin could provoke this issue.

We found our buggy extensions with this debug code that a friend provided here:
http://www.joomlaportal.de/joomla-3-x-templates-und-design/323793-templatewechsel-seit-jommla-version-3-4-8-den-webs-nicht-mehr-verf-gbar-4.html#post1613060

Output of debug code is the first file that calls getTemplate().

50:50 chance.

Main problem like very often: Nobody is willing to test to make further investigations possible. Nobody provided detailed informations about extensions.

• Calling getTemplate() before Routing has happened caches the standard template.
• So, an extension shouldn't do that before Joomla framework has done Routing
• or should "repair" the cached template by setTemplate() immediately after routing. (Friend provided a temporary workaround here: http://www.joomlaportal.de/joomla-3-x-templates-und-design/323793-templatewechsel-seit-jommla-version-3-4-8-den-webs-nicht-mehr-verf-gbar-3.html#post1613046 that's not always reliable)
• Or has to identify correct template and style in a similiar way like protected function parseSefRoute(&$uri) does; without touching core flow.

Because this is not a forum here, try to contact the guy at the German forum. I will tell him. I will help him to translate your message.
Normally he doesn't answer on private messages. So, just a maybe. His decision.

It's simple, any plugin which tries to do something with templates in the onAfterInitialise event is bound to fail. They have to do the stuff in the onAfterRouter event (or later) because only there the routing is done and the template specified.
So it's not a question about whos fault it is. That one is clear. The plugin wants to do something during an event where the needed information isn't available yet. The "fix" proposed in the forum would do the routing earlier, which likely breaks stuff elsewhere. The real fix is that the plugin should use the proper event.