backdrop-contrib / coder_upgrade Goto Github PK

There is an error when trying to update the module from Backdrop UI:

In all install files, within the update_1000() function, there is a config declaration:

$config = ('module_name .settings');

which has an extra space, as in this example.

Not sure exactly how to best do it, but at some point I think that we should implement something like this:

Change this:

function coder_upgrade_upgrade_regex_info_alter(&$file) {
...
  $to[] = "backdrop = 1.x\ntype = module";
...
}

...to something like this:

function coder_upgrade_upgrade_regex_info_alter(&$file, $type = 'module') {
...
  $to[] = "backdrop = 1.x\ntype = $type";
...
}

Then we need to figure out how to best detect whether we are converting a module of theme .info file, and where/how to pass $type accordingly.

Here's some info that might help (see: https://www.drupal.org/docs/7/theming/writing-theme-info-files#s-theme-name-requirements):

Theme .info files in Drupal 7 are required to have a name = and a core = entry (same as modules), but they may also contain entries for:

• engine: (optional, defaults to phptemplate)
• regions[]: (optional, with defaults provided by D7 core)
• stylesheets[]: (required in D7) an array of all .css files you want the theme to use.
• scripts[]: (required in D7) an array of all .js files you want the theme to use.
• features[]: (optional) for page elements that can be toggled on/off, such as site logo/name/slogan/favicon/main_menu/secondary_menu etc.
• settings[]: (optional) if these entries exist, there should also be a theme-settings.php file in the root folder of the theme.

After installing the module, on the /admin/modules page, when I click on CONFIGURE for that module, I get the following error the page located at admin/config/development/coder-upgrade/settings:
Error
set_exception_handler(): Argument #1 ($callback) must be a valid callback or null, class PGPParser does not have a method "exception_handler"

I have included screenshots as well.
Thanks

Checking the log after conversion, I see entries like the following:

Ignoring function '_some_module_some_function' as its name does not begin with the module name or 'theme_'

We need to tweak the regex so not to be skipping _module_name_*() functions. Those should be converted too.

I just tried converting a module and it added the following to the .install file:

/**
 * Implements hook_update_N().
 */
function owlcarousel_update_1000() {
  $config = config('owlcarousel.settings');
  $config->set('owlcarousel_override_ajax_pagination_instance', update_variable_get('owlcarousel_override_ajax_pagination_instance', 'dynamic variable in file /owlcarousel/owlcarousel.module line 126'));
  $config->set('owlcarousel_debug_mode', update_variable_get('owlcarousel_debug_mode', 'TRUE'));
  $config->set('owlcarousel_cache_interval', update_variable_get('owlcarousel_cache_interval', '3600'));
  update_variable_del('owlcarousel_override_ajax_pagination_instance');
  update_variable_del('owlcarousel_debug_mode');
  update_variable_del('owlcarousel_cache_interval');
}

A few things:

1. Enhancement: Set the docblock comment for this function to something like 'Converts variables to config.' ("The documentation block preceding the update function is used as the description for the update on the pending updates at update.php." (source)).
2. Bug: $config->set('owlcarousel_override_ajax_pagination_instance', update_variable_get('owlcarousel_override_ajax_pagination_instance', 'dynamic variable in file /owlcarousel/owlcarousel.module line 126')); I believe this is because the original code looks like variable_get('owlcarousel_override_ajax_pagination_' . $instance)...
3. Bug: $config is not saved! Add $config->save(); before the first update_variable_del() call.

• core = 7.x works 👍🏼
• core= 7.x fails 👎🏼
• core =7.x fails 👎🏼
• core=7.x fails 👎🏼

PS: perhaps this works as expected if the "Coding standards for Backdrop..." option is selected, but we can do better.

What is the reason for creating an empty hook_update_1000() function? I could not find anything about it in the code or Backdrop developer documentation.

@docwilmot in backdrop/backdrop-issues#659 (comment) you mentioned getting code standards checks on contrib.

I use phpcs in backdrop/coder for drush and headless modules. Here is how:

Add a .travis.yml file similar to this:

language: php
dist: xenial
php:
  - 7.2
cache:
  directories:
    - $HOME/.composer/cache/files
    - $HOME/.composer/cache/repo
services:
  - mysql
addons:
  - mariadb: '10.0'
before_install:
  - composer install

script:
  # Check code standards
  - vendor/bin/phpcs -n --standard=vendor/backdrop/coder/coder_sniffer/Backdrop --ignore="vendor/*,README.md" --extensions=install,module,php,inc,theme .

  # Unit tests

