Problem/Motivation
In that issue we wrote a test to prove that the 'core' value in 'projects' for the locale module does not come from the 'core' key in the module's info.yml file.
But locale_translation_build_projects()
still has
'core' => isset($data['info']['core']) ? $data['info']['core'] : \Drupal::CORE_COMPATIBILITY,
Because $data
here comes from locale_translation_project_list()
which ultimately calls \Drupal\Core\Utility\ProjectInfo::filterProjectInfo()
which will filter out the 'core' key that comes from the info.yml file the only place the 'info' can be added back is in hook_locale_translation_projects()
. But if you read the documentation for this hook it is not intended for this purpose.
It also seems very unlikely that this hook would be used this way because
- There would have to be someone hosting their own localization server
- The would have to want 'core' key for localization server to vary per project not based on the actually version of Drupal core is running
Proposed resolution
Change the above code to
<code>'core' => \Drupal::CORE_COMPATIBILITY,
Remaining tasks
Do it
User interface changes
None
API changes
None
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#3 | 3073934-2-plus-3070354-5.patch | 6.26 KB | tedbow |
| |||
#2 | 3073934-2-plus-3070354-5.patch | 6.31 KB | tedbow |
#2 | 3073934-2.patch | 913 bytes | tedbow |
Comments
Comment #2
tedbowHere is patch and another patch with the test in [3070354-5] to prove it doesn't break that test
Comment #3
tedbowi messed up drupalci in 3073934-2-plus-3070354-5.patch
Comment #4
xjmComment #5
Gábor HojtsyComment #7
Gábor HojtsyI agree with the analyses, good find. Thanks! (This already got test coverage in #3070354: Add a test for locale_translation_build_projects() to unensure that 'core' key does not affect translations URLs).
Comment #8
tedbow@Gábor Hojtsy thanks for committing this!