In the Localization Client module:
function l10n_client_save_string() {
global $user, $language;
gets converted to:
function l10n_client_save_string() {
$user = \Drupal::currentUser(), $language;
...which is a parse error.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | dmu-fix-globals-grep.patch | 752 bytes | webchick |
Comments
Comment #1
webchickTaking a look at this one first.
Comment #2
webchickOk, so why this is happening is 'user' is a grep target. From drupalmoduleupgrader.grep.yml:
So far, that's basically fine. There's even one for language there, too.
These variables get converted in the grep converter like so:
The "money" line is:
That converts "global $user" to "$user = \Drupal::currentUser()"
And the reason $language doesn't get converted is because the "global" is at the beginning of the line, not just before $language (this is a common pattern, including in core, so l10n_client isn't doing anything weird here).
Looks like we need to both be more explicit in that line to only do that conversion if the line ends in a semi-colon, and in the event that there are multiple globals on the same line, loop through them all and do conversions each on one line.
Comment #3
webchickOk, this much at least stops the parse errors from happening. But it doesn't deal with
global $foo, $bar;since it skips lines like that. I am actually not immediately sure how to deal with that since I don't think Grep.php handles regular expressions.Comment #5
webchickIndeed:
So I think this is as good as we can do for now; basically skip those lines that will result in parse errors. Filed #2425541: Convert multiple global variable declarations on one line as a follow-up to make this work For Real™.