With the way I have SAFARI setup, I have asisaid as a testbed, and then all of the other SAFARI enabled sites feed off of one codebase to which I push out updates. I did such a push a few days ago to fix the disabled comments bug that was affecting Ed's blog. Silly as I am, I didn't check afterwards to make sure everything was still OK on my church's site, which also uses SAFARI. As it turned out, I killed off most of the site because of a small bug that hasn't been a problem on the other sites.

Keeping the code centralized is good for saving time doing updates, but has its disadvantages...

Just a heads up: I’ve corrected a bug on the “Recent Comments” page that caused the entries to be semi-randomly sorted. With this fix, the latest comments are again placed at the top of the page.

The road to 3G SAFARI is progressing! Let me know if you see any bugs. For those of you who read Ed’s blog, I’m hoping to get this and some other fixes deployed there very soon.

Well, I enjoyed my brief moment as t3h l33t subquery h4×0r, but in the end, subqueries seem to fall flat on their face. Two queries with subqueries were taking SAFARI 7-20 seconds to run, a totally unacceptable speed, especially since my goal with SAFARI was to build it in such a way as to allow it to be Slashdotted without performance problems. Conversely, using a join statement, I accomplished the same effect while reducing the processing time to less than two seconds (how much less, I cannot yet say, since I’m still working on developing the perfect query, but I’m expecting it to drop below 1 sec before I am done).

The road to the next generation of SAFARI progresses…

Update (10 July 2006 12:14 AM): OK, so I wanted to see if I could count the number of comments in my comments table in addition to comparing the objects (metadata) and articles (normal article stuff) table all in one query for efficiency. I ended up with what might be best termed a hybrid solution: the meat of the problem is taken care of via two LEFT JOINs, the latter one joining the results of a subquery to the main results. It seems reasonably efficient: it takes a mere 0.0274 seconds to process! How ‘bout them apples?

As you may recall, I recently discovered subqueries. While everything should seem functionally the same, you'll now be receiving subquery produced information when you view category pages. I think everything seems to be working OK thus far, although the subqueries seem to be a bit slower simply doing several queries, which suggests to me I must not be doing something right -- why would initiating multiple queries be faster than one complex query?

Hopefully, I'll continue working on adding functionality via subqueries in the near future.

Oh, and about commenting or the lack of the ability to do thereof: I think I finally fixed SAFARI so that commenting should be on by default on asisaid. I'll be distributing that minor bug fix to other SAFARI-powered sites, such as Ed's, once I stabilize the subquery work a bit more.

Mark pointed out to me that I had disabled comments on new posts -- not something I intended to do. If you tried to comment in the last day or so and found yourself unable to, please try again.

I'm sorry about that! I should be more thorough in checking my code. Sheesh.

Here’s what I need to do soon to SAFARI 2:

• Implement per post comment_disabled flag. (I promise this to Ed a long time ago.)
• Create query string option to use alternate themes (e.g. for optional front pages that don’t look blog-like.)
• Implement metadata editor allowing editing of any standard metadata as well as addition of unlimited custom metadata.
• Allow data to be limited based on any metadata, not just category.
• Streamline category/metadata selection mode to use MySQL sub-queries.
• Rework search engine from SAFARI 1.x flat file database support to SAFARI 2.x SQL database system.

Launch of the new, reworked Open for Business.

Lower priority goals:

• Implement user-end of multi-level threaded commenting.
• Finish auto-caching spider for high traffic readiness.
• User registration tied to e-mail address verification.
• User-only comment posting restriction mode.

This will make SAFARI 2 functionally complete.

SAFARI 2 Release Candidate Goals:

• Rework inefficient subroutines, removing 1.x legacy code.
• Verify SQL injection protection.
• Decide on and reveal new name (too much confusion with Apple Safari web browser, even though SAFARI the CMS was first.)

