...more recent posts
As might be expected, the /log script was not operating exactly right. I believe that it was O.K. if you had the logs completely on, but it definitely wasn't working right for either of the other two 'on' possibilities (logs (but not you) and logs (but not members).) It was recording the hits, but it wasn't displaying correctly in the new dratfink inspired 1/10 style where the 1 means 1 new hit since you last checked your logs out of a total 10 hits from the given referer.
Possibly it wasn't working with the complete log option either. I'm not sure.
In any case I'm pretty sure it's working correctly now.
Been playing around with the /log pages. Instead of just showing every hit, now it displays refering pages ranked by the frequency of referers (I know I keep spelling 'referer' wrong, but that's because it is misspelled in the W3C spec, and now everyone misspells it that way.) These totals are true for the time range specified at the top of the page (max 30 days, but they haven't been on that long.)
If you have turned the logs on (through /editpage) then the system is keeping track of every hit to your page. But now there are more options in /editpage for how you want these results displayed. "No logs", obviously, doesn't keep track of anything. "Complete logs" tracks and displays every hit. "Complete logs (but not you)" tracks every hit, but doesn't count hits by you in the tally. "Complete logs (but not members)" tracks every hit, but doesn't count hits by any members including yourself. Switching back and forth between any of the three versions of logs won't change the totals, just how those totals are reported.
The system is set by default to only keep records for 30 days. It checks for and purges any older records every time you look at /log (after you look though, so if you don't look for some time you will see everything on the first look, and then only those within one month afterwards.)
The googlebot was spoted this morning on (at least) my page, so maybe they are starting to index us again. Not that anyone really cares, but I thought I'd mention it.
There is some very crude output from the new logs visible at /whateverpage/log. You can only see your own logs, and you won't see any of your own hits (unless you are not logged in to the system when you hit your page.) Just shows the referer (if there is one) and the user agent (browser and operating system and maybe some other info about the surfers computer.) A * means it's not a registered user.
This will all change. And yes I know that's not how you spell referer, but that's the way it got written up in the official w3c spec, so that's how people spell it.
There is now an option for turning logging of your page hits on or off in /editpage. It's off by default. Change it to 'logged' to start keeping track of visitors to your page.
A utility for looking at recent visitor stats will be coming soon.
Wow. I reproduced the "rachael bug" where you try to load the site and you just get a blank page and a 'document contains no data' error. Yuck. This is tied (I now see) to some weirdness in the log out process if you choose to erase the cookie from 'every computer with this cookie'. I think I see how to prevent this. Hopefully this hasn't been a problem for anyone else. (The quick fix is to quit your browser, then delete your cookie file, then restart your browser.)
Steve and Alex and I talked a little last night about how the [new comments] link on the front page sometimes takes you to the middle of a thread, and there will be more unread comments above your position in the same thread. If you go back and reload the home page the preceding (still unread) comment will still be linked, and continuously returning to the home page and clicking on the decreasing number of [new comments] will eventually bring all of them into view. Still, it would obviously be better if the system would take you to the top-most unread comment in any thread with multiple unread comments. I've made a change to this effect, but not sure if it will work. Any feedback as these situations (do or do not) arise is appreciated.
Still working on the weirdo bug that was/is causing problems with the archive (either posts that shouldn't be showing which are, or the opposite.) Tracking this down has basically led me on a tour back through the entire logic of the system. Yikes. It's not a pretty site in there. Spaghetti code I believe it's called. Anyway, made some changes to the /edit and /post scripts. If you were trying to post or edit between 2:30 and 3:30 today you might have gotten some errors or other strange results. Should be working now. Definitely fixed some things. Also got my head around a few more problem scenarios that still have to be fixed. These involve strange combinations of events, but could possibly happen. The best fixed that happened today has to do with deleting posts. Before, if you deleted a post that was showing on a page (say the page is set to display 10 posts) then the page would only show 9 posts. This was a problem in its own right, but also led to other problems if still more posts are added. The probelm would be that stuff at the bottom of the page wouldn't slip into the archive correctly. This should be fixed now. If you have a page set to display 10 items, and you have more than 10 items (i.e., some have already slipped into the archive) and then you erase one post that is one of the 10 showing, you should now still have 10 posts showing on the page (it will now resurrect one out of the archive.)
One of the problems still to be fixed involves changing the orientation of the page (from chronological to reverse, or the other way around.) If you do this, and the end that you are putting at the top contains deleted posts, things will go a little screwey. So beware of reversing the ordering of your page until further notice.
One quick fix for this sort of problem is to set the number of posts to display on page (set in [editpage]) to '1', and then set it back up again to whatever you want. This is like 'reseting' the ordering mechanism of the page. Blah, blah, blah.
Finally getting the "slide show" picture pages working. Feel free to play around with this. Documentation, as usual, will be written real soon now. The short story is this:
When you [create] a new page there is now an option called 'slide show' in the page type pull down menu. Select this, and then in the template pull down menu, select either 'slide show plain' (for no 'posted by...', no comments, and no bottom footer) or 'slide show comment' (for 'posted by..." with comments, and with bottom page footer.) These are just the defaults, and can still be changed in [editpage] after the page is created (in case you want, say, 'posted by...' but not comments, or some other case.)
Anyway, once you create the page, just post pictures to it as if you were making regular posts to a page. The page will be set to display only one post per page, so your first post will become the first page, second post the second page, etc... I made this for pictures, but you could of course use it for text, or a combination of the two.
'previous' and 'next' links will be automagically inserted at the bottom of the page, and if you have more than three pictures a list of the pages will also be displayed (I know that's not clear, see here for an example - I mean the '1 2 3 4 5 6' page controls that show up just above the 'previous' and 'next'.
Comments welcome. There may well be bugs. Let me know.
Always something.
Jim Louis' page alerted me to yet another bug in the system. This one is caused by a change in the new system that is otherwise quite good. Here's the background if you're interested:
In the old system if you deleted a post (or a whole page!) it was actually deleted. I thought that this was not such a good idea, as accidently erasing something (especially a whole page) would result in really losing the data. In the new system I protect against this by not actually deleting anything. When you tell the system to delete something it just sets a delete field in the database so that the system recognizes that that post (or page) has been deleted. But all the info is still in there. Eventually I'll build a trash can system so that you can go back into the trash and resurrect deleted items. This is a good thing (I was especially scared about one of our accounts being compromised and the evil-doer having such easy access to erasing everything.)
Anyway, the probelm was that when paging back or forward (using the '...more recent posts' and 'older posts...' links) the system looks to see how big the window is for the page (the number of posts set in [editpage] for 'number of posts shown on page') and then grabs that many posts either forward or back from where the surfer is. This works fine unless there are deleted posts in the window the system is trying to grab. This was happening on NOLA for the last day. One post on the front page, but then when you tried to go back one page, the next post had been deleted so the system would get stuck. Now I've made it smarter so that it checks for this happening and readjusts itself accordingly.
Anyway, that's probably not too interesting. But I mention it because it is another good example of how subtle problems are all but impossible to find unless your software is actually in use. There is just no way to think about every possibility in some abstract way. Only actual use will uncover bugs. In the open source / free software world they say "with enough eyeballs all bugs are shallow." Amen.