PHP Fatal error: Cannot unset string offsets in /includes/commerce_flat_rate/includes/commerce_flat_rate.admin.inc on line 214

I got this too when editing a service.

@BenK right now the simplest solution is to delete and recreate the service :-(

I believe this is all that's required.

However, if you have this problem (If you have created any shipping services) you have to delete them and re-add them before this fix will take effect.

I'm pretty sure that this will also fix the (probably was broken) "Include Tax in this rate", which includes VAT in a specified rate.

After applying this patch you must delete any existing shipping services and re-add them before you'll be able to edit.

I'm also experiencing the same issue. I applied the patch from #2 and after creating a new flat rate, and then editing, I receive the same error. Do I need to delete all my prior shipping rules before being able to edit?

Yes, you have to delete existing rules, as it says in #2. I'll edit #2 to make that more obvious.

Thanks rfay. I was able to get this to work, but only after re-installing the flat rate module.

I felt guilty saying "You have to delete and re-add services". Here's a patch that provides and update.php that fixes broken flat rate services.

After patching with this patch, you must run update.php. Then you should be able to edit services without the fatal.

rfay, thanks, all works good, your patch solve the issue.

I'm having a hard time reproducing this error, to be honest. Before Randy's patch, whether for a new service or an existing one, I don't get the same error. Is it perhaps a PHP environment variable that I don't have set that everyone else does?

Also, we could just change

if (!empty($form_state['values']['flat_rate']['include_tax'])) {
  // ...
}
else {
  // ...
}

to

if (!empty($form_state['values']['flat_rate']['include_tax'])) {
  // ...
}
elseif (!empty($shipping_service['data']['include_tax'])) {
  // ...
}

to get the same effect without worrying about the update function (which I don't typically provide in -dev modules). That's the real logic that for some reason I didn't enshrine in an elseif originally. : ?

We can still initialize the data array in commerce_flat_rate_service_new(), though.

I'll bet you're running PHP 5.2 and the #fails are 5.3.

Otherwise, I can't imagine you can't get this. I've seen it 100%, and it looks like others have as well.

1. Create a service
2. Edit the service
3. Fatal

I guess I can try it on MAMP; the code is clearly wrong, and the 'data' either needs to be provided or abandoned.

Yep, I'm on PHP 5.2. Something has changed about unset(), then? I've never bothered to check if a key exists in an associative array before unsetting, so this could affect other parts of Commerce as well.

Or perhaps the problem is unsetting a non-existent key nested beneath a non-existent key. : D

Yeah, you've got it. The problem is

unset($something[$x])

where $something is a string instead of an array. The problem is not *unset* it's using a string as an array.

Oh, and BTW, encourage you to move to 5.3. Its strictness in some places will show some things that you'll want to see.

So the problem then is that somehow $shipping_service['data'] was set to a string? Ahh! Because on load it would have "unserialized" from NULL and been turned into a NULL string on the $shipping_service array. All makes sense now. Curious that something that didn't even throw a notice in 5.2.x would throw an error in 5.3.x. I'm not entirely sure how to update MAMP's PHP version, but I'll get it up when I can.

I'm getting the same fatal errors. I'm running php 5.2.13 on MAMP with the following versions:
drupal 7.10
commerce 7.x-1.1
commerce_flat_rate 7.x-1.x-dev (2011-Nov-11)
commerce_multicurrency 7.x-1.0-rc2
commerce_shipping 7.x-2.x-dev (2011-Dec-01)

I'm in the midst of building my first drupal7/commerce site (upgraded from drupal6/ubercart). Randy, your videos have been enormously helpful. Thanks and keep up the great work!

It actually looks like commerce_flat_rate_commerce_shipping_service_info() was initializing the data property to a string around line 132. Can anyone getting this problem test it with the attached patch that combines rfay's approach and my elseif recommendation from above? Test it with both new and existing rates, please.

Whoops, priority change back as this obviously affects everyone but me. : )

I can confirm that the patch in #16 fixed the issue. I was able to edit existing flat rate services. I was also able to create new ones and edit them without errors.

Rockin'. Let's get it in, then.

Commit: http://drupalcode.org/project/commerce_flat_rate.git/commitdiff/149239a