You can either include a composer.json file in the root of your repo (this has the added benefit of having your module available on packagist.org for users to discover and manage backdrop modules) or you can add the composer require --dev backdrop/coder into the .travis.yml file.

Then allow travisCI access to the repo. I'd encourage you to add this code checking to all the modules you maintain and perhaps we (you, I, @klonos anyone who is interested) could lead a campaign making PRs against contrib projects giving them the infra to have code checking on there module(s).

ERROR: max(): Array must contain at least one element on line 424 in [...]/modules/coder_upgrade/conversions/end.inc (Warning)

Hello,

Several of our in-house modules are no-longer backwards compatible with PHP 5.x. A lot of our modules have been upgraded to take advantage of certain changes and features introduced in PHP 7.x. Currently, we try to be compliant up to PHP 7.4.x which introduced typed properties. We have discovered that Coder Upgrade w/ Grammar Parser 1.x does not support typed properties and the conversion result ends up being syntactically incorrect.

Original Code Example:

class MyInteger {
  public int $my_integer;
  protected ?bool $plus_one = FALSE;

  public function __construct($my_integer, $plus_one) {
    $this->my_integer = $my_integer;
    $this->plus_one = $plus_one;
  }

  public function get_my_integer() {
    $my_integer = $this->my_integer;

    if ($this->plus_one) {
      $my_integer += 1;
    }

    return $my_integer;
  }
}

Converted Code:

class MyInteger {
  public int $my_integer;
  public protected bool $plus_one = FALSE;

  public protected public function __construct($my_integer, $plus_one) {
    $this->my_integer = $my_integer;
    $this->plus_one = $plus_one;
  }

  public function get_my_integer() {
    $my_integer = $this->my_integer;

    if ($this->plus_one) {
      $my_integer += 1;
    }

    return $my_integer;
  }
}

We have a fork in progress that addresses this issue and we will be submitting a PR for this issue soon.

Hello,

We are wondering if an upgrade to Grammar Parser 2.x is in the works or has been completed already, perhaps in a fork? @rbargerhuff and I noticed that the current version of Coder Upgrade uses the Grammar Parser 1.x library, but the module here has a 2.x branch: https://www.drupal.org/project/grammar_parser

We attempted to swap out the Grammar Parser library in-place, but it makes some fundamental changes that break several Coder Upgrade functions and hooks.

We were looking into this because the Grammar Parser 2.x library has better support for newer PHP features such as traits, and seemed to have overall better handling of object-oriented code. We thought it might be a better solution than simply back-porting everything into Grammar Parser 1.x. But thus far, it hasn't worked well and has left us will little confidence.

Cheers.

Moved from this issue per @indigoxela.

See php 5.3 failure on this PR.

There are a few gotchas which users should be aware of. Some of them can be fixed, others should have warnings. Currently using coder_upgrade could be misleading developers.

Bugs:

• Deletes __DIR__
• Needs $config->save() in upgrade hook
• Replaces Drupal even if in a URL
• Forces TRUE/FALSE to be strings in config file.

Misleading:

• If a config variable should instead be in state_get, users need to be aware. Perhaps a warning in the README file.

Some situations were fixed by PR 42, but others are not and strings that happen to be equal to boolean values are not. The following test code shows some examples:

  variable_get('coder_upgrade_test_bool', TRUE);
  variable_get('coder_upgrade_test_str1', "TRUE");
  variable_get('coder_upgrade_test_str2', 'TRUE');
  variable_get('coder_upgrade_test_str3', 'BLUE');

.install file contains:

  $config->set('coder_upgrade_test_bool', update_variable_get('coder_upgrade_test_bool', TRUE));
  $config->set('coder_upgrade_test_str1', update_variable_get('coder_upgrade_test_str1', '"TRUE"'));
  $config->set('coder_upgrade_test_str2', update_variable_get('coder_upgrade_test_str2', TRUE));
  $config->set('coder_upgrade_test_str3', update_variable_get('coder_upgrade_test_str3', 'BLUE'));

.json file contains:

    "coder_upgrade_test_bool": true,
    "coder_upgrade_test_str1": "\"TRUE\"",
    "coder_upgrade_test_str2": true,
    "coder_upgrade_test_str3": "BLUE",

In both cases, 2nd and 3rd are wrong; the values should be ordinary string values.

Hello,

We noticed while using coder_upgrade that values passed into variable_get() that contains special characters were being wrapped with single quotes which was ending up as a syntax error due to incorrect conversion. For example:

return variable_get('cas_server_whitelist_failure', t('You do not have permission to login to CAS from this service.'));

While troubleshooting the reason for this, we noticed 2 issues in conversions/call.inc:

First Issue: The variable $raw_value was not being referenced in the preg_match() call which prevented the dynamic warning from being written to the patch file:

// elseif (preg_match('@[\.\s\$\[\]\#\>\(]@', $value)) {
elseif (preg_match('@[\.\s\$\[\]\#\>\(]@', $raw_value)) {

Once this was fixed, we noticed that string values that contained a "space" were triggering the dynamic warning so we updated the elseif to account for this:

elseif (!preg_match('@^\'[^\']*\'$@', $raw_value) && preg_match('@[\.\s\$\[\]\#\>\(]@', $raw_value)) {

Cheers!

See https://git.drupalcode.org/project/multiple_fields_remove_button/-/blob/7.x-1.x/multiple_fields_remove_button.info for an example case:

name= Multiple Fields Remove Button
description= Add remove button for mutli showing fields  .
core=7.x
package="Fields"

With the fix for #64 applied, you end up with this:

name= Multiple Fields Remove Button
description= Add remove button for mutli showing fields  .
backdrop = 1.x
type = module
package="Fields"

Ideally, we'd get this instead:

name = Multiple Fields Remove Button
description = Add remove button for mutli showing fields.
backdrop = 1.x
type = module
package = Fields

@docwilmot Hello there, during our testing and extensive evaluation of Coder Upgrade module, we discovered that namespaces, such as the following were not being handled at all.

namespace taco; /* Standard namespace statement */
namespace taco\cat; // Sub-namespace

use Drush\Backdrop; /* Standard use statement */
use Drush\Boot as TestAlias; // Use statement with alias

We took it upon ourselves to address this after forking this project and we will be pushing our changes soon.

Please read backdrop/backdrop-issues#4186 (comment) to see that replacing Drupal 7's variable_del() function in .install files is not sufficient. Either config_clear() should be used in the .module file to declare variables and then the variable_del() function in .install should be dropped, or the following function:

/**
 * Implements hook_uninstall().
 */
function $mymodule_uninstall() {
  config('mymodule.settings')->delete();
}

should be used instead to get the uninstalled module's configuration file actually deleted.

After running the Tocbot module through Coder upgrade, I couldn't enable Tocbot on a test site due to the following errors:

ParseError: syntax error, unexpected ''textfield'' (T_CONSTANT_ENCAPSED_STRING), expecting ']' in backdrop_load() (line 87 of /.../modules/tocbot/tocbot.module).

syntax error, unexpected ''textfield'' (T_CONSTANT_ENCAPSED_STRING), expecting ']'

Line 87 is the type textfield related one in this code part:

$form['moduleSettings']['tocbot_extrabodyclass'] =[
  '#type' 'textfield'

Related code from the D7 module:

$form['moduleSettings']['tocbot_extrabodyclass'] = [
  '#type' => 'textfield',

Coder upgrade strips the => between typeand textfield and the comma at the end of the line.

Also, according to @docwilmot in Gitter, Coder upgrade doesnt handle the square brackets syntax yet. At the moment a line like

$form['moduleSettings']['tocbot_extrabodyclass'] = [

has to be converted manually to:

$form['moduleSettings']['tocbot_extrabodyclass'] = array(

Note: The bracket syntax shouldn't be used because it's not available in PHP 5.3 (Backdrop supports 5.3).

Temporary files are left behind in the config directory after a run. PR implementing cleanup to follow.

Extra whitespace in a variable_get() call, e.g.,

  return variable_get('coder_upgrade_test_snack', 'garibaldi' ); // note extra space before last paren

leads to a "dynamic value..." entry in the config json file. (But it doesn't crash, like #47 does).

As with #47, the easy workaround is to do a search-and-replace to remove the extra whitespace before running Coder Upgrade.

Hello there,

When converting in-house modules or contrib modules to Backdrop, we have found that references to several classes included in Drupal 7's EntityAPI module will ultimately break the converted module. For example:

EntityApiController in Drupal 7's Entity API module has been changed to EntityPlusController in Backdrop's Entity Plus module.

We are aware that there are provided hooks by Coder Upgrade that allows targeted code to be renamed. However, we suggest, since the Entity API is such an integral part of Drupal 7, that Coder Upgrade should be upgraded to handle the above conversion.

Without this conversion, functionality provided by 3rd party modules will ultimately break.

Thoughts?

Example from a recent port, hook_config_info comes out like this:

/**
 * Implements hook_config_info().
 */
function userprotect_config_info() {
  $prefixes['userprotect.settings'] = array(
    'label' => t('Module name settings'),
    'group' => t('Configuration'),
  );
}

Ideally:

• Label includes actual module name
• There is a return $prefixes; at the end of the function

The issue described on backdrop-contrib/demo#1 is happening again - the forms which were supposed to return FALSE, return 'novalue' string instead, which breaks the intended functionality and makes it difficult to troubleshoot. Please consider removing it completely as it doesn't seem doing any use.

I use Coder upgrade module. It's an excellent help for me. I have written a patch, it can replace more functions. I hope you will find my pull request useful. 😄
Related links:
theme_html_tag() becomes theme_head_tag()

New Layout module

hook_library() and hook_library_alter() have been renamed

Generic sorting function to replace implementations of uasort()

After I processed a Drupal 7 module with Coder Update, the module.install file contained the The old hook_update_N functions cannot be applied to Backdrop. message stripping off the function code. Checking the https://api.backdropcms.org/api/backdrop/core%21modules%21system%21system.api.php/function/hook_update_N/1 page doesn't show any deprecation notice.

The original code for the function was:

/**
* Create database on update.
*/

function search_index_update_7100() {
 if (!db_table_exists('search_index_excluded')) {
   $schema['search_index_excluded'] = array(
     'description' => 'The base table for nodes.',
     'fields' => array(
       'nid' => array(
         'description' => 'The primary identifier for a node.',
         'type' => 'serial',
         'unsigned' => TRUE,
         'not null' => TRUE,
       ),
       'type' => array(
         'description' => 'The {node_type} of this node.',
         'type' => 'varchar',
         'length' => 32,
         'not null' => TRUE,
         'default' => '',
       ),
       'title' => array(
         'description' => 'The title of this node, always treated as non-markup plain text.',
         'type' => 'varchar',
         'length' => 255,
         'not null' => TRUE,
         'default' => '',
       ),
     ),
     'primary key' => array(
       'nid',
     ),
   );
  db_create_table('search_index_excluded', $schema['search_index_excluded']);
  }
}

Any suggestions for my case?

+573 ... coder_upgrade/includes/conversion.inc

When running this module I was seeing the enclosed error. Checking the status column in my system table, it looks like I have 0, not an expected -1. On line 562 of conversion.inc. if I change -1 to 0 everything seems to work as expected.

Error
SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens: SELECT name, filename, type, status, info, REPLACE(filename, CONCAT('/', name, '.', type), '') AS directory FROM {system} WHERE type = 'module' AND filename NOT LIKE 'core/%' ORDER BY directory, name; Array ( [:status] => -1 )

• #2 | Variable_get, variable_set, and variable_del deprecated by CMI
• State/Key-Value storage system implemented
• Removed the theme process layer
• jQuery updated to 1.11.0
• "drupal" replaced with "backdrop" throughout code
• Views added to core
• The class registry has been replaced with a static class map
• Information about tests now in module.tests.info
• New Layout module: Implements a drag & drop model for building layouts
• Dialog API
• Removed the concept of global theme settings
• File entity is now a classed object
• Node entity is now a classed object
• Taxonomy entities are now classed objects
• User entity is now a classed object
• Converted all variables to CMI
• Converted Vocabularies to CMI
• Converted User roles to CMI
• Converted Field API to CMI
• Toolbar replaced with Admin Bar
• [META] Various other theme system cleanup tasks #196
• Remove or consolidate theme functions and templates
• Removed the "Navigation" menu
• Removed the ability for users to select a theme
• Update queries now consistently return the number of all rows matched by the query
• Removed region-specific template suggestions for blocks
• It is now possible to get the last inserted ID from db_merge
• Theme settings converted to CMI
• Entities are now classed objects
• The mail_system variable has been converted to config
• Modules removed from Backdrop (which were in Drupal 7)
• Modules added to Backdrop (which were not in Drupal 7 core)
• System_settings_form() to be deprecated
• language_list() is simplified, locale_language_list() is removed
• Renamed the taxonomy functions that returned multiple values
• Definitions for top-level custom menus are now configuration
• file_delete() now takes file ID as parameter, not a file object
• theme_dblog_message() has been removed
• Changes to AJAX execution
• format_username() changed to user_format_name()
• system_get_date_types() deprecated; use system_get_date_formats()
• Generic sorting function to replace implementations of uasort()
• Placed files in consistent locations for all core modules
• Placed all theme-related functions in modulename.theme.inc file
• $form['#node_edit_form'] removed
• Image styles converted to CMI
• date_iso8601() removed
• Retrieving date formats has been changed
• hook_node_info() removed
• Skip calling of hook_boot() and hook_exit() on cached pages
• The user_pass_rehash() function now requires the user account ID to be passed in
• hook_library() and hook_library_alter() have been renamed to hook_library_info() and hook_library_info_alter()
• Variables changed
• CKEditor module now included in core
• Email module now included in Core
• Link module now included in Core
• Date, Date Popup, and Date Views modules now included in Core
• backdrop_get_path() can now find Layouts
• Page title elements now use the class .page-title instead of ID #page-title
• language_list() now takes a second parameter to return an array of strings
• The category system is removed from user edit and view
• Custom Blocks are now stored in configuration and block_custom table removed
• element_validate_integer() and element_validate_integer_positive() replaced with number element type
• Redirect module now included in Core
• Maintenance pages no longer use theme-provided regions
• system_get_date_formats() return value has changed
• drupal_is_denied() has been removed
• taxonomy_term_uri
• hook_layout_presave() now takes $layout object instead of $data array

If you clone a repo from Drupal it comes with Windows line endings. But when you run through CU its parser/writer routines use Linux line endings, so your file ends up with a mix. See this file here:

Notice all the line endings are LF until the end of the Implements hook_field_extra_fields(). comment, when it switches to CR. This happens for all the Implements hook_wwwww(). lines. It may be this is the only write routine thats messed up since I haven't seen any other problems like this. If you convert the file to Linux line endings first, this doesnt happen.

I have tried both the latest coder_upgrade version (1.x-1.x) from github, and the 1.x-1.0.2-beta from backdrop modules page, both gives the following error on installation (and no coder admin page links appear in the menu): "Error: syntax error, unexpected '$domain' (T_VARIABLE)"
(I am installing to (the root of...) a subdomain, not the root of the main domain (without www) nor to "www", if that is relevant, since the error says "unexpected domain".)

Initially after the installation error, there seem not to be any menu created for the URL "admin/config/development/coder-upgrade" , but not sure if I was tired yesterday. Anyway, coming back to the site now today and manually trying to go to admin/config/development/coder-upgrade by pasting it in the url, then the coder module is there/available/ready, and now the link in the Configuration - Development menu is also in place.

But the error message is displayed on a "white screen" with only that message, so at least the first impression is that the installation failed.

I will try to use it and report back here if it is actually working.

A variable_get() that is initialized from an empty array, e.g., variable_get('mymodule_setting', array()), leads to a "dynamic value in file..." value in the config file and install function. Since empty arrays are relatively common initialization values, it would be nice to catch this situation and properly set the config and install values.

The null coalescing operator ?? gets dropped.

$foo = $bar ?? $baz; becomes
$foo = $bar $baz;

This was introduced in PHP 7, so shouldn't be used in contrib modules that are supporting back to PHP 5.3, but users might be converting custom modules that are only intended to run on PHP 7 and above.

• Change variable calls to config/states
• Add hook_config_info()
• Add update hook
• Add note to install file if dynamic variables

Upgraded an internal module to work with BackDrop CMS and afterwards noticed this in the generated path file.

-    $class = static::class;
+    $class =::;

It replaced static::class; entirely with T_DOUBLE_COLON, or ::

I believe this is an issue but I'm not sure where this should be reported.

Thank you and cheers.

Conversion routines

Option 1

Coding standards for Backdrop (parse and rewrite code files using the Grammar Parser) (it is recommended to run this routine before applying core API change routines so that the patch files accurately reflect the routines applied)

Option 2

Core API changes from Drupal 7 to Backdrop (also includes coding standards changes from rewrite of code files using the Grammar Parser)

Queries

Patch files

Option 1 says to run this routine before core api changes for patch files to accurately reflect the routines applied. running option 1 first and then option 2 there is only 1 patch file. So what am I doing wrong?

Duplication

Option 1 is coding standards. Option 2 includes coding standards as well as core API changed. So are they both needed, or does option 2 do everything?

Converting files is giving the warning:

WARNING: "CONTINUE" TARGETING SWITCH IS EQUIVALENT TO "BREAK". DID YOU MEAN TO USE "CONTINUE 2"? IN /VAR/WWW/DOCROOT/MODULES/CODER_UPGRADE/GRAMMAR_PARSER/EDITOR.INC ON LINE 309

and the long CALL STACK. Is ti normal behavior or a bug?

Upgraded an internal module to work with Backdrop CMS and afterwards noticed that a space has been added between the question mark and the type. I'm not sure if this is intended behavior or not.

Example:

public static function logEntry(? string $logMessage) {

Preferred:

public static function logEntry(?string $logMessage) {

Again, not sure if this is a bug.

Thank you and cheers.

In some cases, the module gives:

ParseError: syntax error, unexpected 'NULL' (T_STRING), expecting ']' in coder_upgrade_cache_info_hooks() (line 5 of /var/www/docroot/modules/coder_upgrade/conversions/begin.inc(139) : eval()'d code).

I got this error when trying to run a code upgrade:

Class 'SearchApiAbstractService' not found

Although this is triggered by the metatag module (backdrop-contrib/metatag#64) - even if it's not turned on - I just deleted the offending class in metatag_search_test.module to bypass this error.

ERROR: Undefined variable: item on line 47 in /Users/laryn/buildkit/build/backdrop-demo/modules/coder_upgrade/conversions/end.inc (Notice)

@jenlampton @klonos, can you give @bugfolder merge/commit permissions please?

I left the setting "Preserve array formatting" unchecked and it breaks the callback function. My suspicion is that it won't break if I enable the setting but I'm not sure.

   // Look through the child items for the MENU_DEFAULT_LOCAL_TASK.
-  $child_paths = array_filter(array_keys($items), function($p) use ($path) {
-    return preg_match("#^$path/[^/]*$#", $p);
+  $child_paths = array_filter(array_keys($items), ($p) ($path){
+    preg_match("#^$path/[^/]*$#", $p)
   });

Any of the following lines in a file being upgraded will cause the error of the title of this issue:

return system_settings_form( $form);
return system_settings_form($form );
return system_settings_form( $form );

Backdrop coding standards call for no whitespace between the parens and arguments, but users upgrading a custom module that didn't follow coding standards might run into this. If so, the quick fix is to do search-and-replace to eliminate such whitespace before running Coder Upgrade.

There are four vertical tabs on admin/config/development/coder-upgrade

• Upgrades
• Extensions
• Directories
• Modules

Each of the tabs displays a list of options.

When I select the "Select all rows" option at the top of one tab, the rows of all tabs get selected. This can e.g. lead to a situation where Coder upgrade tries to convert all modules of a site.

Steps to Reproduce (Example)

• Install Coder Upgrade.
• Go to admin/config/development/coder-upgrade.
• Select the vertical tab Extensions, and check the "Select all rows" option at the top.
• NOTE: Do not hit the Convert files button.
• Have a look at one of the other vertical tabs, e.g. Modules.

Result:

• All options of the Modules tab (and of the other tabs) are enabled.
  (If you'd hit Convert files; Coder upgrade would try to convert all modules of the site.)

Expected behavior:

• Only the rows of the initial / current tab are selected.

The null coalescence operator doesn't parse correctly. With this input:

$foo = $bar ?? $baz;

we get this output:

$foo = $bar $baz;

Fixable by adding the additional case in two places. I'll prepare a PR.

Using the complex curly syntax (variable embedded in a string) creates an error. For example,

  $var = 'bar';
  $name = "foo{$var}";

generates this error message:

ERROR: Illegal string offset 'value' on line 2308 in /mysite/modules/contrib/coder_upgrade/grammar_parser/list.inc (Warning)

The problem is in the data parser. In function PGPReader::buildString() (reader.inc, line 2952), the 'close' token is a literal curly brace, which means that on line 2308, $data is that literal string, and not a token array. The solution is to give 'close' its own case statement that uses $data directly. This fixes the error and generates a correct result.

I will prepare a PR.

A reference is mentioned in the readme, but there is no license file included in this repo. I'm not sure which license to include though. The readme lists GPL 2.

In a lot of the Backdrop contrib module repos, there is no license file; however, it is packaged in the releases, I think. So, this issue affects all the contrib modules.

I was looking for an issue about this topic, but I couldn't find one via a basic search. I know @kreynen knows a lot about licensing and where to put them and may have created issues about this already.

I included a license in https://github.com/backdrop-contrib/xmlsitemap and https://github.com/backdrop-ops/contrib/blob/master/README.md#new-project-checklist has including a license as a requirement.

Could coder_upgrade also go through Javascript files to change Drupal. to Backdrop.?