templates/current-frontend-template/html/layouts/com_your_component

The overrides refer to the current active template so administrator/templates/isis/html/layouts/com_your_component is correct. There is nothing wrong here

Hi, not sure if you understand my previous post.

In case, developer is located in administration but makes a feature for frontend and has the option to force "frontend" - JLayout allows this option - then he/she needs of course use the frontend template.

So if this will be the frontend feature, forced by JLayout to frontend - then another developer can override the layout with frontend template.

If you switch to frontend with option of JLayout, you should switch to frontend fully not partially. :idea:

Now, if you switch to frontend, you have two frontend locations but two backend locations:

• administrator/templates/isis/html/layouts/com_your_component
• components/com_your_component/layouts
• administrator/templates/isis/html/layouts
• layouts

When you change the gear in car to go forward, it does not make sense when two of your wheels go on back and two go forward. :idea:

Jan

@PhocaCz I see what you are saying but that's illogical. Since the backend has a different Joomla! Template it wouldn't make sense to load the front end template override for JLayout. What you should do is duplicate your override to the backend and customise it as needed for the backend if needed.

I believe this isn't really a bug. But more a difference of opinion of how JLayout loads overrides.

You have forced the client and it is looking in the front end component for the JLayout file as designed.

The templates folder is supposed to be used by templaters/frontenders to have full control over the last appearance of things. Calling a frontend template from backend will only confuse them. If it's a backend component it can use its frontend layouts but it should be customised in backend template.

