root log: September 2001 (thing)

oppressor_superdoc nodetype and the sort of experimental proposed node_forward nodetype. node_forward did something like what firmlinks do, except it was more brutish and mysterious: You didn't get the option of going to another node; rather, it just put you there, silently. We decided to use Jay's firmlinks instead.

Created the debate and debatecomment nodetypes, along with sundry htmlpages, an htmlcode, Everything Discussion Directory, etc.

It's a threaded discussion deal. A debate node is the root of the discussion, and debatecomment nodes are comments. At present, debate is readable by gods and content editors, and createable by gods. debatecomment is createable by either. That's the nodetype permissions: There is also a flag to limit read access to gods only. My next move will be to repurpose the flag field as a usergroup id, so, for example, edevsters will be able to have discussion nodes that only they can see, etc.

I've thought of whipping up a document type with a usergroup ID field, which would work the same way. Then again, is that really needed? It seems to me that most restricted_superdocs and edevdocs can and should be replaced by variously-restricted debate nodes. I'm tempted to add a "no more comments" field to debate and leave it at that.

I have some concern about the whole debate node deal. It's not what E2 is really about. We've striven like hell to discourage "response writeups". As far as these are used as support for our real "mission" here, they're a Good Thing: edev could really use 'em, for example. It's not so good to mix the metadata in with the data, so to speak, so it'd be nice to keep edev discussions out of e2nodes. e2nodes are just plain lousy for discussions anyway: That's not what they were designed for. These can also help cut down on the torrent of /msg traffic among the e2gods, content editors, and edev usergroups. Nevertheless, we need to keep an eye out for abuse, especially if we start allowing more users (edev, etc.) to create them.

We still need some usability tweaks with this. The "compact" displaytype should be the default, I believe.

• Much fiddling with ekw theme. Fixed the linkiness in the logo, added more options to ekw Preferences and to the theme itself, improved the CSS deal (the stylesheet's MIME type is now text/css, as it should be, rather than text/html as it was for a while), finally got it to use ekw nodelet container. The stylesheet URL is now being pulled from $$THEME{ 'CSSURL' }. This has... IMPLICATIONS! Dig it. One thought is to allow users to do a full stylesheet in a $$VARS thing, and write a rawdata page that'll serve that. Or you-name-it, really. Let 'em do file:// URLs. Indeed.

  Just about all of the nagging problems are cleaned up now, is the main thing.

• Added class="oddrow" to <td> tags in odd-numbered rows of the tables in displayUserInfo and newwriteups htmlcode. This allows CSS to override the default colors there, without disturbing the code very much, without doing anything theme-specific -- and without breaking anything for users who don't have CSS support: The old color attributes are still in place. ekw theme is the only theme that takes advantage of this at the moment, but gosh darn it, most of them should, eh? I intend to add the class attribute to odd-numbered rows in Everything User Search, ENN, etc. The hardcoded "one size fits all" odd-row colors in these things have always been a cancer eating away at the heart of our little community here. It'll be good to sweep 'em under the rug. Of course, we could simply add an oddRowColor setting to all the themes (why didn't anybody do that before?!), but this gimmick works with ekw's personal-color-choices deal, too (or that of some other theme, if somebody else picks up that idea). Spiffy.

• E2 Word Counter. By the way, superdocnolinks is a nice way to do JavaScript stuff without jumping through any hoops to make regular expressions work.

• Spam Cannon: A superdoc that lets the user send a single /msg to multiple recipients in a single page load. This is gods-only at the moment, but the intent is to open it to content editors and make it a level power for all users, probably level five or six. It needs a little polishing before it's ready for end users: usernames can appear more than once in the recipient list, for example.

• Bouncy bouncy.

• More CSS hijinks: displayvars and editvars are htmlcode things which display tables. The cells in those tables have hardcoded pale lavender backgrounds (very nice, if you've got some Dramamine handy). Some themes have pale text, which is unreadable on those backgrounds. Therefore, I added some CSS to both of 'em, so the text in the cells is now #101010 unless the user doesn't have CSS, in which case s/he's no worse off than s/he was a week ago.

• Changed groupeditor so that for each item in the listbox, it appends the author_user's name. That way, you can actually see what the hell's going on.