upgrading to drupal6 makes image-6.x-1-x-dev a dull boy
ThePeach - February 9, 2008 - 23:08
| Project: | Image |
| Version: | 6.x-1.x-dev |
| Component: | image.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
I'm testing the upgrade to drupal 6 and a parallel switch to a new hosting which is using php5 instead of php4.
To accomplish this I've first upgraded image module to latest 5.x-1.x-dev version then upgraded the whole site to drupal6 and also the image module.
after running update.php I have those two errors:
* user warning: Unknown column 'f.nid' in 'field list' query: INSERT INTO image SELECT DISTINCT f.nid, f.fid, f.filename FROM files f INNER JOIN node n ON f.nid = n.nid WHERE n.type='image' AND f.filename IN ('_original', 'thumbnail', 'preview') in /home/peach/public_html/mysite/sites/all/modules/image/image.install on line 252.
* user warning: Table 'smartart.file_revisions' doesn't exist query: DELETE FROM file_revisions WHERE EXISTS (SELECT * FROM image WHERE image.fid = file_revisions.fid) in /home/peach/public_html/mysite/sites/all/modules/image/image.install on line 255.and from the queries I have only this warning:
image module
Update #5200
* CREATE TABLE {image} ( `nid` INTEGER UNSIGNED NOT NULL, `fid` INTEGER UNSIGNED NOT NULL, `image_size` VARCHAR(32) NOT NULL, PRIMARY KEY (`nid`, `image_size`), INDEX image_fid(`fid`) ) /*!40100 DEFAULT CHARACTER SET utf8 */;
* Failed: INSERT INTO {image} SELECT DISTINCT f.nid, f.fid, f.filename FROM {files} f INNER JOIN {node} n ON f.nid = n.nid WHERE n.type='image' AND f.filename IN ('_original', 'thumbnail', 'preview')
* Failed: DELETE FROM {file_revisions} WHERE EXISTS (SELECT * FROM {image} WHERE {image}.fid = {file_revisions}.fid)the result is that the gallery doesen't display any image (maybe because of the image table empty?)