If you need to call the frontend template (let's say for an exact preview of how something will be shown in frontend) then you need to use your custom logic to do it instead of changing the default JLayout behaviour.

Hi @tonypartridge @phproberto

@phproberto

Calling a frontend template from backend will only confuse them

Just see the part "Force Client" here: https://docs.joomla.org/J3.x:JLayout_Improvements_for_Joomla

I am not the one who added the option to force the client (to have the option to run frontend override from backend)

But I want to render my tags in backend in the same way that com_tags renders them in the frontend! This is covered with this sample call ...

In my case, I appreciate this option and it seems I am not the only one who does. Because it was added to Joomla! core and it is documented. So it seems, such option does have sense.

What I want to say is if you get the option to do frontend override called from backend, in such case, all the parts should play together.

Now it works this way:

administrator/templates/isis/html/layouts/com_your_component
components/com_your_component/layouts
administrator/templates/isis/html/layouts
layouts

For me, this is illogical, you override something by frontend component and backend template together.

I just appreciate the option to force the client, to have the option to override something called from backend by frontend layout.

My need ends by frontend component override, but I think user's need does not end there:

1. Users will expect that if the component have override in frontend, such can be overriden by frontend template too
2. Mostly (99% maybe) users use override by frontend templates only.

For now, there is no option for users to override frontend component by frontend template in case it is called from backend (and don't ask me why it is called from backend, the option for doing this is standard Joomla! core feature, based on some user's needs)

@tonypartridge

You have forced the client and it is looking in the front end component for the JLayout file as designed.

Yes, great for me, but I am not egoistic, I just want that end user can have the option too.

In fact, if I do a template override in extension, I just don't care about me and about the option to override it by frontend component. For me it is easier write the output directly in the code. When I do an override feature, I just think about end users and about their possibility to override the component output.

Mostly end user is exactly the reason for forcing the client. Example:

The component renders some output. The same in frontend even in backend - common thing by XML, PDF and even by HTML, etc. Because of stopping duplicities, you have one output where you don't care if it was called from backend or frontend. And you want that users will be able to customize such output. Of course they will do it in frontend template. So if you add the option to be able to override the code in frontend component, it is just intermediate feature. In fact, nobody needs component override when it cannot be overriden by template. Users need to override it per their template. Customizing frontend component layout is nonsense.

Forcing client feature is great feature but without cooperating with template, it does not make any sense. We (developers) do not override because of us (we can just make the output directly in the source file), we just do it for end users so they can override with template:

administrator/templates/isis/html/layouts/com_your_component
components/com_your_component/layouts
administrator/templates/isis/html/layouts
layouts

But now, how they can do it, they mostly do all the override in frontend template but there is no option to do it.
It is not about us developers, it is about the end users. It is about the complex override feature.

In fact the more I think and write about it, I find out that this:

administrator/templates/isis/html/layouts/com_your_component
components/com_your_component/layouts
administrator/templates/isis/html/layouts
layouts

is completely nonsense. The override feature in Joomla! is only successful when you can override with template. When you force frontend overriding without template (exactly said: with template but not frontend template only backend template) then it is useless. You as developer don't need the override, you are doing it because end users but in this case they don't have any rational chance to override it.

I would say, this is not a bug, this is not a finished feature.

Hello,

That is for component developers and it works as expected it loads he JLayout from the front end of the component not the backend. If you want to override it then you load it from a template override in the backend....

I think you are missing the point being raised by this pr. It's not about if it is good/bad idea to load layouts in admin from frontend and vice versa. The code and docs say you can and it doesn't work.

Actually that is not the case @brianteeman , the docs state you can force it to load it in the front end in the backend and vice versa which works perfectly for components. The issue here is, the overrides for JLayout however are always loaded via the backend of calling the administrator client.

I think the only issue is the docs require clarification that you can force it to load the front or backend JLayout, but it will always look for overrides and JLayout fallbacks in the client side it is being loaded in.

It is always the active template that will do the overrides. No matter if you use forceClient or not. Everything else would be a stupid idea.
Also in which site template would you want to look for a template override from backend? You have no idea which one it would be.

As long as JPATH_THEMES is used in the code "force client" cannot work. That constant is relative to the active application. So the only way to "force" it is to use JPATH_ADMINISTRATOR . '/templates' and JPATH_SITE . '/templates' as the path value, but then you break the fact that we have a customizable path to the templates directory in the JPATH_THEMES path constant.

Just one more reason why Joomla's path unconstants are a constant pain.

@mbabker, but surely you wouldn't want this?

Example, we implement it and a theme has overrides to match their UI say BS4 but the component uses bs2. The component uses JLayout force site load to load the JLayout to avoid code duplication, it then loads the sites active theme JLayout override breaking the backend UI.

It to me wouldn't make sense to load in overrides for the front end theme as they are theme specific.

Oh I agree totally on not trying to load resources from another template. But just pointing out the one line of code that causes this "issue" and fixing it basically equates to removing support for the JPATH_THEMES path constant.

:-) and I agree about your paths pull, was just reading it before.

@Bakual

Also in which site template would you want to look for a template override from backend?

The default one.

I, as developer, of course, understand your arguments, but I just try to look at it from the end user point of view. End user means a webdesigner or template developer who should have the option to override frontend component with frontend template. Mostly, template override happens in one default frontend template. If template developer releases frontend template with overrides of frontend component, in such case there is no option for him/her to use override because of course he/she does not release backend template as bonus for frontend template.

I fully understand, that this feature is here to help developers to not produce duplicity code and reuse one output for both clients. But on the other side it limits webdesigners and template developers (for example).

Hi Jan,

I'm sorry but I really am struggling to understand why a template designer
would be interferring with the backend UI of a component.. This to me doesn't
make any sense as their template isn't loaded in the backend?

But they can easily include a backend template override if they wanted using
JFile to move and create overrides etc.

![](https://link.nylas.com/open/2rcbj3dybp6ft2deqnr1hk6zs/local-410f861a-89fe?
r=cmVwbHkrMDAxNTYwOTYyOGVjY2FiYmMxZjJkNzdhMjM1ZWQzNjQzNDZiMGNjZDFlMGQxMThjOTJj
ZjAwMDAwMDAxMTQ1ZDAyZWE5MmExNjljZTBiMzZhNmNhQHJlcGx5LmdpdGh1Yi5jb20=)

