Navigation
Project: CoreServer
13 April 2009
I tried to get Apache to run Ruby scripts like it would a PHP script. I know PHP, but it and Apache are huge. So, then I remembered Ruby's wonderful GServer class. It takes from TCPServer, which is as low as it gets: I had to write my own packet handlers for POST and GET requests.
Out of all of this came CoreServer, a 5.5kb (zipped) collection of 4 Ruby scripts, which work together to give me the two things I wanted:
- A working HTTP server
- Ruby web scripting
Currently, version 0.5.5 supports:
- Display of whole HTML pages
- Wrapping a template around HTML snippets
- Executing
.rb(Ruby) pages - Support for GET and POST variable types
- Conversely, support for HTML forms
- Easy extendability through Ruby code
- Aliasing pages to functions1
- The
Widgetobject $()— a reference todocument.getElementById()
It's still being developed, but will work with just about any Ruby installation. Note that Windows users will need to follow this guide to fixing 0.5.5, since it uses a Linux command that you guys don't need.
Anyway, if this looks like your thing, it's worth a shot. By default, it opens a webserver at http://127.0.0.1/, so there's no threat of anybody outside your own computer (AKA you) accessing. You could probably run it on a LAN and whatnot, but I've yet to try
1 Basically, you alias a page name to a Ruby command. Say you want to show the server information, and you have a function that does that: serverInfo(). You simply set @alias["server_info"] = "serverInfo()". What that does: all requests to http://your.site/server_info don't make CoreServer get a file named "server_info"; instead, it executes the function you provided!
Widgets — Javascript UI
5 April 2009
Everything that needs to be done on a page can be done through jQuery, MooTools, or one of a hundred other frameworks. But what about when you need something a little more... user-friendly than plain text & links? That's when you have to add another 40 or 50 kilobytes for jQueryUI and the like. And when all you want is easy access to the same HTML buttons you've always used? Just plain old <input> tags you can reference from your JS code easily? You have to code them yourself via some fairly complex HTML or Javascript.
That's what Widgets is for. It sets up two things:
More info can be found on the Widget project page (should be up soon), along with a basic manual for the Widget object.
Spammin Comments
1 April 2009
Well, it would seem this little site has attracted some spammers! An imminent security patch for Comments, release 7, will have some anti-spam built in in the form of a CAPTCHA. This site's currently running Comments 7 RC1, which is testing out the system. It's also got more informative and sarcastic error messages ("You do not appear to be human. Try filling out the captcha next time."), so admins know exactly what went wrong. Speaking of admins, the admin panel has a few minor improvements, such as the addition of a "Continue moderating..." button, so you don't have to remember what page you had selected.
I'll see how it goes. If the spam on the comment threads lowers, then RC1 will be released into the wild. If not... I'll have to find a more complex solution.
Questionable Project: "Categories"
30 March 2009
I've been brainstorming over the last few days, and thought I might put up some documentation for my apps/tweaks/whatnot. However, Projects would very quickly get cluttered with a bunch of pages named docs_vcssh_main. So, the solution? Namespaces!
If I decide to go through with it, Categories would let you make sub-folders in the pages/ directory, which correspond to the categories you have set up. The way it would work is the same way as Wikipedia's system... say you have a URL like this: http://www.site.com/index.php?slug=overview:contents Categories would see the colon (:) in there and intercept the string before it, which is the category. In this case, you'd be accessing the "contents" page in the "overview" category (pages/overview/contents.php).
It's just a thought... Not all NanoCMS sites would need it; most probably won't. But I might develop it just for my own uses. I don't know how much code it would need, but it doesn't seem too complicated on the face.
Comments Tweak 6
28 March 2009
Another release of the Comments Tweak is at hand! The Javascript exploits, mostly along the lines of [url=javascript:exploit()], used to be a wide-open security hole in Comments. However, this isn't a problem any more. Release 6 has improved code clarity, along with this fairly major update.
For those interested, the way it worked was thus: The BBCode filter was run before /\[url\=javascript:(.*?)\]/ was searched for. The result? A lot of <a href="javascript:">, since all of the [url]s had been turned into anchors/links already! I managed to miss this for a while. Once this was found, and the search moved up to before the BBCode transformation, the problem was solved.
