Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I've been asked to look at a site that is undergoing a 5.x upgrade from 4.7.3-ish. The updates executed were from #7 on. Version upgraded from:
// $Id: content.module,v 1.65 2006/07/11 00:18:20 JonBob Exp $
Version updated to was 5.x-1.4, although I've also tried updating to 5.x-1.5 and get the same result.
What's happening is that any field that's single-instanced (specific to only one content type) is coming up with NULL as a value. For example, there's a field_copyright attached to an 'articleop_ed' node type which has no value when an article node is viewed or edited (even though it's a required field, so all article nodes in the system must have a value for this field). On the other hand, all node types share a "field_body_copy", and its content is displayed properly. I've ruled out the theme layer; this is happening during the node_load process.
The values do exist at the database level; if I go into the node_content_articleop_ed table, it has a field_copyright_value field, with the values there.
When I click to view one of these, I get the error:
user warning: Table 'database.content_type_content_articleop_ed' doesn't exist query: SELECT field_copyright_value AS value, field_copyright_format AS format FROM content_type_content_articleop_ed WHERE vid = 6884 in /Applications/MAMP/htdocs/site/includes/database.mysql.inc on line 167.
Going in and manually renaming the table from node_content_articleop_ed to content_type_articleop_ed seems to fix this problem.
The question is, is that an acceptable fix? Why did it get messed up in the first place? I assume this is just a simple namespacing thing with Drupal 5, but wanted to double-check to make sure.
Comments
Comment #1
yched commentedis that (renaming from node_content_articleop_ed to content_type_articleop_ed) an acceptable fix?
Yes, should be. And clear the cache of course ({cache} in 1.4, {cache_content] in 1.5).
One thing to check : the name of the (CCK-managed) content types were content-yourname (prefix 'content' added by CCK)
Those content types are now handled by node.module, but i don't think we automatically removed the 'content' prefix (in order not to break type settings or node templates). Meaning, if I'm not mistaken, and if you did not rename the content type yourself, that the cck data tables should be content_type_content_articleop_ed (CCK now prefixes by-content-type data tables with 'content_type_').
Why did it get messed up in the first place?
Not sure about that. Updating CCK from 4.7 to 5 was a sort of nightmare db-wise. Conflicts with core upgrade functions, then we released 5-1.0, then we had to move the data tables away from the node_* namespace to avoid conflicts with core tables like 'node_access', which led to 5-1.2 (and 5-1.3 as an immediate bugfix...). The db scheme did not move since then.
Providing a clean and smooth upgrade path accounting for all the possible scenarios (upgrade from 5beta, from latest 4.7, from 'old' 4.7...) was really tricky and time consuming, but according to our tests and the activity on the issue queue, I was under the impression that we actually got the thing right (even consolidating a few 4.7 bugs along the way).
Not much time right now (and, frankly, not a killer motivation :-) ) to dive back in this area, so I guess since it seems you managed to get your install right, I'll leave it as is for now and mark as 'fixed' as a support request . We'll see if this gets reported again.
Comment #2
webchickMeaning, if I'm not mistaken, and if you did not rename the content type yourself, that the cck data tables should be content_type_content_articleop_ed
Oops, you're right. I mistyped. That's what I had to rename them to.
Understandable. ;) Thanks a lot for your help!
Comment #3
killes@www.drop.org commentedComment #4
webchickMoving this back to an active bug.... I've now seen this on a second site (seemingly randomly; the upgrade path was working fine yesterday..?), and there was another post about it here: http://www.darcynorman.net/2007/08/14/fun-with-drupal-upgrades/
I might try and allocate some time to figure this out; but either way, I certainly don't expect the CCK maintainers to do so. :)
Comment #5
webchickHm. Still haven't figured out what causes this 100% consistently, but I have a theory:
Let's say you've moved your contrib/custom modules under sites/all. So the first time you run the upgrade, it only does core. So you finish the core update, and then....
- If you hit update.php again directly after to do the rest of the contrib updates (including CCK), it seems to work fine.
- If you hit index.php first and then go back and hit update.php, it seems to fail. Maybe index.php causes some kind of cache clear or something, so CCK starts thinking that it ought to look somewhere else for the tables..?
Comment #6
njehlen commentedI'm having this problem too - i've tried the upgrade (4.7.10 -> 5.5) several times with no luck. In response to #5 - I've run update.php again before going to index.php (i even tried it 3 and 4 times first) but it still doesn't correct the table names. Manually renaming the tables seems to have worked.
Comment #7
Thomas Sewell commentedI ran into the same problem. Renaming the tables fixed it for me as well. I suspect it may have to do with not upgrading to the latest cck in 4.7.X before upgrading to 5.X.
My upgrade process was:
I had a working 4.7 install and also a working 5.X install in another directory. Both were multi-site installs.
Make sure 5.X version of modules was in new sites/all/modules directory. 4.7.X versions were under /modules, not site/all.
Create new db and set permissions, disable cron job
switch to offline mode
disable contributed modules
switch to default theme
mysqldump old database
Copy old sites/ directory to drupal5 install. Copy old files directory as well.
backup settings.php, copy default 5.X settings.php, fix db connect and other entries in settings.php
source backup db sql file into new db.
change apache files to point to new doc root for site.
apachectl restart
activate disabled modules
update.php
Testing at this point showed that table and list views didn't display any results from custom content types. This was fixed by renaming tables manually as above.
upgrade and activate custom theme and test
activate custom modules that I've created
reindex search
run cron
test search
take site out of maintenance
re-enable cron job
Old content module version in 4.7.X: content.module,v 1.56.2.49 2007/03/05 22:10:52
New version in the 5.X upgraded site: content.module,v 1.90.2.49 2008/03/03 00:02:47
Error message encountered:
Comment #8
karens commentedThe D5 version is no longer being supported. Sorry.