...more recent posts
My stupidity really pays off in the sense that I end up working for a long time on simple problems, and then when I finally solve them it feels like I am some kind of genius because, well, the problem must really have been hard for me to work on it for so long!
Follow that?
Anyway, I believe I have the OS X client ftp uploading script now working. At least I slightly impressed Dave with it. The script is an icon that sits on my desktop. Any file (or files) I drag onto the icon are FTP'd to the dmtmusic upload server (which can now handle all media types, not just music.) No connecting. No signing in. No hassles. Just drop 'em and they upload.
I think I could just email this script to other OS X users if anybody wants it. I'll be curious to see if that works. So let me know.
I ended up doing it completely in Applescript so it should be very portable across OS X machines (doesn't rely on Apache and PHP like my first attempt.)
The music system is getting the same makeover the image system got. We are still stuck with the FTP upload system for now, although it looks like I'll be able to automate it at least for OS X people. But as long as you are comfortable with an FTP program, it's extremely easy. And really more powerful than [upload] since you can set your ftp program to upload directories of files ([upload] still works the same as before, just to be clear.)
Once you have files in your directory on the ftp server - (dmtmusic@tulip.he.net/dmtuser_n) where n is your user id - you now go to:
http://www.digitalmediatree.com/sync/
instead of /music_sync/.
Basically it does the same thing, except now it is much smarter, and it puts your files in the new /library/music/n/ location. The /sync/ script can handle most files provided they have the proper extension. Feel free to FTP .jpg, .gif, .mpeg, .ogg, .swf, .png, .wma, .avi, etc... files into your directory. /sync/ will grab them and put them in the right place. If it's an image it will add it to your 'complete list' of images. If it's a music file it will add it to your 'complete list' of music. If it's a movie file it will at least put it in the right place, although the /video/ system isn't built yet (but since it's almost exactly the same as /image/ and /music/ it should be easy.)
Fiddled with the client side uploading script today. It was timing out on large uploads, but now seems to be working after a tweak to the httpd.conf file. This is a very exciting feature I think. Watch what happens to the music library now.
I think Tom was onto this a long time ago, but the Userland weblogs.com update notification system is now not only not working for us, but actually causing posts to time out (if your page is set to notify userland when you post.) So I have removed that function (even though it's still listed as an option on [editpage].)
When I'm done with the media library projects I have open now I will look into this. I know a lot has happened in this space since I last looked. If we want to be doing this sort of thing then technorati is maybe a better place to be pinging. And there are others too.
One thing at a time though.
/editpic now gives you a fully formed img tag so you can cut and paste. This is helpful if you are replacing old instances of /getpic/ with the new img tags. Just [edit] the post. Copy the /getpic/xxxx number, and put it onto the end of /editpic/?pid=xxxx. Then the editpic screen will give you the full img tag you can copy and paste back into the post to replace the img src=/getpic/ tag.
Note, there is no need to do this to old /getpic tags. They will still work. But the new way is slightly (noticeable though) faster. So it is probably a good idea to replace often loaded images (like images that load every time your page loads) with the new form. At least if you want your page to load a little faster.
I've done this for a few pages that are (relatively for us) high traffic. Hopefully nobody minds me taking that liberty.
Mark was onto this potential problem already, with his previous suggestion that I include the picture ID numbers as a custom argument to the img tag. The problem is that given an image in a post, there is no way to get to the editpic page for that image (without looking up the picture in your complete list of [images] to get the ID number to pass to editpic/?pid=xxxx.)
But instead of doing that I made it so editpic understands image paths. So now you can pass editpic the image location in the URL, like this:
http://www.digitalmediatree.com/editpic/library/image/5/example.jpg
You can also still pass the ID number as ?pid=xxxx.
A little esoteric, but this situation will probably come up.
Sometimes it all goes wrong.
Well, actually, I've seen worse. I mean, nothing big came unravelled. But I've spent all of today so far working on one problem with thumbnails that turns out to be unsolvable under my installation of PHP and GD.
And the answer is merely to use image imagejpeg() even when it really really seems like you should use imagegif(). Okay, fair enough, I just wish it didn't take me 5 1/2 hours to figure that out.
Scripting quagmire; I want my cakewalk.
But I believe my client side uploading scripts are now on their way to being finished. At least 90% done, which means I only have about 300% of the time so far invested remaining until they are done. Go figure. Must be that new math.
The [image] pages are now a little better. And thumbnail pages are working again.
I still need to map the old album and thumbnail addresses so they redirect to the new pages. And possibly getpic might be screwed up again for recent pics (remember, it sort of isn't supported anymore) but I'm going to still make sure it's all right tomorrow.
Damn. I just screwed up all the image album information. D'oh.
I'm working on fixing this now, so bear with me if some of your albums are screwed up. I think it probably only screwed up album info for recently uploaded pictures.
I have a full back up of the site from 3/6/2004 so I'm downloading that now to compare, and then I guess I'll fix whatever was uploaded after that by hand. I think I should be able to do this and get everything back.
Sorry sorry sorry.
Just thinking out loud here.
What to do about mp3s? I'm going to use a lot of the code from the image system, but I think we need some security. I'm not really interested in serving up our mp3 collections to the general public (for bandwidth as well as legal reasons) but at the same time there will of course be legitimate mp3 files that need to be served to the general public.
So I guess there will be some option while uploading to put sound files into either your public or private directory. I'm imagining that the private directory will be available to everyone who has a non anonymous user account. I mean everyone who has an account that was not merely made by clicking 'remember me' on a comment page.
[For the record there is a group_level number associated with each account: 0 is a random surfer without a cookie, 50 is someone who clicked 'remember me', 100 gets you image upload ability, 300 lets you add other users, and 900 makes you a super user (I'd tell you what that means but then I'd have to....)]
This means that private mp3s will be accessed through PHP (so I can check cookies.) I am really not sure what kind of a hit this makes on the server (just using fopen($filename) and then passthru()) but my guess is that we have power to spare. Of course this is the sort of assumption that can come back to bite you.
One thing that will alleviate this problem (if it even is a problem) is that my OS X (unix) uploading client can also be a downloading client - thus moving the CPU hit to the client. God I love that idea. I wish I could make that stuff available for windows too. (Theoretically I could, since it only relies on Apache and PHP, both of which can run on Windows, but I would be completely unable to support getting those to run on anyone's windows machine.)
If I do the public/private directory thing for mp3s I could reuse that code to make private image directories as well. But I can't think of why anyone would need that. And I don't want to add even a single checkbox that isn't necessary (despite the look of the [settings] page.)
Also, although I keep saying 'mp3' the new music system will allow for any encoding type (.wav, .ogg, .whatever...)
Going to finish the /image pages first though. Those are still in very rough form. If anyone has any design input for how those image and album listings should look I am all ears. Mock it up in photoshop if you want. Design is obviously not my strong point, but if you don't mind messy table laden HTML I can probably make a fair representation of most designs.
I'm still praying for the day we recruit an HTML/CSS design person to work with us.