The kBlog System: FAQ
Jon Nileprecinct Feline
How did this project come about?
After more than a decade of experience Ive decided its finally time to add a voice to my webpresence. Ive got all the blog accounts but theyre impossible to use, & Im not going to run my own server just so I can customise some css. I need absolute control over the layout & the management of the posts & I need to be able to place the blog on any ordinary (free) webserver of my choice. To implement the "look & feel" of a blog there are some issues concerning common code which have to be addressed, particularly with respect to maintenance.
Whats wrong with mainstream blogs?
The layout generally can only be customised in a limited number of ways. Plus youre locked in to their post management method, usually an editor window which permits at best a subset of HTML tags in the text. Most significantly the chrono ordering of posts is a nightmare. If you go back & correct an old post it may wind up with a new date, & sometimes to desquirrel something you have to repost it completely. If you want a standard "welcome" post on top you often have to keep it reposted as the most recent document. Finally, a web-based blog interface is like web-based eMail. Once you understand the internet you dont want the overhead & intransigence of the interactive connection.
What dont you need from blogging software?
Im not up for the community aspects & comments; I can leave that for another site. I also can do without search capability & the various types of automatic indexing, calendars, &c. Historically the blog helped replace usenet & other unnecessary bandwidth abuses simply by providing a place to publish other than ones eMail outbox. Perhaps Im actually creating a wiki, but Im still calling it a blog.
What are the options for engineering blogwrapper code for posts?
So how does it work?
First of all, the code & documents are composed / maintained on the local machine via the preferred editor(s). Source posts are kept in an absolute de minimus form as ordinary ASCII text files. Although not a complete webpage, a post contains HTML markup beginning with a standard header which is a table containing the title & date. The rest is text in wrapped paragraphs & whatever further explicit HTML is desired. Second, complete webpages are generated by the "blog compiler" which assembles them by pre- & postpending the blog wrapper(s) around the individual posts. The gen script (below) issues one cat command for each member of the document store. If a change is made only to a single document, it can be regenned by itself. Alternatively, all documents in the system can be regenned when a change is made to the common code.
echo building blog posts ...
# generate blog posts from data & component pieces
cat zdxhi01.htm s$1.htm zdxin01.htm zdxlo01.htm > i$1.html
cat zdxhi01.htm sdxindex.htm \
zdxin01.htm zdxwc01.htm zdxlo01.htm > index.html
Finally, after examining & testing the generated codebase via the local browser(s), the object files are transferred to any ordinary webhost via ftp. This assures (1) the integrity of the source documents, (2) the blogmeisters complete control over the blog layout, & (3) painless refreshing of the *entire* blog at any time. If you glance at the source to any of these pages youll see theres nothing to it.
What are the considerations for the design of the blogpage?
A good webpage renders viably on a wide variety of browsers & platforms & avoids horizontal scrolling. At this writing I test my pages on Firefox, Netscape, Opera, Explorer, & Lynx (XP), & on Firefox, Opera, Lynx, & Links2 (Linux). I try to use the most trivial possible HTML including ordinary <table> tags for the sidebar. To this day I remain a dedicated 800x600 user & expect the page to expand or contract properly whatever the resolution, & to look good in text mode. Although it is good practice to avoid specifying explicit pixel widths for areas, images, & tables, this is not all that is needed to achieve universal scalability. Proper text wrapping seems to have been universally achieved in all contexts under (almost) all browsers, but images remain another issue.
What is width="100%" of the "available space"?
Consider an ordinary blog post with an inline image & perhaps an inline table. Elementary rendering would be in the entire screen width where "available space" is almost a redundant concept. But browsers are also supposed to support content "flowing" around items aligned at the screen edges, & content rendered inside a table cell. Here "available space" is narrower than the screen width & in the former case is actually subject to change. For historical reasons specification of a 100% width on items which accept it (images, tables, table cells) is the most bugfree option yet is still sometimes handled in unexpected ways. Notably, in a flowing area most browsers interpret 100% as screen width, not rendering an image until the area is that wide, & doing the same for a table or actually rendering it in situ. This is why Ive contained the posts in a table cell which generally respects the 100% for use in scaling (although entailing issues with search engine visibility). The lone exception is Explorer which in a table cell actually interprets this as a percentage of the *image* itself. Proper scaling must be done with the IE proprietary conditional code & specification of width in pixels narrower than that expected in a hapless IE users session.
Arent you going to need an index?
Absolutely. But its just another HTML page I have complete control over. Like the lines in the shellscript above its just a bookkeeping task & should I choose to keep crossreferences explicitly by topic or date Ill just keep them uptodate by hand. This also implements flexibility over the entire document store in case the nomenclature conventions evolve or I wind up making other types of global changes.
Are you really prepared to upload potentially hundreds of regenned documents for every one character change in the sidebar code?
You bet. Even if the blog layout doesnt stabilise (which I doubt), 100 20K posts is still only 2M, & if the documents themselves havent changed, any inline images dont have to be uploaded again. My approach clones a bit more code but the resulting webpages are rock solid. & the fact is a onetime gen / upload is technically superior to a PHP/SSI expansion each time the page is served.
Are you serious about that server?
At this time Ive not used 50webs alot, but if they dont work out Ill just take the whole system & put it somewhere else. Their response time isnt that slow & their ftp access seems quite robust. Their 500K filesize limit wont affect a blog too much & I keep MP3s & big images elsewhere anyway. I particularly like the combination of *no ads* along with 60M of storage. Thats (eg) 3000 20K documents which is a fair amount of blogging. Maybe Ill write an article or two.