On Dec 5 2016, at 10:26 am, Jan notifications@github.com wrote:

[@Bakual](https://github.com/Bakual&r=cmVwbHkrMDAxNTYwOTYyOGVjY2FiYmMxZjJkNz
dhMjM1ZWQzNjQzNDZiMGNjZDFlMGQxMThjOTJjZjAwMDAwMDAxMTQ1ZDAyZWE5MmExNjljZTBiMzZh
NmNhQHJlcGx5LmdpdGh1Yi5jb20=)

Also in which site template would you want to look for a template override
from backend?

The default one.

I, as developer, of course, understand your arguments, but I just try to
look at it from the end user point of view. End user means a webdesigner
or template developer who should have the option to override frontend
component with frontend template. Mostly, template override happens in one
default frontend template. If template developer releases frontend template
with overrides of frontend component, in such case there is no option for
him/her to use override because of course he/she does not release backend
template as bonus for frontend template.

I fully understand, that this feature is here to help developers to not
produce duplicity code and reuse one output for both clients. But on the other
side it limits webdesigners and template developers (for example).

—
You are receiving this because you were mentioned.
Reply to this email directly, [view it on GitHub](https://github.com/joomla
/joomla-cms/issues/12842#issuecomment-264818258&r=cmVwbHkrMDAxNTYwOTYyOGVjY2Fi
YmMxZjJkNzdhMjM1ZWQzNjQzNDZiMGNjZDFlMGQxMThjOTJjZjAwMDAwMDAxMTQ1ZDAyZWE5MmExNj
ljZTBiMzZhNmNhQHJlcGx5LmdpdGh1Yi5jb20=), or [mute the
thread](https://github.com/notifications/unsubscribe-auth/ABVgltUki-
ETlY6u7RFjqOzvTyJbk3q8ks5rE-bqgaJpZM4KtBty&r=cmVwbHkrMDAxNTYwOTYyOGVjY2FiYmMxZ
jJkNzdhMjM1ZWQzNjQzNDZiMGNjZDFlMGQxMThjOTJjZjAwMDAwMDAxMTQ1ZDAyZWE5MmExNjljZTB
iMzZhNmNhQHJlcGx5LmdpdGh1Yi5jb20=).![](https://github.com/notifications/beacon
/ABVglsc6gfHOYzK9QfV-q2Vju-D5GRVqks5rE-bqgaJpZM4KtBty.gif)

Hi @tonypartridge

I'm sorry but I really am struggling to understand why a template designer would be interferring with the backend UI of a component

Not sure if I correctly explained what I wanted to say. Template developer has the possibility to override the output. Mostly, you do only one type of template: frontend or backend. But this is not the case of component, where you can produce output from both sides: frontend and backend. In fact, as component developer you have the option to force the layout path and if you decide that all will be set in frontend layout, you want that frontend component layout can be overriden by frontend template which is not possible now.

For now I am working on such task, this is why I have asked about this problem.

The demand is: Export of data to XML, CSV or other possible format in component.

1. This export happens in frontend or backend
2. The requirement is to be able to edit the layout and do possible other format output with help of layout (frontend component includes the layout)
3. Edit of the layout will be possible in template of course, editing directly component layout is nonsense as such will be overwritten when updating.

For me as developer, 1) and 2) is enough - for end user is 1) and 2) nothing without 3)

In fact, useless work without 3)

So, to summarize it:

• override of layout is done by template (nobody will change component as this will be lost by update)
• component can produce the same output from backend or frontend. Backend can use frontend layout (this is standard Joomla! feature, not my invention)
• if frontend component layout is used, it does not make any sense to override it by backend template

It is really easy to understand when you get the following task:

Do a component which will output something in backend or in frotend and we want to override the output by our frontend template (as 99,xx % of overrides happens in frontend template)

I just got this task, which I found fully reasonable and found methods in Joomla! to do it, found the force feature but then I was confused why when there is "force" feature, it applies only to component layout and not to template layout. In fact, component layout is nothing without the possibility to be overriden by template.

