Plugins aren't application specific the same way component, modules, and
templates are. So I wouldn't call this a bug otherwise you're getting into
a very deep hole and I don't think we want to go there.

On Sunday, August 21, 2016, andrepereiradasilva notifications@github.com
wrote:

Steps to reproduce the issue

• Use latest staging
• Enable debug and debug lang in global config
• Enable debug system plugin with all options activated
• Go to frontend and check the debug console on

Expected result

Only the used frontend plugins language files are loaded, even if the
plugin is only used in the backend.
Actual result

All plugins that have $autoloadLanguage = true; files are loaded.

[image: image]
https://cloud.githubusercontent.com/assets/9630530/17840497/0adb8d68-6801-11e6-88f2-fd6a701d5c9e.png
System information (as much as possible)

Latest staging
Additional comments

None.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11714, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoSuz3YW2Q9XQccynRay6FjgunQB4ks5qiOI9gaJpZM4Jpa6d
.

I just think plugins used only in the backend shouldnt not autoload the language files.

You'd essentially have to make plugins application specific the same way other extension types are to enforce that. Since these extensions aren't application specific, the only way to enforce it is by adding more class member variables to JPlugin (which has already caused enough problems because of core previously being updatable as an extension) or making our code start parsing the code of existing plugins for $app->is(Site|Admin) style checks.

Loading these INI files into memory and parsing them (even with debug mode on) is a rather cheap process, so there isn't really a major performance benefit to be found here anyway. I'd say the effort to do this is more than the gain to be found.

humm .... the performance impact really depends on which php version you use, if you have opcache enabled, the quantity of plugins enabled, the quantity of strings the plugins have, etc.

Anyway i think we can agree that doesn't make much sense this language files being loaded when we know they will not be used in the site client.

Maybe just allowing to set the client in autoloadLanguage could solve the issue. something like this:

$autoloadLanguage = true; // Autoload in all clients
$autoloadLanguage = false; // Does not autoload
$autoloadLanguage = 0; // Autoload only in site client
$autoloadLanguage = 1; // Autoload only in admin client

I wouldn't do it as allowed integer and boolean values if you're going to touch that var, especially since 0 and 1 are the integer representations of false and true.

The only "true" fix is to not set the var to true and go back to manually loading language files in the plugin event handlers. I still don't personally see any value in trying to add more logic to this stuff since there is such a minimal gain, but if you're that adamant about it go for it.

ok made a PR #11728 for plg_system_stats. It seems a simple change.

As you;ve made those PR can this be closed?

closed as we have 3 PR
#11728
#11730
#11736

Please test