...more recent posts
If you can read this, it worked!
this_is_a_test
OK, you can now delete pictures (one at a time) from the bottom of the upload page. You can only delete your own photos.
Well, instead of doing the real work on the picture upload system I built a random picture grabber instead. Where /getpic/502 gets you picture number 502, /randpic/502/503 gets you (randomly) either picture 502 or 503. There is no limit to how many picture numbers you can use. So /randpic/502/544/545/811/191/1032/777 gets you one of those 7 pictures. Each time the page is reloaded it picks another random image from that list. It doesn't check for repeats, so possibly it will fetch the same picture two (or more) times in a row.
Also, it doesn't matter what else is in the URL as long as /randpic/xxx/xxx/xxx is at the end (so digitalmedaitree.com/randpic/1/2/3 is the same as digitalmediatree.com/jim/weblog/randpic/1/2/3)
More on photos: I've slightly changed the /upload page so now it reports the total disk space occupied by all your uploaded files. The total for everyone is 42 megabytes right now.
I'm working on allowing deletes from the /upload page, but this is proving a little tricky. If you know you have lots of (or a few big) photos you would like to delete feel free to post the id numbers below and I'll erase them by hand.
The database is around 30 megs, so that makes up most of the 70+ megs of space we are occupying right now (out of 100 we are alotted.)
Alex pointed out that the new framed archive view was not working in his browsers (nav 4.x on Mac and I think an older IE on windows.) I believe I have fixed this issue (confirmed for 4.x on mac, but not for whatever the older IE on windows is.) Can anyone confirm this, or spot other problems? Thanks.
Thanks to Alex for finding a somewhat subtle bug. If you tried to move a page by changing the path in [editpage] (which is how you would move a page) and you changed the name to a longer but otherwise similar name (from /test/test2 to, say, /test/test234567) the system would get confused. And that's putting it mildly. Should be fixed now.
In [editpage] you can now switch from the 'standard template' to 'use your own HTML'. If you choose to do this you must make the change to 'use your own...' and then come back to [editpage] a second time and you will see some different options including two new posting boxes (textarea boxes) one labeled 'Opening HTML' and the other 'Closing HTML'. When your page is requested the system will print out 'Opening HTML' followed by your currently active posts from the database, followed by 'Closing HTML'.
As of now the posts from the database are printed as rows in a table (where each row has one column) so it expects a <table> to already be set, plus that it will be closed (</table>) in the 'Closing HTML' (along with </body> and </html>.) I think I'll take out the table in the future and just seperate the posts with <p> tags.
Also there is no way yet to create a 'use your own HTML' page from /create. I'll add that tomorrow. Right now you'd have to create a regular page and then change it in [editpage] (and then go back to editpage and add in the HTML!)
Occasionally, for some as yet unknown reason, the system will screw up and think you have an unread post or comment on a page where you do not in fact have any unread posts or comments. I'm working on trying to make this never happen, but in the meantime I've changed the subscription script so that if you change your subscription to turn tracking off it will clear out all unreads for you associated with that page. Then you can turn tracking back on and it will start keeping track for you again. Note that this works from the individual subscription pages (so from /schwarz/subscriptions in this case, not from just /subscriptions.)
Not sure how closely anyone is following along. I wrote some stuff about the discussion system here on my page recently. The gist of it is that threading (being able to reply to replies) is very costly in terms of storage. I'm commited to providing threading, and at this point the cost doesn't seem to be impacting performance (although in the future this might be a different story.) But I'd like to encourage a more linear comment style where this is possible.
Anyway, one idea I had was to put the posting box at the bottom of the comment page itself. This box would be equivalent to clicking 'add a comment' at the top of the comment page, or in other words, a post made from this box would add the comment to the bottom of the page, all the way on the left (or in still other words, it would add the comment to the bottom of the page as a top level comment.) You could still click [add a comment] on any particular comment to make a threaded comment that will go directly beneath the comment you are responding to (and be indented slightly.) But I think the convenience of having the posting box already visible on the page will make people more likely just to add a top level (non threaded) comment rather than clicking through to a seperate posting page.
Any thoughts? If not I'm going to try this out soon. We can always go back.
Also, I wonder if this would make unknown anonymous surfers more likely to comment? The box would be right there after all. Would that be good or bad?