...more recent posts
I'm not sure how to handle a problem that has come up under testing. So I'll try to explain it here as if it were important for anyone else to understand it, and maybe that will help me decide.
The problem is that now it is possible to swich back and forth between chronological, alphabetical, and numeric page types. Chronological pages use time (although through an intermediate layer, so it is possible to [edit] a post and change it's position on the page without changing the 'posted by x at ....' datetime.) Alphabetical and numeric pages each use a serperate field in the database for keeping track of those keys which are used to order the posts either alpahbetically or numerically.
So if you make an alphabetical page, fill it with some posts (supplying an 'alphabetize by:' key with each post,) and then switch it to a chronological page, there is no problem. The system uses the datetime of each post to determine the new chronological order. And it doesn't erase the 'alphabetize by:' key, it just ignores it. So then if you swich back to an alphabetical page type the page will return to the old alphabetical order. Cool.
The problem happens in the other direction. If you make a chronological page, fill it with some posts, and then switch it to an alphabetical page, the system will have no 'alphabetize by:' information to work with. If the newly alphabetical page has its window set to zero (infinity - every post displayed on the page) then all the posts will print out. But if the window is set to a number less than the total number of posts, you will see just that number, but with no link at the bottom to see the next page worth of posts.
The solution is to go into [editpage] and set the window to zero, then you can access every post from the page in order to [edit] and provide an 'alphabetize by:' key. But I don't like this because it is not readily apparent what is happening. If you make the switch to an alphabetical page, and have a window, then it appears like some of your posts disappered. That is not good. Seems like there should be a warning or something letting you know what happened.
But where does the warning go? I guess when you submit the [editpage] that makes the change from chrono to alphabetical the system should check for this scenario and then warn you before returning you to the page. Maybe it should force the window to zero as well, so that when you are returned to the page after seeing the error message you will at least have access to each [edit] link so that you can fix the problem.
Or maybe all the posts should come up on the error screen together with the 'alphabetize by:' field so you can just fix everything on one screen instead of having to click each [edit] link. That sounds like the best option, but what if there are 500 posts on your page? That will make a pretty big error page. Hmmm. Maybe it's still OK.
Anyway, this is the only problem I am finding during some pretty intense testing. I want to write something soon about testing. It's just dawning on me that "real" programmers have very strict methods for testing code. To the point where it seems that a major part of any software project is to design an additional piece of software that can test the first one. This is something I still don't understand, especially in any formal sense, but just through knocking my head against the wall I'm beginning to understand intuitively what is necessary. And it's way more rigorous than the "just try a bunch of different things by hand and try to break something" approach I've been using. I'll have to consult one of my real programmer friends about this issue.
[Update: Here's some convoluted explanation of what I changed the other day. I had this waiting in 'preview' mode until I squished a few remaining bugs.]
I'm in deep today. Possibly I caused some problems as I made a lot of changes. Here's the summary:
[create] is now slightly different, but probably you won't notice. I had neglected the 'alphabetical' and 'numeric' page types because we don't really use them on this site - but I need those page types for building other kinds of sites with this system. Alphabetical pages are now fully integrated, and I should be finished with numeric pages by the end of today.
An alphabetical page behaves like a regular page except that when posting, instead of a field below the textarea box for a 'summary headline:' you see a field labeld 'alphabetize by:'. Whatever you type in there will be used as a key for alphabetizing (but not displayed anywhere in normal - non [edit] - viewing.) Depending on which way the direction of the page is set, this means that your posts will be ordered by the 'alphabetize by:' key in either a -> z or z > a order. The window ('number of posts to display on the page') works the same way.
For example, you could build an address book type page using an alphabetical page. Each entry would be one post. Each post would contain the person's name, address, phone numbers, email, etc... and then in the 'alphabetize by:' field you could put the last name followed by the first name. To add to the address book page you just make a post to the page. When you view the page it will always list all posts in alphabetical order (by lastname, or if there are duplicate last names, by the full name.) No matter what order you make the posts, they will always appear alphabetized by whatever key you supply.
Numeric pages are exactly the same except that instead of 'alphabetize by:' field there is 'numeric order by:' field. Of course this works the same, except you supply a number and not a text string.
Chronological, alphabetical, and numeric pages can each be presented through any of the page templates. (This was not true before.) So you could make an alphabetical page that is a slide show. And you can swich back and forth between them.
Probably these changes aren't of too much use to anyone here, but they make everything much more consistent from a theoretical stand point.
Similar to the [edit] fix yesterday, posting to a slideshow will now result in you being returned to the just made last post instead of to the top (front) of the slideshow.
Changed [edit] so that when you are editing a post on an archived page (whether the page has a .../pageback/... or a .../date/... URL) you are automatically returned to that page after the edit instead of back to the top (current) page.
There is a new [editpage] as of today. Mostly it is the same. There is some basic explanation of some of the controls now. You can see these explanations by clicking the appropriate [?] links on [editpage].
You can now switch between all page types (you can switch a standard template page to a slideshow, or a slideshow to a use your own HTML page, etc...)
Some subtle bugs were fixed when you changed a page's direction (from, say, newest post at top to newest post at bottom.) You should be able to switch back and forth now without problem. Also, if you do have your page set for newest post at the bottom, and you also have more posts than the number displayed on the page (i.e., if some are already retired into the archive) there is now different wording for the automatically inserted links to move forward or backwards through the archive a page at a time. Before the links said '...more recent posts' at the top and 'older posts...' at the bottom. This only made sense if your page was oriented with the newest on top. Now the system is smart enough to recognize if you have the newest at the bottom, and it says '...previous' at the top and 'next...' at the bottom.
This had the nice result of changing the URLs for slideshows (which by default have the newest post at the bottom - although this can now be changed as well.) It used to be /some/slideshow/pageback/xxxx for the link to the next page and /some/slideshow/pageforward/xxx for the link to the previous page. That always annoyed me. Now the URLs are better: /some/slideshow/next/xxx for the next slide and /some/slideshow/previous/xxx for the previous slide.
Also the 'use your own HTML' page is now created slightly differently. Only one box is used for all the HTML, and you must specify inside your HTML where you want the posts from the database to go. This is very powerful and flexible, but a bit confusing. It is documented on [editpage] if you click on the [?] by the HTML box.
(Tom, your 2 'use your own HTML' pages have been updated accordingly, but it's basically the same since you weren't using any posts from the database on those Doris pages.)
Similarly, page includes are now documented, and they use a new syntax that is in the same style as that used for inserting the posts on a 'use your own HTML' page. The old syntax still works, but is no longer supported.
As discussed last night, I ran all the public pages through the auto post summary generator (it just takes the first seven words of each post that doesn't already have a post summary, strips out any HTML tags, and inserts them, followed by '...', as the new post summary.) You can use this on your page if you want by invoking the URL:
http://www.digitalmediatree.com/system/post_summary_fix.php?ppath=/some_path
where '/some_path' is an actual path to a page that you own (like /treehouse, or /arboretum, or /schwarz.)
This will not overwrite any existing post summaries. You will see a printed list of all the new summaries it has inserted when you run that script.
There was a problem very recently (thanks/sorry Dave, Linda) where if you needed to log in you were met with error messages and no way to proceed. This wasn't really a bug, but just a case of a script file becoming corrupted. Should be working now.
Dave had a suggestion to make the bottom menu bar less complicated. This turned out to be easier than I thought it would. You should no longer see options that are not valid for you on a given page (you don't see [post] if you can't post; don't see [editpage] if you can't edit that page, etc...) This is just the sort of issueI have a hard time identifying: What? It's not all perfectly clear?
Fixed a big problem with pending posts. Fixed a small problem with the email to weblog bridge. There still might be an issue there if a lot of people tried to use it at once. Not sure though. Hard to test. Probably we won't use it here very much, so I might have to wait to find out how it does under load.
In making the new email posting capability (see last post) I created some of those never clearing 'new posts' for everybody. So I cleared everybodies unread posts for this page. Possibly you missed some actual real posts. You might want to lookback if you are coming here from [1 new post].
Seems like this new email to web connection is a little rough around the edges. I'll keep working on it. Thrilled to have gotten this far though.
Now if only I had a blackberry.