older,one table:
CREATE TABLE files (
fid int(10) unsigned NOT NULL default '0',
nid int(10) unsigned NOT NULL default '0',
vid int(10) unsigned NOT NULL default '0',
filename varchar(255) NOT NULL default '',
description varchar(255) NOT NULL default '',
filepath varchar(255) NOT NULL default '',
filemime varchar(255) NOT NULL default '',
filesize int(10) unsigned NOT NULL default '0',
list tinyint(1) unsigned NOT NULL default '0',
KEY vid (vid),
KEY fid (fid)
) TYPE=MyISAM
/*!40100 DEFAULT CHARACTER SET utf8 */ ;
now,two tables:
CREATE TABLE files (
fid int(10) unsigned NOT NULL default 0,
nid int(10) unsigned NOT NULL default 0,
filename varchar(255) NOT NULL default '',
filepath varchar(255) NOT NULL default '',
filemime varchar(255) NOT NULL default '',
filesize int(10) unsigned NOT NULL default 0,
PRIMARY KEY (fid)
) TYPE=MyISAM
/*!40100 DEFAULT CHARACTER SET utf8 */ ;
--
-- Table structure for table 'file_revisions'
--
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(1) unsigned NOT NULL default 0,
PRIMARY KEY (fid, vid)
) TYPE=MyISAM
/*!40100 DEFAULT CHARACTER SET utf8 */ ;
IMAGE patch:
find this function :
function _image_insert($nid, $label, $image) {
$dest = _image_filename(basename($image));
if (file_copy($image, $dest)) {
$info = image_get_info(file_create_path($dest));
$file->filename = $label;
$file->filepath = _image_filename(basename($image));
$file->filemime = $info['mime_type'];
$file->filesize = filesize(file_create_path($dest));
$fid = db_next_id('{files}_fid');
db_query("INSERT INTO {files} (fid, nid, filename, filepath, filemime, filesize,list) VALUES (%d, %d, '%s', '%s', '%s', '%s',d%)",
$fid, $nid, $file->filename, $file->filepath, $file->filemime, $file->filesize,0);
}
}
editor:
function _image_insert($nid, $label, $image) {
$dest = _image_filename(basename($image));
if (file_copy($image, $dest)) {
$info = image_get_info(file_create_path($dest));
$file->filename = $label;
$file->filepath = _image_filename(basename($image));
$file->filemime = $info['mime_type'];
$file->filesize = filesize(file_create_path($dest));
$fid = db_next_id('{files}_fid');
db_query("INSERT INTO {files} (fid, nid, filename, filepath, filemime, filesize) VALUES (%d, %d, '%s', '%s', '%s', '%s')",
$fid, $nid, $file->filename, $file->filepath, $file->filemime, $file->filesize);//don't insert LIST column
}
}
Comments
Comment #1
Egon Bianchet commentedRolled a quick patch for this. Howerver I'm changing the status to "code needs review" because I suspect there could be other things to fix.
Comment #2
walkah commentedconfirming this issue... will get it cleaned up ASAP.
Comment #3
polThanks walkah for your time into that marvellous module...
I hope it get fixed soon.
Comment #4
john.money commented+1 on file table patch
Works. :)
Comment #5
walkah commentedyes, this patch works, in that it doesn't spit out an error anymore... but it's not properly using the file revisions.
i'm working on an improved patch that will actually allow for versioned images. (huzzah)
Comment #6
DaveNotik commentedCan I use the temporary patch and then have no issues applying the improved patch when it's released?
I have a site I upgraded to CVS and I'd like to quash image.module errors as it's live. :)
Thanks!
Comment #7
tfejos commentedThe patch works for me also. (with latest HEAD version)
Comment #8
wpd commentedWorked for my with CVS HEAD, but I want to follow the final solution.
Comment #9
buddaAny progress on the official revisions version of the patch/fix at all?
Comment #10
bryan kennedy commentedJust so everyone is clear, this does fix the display and creation of images if you are in a pinch. It does not fix the revision problem but at least you can get your images to show up at all. I will see if I can put together a patch for adding the data to the file_revisions table this weekend.
Comment #11
buddaNice one Bryan, any progress over the weekend for it?
Comment #12
mgiffordYeah, patch worked for me.. I can start using images again now.. I just got this one warning which I thought I'd bring up:
warning: Invalid argument supplied for foreach() in /home/dm7/modules/upload.module on line 432.
I don't like warnings.. But like this patch, thanks!
Mike
Comment #13
inteja commentedI think there's another related problem with image.module that this patch doesn't fix.
I migrated from 4.6 to 4.7b6. I have 3 galleries each with digicam photos with default filenames like DSC00001.jpg, DSC00002.jpg etc. Each gallery was created independently from a new batch of photos, so on upload (I recall using image_import.module) I guess these deafult filenames must've been renamed if duplicates were encountered, e.g. duplicate DSC00001.jpg became DSC00001_1.jpg etc.
But now after upgrading to 4.7b6 when I go to an image gallery thumbnail page, these duplicates like DSC00001_1.jpg are displayed as the original full-size and not the thumbnail or preview, even though they exist both in the files/images folder and are referenced correctly in the files database table.
Comment #14
Freso commented+1 from me as well. Nice to get rid of those pesky SQL errors in the log. :)
Comment #15
decafdennis commentedThe provided patch is a temporary fix, but by far not enough to completely solve this issue. As I sort of discussed with chx and moshe, the module needs a rewrite, at least the database part of it. The current usage of the files table gives issues when the upload module is enabled.
Comment #16
walkah commentedi'm not in favour of the suggested rewrite. imo, the conflict with upload.module is a shortcoming of drupal's file handling - which i believe should be centralized. regardless of where you stand on the file as nodes or not debate, drupal can definitely benefit from centralized file pointers (which is all {files} really is).
that said - for 4.7 we can either:
a) make image.module depend on (and utilize) upload.module
OR
b) make image.module "conflict" with upload.module for $node->type == image. i.e. either give a warning or actually disable upload.module for image node types.
I'm inclined to go with b)
And for 4.8 - drupal will have a central file handling API that does things right. so help me! ;)
Comment #17
decafdennis commentedYes indeed b) seems the best solution. Since this issue is assigned to you, are you going to write a patch? As I made clear before, I'm willing to do it as well.
It'll be so awesome if Drupal would have a good File API! Too bad we've got to wait for it a little longer.
Comment #18
decafdennis commentedI'll do it. (Solution b.)
Comment #19
decafdennis commentedI think this patch should do it. It removes the 'Attachments' field from the image node type settings form, and
_image_check_settingsmakes sure that attachments are always disabled. The module is now able to use the files table without upload module interfering. I completely ignored the file_revisions table, since its only used by the upload.module anyway.I'm not sure, but this patch should not pose any problems for 4.6 users that want to upgrade.
Comment #20
decafdennis commentedAttaching the patch file would be nice...
Comment #21
timgam commentedAttempted to patch the cvs version of image.module with naquah's image-files.patch. Hunk #3 fails. Am I doing something wrong?
Comment #22
decafdennis commentedYes you're right. I probably created the patch using an already patched image.module. I can't do that right now, but I will submit a new patch as soon as possible.
Comment #23
decafdennis commentedSorry it took a me a few days, but here it is. I redid the patch a bit, and added a good hook_file_download implementation with node access check (only used if upload module is completely disabled). It should apply to HEAD (r1.195).
Please test & review. Thanks.
Comment #24
praseodym commentedPatch looks good, +1.
Comment #25
walkah commentednaquah - #23 looks like it undoes the file_revisions stuff at the end of the patch... do you have good reason for this?
Also - I'd love to hear some feedback from people if they think there should be warning or notice that upload has been disabled automatically for image nodes. IMO, it needs to be documented somewhere - who's got a suggestion?
Comment #26
Egon Bianchet commentedwalkah: maybe a notice in
admin/settings/content-types/imagewould be useful.Comment #27
decafdennis commentedA notice can be easily arranged, just by adding #markup to the form.
Yes, it does not put anything in the file_revisions table. Why bother? The upload module doesn't use it (because attachments are disabled for images), and the image module has no use for it either.
Comment #28
decafdennis commentedUpdated patch; added a notice to
admin/settings/content-types/imagelike Egon suggested.Comment #29
Egon Bianchet commentedTested: works for me.
Comment #30
Rosamunda commentedSorry to bother with this simple issue... but could anyone add this patch to the original version?
I don´t know how to patch a Module.
I´ve read a good explanation, and other one... but with no luck.
I even tried to read the Patch Handbook... with no luck (didn´t get a thing).
Please, could anyone help this poor silly newbie with this simple task?
Thanks !!!
Rosamunda :-)
Comment #31
decafdennis commentedHere y'are.
It would be better though if you found out how to patch files in Windows. I can't really help you with that, because I never tried it. I recently bought my first Mac and then it works right out of the box :) I think the best you can try is install Cygwin (http://www.cygwin.com) by reading the instructions. Then you'll have the GNU
diffandpatchcommands available like in *nix.Btw don't forget to reply about whether this patch works OK for you or not.
Comment #32
decafdennis commentedI just found out that the
hook_file_downloadfunction in the patch provided above seems to break new images in node previews under some conditions. When I get home I'll alter the patch so the function allows downloading images from theimages/tempfolder whenuser_access('create images') == TRUE.Comment #33
decafdennis commentedSee comment above.
Comment #34
mrmachine commentedI am using this patch against Drupal HEAD, and things seemed to be going ok ... but I'm beginning to think that there is some sort of conflict with the Forum module: While I can create containers and forums, whenever i post to them, they only get added as a node, and don't show up in the forums. Then I noticed that the forums and containers I was adding were also appearing in the Image Gallery drop-down taxonomy menu ... they seem to be getting mixed ...
Can anyone else test this?
(my bug-report on the forum.module: http://drupal.org/node/60223)
Comment #35
decafdennis commentedI am 99% sure this has something to do with taxonomy, not with this patch. See my follow up at http://drupal.org/node/60223.
Comment #36
Rosamunda commentedThanks! Sorry for the delay!!!!!
I´m gonna try it and try to learn how to patch... hehe
:-)
Comment #37
decafdennis commentedComment #38
Mago@magodiozio.org commentedOk, I'm a newbie and I'm sorry to bother too....but, I replaced the original module in image directory with naquah's image_4.module, deleted the old one, and renamed the new module: "image.module".
My drupal installation immediately collapsed. It gave me an error like:
Fatal error: Cannot redeclare theme_image_gallery() (previously declared in /modules/image/image_4.module:643) in /modules/image/contrib/image_gallery/image_gallery.module on line 304
Could anyone explain me, please, how to install the patched module? I apologize for such a stupid question (and for my English), but I'm beginning to being frustrated... :-)
Thank you
Mago
Comment #39
decafdennis commentedPatch does not work anymore for latest CVS because the image module's gallery functionality was split unannounced.
Comment #40
mrmachine commentedI used this patch with the 4.7 release candidates, but was never able to get it to work, due to other issues with taxonomy. I am now using 4.7.2, and the latest 4.7 image module, have done the update.php (including putting the Image_update.php in root directory and running it), but am still not able to upload a picture. I'm pretty sure the problem is a result of some of the SQL changes in this patch?! I've reached a dead-end in my investigations of the SQL tables (i've been comparing the tables with a clean install of Drupal and Image module).
When i try to upload an image, it seems to be transferred from my machine, but doesn't show up in /files/images or /files/images/temp. The node is added, but the picture doesn't show up, and I get these messages:
Also, while the image doesn't appear in the appropriate folders, I've noticed that there are empty files in /files/images called
Can anyone untangle this mess I've created? I really want to use the image module :(
Comment #41
Hetta commentedDrupal 4.7.2? Obsolete to the current image HEAD. No comments since June 2006? Obsolete, I'd say. (Cleaning up the image issues queue)