My good, if backward, friend Ed has been missing from the blogosphere for about the last six months. If you didn't notice, don't feel bad. He only disappeared for me, or so it seems. For whatever reason, WordPress took a disliking to my IP address, and I could only view Ed's blog erratically for most of the year and not at all since July. Whenever I'd open the page, it would say there were no entries. I knew there were entries from looking in the Google cache or viewing his site via ssh from another computer, but any of the computers on my network -- Mac OS X, GNU/Linux or Windows -- could not view it regardless of browser.

This was doubly frustrating since I host his site.

Fortunately, Ed had agreed back in July to make himself a willing guinea pig for SAFARI 2, the same software that runs asisaid, and will be running at least four other sites within the next two months. I decided to make Ed's blog the first site -- other than asisaid -- I'd actually deploy SAFARI 2 to. It was a bit of a puzzle to figure out how to convert the WordPress database, but he is now up and running with a nice theme he designed that matches his two other sites.

The best part of all of this is that I can actually read his blog again!

Does this work right? I hope it does, because everything looks right in the code…

I’ve added some new stuff tonight. Now, you can use any of the smilies supported by WordPress on my blog (I shamelessly borrowed the graphics and related material out of WordPress so that SAFARI could do this ). I borrowed JavaScript code from Alex King's wp_grins so that you can simply click the smilies of your choice below the comment box.

You'll also notice a new "others said here" section on the side (to be distinguished from the old "others said" section that is now known as "others said elsewhere"). The two links there will take you to a "forum view" that shows the blog posts that have the most comments and the most recently commented blog posts. The latter differs from typical "recent comments" sections on blogs in that it does not list every new comment individually, but instead shows the posts that have been commented on, rather like the way phpBB shows topics that have new replies. This insures that one busy post won't hide activity on less busy posts; this is not usually a problem, but keep in mind I'm designing SAFARI to work on bigger things than asisaid. The inspiration of using a forum view for this comes from Kevin's blog from long ago that was based on phpBB -- I always liked that concept.

Give the new features a whirl and let me know what you think.

Awhile back, I made the decision to retain the UNIX time stamp system of dating within SAFARI, which I had started using when I first created SAFARI to be used without a database. The UNIX time stamp (seconds from the UNIX epoch of January 1, 1970) is easy to process in Perl, which makes it attractive to work with.

Big problem: this means more of the date processing must be done after a given piece of information is fetched from the db. If I was using the MySQL date-time field format (2005-03-13 16:12:30), I could do some processing within the SQL queries and therefore streamline things. Therefore, I’m going to undertake switching SAFARI over to this, right now. Unfortunately, SAFARI’s sandbox that I built shares the database with the live asisaid copy of SAFARI, so while the code changes won’t go into effect over here until I have things working, some things might behave oddly.

Update (2005-Mar-13 18:50): All done. Now on to fixing things to use my time zone (central) rather than UTC.

Update 2 (2005-Mar-13 19:45): The time zone is now appropriate too. That was a bit more difficult. As it turned out, I had accidentally set my code to store posting dates in Eastern Time (well, or more properly, to use the server’s localtime(), which I have set to Eastern for the sake of matching other U.S. servers, despite the fact that it is in the Central time zone). So all posts from the old program were in UTC/GMT, but all after around noon on December 24, 2004 were in EST. Therefore, I put together this little SQL query:

SELECT cid,FROM_UNIXTIME(UNIX_TIMESTAMP(gmt)+18000) FROM uninet_comments WHERE (‘2004-12-24 12:00’ <= gmt)

Afterwards, I exported the resulting output and did some regex magic to turn the insert statements into update statements:

s/INSERT INTO `uninet_comments` VALUES ((.*?), ‘(.*?)’);/UPDATE uninet_comments SET gmt=’$2’ where cid=’$1’;/sgi;

Finally, I took the those SQL commands, fed them to MySQL. Rinse and repeat for the articles table.

After that, it was a simple matter to add the new time zone adjustments within SAFARI to take the GMT time information and convert it to Central Standard Time (UTC-6:00). Now, I just need to figure out how to implement daylight savings time support, so that posts and comments posted during DST will be UTC-5:00 without making standard time posts and comments switch as well.