I can confirm that the change works to solve the given problem.
+1 for a new release.
Thanks @andrew-answer, that work-around does solve it for now. I imagine that there is no intention to maintain downwards compatibility to PHP 7.0, so probably we'll just leave it at that (and update to a higher PHP version).
My problem was like the one described in the original issue - css and js directories were not created. This happened after an upgrade from Drupal 8 to 10.2 on a Debian server using Apache. When I saved the settings on /admin/config/development/performance, I got this error message:
'stale_file_threshold' is not a supported key.
Similarly, on /admin/config/media/file-system I got:
'filename_transliteration' is not a supported key.
It seems, these invalid keys were still stored in my configuration. I searched for the strings in my code base and found a config-sync file holding them:
$ grep -rnw . -e 'stale_file_threshold'
/config-sync/system.performance.yml:18:stale_file_threshold: 2592000
$ grep -rnw . -e 'filename_transliteration'
./config-sync/system.file.yml:9:filename_transliteration: true
Removing them like this solved my problem:
$ drush config:delete system.performance stale_file_threshold
$ drush config:delete system.file filename_transliteration
I thought this might help others finding this issue.
Sorry, I haven't had time to work on this. But the problem still exists. I have also upgraded to Drupal 10 and the message is the same. Probably I'll have to re-create the theme but I was hoping to avoid that..
I am using Bootstrap 8.x-3.29 now.
I can also confirm that this patch works and solves the problem.
Thanks muniraj.m. I'm using PHP 7.0.33 in this case. I'll try to update to a newer version.
Similar here when I try to open Taxonomy Manager:
ParseError: syntax error, unexpected ',', expecting ']' in menu_execute_active_handler() (Zeile 1382 von /sites/all/modules/contrib/taxonomy_manager/taxonomy_manager.admin.inc).
Version: 7.x-1.2
I just realized that this is probably more complicated than I thought because the E.164 standard for international phone numbers can have country codes of variable length (for example +1 for the US and Canada, +49 for Germany, +233 for Ghana etc.). Also city codes vary a lot.
Google's libphonenumber could come to the rescue, but it's probably an overkill in most use cases (> 200kb minified code). But it might be an option that could be activated. More on the topic here.
Another way could be to define a format in the module settings (for example telling how to slice the numbers).
In my case, for a German phone number (+49) I just patched phoney.js in lines 89 and 90 to this:
element.setAttribute('href', 'tel:' + tel);
element.innerHTML = '(' + tel.slice(0,3) + ') ' + tel.slice(3,6) + '-' + tel.slice(6);
Not a solution, but a workaround to display a German number with a 3-digit mobile code like this: +49 123 4737628.
yan → created an issue.