Ubercart doesn't uninstall completely

The field tables related to the Catalog are caused by #687180: Deleting a taxonomy vocabulary leaves term reference fields still pointing to it, and a PDO Exception when creating content. That's a bug I hope to fix soon.

That may be the same problem for the product images, as well. I'm not certain that the node types are being deleted properly, so the fields might be hanging around because of them.

The image variables were just forgotten.

In preparation of #687180: Deleting a taxonomy vocabulary leaves term reference fields still pointing to it, and a PDO Exception when creating content being committed, or something very like it, I've tweaked the way the uc_catalog_image and taxonomy_catalog fields are being created when the module is installed. Mostly it just makes sure it doesn't try to add fields or instances that already exist.

References to {uc_catalog_images} have also been removed from the code, except for the update function that moves that data to the field. The table itself will stick around for posterity, just like the uploads table from Drupal 6.

Well, #687180 is mostly a wash. #628244: No way to attach the automatically created taxo field specifically took out that functionality I was trying to put back in, so uc_catalog needs to set up the term reference field in addition to the vocabulary entity.

I am not so sure that Ubercart needs to delete the fields it creates. It's entirely possible that someone could reuse those fields on other entities, and we shouldn't really delete their data since it doesn't have anything to do with Ubercart.

However, I think it is supposed to work out because field data isn't really deleted when you call field_delete_field(). Instead, the row in field_config has the "deleted" column set to 1. Then field_cron() goes through the field data and removes the fields and instances that have been marked for deletion. I also think it is supposed to remove fields that don't have any more instances, so if uc_product_image and uc_catalog_image haven't been reused on a site, they should go away eventually.

If none of that actually happens, then a bug report needs to be made in the Drupal issue queue.

As for the uc_image_* variables, I guess I forgot that uc_product_types() shouldn't work when the module is disabled. I guess the database query is the better idea.

In my testing, I found an error where uc_product kept trying to create the uc_product_image instance even when it already existed. That fix has been added to this patch, which has been committed.

I think Drupal needs to do more when modules providing node types are disabled or uninstalled. The cron jobs that are supposed to purge field data seem to get confused when uc_product isn't available any more.

Attached two images to clarify:

1. In the first, I click on (automatically create images).
2. Then it appears the error of the second image.

I can't reproduce this. Ubercart already deliberately checks that the image field doesn't exist before trying to create it. I think the error is actually an inconsistency in your database regarding Field API; it doesn't think the field exists (is it listed in the field config table?) but the data table does exist when it tries to create it. Have you been making changes directly in your database, or had any other field related errors?

It was created by Ubercart istself cuz I had ubercart before, I deleted it and uninstalled (maybe it was not completely uninstalled) and then tried to re-install and happens that.

It's ok it looks for image to see if it is already created, but if, in fact, it is, then it should just say ok and continue, not stop and break :S

will try to repair it manually.

It does say "ok and continue". The code is as follows:

  $field = field_info_field('uc_product_image');

  // Set up field if it doesn't exist.
  if (!$field) {
    $field = array(
      'field_name' => 'uc_product_image', 
      'type' => 'image', 
      'cardinality' => FIELD_CARDINALITY_UNLIMITED,
    );

    field_create_field($field);

In your case field_info_field() must be returning FALSE, which means the field doesn't exist. But then field_create_field() is throwing the error, saying the field table already exists. I think the field structures in your database have become corrupted somehow, as I said I can't reproduce this without manually deleting things from the database to deliberately cause the error.

I still can't reproduce this without deliberately breaking the database structures.

Resurrecting this thread, because I am getting this exact same error for my Catalog and Taxonomy field data:

DatabaseSchemaObjectExistsException: Table field_data_taxonomy_catalog already exists. in DatabaseSchema->createTable() (line 652 of /home/ninja/public_html/includes/database/schema.inc).

AND

DatabaseSchemaObjectExistsException: Table field_data_uc_product_image already exists. in DatabaseSchema->createTable() (line 652 of /home/ninja/public_html/includes/database/schema.inc).

Both tables, field_data_uc_product_image and field_data_taxonomy_catalog, exist according to phpMyAdmin. Here's what happened:

I was installing UC on one host. Drupal crashed. I realized I needed a VPS with more ram. I copied the files, downloaded and uploaded the database via phpMyAdmin. On the new host, things went well until I enabled the Ubercart modules and started getting these errors.

Since a heck of a lot of work has already gone into this site, what are my options? Can I force UC to "see" these tables? Do I drop those tables? Any advice would be welcome.

Wow, I did not detect a need to apply 687180-59-combined.patch to the taxonomy module based on the comments above. However I did as you suggested, taxonomy.module and taxonomy.test are now updated.

But I get the exact same two errors when I try and create a catalog taxonomy reference field or "Click here" to automatically configure the following items for core image support. (I'm not sure HOW the taxonomy module and my issue with core image support are related.)

I also see a patch on this thread, but since it is from 2 years ago, I assume it is rolled into the 7.x-3.0 I am using.

What other options do I have? Did @RaulMuroc have any luck manually repairing the database? Any idea how I might do that?

Tagged as the wrong version number. This is all with 3.0.

Drop the tables, then Ubercart should be able to recreate the fields. Field API isn't very robust, and if its metadata gets out of sync with the actual database structure - which likely happened when you ran out of RAM - it gets a bit confused.

Unfortunately if this is to be improved it needs to happen in Drupal core to fix things for all fields, not just Ubercart ones.

I agree to #21 longwave, then we shall assign it to Drupal core instead, shall not we?

I did for the case, feel free to correct me if I missunderstood.

Thanks to all, this is a really great community :-)