Multiple rows of this error on Ubercart catalog views:
user warning: Unknown column 'delta' in 'order clause' query: SELECT * FROM content_field_image_cache WHERE vid = 103 ORDER BY delta in /home/mtsite/drupal/sites/all/modules/cck/content.module on line 979.

What version of Ubercart are you on? There have been some problems lately with Imagefield changing it's field settings so that Ubercart 2.x-beta5 doesn't provide the right values when it creates the default image field.

user warning: Unknown column 'delta' in 'order clause' query: SELECT * FROM content_field_image_cache WHERE vid = 3 ORDER BY delta in /home/..../public_html/gold/sites/all/modules/cck/content.module on line 987

Under the Manage fields page, do the settings for field_image_cache say you can have multiple values? It looks like CCK expects it to, though the database table wasn't created that way for some reason.

I had the same problem. I solved it by changing the global settings "number of values" for the imagefield to "1", saving the node, and then changing it back to "Unlimited." I'm not sure why that works, but the issue hasn't surfaced again since. Since these are global values, you only need to do it on one instance of imagefield (field_image_cache).

Hope this helps.... before I solved this, it wasn't letting me save any images to a product node.

John CarboneCreditAttribution: John Carbone commented October 6, 2009 at 6:30pm

Huh... ran into a very similar message when working with noderef: "user warning: Unknown column 'delta' in 'order clause' query: SELECT * FROM content_field" ... yada yada... totally unrelated to UC, but comment 16 fixed it for me too. Thanks! Just to clarify for anyone else that might find this, I think he meant to say to change the settings on the content type and save it, not the node. : )

Here's how you can duplicate the error.
1. Go into the default product content type - and modified the image field and set the Number of Values to be 1.
2. Create product nodes with images on then.
3. Create a new product class in ubercart.
4. Now the nodes you created should loose their images.

That should be all that's require to duplicate the error.

So here's what I go so far
When the new product class is created the uc_product_class_form_submit function is call which calls the uc_product_add_default_image_field function.

In the uc_product_add_default_image_field function a new instance of an image_field is attached. You can see the code below.

As you can see above the global settings such as required, multiple, list_field, list_default, and description field are set in the new instance array. Which in turns are applied when then content_field_instance_create function is call with the $field parameter.

So what happens is that every time a new class is created the global settings are reapply and the field table gets re-setup. Which cause you to loose that data. Which sucks. :-(

So there's the problem.

A quick-fix is just commenting the global settings. I know this works once you have the "product" node set up. But I don't know what the consequence will be if it's a clean install and the uc_product_enable function is call.

Dang. It looks like it wants to list the files through CCK when the field is added afresh. That's not good for the initial field settings, but I can imagine some reasons why someone would change that for their product images.

FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 383330_global_field_settings_0.patch. See the log in the details link for more information. View

Actually, since display_settings are per-instance settings, I can leave them in the $field. Give this patch a test install. I've been using drush to disable/enable the modules quickly. Make sure you actually remove the field first, if you do that.

No it worked for me too. I just think it is funny and reminds me of when the Fonz hits the jukebox or in the 60's when hitting the TV got the picture to stop fluttering. Just making light of the fix. It is actually an amazing find. I don't know how people figure that stuff out. Didn't mean to sound cynical.

I suspect this is really a CCK issue, related to sharing a field across multiple content types. A few weeks ago we tracked down this bug: #671708: Repeating date should be a different date type by stepping through the debugger, and basically found that CCK would alter the underlying table in the database whenever you saved the field definition on a content type. So whichever content type you looked at last could actually delete data in the same field, in other content types!

I'm not sure this is the problem here, but I really suspect it's the same bug. In our case, we started getting this error (and images disappeared) when we enabled the Product Kit module. Suddenly the field_image_cache was no longer unlimited in all content types it appeared in, and the image queries broke with this error. That would explain why changing the number of instances (twice) would repair it -- though you would lose any additional images.

So is anyone going to try out the patch in #25 and report on it? The "workaround" in #16 isn't a fix to Ubercart, doesn't get this issue any closer to being resolved, and doesn't keep other people from encountering the same problem.

If you are one of the people experiencing this problem, the community needs to test the patch and let us know whether that fixes things. Only when the patch has been show to work without causing other problems will it be committed to Ubercart.

I'll try the patch. To test it, what would I do before and after applying the patch? For example, would I remove the images from the products, apply the patch, then add the images back to the products?

This is a problem with the fact that at this time the Product Kit does not have an image fieldset like the standard product has.

Somehow, I have not seen those errors in my logs or on screen but it is a problem for me since I show a list of software for sale and all the bundles do not include the field.

I did not read all the comments, but patches in #22 and #25 have nothing to do with improving the software. It just removes the SQL error. We'd need to add the field to the product kit table and the code in the node edit page so we can have an image. 8-)

Maybe I'll do that later, although right now I have a few other problems to work on...

I've just hit this problem with a clean install - and part of the issue seemed to be that the Product image had files as the directory which was throwing an error so I had to change that as well as performing the changes in #16

Hmm. For me the solution was much simpler than the one outlined in #16 and #36. I created additional product classes and somehow the field became multivalued instead of a single value field. I went into the "master" product content type and set it to single value. Voilá: problem solved!

I had the same problem, and I did run update.php (over and over). The issue however was update.php related.
The version update on the uc_product module was not being picked up correctly, so I had to set it manually. That fixed the issue for me.

I had this problem and none of the fixes worked. I wanted to stipulate 1 image rather than multiple. I realised i had a relationship on the image fid on the 'views - > relationships' which i don't suppose is needed on a single image value. I deleted this and it has started to work.

Agreeing with freelock in #35 - I suspect this is an obscure bug in CCK that only occurs when sharing fields between content types, and when those fields are created programmatically rather than in the UI. I have seen similar issues in Features and there are a couple of bug reports in Date about the same thing. Tracking down the offending piece of code seems very difficult, though.

How to reproduce: Create at least one product class in Ubercart. Change the content type to allow exactly one image per product rather than the default "unlimited". Add a few products, each with an image attached. Create a new product class. All the images in existing products will no longer show up because of a broken SQL statement. The root cause is that inserting a new product class will overwrite the existing field definition and thus create the invalid SQL for any previously inserted products.

The function uc_product_add_default_image_field() should instead test whether the field already exists and if it does, honor the current settings. If it does not exist, it can follow the current strategy and insert a new field with reasonable defaults.

Finally, thanks to the steps listed in #60, I think I have a patch that solves this. This ensures that if a field instance already exists, we copy the settings from the existing field, rather than always trying to reset it to "unlimited".