#1
this is really a duplicate of http://drupal.org/node/217515 but this has a better description of the problem so i'm marking that as the dupe.
#2
ok, I just went on trying to figure out what is happening, I tried to restart from a safe point the upgrade, and it gave me a different error. First this:
An error occurred. http://localhost/update.php?id=1&op=doFatal error: Call to undefined function image_get_sizes() in /home/peach/public_html/mysite/sites/all/modules/image/image.install on line 250
and then:
The update process was aborted prematurely while running update #5200 in image.module.also I noticed this:
Update #6022
# ALTER TABLE {file_revisions} RENAME TO {upload}
I'm going to try again... maybe :-\
#3
Probably the same problem without any host change. This was rather a new install -- started as 5.6.
Errors during update:
Table 'dbname.file_revisions' doesn't exist query: DELETE FROM file_revisions WHERE EXISTS (SELECT * FROM image WHERE image.fid = file_revisions.fid) in/.../www/sites/all/modules/image/image.install on line 255.Unknown column 'f.nid' in 'field list' query: INSERT INTO image SELECT DISTINCT f.nid, f.fid, f.filename FROM files f INNER JOIN node n ON f.nid = n.nid WHERE n.type='image' AND f.filename IN ('_original', 'thumbnail', 'preview') in /.../www/sites/all/modules/image/image.install on line 252.There are warnings about directories not existing when trying to set default path or edit image; no image is visible. Gallery structure, captions, etc. are preserved. Database after the update has 'files' table (fid, uid, filename/path/mime/size, status, timestamp) with seemingly correct data (file paths, uids, ...) and empty 'image' and 'image_attach' tables. There is no 'file_revisions' table.
Current directory structure is: www/files/images, drupal's 'File system path' is set to 'files' (that's correct) and 'Default image path' is set to 'images' (that's correct too, but not changeable in the current state). Database paths in the 'files' table look like: 'files/images/name.png'.
#4
After uninstalling and reenabling all works fine (you have to recreate all the galeries for that) , the only difference i can see is that 'image' table got populated with some data: fids from 'files' table, 'nids' i don't know from where and 'image_size' equal to '_original' in every row. Should be easy enough to make such a query manually.
Note: for removing the module i did: disable, uninstall and remove by hand all rows from files table concerning images (that's easy to filter too if you know a bit of sql).
#5
Check these for troubles with MySQL < 4.1: http://drupal.org/node/208785
and this for troubles with a pre-existing image table: http://drupal.org/node/235227
Dunno where the file_revisions table should have been added; have you tried a new install of drupal 5 or 6 for that, instead of an upgrade? (If it's still a problem with the new install, you should open an issue in core.)
Anyhow, the table data for file_revisions, for MySQL, is:
CREATE TABLE `file_revisions` (`fid` int(10) unsigned NOT NULL default '0',
`vid` int(10) unsigned NOT NULL default '0',
`description` varchar(255) NOT NULL default '',
`list` tinyint(3) unsigned NOT NULL default '0',
PRIMARY KEY (`fid`,`vid`),
KEY `vid` (`vid`)
) DEFAULT CHARSET=utf8;
Luck!
#6
Thank you for your answer.
I think i may have found another source of this (MySQL 5.0.44, it was a clean install of 5.6, so i believe that's something new).
Seems the 'file_revisions' table is renamed to 'upload' in 6.x (see http://api.drupal.org/api/function/system_update_6022/6). You run the system update before the modules updates, so the table will be probably already renamed when the module updates.
There's also a comment in the source saying that only the upload is supposed to use this table, but i don't know if that matters. Anyway, I've just checked that I don't have 'file_revisions' neither in the upgraded one nor in an almost fresh 6.x install and yet all works fine (but I did have it in 5.6).
#7
Hi all!
While upgrading my Drupal 5.7 to Drupal 6.2 I also got some errors.
An error occurred. http://domain.tld/update.php?id=3&op=do <br /> Fatal error: Call to undefined function image_get_sizes() in /home/name/www/drupal-6.0/sites/all/modules/image/image.install on line 250To fix that I had to add
include('image.module')on top of image.install file.To fix that I had to replace the line
$ret[] = update_sql("INSERT INTO {image} SELECT DISTINCT f.nid, f.fid, f.filename FROM {files} f INNER JOIN {node} n ON f.nid = n.nid WHERE n.type='image' AND f.filename". $cond);with this line:
$ret[] = update_sql("INSERT INTO {image} SELECT DISTINCT u.nid, f.fid, f.filename FROM {files} f INNER JOIN {upload} u ON f.fid = u.fid where f.filename". $cond);and line
$ret[] = update_sql("DELETE FROM {file_revisions} WHERE EXISTS (SELECT * FROM {image} WHERE {image}.fid = {file_revisions}.fid)");with line
$ret[] = update_sql("DELETE FROM {upload} WHERE EXISTS (SELECT * FROM {image} WHERE {image}.fid = {upload}.fid)");include('image.module')from file image.installI don't know if this is the 100 % correct way of how to do it, but I see all images and everything is fine ... hmmm all? ... there was small village of indomitable Gauls ...
Anyway: Currently I can not select the image gallery to which an image belongs. While using Drupal 5.x there was an image gallery field in the taxonomy section (now called vocabularies) but after upgrading to Drupal 6.2 I see there only the taxonomies but no combobox for the galleries. I also found no information in the database where this relationship (which image belongs to which gallery) has been saved.
Suprisingly the gallery is working, but I can not change the relationship between image an gallery.
But maybe that topic is also denoted to the alpha state of this module.
Many thanks and good luck.
#8
I've had similar problems and am following this closely.
Shai
#9
I've upgraded from a 5.2 to 6.2, with same problems. I applied the suggestions of max9 at comment #9 and seems resolved them! Many thx! :-)
#10
Hi fulvioz!
You are welcome.
In the meantime I solved the problem, that I could not select the image gallery an image belongs to. That happens only because the taxonomy/category forgets the association to the image-type. To solve that go to 'Administer > Contentmanagement > Categories' click on 'edit vocabulary' of the vocabulary(s) with the type 'image' and check there 'Image' under the section 'Types'. That's it! Now, you can associate an image with a gallery on the edit page of an image.
You may have the same problem.
I also had that problem after updating from Drupal 5.2 to 5.7 and at the same time I updated the image module to 5.x-1.8 (don't know the previous version). Of course, it also happend while updating Drupal 5.2 to 6.2 with the necessary update of the image-module.
Good luck
#11
Hi all,
a newbie here.
I read the thread with interest. My situation is that I am not a techie really, and am waiting for an upgrade procedure that ensures smooth upgrade from Drupal 5.x to 6.x with Image module upgrade, whilst keep all previous galleries, images etc in tact.Does anyone know if there will be an upgrade path provided soon please?
I have raised this in a support request ( http://drupal.org/node/246512 )
thanks
Mark
#12
Hi Mark,
There will certainly be an upgrade path for the Image module that will not require patching or other super-geeky activities. You just have to be patient.
I came to Drupal as a non-techy. One thing I've realized about this whole open-source adventure is that identifying oneself as a "geek-in-training" as opposed to a "non-geek" helps one to be a more a part of the community and ends up getting you more help from the techies. "Geek-in-training" doesn't have to communicate a professional goal. Identifying as such does, however, communicate an openness to learning new things that will certainly earn you "points" with the coders in this community.
Offering to help with documentation or testing can also communicate to the people who are actually upgrading the code that the people "waiting in line" for the code are willing to help out where they can.
At this point, patience is your biggest asset. D6 was released in February. I'm not planning to launch any D6 sites until Sept. or Oct. so that I give plenty of time for the module upgrades to happen. If you plan for that and your expectations are in line, then not having various modules ready won't feel so disconcerting. FYI, I thought I was ready to relaunch my blog in D6 when I saw that the image module had been upgraded, but decided against that when I saw that the image module upgrade isn't really done yet. I haven't even considered launching new sites that I build for people or upgrading existing sites that I've built in D6.
I hope this helps, and I hope you don't get too frustrated by all this. When you learn how to navigate this process, you can leverage an amazing tool and have fun with the community.
Sincerely,
Shai Gluskin
http://content2zero.com
#13
Hi Shai,
I agree with you there. I need to be more patient. With such a great tool as Drupal it's like having a new toy to play with every day.
I shall just have to sit and wait patiently won't I.
I have 2 sites which I use for family members. One is using Drupal 5 and the other Drupal 6. I have about half a dozen other modules installed, including Image and SMF Forum. Maybe I missed it, but there was no preparation for the sudden pulling of the SMFForum module. Rather a shame, since I invested quite a bit of time on it! I think there's a valuable lesson there.
But back to Drupal and Image module. It's wonderful and my users love the galleries, and posting image nodes, in both sites.
So I shall wait patiently for the upgrade path before upgrading from Drupal 5 to 6. I shall enjoy both sites in the meantime.
Regarding the other advice, yes, indeed I agree, and have offered to test any new versions.
Always willing to do so in order to help the developers.
Thanks for your advice.
Mark
#14
subscribing
#15
ok.. i ran into the same issue. after upgrading from 5.x to 6.2 all my images were gone. I had same SQL errors during the upgrade as #3 had. Here is a "magic" query to rebuild the image table which got messed up during the upgrade:
insert into image select upload.nid as nid , files.fid as fid , filename as image_size from upload, files where upload.fid = files.fid and files.filemime like "image/%";Note: this query is meant to be executed after the upgrade to 6.x with errors in the image upgrade part - not before!
Cheers!
Paul.
#16
Thank you for that concise solution to my problem, Paul.
-Jeff