unanswered question

As of January 2010, I have no answer to the problem – but suddenly have no problem, either. In the kind of unsatisfying conclusion that happens time and again, I find that I can now change all affected sites to Public download, and even enable optimization of CSS and Javascript at Administer » Site configuration » Performance (which was the point of it all). After doing so, images display normally – even though the images still have the screwy addresses, like http://www.site.com/sites/site.com/files/images/image.png, that earlier resulted only in "image broken" placeholders.

That's if I'm logged in. If not logged in, image addresses have the nice expected form http://www.site.com/system/files/images/image.png. Can't these images make up their minds? But either way, they seem to display just fine.

So, what gives? I can't say. I don't recall making any major changes to the system that would affect this; perhaps it was simply an upgrade to the Image module somewhere between then and now (I'm currently running 6.x-1.0-alpha4).

If you've had this same problem, all I can suggest is trying the change from Private to Public again, especially if you've made any changes to Drupal or modules recently. Who knows, it just may suddenly work. 

This plea of mine on the Drupal.org forums got no response but the dolorous sigh of a forsaken wind. Just as I was about to retreat to bitter existence's sole comforting shoulder – I'll always be there for you too, Wild Turkey – the kindly and knowledgeable GR stepped in by email with ideas.

I headed to phpMyAdmin (which used to scare me but I'm better now, thank you), called up my donor database that held the Book captive, and used this SQL command:

select * from 'node' where type='book' 

which selects all records from the node table, of type 'book'. I exported the results into a file.

Then I went to the hot-with-anticipation recipient database and attempted to import the file. The returned message started as follows:

INSERT INTO `node` ( `nid` , `vid` , `type` , `title` , `uid` ,
`status` , `created` , `changed` , `comment` , `promote` ,
`moderate` , `sticky` )
VALUES ( 13, 13, 'book', 'Understanding These Instructions', 1, 1,
1168408293, 1188227828, 2, 0, 0, 0 ) ,...

... and so on, for 40 or so book records within VALUES. But it then all failed with the error:

#1062 - Duplicate entry '13-13' for key 1

Apparently, the first record, which has nid (node ID) 13 and vid (version ID) 13, ran up against an existing node that also has nid 13 and vid 13. Like two Jean-Claude Van Dammes in Timecop, these cannot exist in the same place at the same time without results most distressing.

Interestingly, the clash didn't involve any existing Book nodes, as the site in question (this one!) had no Book nodes. So the existing node fervently laying claim to nid/vid 13 wasn't a Book node, but apparently that makes no difference.

I figured that I needed some way to change the nid/vid numbers of the old Book nodes before exporting them. Back to the donor site's database. GR helped out with the SQL here:

update node_revisions set nid=nid + 1000000 where nid in (select nid from node where type='book');

then

update node set nid=nid + 1000000 where type='book' 

(I like the audacity of the numbers! Works for me: if we're going to artificially boost the ID numbers, let's kick the buggers up into the bloody ionosphere.)

That done, I went and did the same for vid too (replace nid with vid in the above). And once again,

select * from 'node' where type='book' 

and export.

GR reminded me that I need to export and import not just from the nodes table, but from the node_revision table as well. So I did the same updating of nid/vid within that table, then the export procedure, all replacing node with node_revision.

Next up: you guessed it, head to the recipient database and import my files containing the above exports.

Solved?

Alas... things weren't quite licked. The nodes didn't function properly as Book nodes. They showed up as content, but the imported Book structure didn't show up in any way under admin/content/book. And when editing or creating a Book node, none of my imported Book nodes showed up under the drop-down Parent field – i.e., there wasn't a way to recreate the actual structure of the book. The nodes were there, but they weren't right. ("The nodes are sour", a crusty Maine character might deliver in a Stephen King yarn.)

Well, around there I cheated, and brought over my Book the really old-fashioned way: cut'n'paste from the donor site into fresh new Book nodes on the recipient site. (Those are, by the way, the Easy Drupal Admin Manual.) I had a lot of editing in store for each node anyway, so a one-step mass import wasn't an utmost requirement. Still, a chagrined Ace I am.

Sleuthster GR suggests that I left a third vital table out of the process: the books table, which also needs its nids/vids changed, and its content exported and imported, like the other tables above. Hmm, a table called books... that does sound suspiciously important to the task at hand. Chagrined and red-cheeked I am.

That extra step may have done the deed, but I had already embarked upon my more Luddite methods, and since then have not had cause to attempt a fresh export and import of a Book. So I'm going to leave this one an Unanswered Question for now, simply because I can't yet verify the whole proper process. But I hope this tale, and GR's assistance, will help someone else complete the task. Please write in if you have experience or ideas here!

Another method?

The helpful boris-doesborg suggests here two modules that may provide a solution:

http://drupal.org/project/importexportapi
and
http://drupal.org/project/node_import

I don't have need or opportunity to experiment with these now, but if anyone out there does, please report!