Example details:
When you produce some output in frontend or in backend, you just select one place for layout. Mostly frontend. When forcing component layout, you expect that the bound part (template override) will cooperate.

See image:

I still think it would be wrong to use the template overrides from the other application. As you said the only real option would be to use the overrides from the default template. But that's wrong as well.
The current behavior is exactly what I expect. I have some JLayout which I want to use both in frontend and backend, and I expect an override done in frontend not to be applied in backend as it would completely break the layout in Isis.

Your case is a very specific need and you should just implement your own path lookups (I think JLayout even supports that).

@Bakual

Your case is a very specific need and you should just implement your own path lookups

:-) I am now working on public component and this feature was asked by community in public discussion as the best solution for customizing the output. I really don't understand, what is not understandable on fact that if your layout is located in frotend, it is logical to overwrite it with frontend template?

This was just asked by users: "We just want to override frontend layout with frontend template, not by backend template"

I have some JLayout which I want to use both in frontend and backend, and I expect an override done in frontend not to be applied in backend as it would completely break the layout in Isis

Not sure, if you count the fact, that you need to force it. When you run something from backend, backend component layout is used and backend template override is active. This is standard feature but we are talking here about if we purposely force the layout path change.

In fact it is valid exactly for the opposite: We force frontend layout and user expects, frotend component layout will be overriden by frontend template. But this way it does not work for now.

You run the same output from frontend and backend and you just force the frontend layout for both to prevent from duplicities (this is standard Joomla! core feature). And users will expect that they can override it with frontend template.

I am sorry, if my English is not understandable but I think, the image should say exactly what I mean.

1. because of preventing from duplicities, we just decided and forced that only one layout for both (frontend, backend) will be stored in frontend
2. and when we have the layout in frontend, we just expect that it can be overriden by frontend template 💡

The only way I can see what you are requesting is if the frontend client is forcing the backend JLayout and therefore I can see your point as the frontend template does get asdjusted.

The other solution here is to include the php file twice but in one of them use php include to include the backend php file code so your override will then work as required.

@tonypartridge

The only way I can see what you are requesting is if the frontend client is forcing the backend JLayout and therefore I can see your point as the frontend template does get asdjusted.

Request is easy and simple: override frontend component layout with frontend template

• works when your output is produced in frontend
• does not work when your output is produced in backend but you have forced frontend layout (you just said to Joomla! system that your layout is located in frontend even you are now calling it from backend)

I already pointed out the exact problem at #12842 (comment)

There is not a manner to "fix" this which does not either break backward compatibility or existing features.

Not sure, if you count the fact, that you need to force it. When you run something from backend, backend component layout is used and backend template override is active. This is standard feature but we are talking here about if we purposely force the layout path change.

I know. I want to use the same JLayout file (which is located in frontend) also in backend to avoid duplicate code. In frontend it has to blend in with the frontend template, in backend with Isis.

Request is easy and simple: override frontend component layout with frontend template

We all understand your request, but I think it is a wrong default behavior. The overrides should always be taken from the active template. Not a random one and not the default one. Otheriwse you would have to implement a selector like we have for article or module layouts where you can explicitely select a specific template override.
But as said you already can provide your own lookups to my knowledge.
I just don't agree that it should be the default behavior (and it wouldn't be B/C anyway).

@Bakual

I just don't agree that it should be the default behavior (and it wouldn't be B/C anyway).

I didn't write here because of adding this to the core a priori, I just wanted to report it as not correctly behavior (in my view)

@mbabker
I just don't understand what is the problem with JPATH_THEMES (of course it can be caused by lacking my knowledges regarding themes feature in Joomla!)

If I want to get this:

templates/your_frontend_template/html/layouts/com_your_component
components/com_your_component/layouts
templates/your_frontend_template/html/layouts
layouts

instead of this:

