...more recent posts
Problems are already appearing.
I'll have to think about how to handle this. It may not even be a bug. Anyway, when you create new pages, there is now an expanded facility to create the new page just like a page that already exists. When you do this the system makes the page in the same style (chronological,alphabetical,numeric,) copies the style sheet, copies any permanent text (left_text, top_text,) and also copies all the subscription information.
What just happened now (I'm guessing) is that alex made a new page using this cloning method - but he cloned /arboretum, so we all ended up having the new page on our front page (because it copied all the subscription information from arboretum, and we all have arboretum on our home pages.)
Perhaps cloning is too powerful. Maybe it shouldn't copy subscriptions too. I'm not sure. Anyway, just be aware that when you create a new page "just like" an older page, it really will be just like it.
We're back.
No doubt there will be problems. What the hell do you want for free?
So let me know if anything seems amiss and I will correct it asap.
I still have the old system, of course, and multiple copies of the old database, so if somebody finds a show stopper bug we can easily go back.
I wouldn't doubt it at all if things were screwed up in early browsers.
More new stuff coming this week.
This site served around twice as many pages yesterday as a normal day (usually the traffic is very level.) Any ideas? I know my page has been getting hammered by the googlebot, maybe it's all from that?
I noticed that Tom and Bill both had weird situations where viewing their pages from the [new post] link on the front page resulted in the doubling of posts. Viewing the page regularly (without the /?new) was fine.
Have you guys been using the preview? My guess is that is where the problem is. Any info is helpful.
Tom was asking me about the behavior of the system when switching (in [editpage]) between the different commenting styles. This prompted me to rethink how this works. I had never really played around with it too much. Yet again, the incomparable value of having other people actually use the code you are writing.
Anyway, I've made some changes to the comment pages. The default behavior is to allow for comments to be added either flush left (not indented) after any comments that are already there, or directly under (and indented) any particular comment. The 'add a comment' link at the top of the page (or if it exists, the actual posting box at the bottom of the page) will always give you the first behavior. When it's allowed, clicking the [add a comment] link after a specific comment will put your follow up comment right under the one whose link you clicked (and indented.)
Anyway, the page owner can always switch back and forth between styles of comments (either straight, or allowing this indenting.) But if you already had indented comments on your page, then switching to straight (non-indented) comments would loose any old comments that were indented. Well, they wouldn't be lost, but they wouldn't display.
Anyway, to get to the point. I've changed things so now if you change a page that already has indented comments to the straight style it will "flatten" any indented comments (un-indent them) so that everything displays.
I am very happy about this. The reason is that it is my secret desire to get rid of the indenting comments altogether. While I agree that it is nice to have options, this one is so expensive that I think we'd be better off without it. I won't do anything rash, but over the long haul (and especially if we started to become more busy) I am thinking of eventually loosing this feature. I'll explain the cost if anyone really cares, but take it from me, it's a really high cost (in storage, and processor power) to get the indenting comments to work. If we had a hundred users it might not work out so well (or it might.) A thousand users and I'm pretty sure it would be too much strain. I'd love to find out some day how big this could scale.
Well, I've done a lot of testing and I can't get any of these comment problems to happen again. But I saw some happen yesterday (in the wild, as it were) so I know that something is up. I'll keep looking.
Did somebody say something about having to scroll down on the /settings page before you see any text? That doesn't sound right. Can someone confirm this with browser/OS information?
Does this happen on any other pages?
Thanks.
There are definitely some problems with the [x new comment] counters. This is a result of some new capabilities (yeah, I know) that were just added. I'll get this all straightened out by tomorrow. If anybody notices they make a comment that then doesn't show up, please write to me with the following info:
Did you post from a comment box on the comment page itself, or did you add the comment from a posting page that only contained a posting box (and no comments)?
Did you post directly as a comment, or did you use the new 'preview' feature?
Thanks.
I have not done serious testing, but I believe that preview mode now works for comments. There could well be errors (with the [x comments] comment counters, or the [x new comment] counters on the front page.) Please let me know if you think something is funky.
Also, there is a new page /settings where you can make some adjustments. More options are coming. Right now you can use /settings to manually zero all your new post/comment tracking counters. Plus you can assign a pixel dimension for all your posting boxes. Plus you can set a default behavior for converting line breaks to HTML (you can either have this default to on - checked - as it does now, or you can switch it to always default to off.) Also you can turn off or on the options of preview and pending (future) posts.
I'm sure this is confusing. Any help with the language that might make these options clearer is much appreciated. Also ideas for other settings.
Fixed the problem with "use your own HTML" pages not recording hits for the referer log. Tom brought this to my attention and it turned out to be a little more difficult to track down than I had thought. Turns out that those pages were correctly recording hits, except in the situation where all the content is just put into the template (and nothing is [post]ed.) This turns out to be a reasonable way to build these pages, but it isn't the way I had in mind when I designed it. The original idea is that the format and graphic design elements would be entered on [editpage] into the HTML field, but that you would still post the "real" content through [post].
In any case, it works fine just to make the entire page inside the template. Hits will now record. The only possible draw back is that the search engine won't find text on that page.
Fixed, finally, the 2002 archive bug. This caused problems with the framed view of the archives for sure. Not sure about the regular view. In any case this will be a problem again after 12/31/2012 but if we are still using this code base then this will be the least of our problems.