images in /data directory not being renamed during upgrade!
 

Please help.

I've been trying for almost a week now and no progress.

I was running PP 4.86 + vB 3.0.x

Recently upgraded to vB 3.5.0 GOLD and am now trying to upgrade to PP 5.21

My method: Old live PP install was in /photos on my domain. I unzipped the 5.21 zip file into a directory called /photos2/. Edited the config-inc and config.int files with my correct data and paths that point to /photos2. I also point it to a new DB which is a copy of my old 4.86 DB so that I dont have to touch the live copy. I then copy over the /data and /uploads folders into /photos2 and chmod -R 777 both of them. I run the upgrade script starting at the 4.85/4.86 point and everything goes through seemingly fine except for some "already existing" errors on the 4.85 step 1 which seems to be common.

The rest of the install seems to go fine and I can login to PP afterwards, but all the images and thumbs are broken. They point to images with apparently prepended #'s on them, which arent there. So I'm assuming one of the upgrade steps renames the files in /data? This doenst make sense because its been properly chmodded to 777 recursively.

BTW- I've tried this numerous times, all with fresh DB's and fresh install directories. Just so that steps were not duplicated.

One question actually -- in Step 2 for the 4.86 upgrade, when it renames the DATA directory... in the next page shoud it verbosely list the files that have been renamed? Or not?

I'm out of ideas. Please help!

We dont rename the data directory. More than likely your error is in something your doing with trying to do in the replication process

Your data path is in your database not files. Basically the 485-486 upgrade creates directories underneath your data directories of medium thumbs and mini then your medium images and thumbnail images are renamed and moved. Then on the last step your entries on the photo table the bigimage is renamed to userid on front of image

As long as everything is ran as it is suppose to be ran and all paths etc are right and images exist where they should be you should be fine.

Any issues with this upgrade resolve to 3 things

1. user's data path is wrong

2. permissions on data directories not 777

3. step 3 is ran more than once resulting in userid being prepended on images more than once.

Thanks for the quick reply Chuck.

I've tried many more times and double-checked my configs, heck, even chmodded every file in my photopost directory recursively with 777 and no go. I even took down my old live copy and ran the upgrade from the original path (/photos), and no go. Step 3 in the 4.8x upgrade was screwing me over by prepending the userID on every image filename in the DB, while step 2 was not renaming them to facilitate step 3.

However, I have gotten it to work now, and the way I did it was by skipping Step 3 in the 4.8x upgrade. Every other step before and after it I did. Now my photopost looks to be up and running 100%.

Please tell me if there are any negative consequences to skipping this step. In my eyes there don't seem to be any. Ive uploaded some test images to make sure my PP is working and it looks fine. You can take a look at my live PP running now @ http://www.toyotanation.com/photos/

That would mean you did step3 if it works. I can say that without a doubt as if step3 had not been done they would not show. It is pretty absolute in the new code we do not parse the userid before the image after PP5 so your bigimage field in photos in step3 had to have been run prepending the userid to the image name in the bigimage field

Looks fine EXAMPLE HERE

http://www.toyotanation.com/photos/s....php/photo/200

You say you did not do step3 yet look here is a very old photo

Look at this user 2 image is being shown.

Look at the code in showphoto

$imgurl = "{$Globals['datadir']}/$storecat/medium/$bigimage";

That means you definately ran STEP 3 of the upgrade ;)

could it be that i was possibly running PP 5.x before the upgrade?!? In my old config-inc.php it says:

// PhotoPost Pro Version Number
$VERSION = "4.86";

Is there any other way of confirming the version number of an installation?

This would explain EVERYTHING!

It could have been indeed you where already running 5.0

would not be the first time someone was mistaken about what version they are running