administrator/templates/isis/html/layouts/com_your_component
components/com_your_component/layouts
administrator/templates/isis/html/layouts
layouts

!!! force client is active

I just change the code in libraries/cms/layout/file.php
on lines: 585, 599

FROM:

// (2) Component template overrides path
$paths[] = JPATH_THEMES . '/' . JFactory::getApplication()->getTemplate() . '/html/layouts/' . $component;

TO:

$db = JFactory::getDBO();
$query = "SELECT template FROM #__template_styles WHERE client_id = 0 AND home = 1";
$db->setQuery($query);
$defaultTemplate = $db->loadResult();

if ($this->options->get('client') == 0 && isset($defaultTemplate))
{
   $jPathThemesFrontend =  JPATH_ROOT . DIRECTORY_SEPARATOR . 'templates';
   $paths[] = $jPathThemesFrontend . '/' . $defaultTemplate . '/html/layouts/' . $component;
} else {
   $paths[] = JPATH_THEMES . '/' . JFactory::getApplication()->getTemplate() . '/html/layouts/' . $component;
}

FROM:

// (4) Standard Joomla! layouts overriden
$paths[] = JPATH_THEMES . '/' . JFactory::getApplication()->getTemplate() . '/html/layouts';

TO:

if ($this->options->get('client') == 0 && isset($defaultTemplate))
{
   $jPathThemesFrontend =  JPATH_ROOT . DIRECTORY_SEPARATOR . 'templates';
   $paths[] = $jPathThemesFrontend . '/' . $defaultTemplate . '/html/layouts';
} else {
   $paths[] = JPATH_THEMES . '/' . JFactory::getApplication()->getTemplate() . '/html/layouts';
}

Please, look at the code as at an example, I really don't know the themes feature in Joomla! and don't know for now if this can cause some conflict or can be written better way (this is just quick example). And of course, because of backward compatibility, the "client" parameter can be changed to some new parameter (defaultFrontendTemplate).
💡

You have explained what you want like 10 times. Everybody understood it. Please do not repeat it again and again.

If you need that implement it in you own renderer extending JLayoutFile. You only have to override 1 method.

I just don't understand what is the problem with JPATH_THEMES (of course it can be caused by lacking my knowledges regarding themes feature in Joomla!)

JPATH_THEMES is a "relative" path constant. When you are on the frontend, its path is JPATH_SITE . '/templates' and on the backend JPATH_ADMINISTRATOR . '/templates'. So it is not always the same base value.

Using your suggestion of $jPathThemesFrontend = JPATH_ROOT . DIRECTORY_SEPARATOR . 'templates'; stops using this path constant and breaks if someone was crazy enough to redefine that path to something other than a templates directories, which I think is actually more possible than renaming something like the administrator directory.

@phproberto
Not sure if you read all my posts. I don't describe what I want to achieve, I describe what end users requested and what I found reasonable and logical and found that such way the code does not work.

As you already know, for me it is really not a problem to write own rules, I just wanted to report it, so community can think about it. From the quotes I added to my posts, you can see that not everybody understood what I think even I have explained it many times.

Please don't use incorrect states like "You have explained what you want like 10 times". I am not here to fulfill my needs but to send a feedback to Joomla! community and until I get answers which seem like not understandanding what I wanted to say, I just try to explain it better.

If you have understand it from beginning, maybe it would be great you can summarize it better way so we don't need to read all my rest posts.

@mbabker
Now I see in administrator/includes/defines.php what you mean with JPATH_THEMES
define('JPATH_THEMES', JPATH_BASE . DIRECTORY_SEPARATOR . 'templates');

if someone was crazy enough to redefine that path to something

Which path do you exactly mean? Who and where will someone can someone redefine this path

$jPathThemesFrontend = JPATH_ROOT . DIRECTORY_SEPARATOR . 'templates';

You can override the defines.php file in both applications and move the base file paths in the system. So it is not a guarantee that JPATH_ROOT . '/templates' is the same thing as JPATH_THEMES. Likewise for JPATH_ROOT . '/administrator/templates' and the admin app.

