As of a few minutes ago, Kirsle.net is no longer powered by Perl. Instead, I've been working on a new content management system written in Python to replace it.
The reasons for the switch-over are numerous:
index.cgion Kirsle.net was sucking up so much memory.
I named the new project Rophako, because I was sitting at the Github "new repository" screen for a half hour trying to think of a name, and ended up just making use of my Azulian Translator to come up with a name. So, Rophako is Azulian for "Website." I'm a clever genius, I know.
You can check out Rophako on Github: https://github.com/kirsle/rophako. The "default website" that comes with it isn't very polished yet; I literally just finished writing the code to support Kirsle.net. So, sometime later I'll tidy up the default website and have a working copy of it running on some subdomain like rophako.kirsle.net.
Anyway, this is the new CMS. I ported over all my old blog posts, comments, comment subscriptions, and things of the sort. All the old URLs should work too, due to my kirsle_legacy.py module in Rophako. If anybody finds any broken links or issues with the site, let me know.
I've polished up Rophako's default site and have an example running here: http://rophako.kirsle.net/
That's the site you'd get if you download and install Rophako (minus the blog posts and photos ). So... the project is officially in "beta" status now and is usable!
I've now enabled Taint Mode on my Siikir CMS, for Kirsle.net, Siikir.com and RiveScript.com (which now runs the Siikir code as well).
Fortunately it wasn't too difficult to fix my code for taint mode to work. I was already centralizing my various string filtering functions to a small handful, which just needed to untaint the strings before returning them.
Then it was just a matter of making sure I ran these filters everywhere that a user ID gets passed into a function (I was relying on the fact that my
userExists() check would fail if you give a bad user ID number, but the variable was technically still tainted so I had to fix that properly).
I've thoroughly tested all areas of my sites to make sure nothing broke. Hopefully I didn't miss any.
Today I've implemented "Log in with Facebook" support for my Siikir CMS (and as of now, it is only live on Siikir.com and not Kirsle.net; it probably won't be enabled on Kirsle.net because this is a sort of "single user" site).
So I've decided to post about a fleeting thought I once had, about where the Siikir CMS may end up one day (specifically, for Kirsle.net). Just to clarify, both siikir.com and kirsle.net run my Siikir code; they only differ in the pages and web design. The back end is kept in sync between the two.
I increasingly dislike Facebook, but I'm sorta stuck with it because it's the only way to keep in touch with certain people. There are a few open source, distributed social networking projects, such as Diaspora and GNU Social. The idea of these distributed networks is that anybody can set up their own Diaspora or GNU Social server, create their account on their own server (or let their friends or family create accounts), and they can still connect with millions of others who have accounts on various different servers.
They do this by utilizing open standards like OAuth and OpenID to share content between the servers. In theory, every Diaspora server should be able to communicate with every GNU Social server, even though the software is different, because they use the same protocols for sharing data.
I'm not interested in creating a social networking platform for the sake of creating a social networking platform. I'm more interested in finding something to replace Facebook for me. This is the primary goal of creating my Siikir CMS. I built it because I wanted to run Kirsle.net on it, and so Siikir supports web blogs, photo albums, messaging and commenting.
This way I can keep my blog and photo albums and things on Kirsle.net instead of on Facebook. But, I'm slowly adding Facebook integration into the Siikir CMS, so that eventually, I'll be able to post new photos on Kirsle.net and have my Facebook news feed automatically notify my friends to come and check them out. This is the short term goal; the long term goal is to implement OAuth and other standards so that Siikir can link with Diaspora and GNU Social servers.
In other words, Siikir may eventually grow up to be a distributed social network platform like Diaspora... even though that isn't really its goal.
(siikir.com will probably remain as an isolated island to itself, because it doesn't really fit the model of "general purpose social network." But if the Siikir code gets to this point, it will be released as an open source social networking platform)
I decided I'd take some time today to investigate setting up mod_perl to speed up Siikir.com and Kirsle.net, because some of the page load times on both sites were just unacceptable. They both run well on my local dev server (using all the same data as the production server), but I suspect some combination of a slower CPU or slow file I/O time on my production server is the culprit.
With mod_perl, the Apache server would run its own built-in Perl interpreter which would be re-used between requests, so that the overhead of having to load the Perl interpreter for every request goes away.
I tested it on my dev server first, and got it all set up and then realized it doesn't work with mod_suexec. With mod_suexec, you can have multiple users on the web server who each have their own websites, and their Perl/CGI scripts will execute in the name of the user instead of as the global Apache user. So then, it makes permission handling easier: the Perl script can read and write files owned by the same user who owns the entire website. But, with mod_perl, the Apache user executes the Perl scripts and this causes problems.
So I found an alternative: FastCGI. It's black magic to me, but it works similarly to mod_perl (reusing the same Perl process for multiple requests), but it does work with mod_suexec. So, I've gotten Kirsle.net and Siikir.com to both use FastCGI now, and, well, both sites run a lot faster.
Every request still creates its own unique instance of the Siikir CMS object, but I did tweak my JsonDB plugin a bit for performance too: while every request has its own CMS object, the JsonDB plugin is always a singleton object--it is only initialized once, and then it is shared between every request. Also, it caches the DB documents when it reads them and keeps the cache in memory until the document changes on disk. So this helps tremendously with the file I/O problem on my server. Running the search page on Siikir.com gives results in less than 3 seconds, whereas before it would easily take 10 to 15 seconds.
I'm still keeping a lookout for new bugs that may emerge, though. I have to test and make sure the JSON document caching is working properly, for example. But for now everything seems to be working out pretty well.
I've updated the CMS that powers kirsle.net and Siikir again. New features now are:
* There's an admin GUI for reconfiguring the site's plugins (not useful for end users)
* All photo thumbnails are now square shaped. I'm using the jQuery Jcrop plugin for this.
* Comments on everything by a guest user now supports Facebook Graph API to login with Facebook.
These changes are now live on both sites. Also, the web blog and photo commenting code is live on Siikir now too (but blogs are still for admins only until I work out a safe way to restrict HTML for the regular users).
Everybody's existing photos were automatically cropped down. New photos uploaded get cropped automatically, but the user is immediately given the option to change the thumbnail himself. You can also re-crop the photo at any time from your photo view page.