I'll do my best to describe what I encountered and how I resolved it.

First, I had an issue where I was attempting to create a node via node_save and CCK was only reporting ...
user warning: in \sites\all\modules\contrib\cck\content.module on line 1099
in rc7 and in dev, I'm getting it on ...
user warning: in \sites\all\modules\contrib\cck\content.module on line 1141

I eventually notice a pattern wherein the records affected appeared to use "special characters" capatured from a non-UTF-8 data source. IT was going to be stored in a LONGTEXT field in the content_type table created by CCK. After discovering that, I ran the suspect data through mb_convert_encoding and converted it to UTF-8 and then errors went away. I'm not sure if this is a bug with my code or with CCK, but figured I'd go ahead and share as best I could.

See also:
http://drupal.org/node/308333#comment-1022892

Comments

yched’s picture

yched commented
Status: Active » Postponed (maintainer needs more info)

Are you sure your database and all the tables use the charset utf8_general_ci ?
"capatured from a non-UTF-8 data source" : meaning ? you copy / paste it into the node form's text inputs ?
Also, it's really strange that you don't get any actual error message, only line numbers.

matt_paz’s picture

matt_paz commented

> Are you sure your database and all the tables use the charset utf8_general_ci ?
Yes, the charset is UTF8 and the collation is utf8_general_ci

> meaning ? you copy / paste it into the node form's text inputs ?
No, meaning I'm automatically capturing the data from CURL and then using node_save($my_new_node)

> Also, it's really strange that you don't get any actual error message, only line numbers.
That's what I thought too ... perhaps it is worth mentioning that this is occurring on a dev server using IIS/FastCGI?

yched’s picture

yched commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

I do think that if you give node_save() a hardcoded, UFT8 string constant, it will be saved normally.
I guess you should look into the curl settings and check the encoding used for the connection.
Anyway, not something for CCK to fix.

matt_paz’s picture

matt_paz commented

10-4 ... at least I know now ... I do wonder, however, if it might be worth considering how/why this occurred and if cck might be able to become a little more fault tolerant in a similar situation. Perhaps not ... CCK is already a brilliant module and I know it has its necessary overhead ... and perhaps extra error handling or content-encoding isn't necessary... especially if it would normally be handled further upstream through normal form processing. Thanks for the feedback either way!!