So if your code uses that hardcoded path structure, then if someone moves the application's templates directory by overriding the path constants, then their changes will be broken by the use of a hardcoded path. Hence, it does break feature compatibility in our API, even if it's something 99.9% of users will never do.

Extension developers create extensions. Template developers create templates. You as extension developer have control over your extension folders (frontend & backend). You do not decide how and where template developers override things.

Client 0/1 means that you as EXTENSION developer want to reuse your layouts from YOUR extension folders.

You as extension developer do not set how & where things are overriden.

Template developers most of the times cannot get access to the source call so they cannot know if an extension developer decided to use 0/1 in a layout call. What you propose is a nightmare for them

@mbabker
Thank you, now I understand and yes, "if someone was crazy enough to redefine" defines.php, I think this:

$jPathThemesFrontend = JPATH_ROOT . DIRECTORY_SEPARATOR . 'templates';

will be the slightest problem he/she gets :-)

@phproberto Did you really read what I wrote in my posts or is my English so bad.

You do not decide how and where template developers override things.

I don't want to decide how and where template developers override things. If I decide as extension developer that the component layout is located in frontend (I just must select one - if in frontend or backend) I don't want to explain template developers or end users that they should override my frontend component layout with backend template which happens now.

I just propose the wishes of end users - they just want to override frontend component with frontend template.

Sorry, you speak about repeating something many times but you still don't understand the base problem of this topic :-( or is this some kind of humor to write after many posts that I want to decide how and where template developers override things. :-(

Hi Jan,

I think what has got confusing is the fact you referred to backend override
from frontend template.

For the unique scenario you are wanting to allow I would suggest you just
have the file in both front and backend and instead of duplicating the code
just do a php include to the other file.

Adding this in now could cause unforeseen issues with sites.

On Mon, 5 Dec 2016 at 23:33, Jan notifications@github.com wrote:

@phproberto https://github.com/phproberto Did you really read what I
wrote in my posts or is my English so bad.

You do not decide how and where template developers override things.

I don't want to decide how and where template developers override things.
If I decide as extension developer that the component layout is located in
frontend (I just must to select one - if in frontend or backend) I don't
want to explain template developers or end users that they should override
my frontend component layout with backend template which happens now.

I just propose the wishes of end users - they just want to override
frontend component with frontend template.

