[#10344] - Alternative approach to #9999 to deal with hardcoded import of plugins
- Fixed in Code Base
- 16 Jul 2016
- Medium
- Build: staging
- # 10344
- Diff
- mbabker:alt-9999
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success JTracker/HumanTestResults Human Test Results: 2 Successful 0 Failed. Details
User tests: Successful: Unsuccessful:
This is the implementation of the alternative approach to #9999 I suggested.
To be quite frank, I don't work with the multilingual system so I don't know if this will have unintended side effects, someone more familiar than me on that will need to guide on this.
In essence, instead of importing the languagefilter plugin (which seems to hardcode it as the first plugin to be executed because the event dispatcher doesn't have an internal handling for event priorities), the plugin data is only loaded from the database and the params extracted out to set the application vars.
This defers importing of the plugin until the point when the system plugin group is imported to trigger the onAfterInitialise event and should cause the configured plugin ordering to be respected when importing and dispatching events.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Labels |
Added:
?
|
||
That's why I'm importing the plugin's params without loading the plugin to the event dispatcher basically. It's still a big stinking pile of crap keeping a hardcoded dependency to the plugin, but it ultimately fixes a deeper issue in the order that observers are attached to the event dispatcher which is what Soren is trying to work around.
yes i understand that.
i will test this when i have time.
brianteeman
- | Category | ⇒ | Multilanguage Plugins |
| Category | Multilanguage Plugins | ⇒ | Libraries Multilanguage Plugins |
I have tested this item 
successfully on d939290
Applied the patch and tested in a multilanguage sample site (3 languages):
- Fallback with no cookie to site default language (system language filter plugin option)
- Fallback with no cookie to browser default language (system language filter plugin option)
- Use language cookie if exists
- Language associations
- Language routing
All worked with no issues
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10344.
@aDaneInSpain This was in response to your issue...
@mbabker Thank you for your approach but I think this will not solve the issue we are having. I would like to know if remove that hard core dependency of "languagefilter" plugin. Maybe some changes is need in several places, so I would love to get some advice from the people that know how this plugin works.
@vistiyos without moving the language filter plugin's parameters to either a component or the global configuration, there is no way to 100% decouple the site application from the plugin. Moving the params IMO is more hassle than it's worth (it's a B/C break moving the param from one source to another as now code using the plugin params would have to be updated to use a new source).
This change should resolve the underlying issue of how the plugin is imported into the event dispatcher which causes it to always be the first plugin called when an event is dispatched, regardless of the ordering configuration you have set.
#9999 is one possible fix to this issue but the "flaw" with it is that it is importing everything into the event dispatcher immediately. This PR explicitly is only loading the plugin's parameters (and inherently the plugin data into the static container in JPluginHelper); this PR makes an explicit change to NOT push the plugin to the event dispatcher.
I have tested this item
Applied the patch and tested in a multilanguage sample site (2 languages):
Fallback with no cookie to site default language (system language filter plugin option)
Fallback with no cookie to browser default language (system language filter plugin option)
Use language cookie if exists
Language associations
Language routing
All worked with no issues
roland-d
- | Status | Pending | ⇒ | Ready to Commit |
| Milestone |
Added: |
||
Can we have a RTC here?
| Labels |
Added:
?
|
||
ok we have it now
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-07-16 06:06:46 |
| Closed_By | ⇒ | roland-d |
| Labels |
Removed:
?
|
||
Are you testing with both this patch merged plus that patch applied? If anyone is testing with only the changes to the language filter plugin applied then of course it would be broken because they are missing the changes to the application class.
If this is really causing issues I'm going to say someone else devise a patch to fix Soren's original issue because I don't get the language system enough to deal with this type of stuff. I just fixed what was a logical workflow issue.
i tested indeed with both.
Then either the plugin parameters aren't being correctly loaded in the application class or some other change has caused this to misbehave. In either case, I don't have the knowledge of how the language system works to make any further corrections, so if you want to revert it go ahead.
no need to revert it. i think it's ok now. please confirm @infograf768
yep
IIRC of that part is used to define the user language, and we need the language filter plugin params to calculate that.
@infograf768 please check