Problem/Motivation
hook_l10n_update_projects_alter() implementations can modify the project data collected for translation update. However the core release version data is overwritten with the actually installed version number. It is unknown if other core data is overwritten too.
Proposed resolution
To be determined
Original report by inkling
If you put the following code into a module, it will correctly alter the list of projects to include a specific translation version for panopoly_core. The version will be set to 7.x.1.0-rc3 and l10n info will be correctly added. The version for the drupal project will also be correctly altered:
/**
* Implements hook_l10n_update_projects_alter()
*/
function l10updproblem_l10n_update_projects_alter(&$projects) {
$l10n_server = l10n_update_default_server();
$projects['panopoly_core'] = array(
'name' => 'panopoly_core',
'project_type' => 'module',
'info' => array(
'version' => '7.x-1.0-rc3',
'core' => '7.x',
'l10n server' => $l10n_server['name'],
'l10n url' => $l10n_server['server_url'],
'l10n path' => $l10n_server['update_url'],
),
);
$projects['drupal']['info']['version'] = '7.17';
$projects['drupal']['info']['core'] = '7.x';
$projects['drupal']['info']['l10n server'] = $l10n_server['name'];
$projects['drupal']['info']['l10n url'] = $l10n_server['server_url'];
$projects['drupal']['info']['l10n path'] = $l10n_server['update_url'];
}
However, if you now go to Administration » Configuration » Regional and language » Translate interface, go to the Update tab, and hit the "Refresh information" button, you'll see that the translation for the drupal core project set to 7.19, instead of 7.17.
I think the problem lies in l10n_update_build_projects(). These lines of code are about halfway down the function:
elseif ($name == "drupal" || preg_match("/HEAD/", $data['info']['version'], $matches)) {
// Pick latest available release.
$release = array_shift($projects_info[$name]['releases']);
This overrides the version number provided by hook_l10n_update_projects_alter().
I've tried a couple of different ways to fix this, but none of them satisfactory as yet. If I remove the condition $name == "drupal" form the elseif above, I get 7.17 as I want. However, if I now decide to remove specifying drupal's version number in hook_l10n_update_projects_alter (such as in the first code block above), I get 7.15 for version. This is probably not right, and maybe the reason why the original coder put in the elseif to begin with. This may then mean that the elseif is masking a bug in l10n_update_project_list, which l10n_update_build_projects calls to update the project list.
Comments
Comment #1
sutharsan commentedThis has been reported in #1883154: Check version before update too. The code just takes the latest available release, and does not check if this is more recent than the current.
This line checks if the module at hand is Drupal core or the module release is a dev version. It's intended use if for dev releases, both of core and contrib modules. Not sure if checking for HEAD is the proper thing to do. It is a side track, but nice if we can include it here.
This looks like the thing that returns the latest release. Sorted by available releases, this returns the latest.
The code should not mask a bug in hook_l10n_update_projects_alter. Forget hook_l10n_update_projects_alter, try with a real dev release of core and a real core git checkout. Those cases should be handled correctly.
@inkling, It would be great if you could dive into this.
Comment #2
inkling commentedI'm using hook_l10n_update_projects_alter to get around the issue raised by #1883154: Check version before update. This is a summary of what I said there as it applies here:
Hope that clarifies.
Comment #3
sutharsan commentedDuplicate of #1837704: Stop spamming the watchdog log with "Automatically checked 0 translations, updated 0."
Comment #4
sutharsan commentedNo duplicate, this is just a difent issue. Changing tile and issue summary to make it more clear.
Comment #4.0
sutharsan commentedfix typo
Comment #5
inkling commentedThe patch provided by Sutharsan at #1883154 Check version before update may resolve this issue, or at least suggest a resolution. I'm currently checking into it.
Comment #6
inkling commentedThe patch provided by Sutharsan at #1883154 Check version before update does indeed resolve this issue. :-)
Comment #7
inkling commentedIf I understand correctly, the status of this issue should be set to Needs Review now. However, the patch is over on #1883154. Seems to me that the patch really belongs here, so I'm not sure what to do at this point. I'll let someone else more experienced in Drupal decide.
Comment #8
sutharsan commentedI did not expect that patch to solve this issue, but you may very well be right. Thank you for the observation, that saves me some debugging in D8 too (where this part of the code is used).
Thanks to #1883154: Check version before update, this issue can be closed too.
Comment #9
inkling commentedFWIW, it appears the same solution works for D6.
Comment #10.0
(not verified) commentedUpdated issue summary.