Wedge

Hmm, built for Win95, so it's likely been modified internally to run on newer Windows versions but yeah, that should run like ****  off a shovel on a modern PC, assuming they haven't broken the timing logic in making it work on later versions.

No, I didn't, heh.Because the context is different, and has different settings in regard to what's really needed. Albums let you set read/write per group per album[1] but there's no deny per group.

Even if we, for the moment, transpose read/write as view/enter, we've still got to somehow convert the per-user disable read and per-user disable write into something that works for groups, which means you have three states per view and three per enter (as opposed to two which can be meaningfully represented with a checkbox)

I'm also not sure about setting a password per board, though it is requested often enough on sm.org.

(Also, in an album configuration in Aeva, you can set per-user grant and per-user deny. If you put the same username in both, what happens, out of interest?)

1.	Doesn't cleanly handle inherited groups but I think that entire concept is semi broken anyway.

Pssst, you know I implemented it already, right? Ages ago I rewrote the old query_see_board to become query_see_only_board (later query_list_board) and it's all stored in the board_groups table ;)

The one downside is that I *still* haven't fixed the UI for it in the admin panel, even though it's like months later, because I still haven't figured out a non-ridiculous way of doing it that I like. (It's certainly going to be an improvement on it being a true and physical permission like my mod was)

I would not perform htmlspecialchars on the client side. I would leave it as is, and do it on the server side. Always assume the client is insecure/unsafe.

Strictly speaking, anything that's going to be sent, no matter how indirectly, to the bbc parser 'should' go through preparsecode, and if memory serves, preparsecode does not perform htmlspecialchars anyway, because I seem to recall it's always done ahead of time by other processes.

It's complicated because there are other side matters to attend to with it. preparsecode actually does an insane amount of stuff, IIRC the list in no particular order is:

* convert newlines to br tags (not entirely sure why it does this, I've never fully understood this logic but I'm assuming it's for the benefit of code tags so that you don't try second guessing p tags, and it means if you want a double blank line, you get one)
* validates that anyone using the html bbcode is an admin (or remove the tag otherwise)
* breaks the content of nobbc bbcode so that it won't be parsed (physically convert the brackets to their numeric equivalent)
* attempt to fix table tag hierarchies through regular expressions (table must contain tr, tr must contain td, td must be inside tr, tr must be inside table, list must contain li, li must be inside list)
* convert double space to nbsp+space so they're actually displayed as such
* break instances of [] and [' so that they're not parsed as potential bbcode for speed (e.g. inside people posting code outside of code tags)
* convert /me to the me bbcode
* convert specific colour bbcodes to the generic case (e.g. replace red, blue, etc, bbcode with color=red, color=blue)
* invoke the tag scheme checker to go through img, url and similar tags looking for valid http/s entries and forcing them to have the right scheme
* if images are posted and there is a maximum image size, validate the image's size and rewrite the img bbcode if necessary to include new sizes

It is pretty insane when you think about it! But that's what's required to ensure that any arbitrary posting is safe to be displayed later. (More, in fact, could be done, because it could step through the tags at save time and validate that they are properly nested and so on, and take that burden off parse-bbc)

Long story short, it depends on what you're looking to allow in the thought system. If it's the small list of inline codes, you don't need to invoke the entire preparser, but it will need a subset of the loop at the end of the routine where it splits the post into sections by code tags, most importantly to catch the fixTags call (to sanitise links and/or images posted, though images should probably be rewritten to links anyway!)

You don't need to have it also do the regexps that handle fixing table/list nesting because they're not going to be parsed anyway, so no need to alter them (and I'd suggest not altering the thought for that purpose)

Perhaps there should be a parameter to preparsecode, for inline parsing requirements, where if false, only do what's necessary for inline bbc requirements.This is a problem that has affected many, many people in figuring this stuff out. The HTML to BBC converter is not rugged, but if you're only feeding it the inline tags, it's probably enough.

The last day or so I've been working on a one-off site, pretty privately. The site has a lot of potential to it, and regulars on another forum will probably know what the domain name for it is too. But I'm not prepared to share that here, not yet.

The technical design is one-off, utilising a modified forum backend as the admin area (and only the admin area) while not showing anything of the forum on the regular user side, at least not directly. (The site blog will be using SSI to pull from the forum, the login system will use the forum login core, making use of the API to handle authentication and registration, with comments going back to the forum too)

What I will say is that it will be powered by nginx, PHP, and Wedge (though, really, there's no reason why I can't do it in SMF, I'm not using the forum core, but it will mean I have to fix the API) and make heavy use of the GD or Imagick libraries (might be a good time to learn that really)

But I'm stuck primarily on the site's look and feel (generally; I already have some of the very specific elements on the site planned out and even drawn in some cases).

What I guess I'm wondering is whether anyone has any resources or places they go for general inspiration for design. I don't even have a colour scheme at this point in time; time is the theme of the site, and I did contemplate doing some kind of steampunk clock motif around the border (since the majority of the main content is its own thing), but not sure about that at this time.

Sorry I can't give any details out, trying to keep this one sort of a surprise until I'm closer to being ready with it.

Yeah, it's one of those I already bought on Steam and is currently downloading right now.

Also, in a fit of pique and/or wanting to relive my mis-spent youth, I picked up Sonic Generations.

Holy **** it's fast. I mean, the original is fast but this is faster if any, and in 3D at times :o My machine can't actually cope with it at times because of the animation at such high speeds.