...more recent posts
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.
The image system continues to change. The [upload] screen is now much different. All the album options are gone from there now. I like this more simple interface.
When an image upload is complete you are taken to the new /editpic/ page where you see the picture and all vital information. Below that you can delete the picture, and below that you can control in which, if any, albums the image belongs to. I think this is more straightforward as well. Check an album and the image goes into the album. Uncheck an album and the image comes out of that album.
You can also make a new album here. When you erase the final picture from an album the album itself disappears.
I am keeping it so that the old album URL scheme still works. So /image/album22/ still gets you my Paul Laffoley album, even though that URL is deprecated and the official URL is now /image/album/5/Paul_Laffoley/
I still have to put back thumbnail view when accessed from the new URL scheme. And some of the other /image/ listing pages are not complete design-wise.
Okay, I put off changing the /album/ file structure for the moment. I need to think more about this. But the new editing has been partially activated. Clicking on the picture id link from any of the image pages (or clicking on an image thumbnail from a thumbnail view image page) now takes you to the new /editpic/ page. This shows the picture along with meta information about the picture. And if the picture is yours it allows you to make some changes (edit name and size) as well as deleting. This script will also allow you to add or edit how the picture appears in different albums, but that is not yet working.
Deleting from this new new /editpic/ script will solve the problem Tom ran into yesterday.
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.)
Another long day today. And a lot more progress.
This will be exciting for Mac OS X users. I have the functioning skeleton of a new program that uploads files to the website. Right now it understands a bunch of different image formats and the mp3 music format. But I can add other types very easily (certainly other music formats are dead simple to add, but movie formats will be only slightly more difficult.)
The cool thing is that half the program runs on the client machine. Since OS X is unix this makes everything really easy - and I'll be able to install it on any Mac OS X machine. This program makes it so that there is a web upload folder on my machine. I can drag media files into this folder, and then I just load a particular web page in my browser. That starts a chain of events that uploads every file in that folder to the server, and then synchs all those files (putting them into /library/image/x/ or /library/music/x/ (or /library/video/x/...) and adding the appropriate information to the database.
The big win here is multiple file upload capability. You could just set it going on a big folder and go out for a bite. But the other win is speed. Unlike the present photo upload system, which sends the file over HTTP, this program (running on the client) makes an FTP connection to the server. This means that big files will not be a problem. It's basically a replacement for the complex music uploading system we have now (that requires a standalone FTP program on the client) and it handles photos (and soon movies) as well.
This should run on any unix based machine that can run PHP.
Of course I will continue to do my best to support all platforms, so there will always be ways to do these things from windows - I just can't guarantee it will be as easy to use.
Probably take me a couple more days to get it all polished up.
Holy cow what a long day. Very frustrating. Nothing was going right.
I was just going to finish up my work on the upload scripts this morning, but it ended up taking all day. I *think* things are back in working order now though.
If you were around today you might have noticed some errors since I was uploading lots of different files to the server (if you request a page right as I'm changing it you would get an error.)
I changed the new library structure a bit. Before (I mean yesterday) a picture (say test.jpg) that I uploaded would be in /library/5/test.jpg. Now it is in /library/image/5/test.jpg. I added the extra layer in the hierarchy because soon we will also have directories like /library/music/ and /library/video/. Nothing should have broken because of this move. But I'll go back and change any links anyone made yesterday while the filesystem was set up the other way.
Otherwise everything else is the same. But under the hood there are a lot of changes - and everything is much more sensible down there now.
Yesterday I slightly broke the comment system in the case where you are leaving a comment from a /new_comment page. In those cases line breaks were not being converted to html break tags.
This is now fixed.
The active page owners on the site can now create top level pages. Let me know if you want this and I've overlooked your account.
I've been putting it off all week, but this morning I finally dove in and made changes to the picture uploading system. I'm 90% done, and it has gone fairly well so far.
Don't panic too much, all photos still exist in their old location, and I'm leaving the /getpic/ scripts in place for the foreseeable future. So everything will continue to work as it always has.
But I'm bringing the new system up in parallel, so the new way will start to work alongside the old way, and maybe eventually we'll get rid of the old way (but we'll always leave /getpic/ in place so no external links will ever break.)
The goal here is to get PHP completely out of the equation when an HTTP request is for an image file.
There is a new directory /library. Inside /library are folders for each user id (well, for each user id that has uploaded pictures.) A copy of every picture you have uploaded is now inside that directory. In the old folder (kept outside the webserver domain) the files had unique numeric filenames corresponding to the id for that picture in the database. All file information (name,date,user,etc...) was in the database. In the new system the info is still in the database, but the filename is kept the same as when you uploaded it (except in the case of duplicates where the system appends _1, _2, _3 as necessary, as well as replacing spaces with underscores.)
So where img src="/getpic/123" would request picture 123 (which had, say, the real filename 'test.jpg' when uploaded,) the new tag would be img src="/library/5/test.jpg".
The /5/ in the above example is my user id number.
The thumbnail is still at img src="/getthumb/123", but now it is also at img src="/library/5/thumbnail/test.jpg".
But remember /getpic/123 will continue to work, so nothing is going to break. When you upload new pictures they go to both the old directory and the new directory (same for thumbnails.)
Next I am going to update the post script to do some substitution. I am thinking of using this shorthand for inserting pictures: <[xxx]> where xxx is either the picture number or the exact text of the description you gave the picture when uploading. When you post an entry with that code in it, the post script will replace it with the appropriate img src="/library/n/xxx" format.
If that seems to work I'll write something to go back through the database and change all the /getpic/ statements to the new form.
This will be much more efficient. And it also will solve the weird problems we sometimes encounter because the file extension is not visible in the html. Some browsers get confused and download the file to disk rather than displaying it in the browsers. This will become even more of a problem as we move to dealing with many more mime types (moving images and such.)
I've revamped the subscription script. The changes can be seen when clicking [subscriptions] from the front page. This is the master subscription page that used to take *forever* to load. Everything you can do on the master page, you can also do on each individual subscription page, but on the master page you can change many pages at once.
(For instance, you can go to /systemnews/subscription/ and add or remove this page from your home page. But you can also go to /subscription/ and add or remove this page, as well as adding or removing any other pages.)
It now loads much faster because the 'Add any page' pull down menu no longer lists every freaking page on the site. I have changed this to 'Pages you might want to add' and that pull down now lists every page you have permission for which isn't on your homepage, but is on at least one other persons homepage. In addition, there is now a text field where you can type in the path of any page you want to add (in case you want to add one no one else has on their homepage.)
The rest works the same. This is the best page to use to organize the ordering of pages on your homepage. The system is pretty smart when you change the numeric order of any of your pages. You can change, say, number 15 to number 2 without manually reordering all the pages in between. Just change 15 to 2 and leave everything else the same (so you have 2 number 2's and no number 15.) The system will sort out the conflicts and reorder everything nicely (the old number 2 becomes 3, 3 becomes 4, etc....)