[#6290] - Add onBeforeInitialise event
- Closed
- 26 Aug 2015
- Medium
- Build: staging
- # 6290
- Diff
- wilsonge:lang-plugin
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
This removes the requirement that the language filter plugin ALWAYS loads before any other system plugin by adding a new plugin event before the app is initialised.
Doing this also gives app's a way to inject their own language object before the rest of the checks are run. Making things more diverse.
I gave this some basic testing and things seemed to be good but it 2 GOOD tests (as well as maybe a performance check?? - I'm not sure what the cost of additional plugin events actually are).
Potential b/c issue
The system plugin group as a result are now loaded earlier in the load cycle. As an example if a constructor tried to do JFactory::getLanguage it would return null
joomla-cms-bot
- | Labels |
Added:
?
|
||
I not really in topic, but if it for language, then maybe make event just for it, eg onLanguageInitialise
just thought 
It's not necessarily just for language. That's just the immediate use. In fact there are more generic reasons you could trigger a plugin event here.
In terms of initialiseApp - you can't drop any because of b/c until 4 - although I agree then we can start looking into what does and doesn't need to be there. You need to make sure JFactory::getLanguage contains the correct language object which is done in intialise App. Otherwise any plugins triggered before the component routing get triggered with the wrong language as I understand it.
They are already triggered with the wrong language. Since initialiseApp doesn't care for the URL, you might have fr-FR in your cookie, but your URL would be domain.tld/en/, thus the right language would be en-GB. initialiseApp would create JLanguage with fr-FR and the languagefilter Plugin later, during routing, will fix that.
Regarding the language discover stuff in initialiseApp: There are several cases that are only executed when the languagefilter plugin is enabled OR if you write your own app and extend from JApplicationSite. I can see a break in b/c for the later, but otherwise they are pretty much useless here.
Anyway, the question is, if we need all those checks of JLanguage::exists(), because each of those cases means that someone knowingly tries to sabotage the system. So we might as well have one check at the end of the whole method for this once and if that one fails, fall back to en-GB.
zero-24
- | Category | ⇒ | Plugins |
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-08-26 16:50:53 |
| Closed_By | ⇒ | wilsonge |
I would rather not add this, but instead simply remove the languagefilter plugin line. I don't see any way how this could be usefull for people. There are already 7 ways in JApplicationSite::initialiseApp to hand in a language and I would drop at least 1 of those methods. At the same time, you can already replace the language in an onAfterInitialise plugin, like the languagefilter plugin does. I don't see a reason to add another way, especially since it seems to me to open up ways for a lot more bad code in the future...