I have a lot more work done on the image system (uploading, editing, and categorization) but nothing ready to show yet.
I'm curious if anyone is wedded to the /image/album0/ naming convention for image albums? At the moment I am planning on changing this so that, say, my Austria 2002 album would move from http://www.digitalmediatree.com/image/album32/ to http://www.digitalmediatree.com/image/album/5/austria_2002/ (or maybe I'll put /image inside /library, so /library/image/5/album/austria_2002/)
Any thoughts on this? Any idea if there are external links going to any albums at the old locations which might break? (I don't really think so, but I could be wrong.)
I have several art archive pages linking to those URLs (I like the thumbnail pages). Those few links would be easy to remedy, but I'm pretty sure I've done it elsewhere (maybe in the weblog) and I can't remember where. If it's for the greater good, I'll do my best to remember where I did it and fix it. Also, FWIW, I know google has been archiving the image files as they are.
One thing I learned under the new system (or maybe it's just that you're working on it now?):
I made a slight change to my Nausicaa drawing. In the past, if I deleted the old image and uploaded the new one really quickly, I could keep the same image # and wouldn't have to change the tag. Today, when I deleted "NAUSICAA gif.gif" the system kept pulling it up after I uploaded the identically named replacement image. So I kept the replacement image in the dmtree system and uploaded it again, without changing the file name on my hard drive. This time the system renamed the new image "Nausicaa_gif_1_2.gif" or "Nausicaa_gif.gif_1_2" (I forget which--and why _1_2 instead of just _2?) and the oldest image was replaced. So the moral is, now you need to upload a replacement first, let the system rename it, and delete the old image second (for housekeeping) otherwise the old image keeps coming up. Correct? That's because deleted files never actually leave the server, right?
This won't be a problem in another few days when I put up the rest of the scripts. There is a new one called editpic that is something like showpic except it gives you more options. This is where you will delete pictures from, and when you do they really are deleted from the server (but you are correct, deleting them the old way does not remove them from /library/....) So you will be able to delete, and then reupload the old file (at any point in the future, not just before someone else uploads another file, which is why you have to do it fast now) it will have the same name on the server so you won't have to change any of your image tags.
The system does try to change names it doesn't like (it doesn't like filenames to have special characters or spaces, and it needs them to be unique for each uploader.) It changes example_1.jpg to example_1_1.jpg instead of to example_2.jpg because it's not very smart. And also because it would be a little presumptuous to do that. I wouldn't want a picture of my 2003 trip to the beach, beach_2003.jpg changed to beach_2004.jpg. I'd want it changed to beach_2003_1.jpg. And it's really hard to tell the example.jpg case from the beach_2003.jpg case. But if there was a way it would be better, I agree.
OK. sorry to jump the gun while you're still working on this. My confusion over the naming was, I hadn't used any numbers in the file names. The system added "_1_2" when there was no "_1" in the file name to begin with. It shouldn't matter--whatever pulls up the file--but I wanted to point it out in case it's relevant.
Yes, thanks, it is. -1-2 is definitely a bug if there is no x-1 and x-1-1. I'll fix this.
And thanks as always for all reports.
|
I'm curious if anyone is wedded to the /image/album0/ naming convention for image albums? At the moment I am planning on changing this so that, say, my Austria 2002 album would move from http://www.digitalmediatree.com/image/album32/ to http://www.digitalmediatree.com/image/album/5/austria_2002/ (or maybe I'll put /image inside /library, so /library/image/5/album/austria_2002/)
Any thoughts on this? Any idea if there are external links going to any albums at the old locations which might break? (I don't really think so, but I could be wrong.)
- jim 3-03-2004 10:27 pm
I have several art archive pages linking to those URLs (I like the thumbnail pages). Those few links would be easy to remedy, but I'm pretty sure I've done it elsewhere (maybe in the weblog) and I can't remember where. If it's for the greater good, I'll do my best to remember where I did it and fix it. Also, FWIW, I know google has been archiving the image files as they are.
- tom moody 3-04-2004 12:35 am [add a comment]
One thing I learned under the new system (or maybe it's just that you're working on it now?): I made a slight change to my Nausicaa drawing. In the past, if I deleted the old image and uploaded the new one really quickly, I could keep the same image # and wouldn't have to change the tag. Today, when I deleted "NAUSICAA gif.gif" the system kept pulling it up after I uploaded the identically named replacement image. So I kept the replacement image in the dmtree system and uploaded it again, without changing the file name on my hard drive. This time the system renamed the new image "Nausicaa_gif_1_2.gif" or "Nausicaa_gif.gif_1_2" (I forget which--and why _1_2 instead of just _2?) and the oldest image was replaced. So the moral is, now you need to upload a replacement first, let the system rename it, and delete the old image second (for housekeeping) otherwise the old image keeps coming up. Correct? That's because deleted files never actually leave the server, right?
- tom moody 3-04-2004 10:59 pm [add a comment]
This won't be a problem in another few days when I put up the rest of the scripts. There is a new one called editpic that is something like showpic except it gives you more options. This is where you will delete pictures from, and when you do they really are deleted from the server (but you are correct, deleting them the old way does not remove them from /library/....) So you will be able to delete, and then reupload the old file (at any point in the future, not just before someone else uploads another file, which is why you have to do it fast now) it will have the same name on the server so you won't have to change any of your image tags.
The system does try to change names it doesn't like (it doesn't like filenames to have special characters or spaces, and it needs them to be unique for each uploader.) It changes example_1.jpg to example_1_1.jpg instead of to example_2.jpg because it's not very smart. And also because it would be a little presumptuous to do that. I wouldn't want a picture of my 2003 trip to the beach, beach_2003.jpg changed to beach_2004.jpg. I'd want it changed to beach_2003_1.jpg. And it's really hard to tell the example.jpg case from the beach_2003.jpg case. But if there was a way it would be better, I agree.
- jim 3-04-2004 11:35 pm [add a comment]
OK. sorry to jump the gun while you're still working on this. My confusion over the naming was, I hadn't used any numbers in the file names. The system added "_1_2" when there was no "_1" in the file name to begin with. It shouldn't matter--whatever pulls up the file--but I wanted to point it out in case it's relevant.
- tom moody 3-05-2004 12:13 am [add a comment]
Yes, thanks, it is. -1-2 is definitely a bug if there is no x-1 and x-1-1. I'll fix this.
And thanks as always for all reports.
- jim 3-05-2004 1:14 am [add a comment]