I just discovered that the $has_body field was added to node_update_7006(). The problem is that even on a 6.16 (upgrade) version that modules (ie; "quotes" for example) may not have a entry in the {node_type} table, hence, we lose all relevant data. Earlier when running upgrades the quotes body data was stored in {field_data_body} and {field_config_instance} had a entry for the quotes module correctly.

7006 seems to be working perfectly except that it relies on $has_body and we lose all node bodies where $has_body is not found.

It may be broken module code but how many other modules are out there that use {node} for storing body data that does not have a {node_type} entry. Now this could also be a issue that this particular database was a D5 upgraded to D6 and the missing {node_type} entry could be due the D6 upgrade process breaking.

In either case this seems like a major WTF and a D7 beta-blocker.

Comments

int’s picture

int commented
Issue tags: +beta blocker

add beta blocker tag

ctmattice1’s picture

ctmattice1 commented
Priority: Critical » Major
Issue tags: -beta blocker

Think this issue may have already been covered when discussing node_update_7006() with disabled modules.

I went into the site where I upgraded D5.something to D6.16 and checked whether quotes was enabled. It was still disabled so I enabled the module and the {node_type} entry showed up. Took and updated to D7 and everything went as expected with the bodies stored in {filed_body_data} and {field_config_instance} had the quotes entry.

One thing it did do that is/may be covered under a different issue is that it added the quotes navigation menu link to the home page. Kinda surprised me to see a link but then maybe not.

In any case I'll down grade this but still think that edge cases such as someone updating from D5 to D7 may experience something like this but more than likely be extremely rare and is definitely not a beta blocker. The issue still should be looked into though. What if a D5 site wants to migrate to D7 but there is not a D6 module (why they remained with D5 in the first place). Probably doesn't make too much sense to many, however, to those D5 users who migrate, they sure would not want to lose their data. They may decide to rebuild the module, hire it out, what ever. In any case with the main body saved, as a fields_body_data entry, they might also be able to use the fields_ui and get the data to work for them.

At one time it did not matter whether the module in question was enabled or disabled, now that 7006 is working properly, my suggestion would be to go back to storing everything that has a node body. If there is agreement on this I'll make a patch removing the $has_body check. If it's decided to leave it like it is, there should at least be a note in UPGRADE.txt to warn users that this will occur.

chx’s picture

chx commented
Status: Active » Closed (duplicate)

#891028: Orphan node types lose bodies on upgrade