🇺🇸United States @oadaeh

xjm → credited oadaeh → .

I think this issue needs to be in the JSON Field module's issue queue, because that's where the changes will need to be made.

A related issue is already there, and I added what I did to migrate there: 💬 Help migrating from jsonb to json_field Active

I created an update hook that uses guidance from this SE answer:
https://drupal.stackexchange.com/questions/208946/how-do-i-change-a-fiel...

It requires some manual set up operations, so I don't know that this could be included as a generic update for the module, but if someone wanted to explore that, this should help them quite a bit.

Start with a backup and practice on a development copy of the site to convert. You will probably need to rebuild the site from the database backup a few times before you get your finished product.

Follow the steps in that SE post.

You need to modify the config of the fields, and that is done by deleting and recreating the fields, exporting them, then changing the UUIDs back to what the original fields were. What you are targeting is updating the config of the existing fields, not creating new ones, but you might need to manually delete and create them to know what config changes need to be made. You could also manually modify the files, if you know what needs to be changed.

When you are done, you should have an update hook and modified config that will convert your site with a drush deploy command

Here is my code, which differs slightly from the code in the post:

function custom_module_update_1234() {
  $database = Drupal::database();
  $fields = [
    'node' => [
      'field_fieldname1',
    ],
    'block_content' => [
      'field_fieldname2',
      'field_fieldname3',
    ],
  ];

  foreach ($fields as $entity_type => $field_names) {
    foreach ($field_names as $field_name) {
      \Drupal::logger('custom_module_update')->debug('Converting ' . $entity_type . '__' . $field_name . ' from JSON/JSONB to JSON Field.');
      $field_storage = FieldStorageConfig::loadByName($entity_type, $field_name);
      if (is_null($field_storage)) {
        return;
      }

      // Include the revisions as well.
      $tables = [
        $entity_type . '__' . $field_name,
        $entity_type . '_revision__' . $field_name,
      ];

      $rows = [];
      foreach ($tables as $table) {
        $rows[$table] = NULL;
      }

      // Store the data to restore after the update is completed.
      foreach ($tables as $table) {
        if ($database->schema()->tableExists($table)) {
          $rows[$table] = $database->select($table, 'e')
            ->fields('e')
            ->execute()
            ->fetchAll();
        }
      }

      $new_fields = [];

      // Use existing field config for new field.
      foreach ($field_storage->getBundles() as $bundle => $label) {
        $field = FieldConfig::loadByName($entity_type, $bundle, $field_name);
        $new_field = $field->toArray();
        $new_field['field_type'] = 'json_native';
        $new_field['settings'] = [];

        $new_fields[] = $new_field;
      }

      // Deleting field storage which will also delete bundles(fields).
      $new_field_storage = $field_storage->toArray();
      $new_field_storage['type'] = 'json_native';

      $field_storage->delete();

      // Purge field data now to allow new field and field_storage with same name
      // to be created. (The batch size might need to be increased.)
      field_purge_batch(10);

      // Create new field storage.
      $new_field_storage = FieldStorageConfig::create($new_field_storage);
      $new_field_storage->save();

      // Create new fields.
      foreach ($new_fields as $new_field) {
        $new_field = FieldConfig::create($new_field);
        $new_field->save();
      }

      // Restore existing data in the same table.
      foreach ($tables as $table) {
        if (!is_null($rows[$table])) {
          foreach ($rows[$table] as $row) {
            $database->insert($table)
              ->fields((array)$row)
              ->execute();
          }
        }
      }
    }
  }
}

oadaeh → created an issue.

oadaeh → created an issue.

Okay, here's one that actually includes the latest changes in dev, and a forgotten use statement.

Here's an updated patch, removing the unrelated addition of providing a human readable description (I'll create a new issue for that) and based on the latest changes in dev.

I recreated my patch based on #11 🐛 View title is always displayed if the extra setting is hidden Needs work , so the missing option should be there.

I found a problem with my patch, and I'm working on an updated one.

I created release 8.x-1.0-beta8 → that includes the changes for this issue, so I'm marking this fixed.

Here is the patch.

oadaeh → created an issue.

Here's another updated patch for more updates in dev.

Reviewed, approved, and merged.

Thanks for that @artem_sylchuk.

There are two more in src/Form/FormsStepsEditForm.php and one in src/Form/FormsStepsProgressStepEditForm.php.

Here's the patch.

oadaeh → created an issue.

Oh, yes, that should work. I totally forgot about it. Thanks for the reminder.

The functionality is still there.

The new `commerce_shipping_boxpacker.module` file is there.
The new `config/schema/commerce_shipping_boxpacker.schema.yml` file is there.
The additional $max_weight code in `src/Packer/Packer.php` is there.

Is it not working for you?

I'm also attaching an interdiff, which I should have done previously.

I figured it out. By adding the the library's Packer class in a use statement, I created a name conflict, so I removed the use statement and directly specified the class where necessary.

Shoot! The PackagePacker class was supposed to replace the Packer class, not add to it.
I kept getting "PHP Fatal error: Cannot declare class Drupal\commerce_shipping_boxpacker\Packer\Packer because the name is already in use in /web/modules/contrib/commerce_shipping_boxpacker/src/Packer/Packer.php" until I renamed it.

Try the attached patch and see if that is acceptable.

I included modified changes of the code listed in comment #3 in my patch added to ✨ Improve Packer class Needs review .
They were added to my patch because the code changes here and there are in the same code.

Also, this patch makes this module compatible with Drupal 10.

oadaeh → created an issue.

I was working on this last week, but had to rebuild my local environment, due to various problems, so that delayed me a bit.
Due to the fact that the MR is broken, I chose to manually create a patch file with all the relevant parts (and hopefully leaving out the brokenness). I did not at all investigate comment #17.
The patch does apply for me, but only to 8.x-1.x-dev, due to some incompatible changes between it and 8.x-1.5.

I merged in the patch, adding the necessary changes for the .info.yml file.

I've merged this in. Thanks.

oadaeh → made their first commit to this issue’s fork.

Thank you.

I've attached a patch that includes the things the bot can't get, including updating the *.info.yml files.

oadaeh → created an issue.

oadaeh → created an issue.

The test that failed previously was passing for me locally, but I started a complete test suite to see if anything different comes up. I also triggered the test bot here for multiple environments, in case the problem is with some unrelated PHP 7 incompatibility causing the failure.

Attached is a patch that addresses 1 and 2 of #2752783-13: [D7] file_unmanaged_move() should issue rename() where possible instead of copy() & unlink() → .

@David_Rothstein, all of 3-7 are in what was committed in the D8 commit: http://cgit.drupalcode.org/drupal/commit/?id=26cf55b

Regarding 3, the explanation for that is in these comments:

• #1377740-5: file_unmanaged_move() should issue rename() where possible instead of copy() & unlink() →
• #1377740-10: file_unmanaged_move() should issue rename() where possible instead of copy() & unlink() →
• #1377740-21: file_unmanaged_move() should issue rename() where possible instead of copy() & unlink() → together with #1377740-22: file_unmanaged_move() should issue rename() where possible instead of copy() & unlink() →

Regarding 4-7, considering that's the way they went into D8, did you want them changed anyway? I agree that there is much in those comments that could be improved, but I'm not sure I would change them without also changing them in D8.