I am upgrading my site from 4.5 to 4.6. I am having problems importing old images into my new site. Note that the new site is located in a different DocumentRoot directory than the old site. Also note that my new site shares its code base with other sites. It is located in /drupal_root/sites/new.com.
I tried the following to import the old images into the new site:
1) I copied the directory containing my images from the old site, located at /drupal_root/images, to the following three places in the new site's directory:
a) /drupal_root/images
b) /drupal_root/sites/new.com/files/images
c) /drupal_root/sites/new.com/images
2) I set permissions to each of the directories to allow the web server to write to them
3) I ran the update-image.php script, once for each of the three image directory locations listed in above
The update-image.php script did not work on any of the three times I ran it. When I visit the home page of the site immediate after I run the script, I see a long list of "File copy failed" errors. And when I look in the /drupal_root/sites/new.com/files/images directory, I see a ton of files with 0 bytes each named files_xxx where 'xxx' is a number.
I'm not sure if I'm doing something wrong or what. Can someone please help?
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | images4.png | 4.63 KB | Capnj |
Comments
Comment #1
Capnj commentedMe too, with additional question about multi-site handling. I will have 5 sites running from the same core installation. If 'images' is set relative to 'files' in ./drupal/files --- and if I have site1, site2, etc and each has images ... how are they going to be kept separate?
I created a directory /drupal/files.site1 and made that my file system path. When I enabled the image module, it created the subdirectories under files.site1 --- and when I run the upgrade script I get the same behavioir as Nysus did ... with the 0 byte files created in /drupal/files.site1/images/
One interestng thing, the first such file is files.site1 within the images subdirectory, and the first file apparently attempted to be created is 'files_0.site1' and so on. Seems as if the upgrade script is doing something to handle the multiple site situation.
At this point I'm not even sure what all it is I don't understand! ;-)
gil
Comment #2
adrinux commentednysus: try seperating the two tasks, upgrade first, then move the site into a multisite setup.
I did this and it worked quite well. So:
1. update 4.5 site to 4.6
2. created files directory and made sure drupal was happy with it
3. updated image.module to 4.6
4. ran image upgrade script (this successfully moved all the images from the old media/images, media/thumbs and media/tmp directories I had made into files/images etc)
5. move the sites config to a multisite setup
6. manually move the images from files/ on the old site to files/ in the multisite (it should be noted that I had no other images in the multisite setup at the time)
And it should be working.
Comment #3
Steve Dondley commentedAdrinux,
Tried your suggestion but I'm still getting the same results. Not sure what else to try at this point.
Comment #4
adrinux commentedWell, if you have to set it up all over again, syscrusher's module might help:
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher/im...
I'm about to give it a shot to bring galleries into drupal that I'd previously put in static html pages outside of Drupal.
But really it would be better to figure out why the upgrade script isn't working.
Comment #5
Steve Dondley commentedI'm making some progress. I delted all the entries for images in the files table and letting the get recreated. After doing that the image files are getting moved from the old directory to the new one. But images are still not loading in the site.
Comment #6
Steve Dondley commentedScript looks very buggy. I'm seeing some weird things. For example, the "File copy failed" error occurs when the script tries to copy a file from '/home/live_drupal-4.6_sites/files' to 'files/images/files'. This doesn't make logical sense.
Also, from studying the code that generates the image galleries, it needs images files that have 'original', 'preview', etc. in its name. This script does not alter the name of the images, it simply moves them from one directory to another. So even after running the script, I still can't see any images in my gallery.
Maybe I'm having problems because I used random file names? My files are named stuff like 'fe8d6084b34f64e14e1dfa3b49d139bb-328.jpg'
Comment #7
Steve Dondley commentedOops. I uncommented a line I had commented out while debugging. Now the images appear in the site.
I would recommend to anyone having problems with this script to go to the "files" table first and then delete all the entries for images. Then rerun the script.
Comment #8
Capnj commentedVersion 4.6. Nysus appears to have gotten it to work, but from this thread I can't tell what all he did. I have a bunch of images in a site (all backed up!) that are, I think, in the correct directories but something is not connecting because all of my photo galleries have no images -- but everything else is there: title, description, upload time, etc. The attached .png file shows a typical node being viewed.
I have searched the Drupal site, read everything about image.module and update-image.php that I could find, and am stumped! Here is everything I know about my files and data related to this and would be most appreciative of help.
New uploads also do not appear. They appear to upload and the description appears in the gallery but no image. Although from the settings below I expect the images to be in /mysite/files/images the new one appears in /mysite/images and the thumbnail is in /mysite/images/thumbs.
I did the initial conversion with 4.6 installed in the directory where the main files were, did the update-image, and when that did not work I have the site installed and successfully running in multi-site mode. Successful except for the images, of course. The site is http://dajudge.us/drupal/capnj. The files in the db are prefixed with "capnj_"
File system path = files
Temporary directory = /tmp
Image filepath = images
Cache support is disabled and I've emptied the cache via phpMyAdmin
As mention above, the images are actually in /mysite/images instead of /mysite/files/images. So, I copied dupes of all the files to /mysite/images (and the thumbnails to /mysite/images/thumbs). They still don't show in the directory. With what little I think I understand about the database, "images" appears to be where they're supposed to be located.
Here is the data in the capnj_IMAGE file for the photo that is supposed to be in /node/320:
320 images/oxcamp0002-320.jpg images/thumbs/thumb_oxcamp0002-320.jpg
The following are relevant lines from the capnj_FILES file:
1287 320 thumbnail images/thumb_oxcamp0002-320.jpg image/jpeg 2322 0
1288 320 _original images/oxcamp0002-320.jpg image/jpeg 212927 0
The system is NOT looking under "files" but in /mysite/images. I can open it with my FTP program. I cannot open it with /mysite/node/320.
Help!
gil
Comment #9
Capnj commentedBump
Comment #10
walkah commented@Capnj: i'd say your upgrade has more issues than just image.module... the URL you provided gives me:
Fatal error: Unknown column 'severity' in 'field list' query: INSERT INTO capnj_watchdog ....
Comment #11
Capnj commentedWalkah: by the time you checked the site I had jacked around with the settings.php file and it was pointing wrong. The site will load now so that perhaps you can see what is going on. Sorry for the confusion.
gil
Comment #12
walkah commentedCapnj : there seems to be something funky with your site:
http://dajudge.us/drupal/capnj/files/images/thumb_oxcamp_map-321.png
i get a 403 from apache on that image. Either you've got .htaccess set to deny for .png (or something) in your files/ dir or the permissions are set wrong (i.e. the apache user needs read access to the image).
did you perhaps run the update script as another user?
anyway, as far as i can tell your images are there, but the permissions are wrong.
Comment #13
Capnj commentedEureka! The permissions on the files directory were wrong. I had checked that at one time and somewhere in the process of playing with my setup and fixing something ELSE, this got changed. All is well. I never thought of trying to directly access one of the files like you did and that quickly pointed up the problem.
Thanks a bunch.
gil
Comment #14
walkah commentedcool..
Comment #15
(not verified) commentedComment #16
romca commentedthe errors, you had likely seen are because update scripts tries to copy nonexisting images - notably strings from "preview_path" column of image table (I am just upgrading from 4.4 and this column is totally empty) - I got 660 errors, I have 644 images, 16 errors were because file did not exist any more
rca
Comment #17
dmjossel commentedI'm seeing this same exact thing, except that file permissions do not seem to be the issue. I've chmodded everything in sight to 777, and the settings pages for the site and for the image module report no errors before I run the update script.
When it's done, the gallery thumbnails work, but the original images do not display.
Every image in the images folder has been duplicated, once for each time I've tried to run the update script on a given site (_0.jpg, _1.jpg, _2.jpg for every file) and a huge number of 512 byte files called sitename_files_XXX have been created. This is where the img src points to when the update-image script is done, but those files aren't images.
After the script runs, the image settings page shows a single "file copy failed" error.
More detail crossposted here, but so far I don't think anyone has looked at it:
http://drupal.org/node/31816
Comment #18
anj commentedFirstly, to confirm what folks are saying, I also got lots of 'file copy failed' errors because my original list of images had no preview_path set in the database. I went in and did an "UPDATE image SET preview_path=image_path WHERE preview_path='';" (I may not have remembered that exactly right) and this stopped those errors from occuring.
But I still ended up with missing images. It took me a long time to work out that images with low node id numbers were fine, and images with high id's were not. This was because the update-image.php script was taking too long to run. I was hitting the 30 second maximium script execution time limit, and the script kept stopping after a few hundered images.
I avoided this by running the script from the command line '% php update-image.php'. You could also do this by modifying the update-image.php script to start at higher node-id numbers.
Hope that helps.
Cheers,
Anj