Jump to:
| Project: | File (Field) Paths |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
This fault basically breaks the module for any types where there is a space in the type name. I have a type with the name "Supplier Profile" and the machine name "supplier_profile", but as you can see below, this is changed, and as a result, directly or indirectly, this breaks the module.
user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IS NOT NULL AND n.type = 'supplier-profile'' at line 1 query: SELECT c.nid FROM content_ c LEFT JOIN node n ON c.nid = n.nid WHERE c. IS NOT NULL AND n.type = 'supplier-profile' in /home/spectro/domains/example.co.uk/public_html/sites/all/modules/filefield_paths/filefield_paths.module on line 318.This is caused by the space in the type name I think - although I'm not sure - but basically the call to content_fields() fails, causing the above error. I've tried forcing the type name to be "supplier_profile" by adding a default parameter in the function declaration, but this didn't work either.
This is with the 1.2 release, and the latest CCK (2.3), along with filefield 3.0, and ImageAPI 6.x-1.6, ImageCache 6.x-2.0-beta9, ImageField 6.x-3.0, ImageField Tokens 6.x-1.0
Comments
#1
Hi Nik,
From first look, it appears to be a problem with the SQL query that is unlikely to be caused by the space in Content Type.
The bold sections below are likely the problem:
SELECT c.nid FROM content_ c LEFT JOIN node n ON c.nid = n.nid WHERE c. IS NOT NULL AND n.type = 'supplier-profile'
Out of curiosity, did you run update.php after updating to the latest version of CCK?
Going to run some more tests to see if I can reproduce, but my initial test found no problem, however I was using the latest dev version of FileField Paths and CCK.
Cheers,
Deciphered.
#2
Hi Nik,
Just tested with the same versions as you and was still unable to reproduce the issue.
Any more information you can provide would be extremely helpful.
Cheers,
Deciphered.
#3
The query string is constructed using values returned from content_fields(). The value of node_type passed to that function gives different results depending on how it's formatted.
If I leave as is, and dpm() the $field object, I get nothing, and an error. However, if I force the node_type string to be "supplier_profile" there, I get an array pretty-printed in the message. This tells me that something is awry in there somewhere.
The SQL would be fine, but it's the return values from content_fields that are screwy (non-existent) when node-type is with a - instead of a _
#4
Nik
I looked into it a bit further and have managed to reproduce the issue. It only occurs when you use retroactive updates (which would have been handy to know that's when the error was occurring :)). Will have a fix shortly.
Cheers,
Deciphered.
#5
Fixed and Committed to DRUPAL-6--1 and DRUPAL-5.
Cheers,
Deciphered.
#6
Ah... Yeah I probably should have mentioned that. Damnation. I guess I had assumed (very stupidly) that this bit of code would only get called under those conditions.
Thanks very much for helping me out of a spot here! :) What was the bug, out of interest?
#7
You where pretty much on the ball with the problem, Drupal was providing (based on the way I was retrieving) the variable with a dash ('-') when CCK needed it with an underscore ('_').
Cheers,
Deciphered.