Sorry, you speak about repeating something many times but you still don't
understand the base problem of this topic :-(

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

Hi @tonypartridge

For the unique scenario you are wanting to allow I would suggest you just have the file in both front and backend and instead of duplicating the code just do a php include to the other file.

This I can do in case when I do it for myself - I will not do an include, I will just make a function which I will call from backend or frontend.

What I describe here is, end users want to have the option to override it by their template. So in fact they need component layout so they can override it with their templates.

It is not about the output, it is about the possibility for users to override it.

For now this is possible but with following scenario:

• the component layout is stored in frontend but user needs to override it with background template

Which of course will be hard to explain to users why they cannot use frontend template for frontend component.

Except they CAN override the layout in the frontend. When you initialize JLayoutFile from the admin app (the request was to /administrator since as previously stated the different apps cause different values for JPATH_THEMES), the template override paths are for the active admin template. When initialized from the frontend, the template paths are the frontend.

So, you can force client and the layout will be found in the frontend component unless there is a template override for the active template in place.

What the code does NOT allow you to do is to force the template override paths to use the non-active application (as in it will not look for an override in Hathor/Isis for a frontend request or Beez/Protostar for a backend request).

So, I'm not quite sure what you're trying to get at anymore.

@mbabker

What the code does NOT allow you to do is to force the template override paths to use the non-active application (as in it will not look for an override in Hathor/Isis for a frontend request or Beez/Protostar for a backend request).

When the code allows you to use non-active application - frontend component layout in backend:

$layout = new JLayoutFile('joomla.content.tags', null, array('client' => 0, 'component' => 'com_tags'));

why not to allow using of non-active application - frontend template?

(in case frontend layout is more related to frontend template even it is not active)

If you are located in backend - both: frontend component layout even frontend template are non-active applications for you.

So, I'm not quite sure what you're trying to get at anymore.

As many times written, users want to override frontend component layout with frontend template.

Look at the code again and you can have your answer; the component paths aren't reliant on the application object or data. The template paths are. Changing this logic introduces a backward compatibility break and arguably a major logic break (now a template from another application is used to produce the markup for a page).

The only way to fix this in core is to deprecate the use of the JPATH_THEMES path constant and hardcode all template lookup paths application wide to the respective templates directories. Anything short of that is a hack job, introduces inconsistencies to the core API, and WILL break backward compatibility.

You have an edge case where you want a frontend template override to affect the rendering of the backend page (or vice-versa with backend templates overriding the frontend). You can subclass or overload JLayoutFile to do what you need it to do.

@mbabker

Changing this logic introduces a backward compatibility break and arguably a major logic break

I didn't write, it should be changed, the code I have pasted was an example, another parameter can solve the situation. When you have parameter to force component layout, you can have a parameter to force template.

You can subclass or overload JLayoutFile to do what you need it to do.

See my previous post, I don't have any problem and no lack of knowledge to solve it easily for myself, I just wanted to report it as I found this behavior as wrong.

You have an edge case where you want a frontend template override to affect the rendering of the backend page (or vice-versa with backend templates overriding the frontend).

I didn't invent this process, there is current parameter in Joomla! core to force/switch backend to frontend or vice-versa component layout so I just was asking why this does not work for template too. As in case you force component layout you can combine it with template and have both in the same part.

I didn't invent this process, there is current parameter in Joomla! core to force/switch backend to frontend or vice-versa component layout so I just was asking why this does not work for template too.

It breaks the expectations for the vast majority of users. I don't expect that if I have the component path forced to the frontend that a layout override in a Bootstrap 3 based frontend template can be used in the default Bootstrap 2 based admin template; I expect either a layout for that template to be used or a fallback to a "default" layout (which are generally layout files not included in the templates directories).

@mbabker

It breaks the expectations for the vast majority of users

Yes, but we are not speaking about default settings. As default, everything is OK and it has own logic. Nobody's expectation is broken as default. We are speaking about "force layout" parameter which extends the possibilities of output in Joomla! (it exists and works great). And the same way it can do "force template" parameter.

Override in Joomla! is great feature and limit it only to HTML output (Bootstrap 3 <--> Bootstrap 2) will be a mistake. As example you can imagine the XML output. With help of override feature users can easily customize own XML - it is not only design, you can change attributes, names, even you can skip some of them and build customized XML for you even the component produces another one. Force layout allows you to have only one layout for backend and frontend (no duplicity) and Force template will allow you to bind up frontend component layout with frontend template override.

I really don't invent any specific complicated feature, I just listen to the needs of end users.

Just imagine, both of your website parts (frontend, backend) produces the same output which is stored in frontend component layout and you give the chance for your users to override it. It is stored in frontend part. Which template do you select an user can override? I would select the frontend because the layout is stored in frontend part and because customizing of template mostly happens in frontend (the second argument is not logical but convenient).

See, the feature with forceClient isn't intended for the use case you have, thus the overrides don't match your expectations. As said you need to write your own logic for it.

JLayouts are not designed for XML or other raw outputs. They are designed for HTML snippets which are put together to the full page. Thsoe snippets may be usefull both in frontend and backend and thus we have the forceClient parameter to tell it where to look for the snippet. But the overrides always have to come from the active template neverthless. Because as I said already an override for the BS4 frontend template will not work for the Isis backend template.
Yes, you can use JLayouts for your case as well, but it's not what they were designed for.

I'm closing this as there is clearly no support for this request and we're spinning in circles here.