|Drupal 7 Problem - corrupted content type?|
comment body won't display
| 8:05 pm on Jan 7, 2012 (gmt 0)|
I have a thorny Drupal problem and I just can't figure it out. Looking for any ideas. This is long. I'm about to try your patience... Mine is past trying. It's gone!
I have about five content types and all have a the main comment stored in the comment_body field. This is an import of the site from Drupal 6, but since the import almost entirely failed, it is actually a lot of manual importing into the DB and a lot of simply recreating nodes.
All behave as expected except for one content type where the comment body does not show. The title, excerpted from the body shows, but the data does not. If I add a new field, nothing at all from that field shows, regardless of whether it comes first or second in the Comment Fields listing.
This content type is missing the author and subject fields when I look at the Comment Fields tab. In the other content types, if the author and subject fields are present, they are customizable (you have "edit" and "delete" links), which is not normal for Drupal 7 comments.
I also have an older version where the comment body does show on the offending content type, but all the other problems with the other content types are present.
I've ruled a lot of stuff out.
1. It's not a theme issue. It's a database issue.
I've tried this in Bartik, Stark and Seven and the theme makes no difference.
I took the functioning backup and the working version and did a complete diff for any differences in any files and there are none. The files are identical except for the database declaration. So it's the database.
2. It's not just a display problem. The data is missing in the outuput.
When I look at the devel /render output, the comment body shows that in other content types there's an array element for (where 2070 is the comment number):
$array['comments']['comments']['2070']['comment_body'] and that element contains 16 elements.
In the content type that has problems, this is entirely missing. So somehow it is not getting rendered at all.
When I look in the DB, the data is there. When I edit the comment, the data is there. But when I preview or look at the comment on the page, all I get is the title.
The really strange part
I used the Bundle Copy module to duplicate the 'trail' content type. I then renamed it 'trail2' and used the Node Convert module to convert the 'trail' nodes to 'trail2' nodes. Voilą! The comment bodies are back! I clear the caches, run cron and all that and they're still there.
Then I delete the old, unused 'trail' content type and all the 'trail2' comment bodies disappear. Poof! Gone. Still in the DB, but no longer display.
I've been making minor changes to isolate this and then dumping the DB and running a diff on the DB to see if I can find anything odd in the changes that would explain this, and I just can't find anything.
compared all the settings to those of content types where it works.
compared the fields in the field_config_instance table against functioning content types.
compared the field_config, field_config_instance, comments, field_data_comment_body, variable tables before and after deleting the 'trail' content type to see why this would affect 'trails2' comment display.
set the `data` BLOB for the offending content type to equal that of a content type that is working
Now I'm faced with
a. Having 10 content types. Five that work and Five that don't, and if I accidently delete one of the non-working ones, the working one goes bad too.
b. using various export/import modules and laboriously moving things to a new site and seeing where the fail point is, but this will involve a lot of manual work, since some things don't have good export/import options.
Anyone with good ideas... I'd love to hear them.
| 2:53 pm on Jan 10, 2012 (gmt 0)|
Did you compare the database definitions? What changed, charset or collation? Or both?
| 9:45 pm on Jan 10, 2012 (gmt 0)|
Coop, full diffs on every incremental change. The only changes in the definitions were a couple of tables where the auto increment value was changed. Otherwise, minor data changes.
I think I've given up and moved on. Next step, recreate the structure and import data in chunks as small as I can make them without breaking relationships and try to either get all data in (problem remains a mystery, but I'm over it) or I isolate where the problem is coming in.
| 9:58 pm on Jan 10, 2012 (gmt 0)|
When you said "content type" I thought you were referring to charset and collation, such as the default configuration for MySQL (latin1/latin1_swedish_ci) versus say, utf8. Some of the database transitions I have performed over the years this has been a stickler. So I guess that is what I was alluding to and thought perhaps you could check.
| 5:03 am on Jan 11, 2012 (gmt 0)|
Nope... I mean "content type" in Drupalspeak - a user-defined structured data page.
So MySQL doesn't think the data is corrupt in any way. Looks fine. Acts fine. But that perfectly fine data, when interpreted by Drupal, gives unexpected results.
| 4:10 pm on Jan 12, 2012 (gmt 0)|
Ah, understood. Ignore my responses then, I was talking non-Drupalspeak :P
| 6:04 pm on Jan 12, 2012 (gmt 0)|
Moot question now. I simply started with a clean slate, imported data in the smallest chunks possible (i.e. clusters of related tables), until I had everything I wanted in the new site. Never did find out what setting was causing it, since I imported almost the entire DB.
Pain in the butt. I could have done it in one fifth the time, but I did really want to understand the cause. I think you understand this coopster.
| 3:25 am on Feb 3, 2012 (gmt 0)|
Oh yes, I understand ... every time I am contracted to touch a CMS like Drupal ... WP ... Joomla ... :)
| 4:31 am on Jun 15, 2012 (gmt 0)|
Hi ergo, did you solve your problem? I have some suggestions.
Avoid importing Database to database, try to export data as CVS and then import as CVS into the database checking the fields, very carefully. Remember the "version-sdfasdf" for every imported data, it seems like a dupp almost... and empty the cache from the database.
Recently I discover it is better to do this from the DB (admin) than directly from the "clear cache" under drupal, it missed a lot of things when importing data.
What I mean is creat site from scratch and re create the content types at hand, just do the data import.
I would suggest serving all your data as RSS (full rss) on your old site and then importing the RSS into the new Drupal7 site, it can be done, I did it (other thread) I just had problems with the preview images but that's something different. The FEEDS module can import the images automatically.
I just had an issue, during the days I was doing this over and over there was an upgrade both for the module and core... it never worked again! but I can tell you it can be done. I really prefer my custom CMS made by me :) but if I have to use something else I always go after Drupal, Wordpress is my third option (drupal is the 1st and second) but I always avoid import-export, I always start from scratch creating everything at hand, except from the data import.
| 2:42 am on Jun 18, 2012 (gmt 0)|
Hi explorador - I did solve the problem using the brute force method mentioned above. Thanks for asking though.
In my case, there wasn't really an "old site" in any meaningful sense. I was trying to get data from Drupal 6 + Gallery into just Drupal 7... so I was doing a lot of manual stuff on the DB. Never did figure out the actual source of the problem, but sometimes it's less time to cut your losses and go back to a more manual approach.