John Crepezzi and I launched GetSparks.org (the CodeIgniter package manager and repository) a little under a year ago, and the response we received from the community was overwhelmingly positive.

The best part of GetSparks isn’t the site itself. It’s a moderately simple app that provides a vehicle for quickly dropping other developers’ code in your codebase.

Many of the packages on GetSparks are very well maintained. I am continually impressed by the amount of effort spark developers pour into their submissions when I peruse the site and try new packages out. One example would be WanWizard‘s DataMapper-ORM: Look at how well thought out it is, and how detailed the docs are.

Another would be codeigniter-payments. I rolled in to the second day of CICon 2011 NYC to find @calvinfroedge talking about a new payment spark he had made — one of the most in-depth, flexible payment libs I’ve ever seen.

GetSparks has almost clocked 50,000 package downloads at this point, but there are handful of sparks that have really stood out in terms of popularity. They are the year’s top 10:

And of course, there are people whose contributions have made GetSparks.org the success it is. A special thanks goes out to:

• Beau Frusetta — First team member (retired), and the guy who made GetSparks look halfway decent
• Mike Pauley — Team member
• Sean Downey — Team member
• Joe Auty — Team member
• Jake Ingman — Who made us a sweet logo
• Joel Cox — For some fine features and great sparks
• Balsamiq — Who donated a copy of their mockup software
• Spicer Matthews of CloudManic, who contributed the “forking” feature (which I have big plans for)

Happy New Year everyone. Keep up the awesome work, and keep knocking out those timeshanks when developing a new app with new sparks (things like payments, emailing, auth, assets, etc).

Note: CodeIgniter Reactor 2.0.2 has a bug in it’s core Loader class that breaks package config file loading (and sparks, sadly). It’s recommended that you use 2.0.1 OR the latest at https://bitbucket.org/ellislab/codeigniter-reactor OR make the following change in your 2.0.2 installation: https://bitbucket.org/ellislab/codeigniter-reactor/changeset/c461483c8ca0 . The last option is the best.

It took a month longer than expected, but we’ve finally released the Beta version of GetSparks.org, the repository and package manager system for CodeIgniter.

Here’s the very minimum of what you need to know:

1. A spark.info file is now required in every spark
2. You should upgrade your spark system as soon as possible (just follow the usual installation instructions)
3. If you submitted a spark prior to the beta, we’ve normalized all version numbers to x.x.x. So curl 1.0 becomes curl 1.0.0. Check the site.

The alpha was all about weeding out fundamental issues in the initial repo and system. The big problems we had were:

• Some spark developers wanted the ability to specify dependencies
• There was no difference between a repository tag and the spark version — They had to be in sync
• Users wanted RSS feeds for latest spark overall, and latest versions of individual sparks
• There was no way to rate a spark
• There was no way to tell if your spark was going to be accepted by the spark processor prior to submission

We knocked those out and a little more with the beta. Going forward:

All sparks must have a spark.info file at the root. Details are here.

• You can now specify spark dependencies in spark.info
• The spark manager will now install a spark and all of its dependencies
• The spark manager can now self-update
• All spark versions must be in x.x.x format. Sparks released prior to the beta had their version numbers change in the system (tags remained the same though)
• Versions and tags are now decoupled. The version is pulled from spark.info
• Sparks are now ratable via a simple “Love”, “Like”, or “Hate” rating
• A Spark-SDK is available to spark developers in order to validate their sparks prior to submission

It is necessary that you upgrade your spark manager with the release. The current version is 0.0.4. You can upgrade by removing the ‘tools’ folder from your webroot and following the same installation instructions at: http://getsparks.org/install

Send any issues to ohcrap@getsparks.org!

Now that the structural changes have been made, we can focus on tightening up the spark system’s feature set. This is what you see in the coming weeks:

• The ability to install sparks in configurations where the application folder is not in your webroot (possible now, but not automated)
• The ability for sparks to act more like modules — ie, sparks will be able to override core libraries and more

Also, we plan to:

• Put a news section on the site (long overdue)
• Configure our notification system better so its emails don’t land in your spam folder

And don’t forget the ultimate goal: Integration in CodeIgniter Reactor.

Check out the beta and ping the team with any problems! ohcrap@getsparks.org

There are a lot of people out there who call themselves “LAMP” developers — short for Linux, Apache, MySQL, PHP. That’s the standard configuration for production PHP applications. Recently, I ended up having to build a CodeIgniter application on Windows, IIS, Mysql+MS-SQL, and PHP. Sound like there are bound to be issues? You bet, and it especially hurts because now I’m a real-live WIMP developer.

And what made it even more interesting was that due to constraints, I had to develop the application in Ubuntu and deploy to Windows for production.

Please keep in mind that I didn’t opt for this setup by choice. The servers to be used were already in place, and well, it just had to be this way. I’d imagine this unholy mix can be found on server farms somewhere around the seventh or eighth circle of hell.

Anyway, the point of this post is to document a few “gotchas” that came up along the way. At this point I should say that application is now happily humming along in production. I knew from the start that mixing all of the above would be a headache, but luckily, things worked out without sapping too much time. I should also say this before I start: Thanks to some great work done by others over the past 2 years, this setup was actually possible.

Gotcha #1: PHP and MSSQL on Ubuntu

Thank god this was so easy. In order to use the standard database functions like mssql_connect, mssql_query, etc, all I needed to do within my existing LAMP installation was run:

$ sudo apt-get install php5-sybase

And sh-bang, I could connect to SQL Server without an issue. From CodeIgniter, I set the database to use mssql as my driver, and I was home free.

Gotcha #2: PHP and MSSQL on Windows

For years, forums and IRC rooms were filled with hopeless requests to get these two to mix. In 2008, Microsoft wrote a driver to help PHP developers seamlessly connect to SQL Server. For Win-PHP installations, just install this gem: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=80e44913-24b4-4113-8807-caae6cf2ca05 . Also, read up on the docs.

That driver uses a different API then the regular PHP mssql_* functions. In fact, it uses sqlsrv_* functions instead. So CodeIgniter can’t work with it out of the box. Luckily I found an excellent 2 and 1/2 year-old post by a guy who wrote the CodeIgniter driver to work with the Microsoft drivers. Just download the code, and drop it into system/database/drivers. Read up here: http://www.kaweb.co.uk/blog/mssql-server-2005-and-codeigniter/

One thing you will have to do to make it work with the latest version of CodeIgniter is create a dummy function in sqlsrv_driver.php. Just drop ‘function db_set_charset() { }’ somewhere in the class declaration.

As a side note, that driver would make a great addition to CodeIgniter Reactor.

Gotcha #3: mssql vs. sqlsrv

Notice that I had to use different drivers for connecting to SQL Server between Ubuntu and Windows. This is why it’s handy to use some sort of database abstraction class like the one that comes with CodeIgniter. All I had to do to switch between drivers when I deployed to the new environment was edit the configuration.

Also, query result fields that are fetched using PHP’s mssql driver come back as strings. The Windows sqlsrv driver gets fancy and hands back field values as objects. Your code won’t have to change for the most part, but beware that MSSQL ‘datetime’ fields come back as native PHP DateTime objects using sqlsrv_*, not strings. In the code, I ended up doing something like: if($date instanceof DateTime) return $date->format(…); else return $date;

Edit: Commenter Brian Swan and Twitter user Juozas Kaziukėnas have pointed out that the sqlsrv_ PHP driver will take a boolean ‘ReturnDatesAsStrings’ option in sqlsrv_connect() that specifies whether datetime fields come back as strings or objects. More info is here: http://msdn.microsoft.com/en-us/library/ee376928%28v=sql.90%29.aspx. Thanks guys!

Gotcha #4: File Permissions and Logging

As the author of WPSearch, a Wordress search plugin which does heavy work with the filesystem, I can say that the number one cause of broken installations is that the permissions are too strict. On Windows, files can appear to be 777 when viewing them via FTP, but on the Windows end, they are set as ‘Read Only’, or ‘Archive’. This throws a serious wrench into things.

When I first deployed to the production server, all I would get for responses was a blank page. Worst of all, the log wasn’t writing anything. After a trace through the CodeIgniter bootstrap, I found that the application died when the logging class was loaded. If your application’s logging threshold is set to write anything, and the logging fails, the application might just crap-out. This is different behavior than I’ve seen on linux, where you just won’t see logs appear in the logging directory, but the overall application still works fine.

Just turn off logging to make sure that empty responses aren’t the result of file permission errors.

Gotcha #5: No .htaccess Fo’ You!

I hadn’t known that I needed to drop the final application into an IIS instance from the start. I learned about that 1 day prior to the launch. Before that, I though I’d be rollin’ on Windows/Apache. Wrong!

IIS doesn’t use silly .htaccess files, which I had only used for standard URL rewriting/prettified URLs. I was forced to decide between converting the .htaccess to an IIS web.config file, or just ditch the prettified URLs. Since it was a small application, I went with the latter. Here’s a nice StackOverflow thread discussing a translation though: http://stackoverflow.com/questions/702526/translating-an-apache-htaccess-file-to-an-iis-web-config

Edit: Juozas had some comments here too: “@_kennyk_  about .htaccess vs web.config – you can actually import .htaccess in IIS URL Rewrite section.”

Gotcha #6: 2 Databases, 1 Application

This is more of a CodeIgniter issue. For this application I had to lookup data in a MySQL database, then use some of that information to pull rows from a MSSQL database. The hurdle revolves around having two concurrent database connections open in CodeIgniter.

You can’t really load the database in traditional CodeIgniter style, like $this->load->database(), or by autoloading it. Something like this doesn’t work:

$this->load->database('mysql-group-name');
# Do Stuff with mysql
$this->load->database('mssql-group-name');
# Do Stuff with mssql

Instead, you have to ask CodeIgniter to hand you back the actual database object with each connection. It’s a good idea to encapsulate each within the models where you’re using them. Do something like this:

class SomeMySQLModel extends Model {
  # the mysql db instance
  private $_db = NULL;

  function SomeMySQLModel() {
    $this->_db = $this->load->database('mysql-group', TRUE);
  }
}

class SomeMSSQLModel extends Model {
   # the mssql db instance
   private $_db = NULL;

   function SomeMSSQLModel() {
     $this->_db = $this->load->database('mssql-group', TRUE);
   }
 }

Gotcha #7: Mysterious lag time

IIS can exhibit some odd behavior regarding response times. When I was initially testing the application on my SliceHost dev server, I was getting pretty speedy responses in about ~100ms (keep in mind that I was connecting to both MSSQL and MySQL across the internet, not locally).

But when I moved to production, requests were taking 6 seconds each. Confused, I thought there must be some sort of bottleneck in the application. I used CodeIgniter’s profiling and benchmarking classes to investigate. I benchmarked the MySQL and MSSQL connections, queries, and overall application execution time.

The app was reporting that it was finishing responses within 100ms. So where was this strange delay coming from?

I then thought there might be some sort of redirect loop going on. From the shell, I ran:

$ time curl -v [address]

And something else became apparent. The full content of the page would come back, but there was a 6 second lag before the connection would finally close. After a little research on the Google, it turns out I’m not the only one who’s observed this with PHP and IIS: http://www.google.com/search?q=iis+php+response+lag

I would like to say I figured out why IIS was being so lame, but the in-house net-admin suggested moving the application to another production server on hand, where the issue mysteriously dissappeared. At that point, everyone was happy, so I didn’t look into it any further. I did read about some resolutions regarding DNS settings, and skipping name resolutions in the db configurations. That might have been it, but I’ll never know.

Recap:

Don’t willingly try this. That being said, everything worked out much better than it could have, and there were relatively easy solutions to the bumps along the way. If you have to put together a project like this, I highly suggest using some sort of database abstraction (or a framework like CodeIgniter), and planning out how you’ll work out URLs, permissions, and differing environments. Thinking these things over will save you a lot of time, and hopefully leave the stakeholders a whole lot happier.

A couple of weeks ago, Derek Jones of EllisLabs announced that the CodeIgniter Core would officially be branched so a community-driven version of the framework could be created. This new branch will be called CodeIgniter Reactor.

The plan, which was clarified today, is focused on allowing a select group of CI engineers to actively commit new features to the codebase, while taking feature requests via a uservoice forum. Over time, any proven, time-tested features in Reactor will be merged into the Core.

This announcement comes after a two year period of relatively few changes to CodeIgniter — something the community has had mixed feelings about. For some, it meant CodeIgniter would remain a remarkably stable platform to build on in contrast to frameworks like Cake or Kohana. For others, it meant CodeIgniter was probably dead.

So is that why frameworks like Kohana, once a fork of CodeIgniter, exist?

That, and also: A frustrating reality for many in the CodeIgniter community is that although it is the fastest, lightest MVC framework for PHP, it still lacks some important features. Many once-smitten CodeIgniter evangelists grew out of the framework and began looking for something that was more full featured. That is, they wanted an ORM, more libraries, more robust implementations of unit testing and caching, and a style of usage that actually conforms to the definition of MVC.

Why does CodeIgniter still have such a loyal following if more full-featured frameworks are around?

As mentioned, CodeIgniter is considered one of the fastest script-based frameworks available. It takes a “load only what you need” approach — something other platforms definitely don’t do. Rasmus Ledorf, the original author of PHP and skeptic of PHP frameworks in general, has even singled out the framework as something he might actually use.

As a side note, while at Yahoo! I’ve had the chance to read into exactly why Rasmus doesn’t like MVC via the internal wiki pages that he wrote himself — and guess what, he’s right. But that’s a topic for another post.

The other big (if not HUGE) reason that CodeIgniter has remained popular is the documentation. You cannot find a framework with more clear or concise documentation. Of course, it’s easy to keep the docs current when the framework hasn’t changed for two years!

So what the hell is going to happen with CodeIgniter Reactor?

I’m one of the engineers on the project, and I’ll be clear that CodeIgniter Reactor will pick up where CodeIgniter left off. Although the official roadmap hasn’t been laid out just yet, you’ll find Reactor will still have a high level of dependability and outstanding documentation. If Reactor’s docs fall into dismay, hold me personally responsible. I won’t let it happen.

There is a feature request forum for Reactor set up at UserVoice — a place where CI users who want to suggest additions can go.

Of course, that doesn’t mean every feature suggestion, whether it’s the popular or not should actually be implemented. The Reactor team will make intelligent decisions about what and what not to change, remaining in line with the original principals of CodeIgniter: Light footprint, low barrier to entry.

If I had to underscore my own objectives in implementing new features, they are speed, efficiency, and power. That is:

• Does it belong in the framework?
• Can this feature be built efficiently?
• At the highest level of efficiency, will it be fast?
• Is it comparably robust, and powerful in the face of similar features in other frameworks?

A word to the skeptics:

A tweet I saw immediately following the Reactor Announcement was “Death by bureaucracy is the fate for CodeIgniter shame … Good riddance, it never matured”. This really embodies the sentiment most users have about other frameworks. It’s arguably the fate that Kohana and Cake have seen.

What I’m saying is: stuff away the cynicism until the first quarter of 2011. You’re going to see a ton a positive changes in the framework, and CodeIgniter users will have plenty to brag about without sacrificing usability and documentation.

There are 6 engineers on the dev team — one who I know very well, and a few others who I’ve met just recently. In all honestly, I’ve been very impressed by everyone, and I couldn’t imagine anything but a bright future for the framework. The other devs are:

• John Crepezzi
• Ed Finkler
• Mark Huot
• Kenny Meyers
• Phil Sturgeon

Six developers can approach the “too many cooks” scenario, but I think you’d also have to recognize that CodeIgniter is supported by volunteers, and a project needs 5 or 6 people in order maintain consistently high activity when they’re generally working on it part-time.

Okay, so now what:

Over the next few weeks, the Reactor team will be getting organized and planning out the future of CodeIgniter. Check back here or at my Twitter feed, because I’ll definitely post a podcast outlining exactly what the Reactor team plans to do. Also, I tend to lurk around the IRC #codeigniter channel on freenode as _kennyk_ .

If you have any questions, comments, or general skepticism, comment below. I’m all-ears.

I’m definitely not the type to evangelize something I don’t think is useful. Ask friends of mine, and they’ll likely tell you how I went through phases where I endlessly promoted things like Notepad++ for Windows, Netbeans IDE (PHP), Sequel Pro, Gnome-Do, Thinkpads, Macbooks, Toy Story 3, iPod Touches, and Visual Studio ’08. I just can’t help it. When I get excited about something, I have a hard time stfu-ing.

But holy crap. Let me tell you — if you think the WordPress default search sucks — as I did 2 years ago, try WPSearch. It’s (IMO) the second-most-useful plug-in that has ever existed for WordPress. It also has the slickest admin UI I’ve ever used in WordPress (a big thanks to JQuery and it’s plug-ins, of course).

I wrote WPSearch, and I 100% recommend it to anyone running something that isn’t a traditional WordPress blog. Run a recipe catalog? Use It! Review engine? Use it! Shopping engine? What the hell are you doing without my plug-in on your site? Your customers can’t find shit!

Fun scenario: Let’s imagine you sold laser printers on your site along with other computer peripherals, and every product page on your site had “[brand] [model] Printers” in it’s title, like “Dell 1100 Laser Printer”. If someone searched for “printers” with default WordPress search, they wouldn’t get those products back.

Does that scare you? It should. Get WPSearch now. And if you don’t like it, tweet @_kennyk_ and be brutally honest. I can take it.

Side note #1: When I wrote WPSearch, I was also trying to cash-in big time at a programming contest where the grand prize was a trip to RailsConf and the runner-up would get a set of steak knives (presumably to stab whoever won the grand prize).

Side note #2: Toy Story 3 is an intellectually provocative and introspective masterpiece!

Side note #3: Askimet is #1, but is tragically taken for granted

If you want to read about the background of the WPSearch Search plug-in for WordPress, read below. But if you just want the gist of this post, here it is:

WPSearch is the best search plug-in for your WordPress blog. It is a stemming, stop-word blocking, fast, relevant, fulltext search for WordPress. There isn’t a single plug-in in the WordPress repository that can do what it does.

You can get it here: http://wordpress.org/extend/plugins/wpsearch/ — or just install it through the WordPress plugin administration backend. Just search for WPSearch.

If you run any sort of monetized blog, you might be losing sales or readership if users can’t find what they need on your site. According to Adotas, 43% of users hit the search box first.

Background:

I’ll admit that I’ve been pretty vocal already about WordPress’ lacking search functionality. I’ve been vocal about it for 2 years, and it was the original impetus to get this blog up and running. It was also the reason that I wrote wpSearch, the original version of WPSearch — the lucene-based search plug-in for WordPress. wpSearch was the first true fulltext search for WordPress, in my opinion.

But the problem with wpSearch was that it wasn’t highly engineered. I had written it for a programming contest, and I was on a tight deadline — and when projects are rushed, the quality of code goes down. And because of that, bugs made their way out of the woodwork over the next two years.

Consumed by college work and my job, I didn’t have much time to address those issues. In fact, I had declared wpSearch unsupported a year after it was released in 2009.

A year following that, Daniel Hay at Pixelberry in New Zealand had requested that I add the ability of searching within a category for a client of his. That’s when WPSearch 2 development began.

I wanted to give wpSearch a full rewrite, and correct several mistakes I made with the first version:

• Rename it from wpSearch to WPSearch
• Change the listing name in the WordPress repository to WP Search, so searches for ‘search’ would bring it up
• Follow and MVC pattern (it’s a complex plug-in)
• Build a configurable search driver framework, so any driver could be written to search and index
• Build better logging
• Evangelize it to no end (wpSearch was barely promoted)
• Give it a UI independent of the default WordPress stylesheets, and also make it stylish

The biggest change is the configurable driver part. The free version of WPSearch contains a driver that uses Zend Lucene in the background. Any driver, however, can be written to work with WPSearch. Drivers for SOLR, sphinx, the Google Search Appliance, or name-your-own-search-product could be written.

I did that because PHP is not the best language to write a search engine in. Since Zend_Search_Lucene is the backend driver of the free version, there is an upper-bound of scalability on the plug-in. After all PHP is a scripting language, and I doubt Zend ever really imagined someone would make the ludicrous decision of indexing tens of thousands of posts in PHP. I found the breaking point to be about 20,000 docs. At that point, I ran into memory issues, slow mid-indexing optimizations, and slow first-hit (non-cached) searches.

So the point is that I poured everything I had into WPSearch 2, and I want to tell everyone about it. I did this project under the umbrella of OConf, my start-up, with business partner John Crepezzi. John’s an ex-engineer at Sun Microsystems, and he spends his days at Patch.com now. He also wrote the backend driver for WPSearch Pro, an alternate driver for WPSearch 2 which can handle up to 500,000 docs.

John and I gave a talk at Wordcamp NYC, where we officially launched WPSearch 2.The topic was on the default WordPress search, and why avoiding a remedy to it can lose you both readers and money. If you run a shopping engine, people can’t find your products. If you run a news site, readers can’t find your content.

If you don’t think people even use the search box — heads up, the advertising gurus at Adotas say 43% of users who find your site do.

You can check it out here: http://wordpress.org/extend/plugins/wpsearch/ . In it’s short time in the repository (about 9 days), it’s already had around 1,000 downloads, and I’ve had a lot of positive feedback coming in. I also dropped a comment about it on WordPress founder Matt Mullenweg’s site, where he mentioned a search product for Drupal. Hopefully he’ll check it out and let me know what he thinks.

Check it out!

CodeIgniter’s output caching mechanism — at least in my opinion — has limited usefulness. It can be used to cache the final payload sent to the user for a given number of minutes. But sometimes clearing the cache for all pages or a specific page can be useful, especially if keeping the user from seeing stale data is important.

This post will discuss what caching is, and how it is used in CodeIgniter. The next post will provide a few helper methods for clearing caches for specific pages (or really, URIs). I think this will make CI’s caching feature a lot more usable.

In a nutshell, this is how (and why) output caching is typically implemented:

Suppose we have a page at http://mysite.com/stats/website which loads and shows all the statistics about the users on my site, activity, files posted, etc. In other words, a lot of SQL queries (maybe 40 or so) and calculations go into this page. That takes significant time and resources.

Now imagine that this page is particularly popular. Maybe a heavily-read blog or bookmarking service links to your website, and you receive an unexpected burst in traffic. All of those page loads are re-running your calculations and queries, and that is consuming serious memory and CPU cycles. The number of requests your website can serve per-minute is now falling through the floor!

The idea of caching involves using the fact that our page probably doesn’t need calculate those statistics or run those queries every time. Perhaps gathering all of that data once an hour would suffice.

“Caching” involves generating the statistics page like we normally would, but saving a copy of the output we were going to send to the user for a certain amount of time. During that time period, everyone who requests that page will get the same page output that we generated x minutes ago.

After that time period passes, and we receive another page request, we recalculate the stats, and send them to the user. Of course, we’ll save the newer stats for a given amount of time for subsequent requests.

This basic caching — “page caching” — is the kind that CodeIgniter offers.

When you are inside a controller, you can tell CodeIgniter that you want to cache any requests to the current URI for n minutes. For that time period, you only want to send the output your are about to generate.

This is how it looks:

class Stats extends Controller
{
  function website()
  {
    // 40 SQL Queries (Maybe a little overboard)
    // Serious, ultra-precise calculations
    // More intensive code that isn't good for fast page loads
 
    // Tell CI you want to cache the output of this page for 10 minutes.
    // This means that for the next 10 minutes, when CodeIgniter receives
    // a request for stats/website, the CI system will not even consult this
    // method or instantiate this controller. It will serve a static page containing
    // the exact content that you output here.
    $this->output->cache(10);
 
    $this->load->view('stats/website', $data);
  }
}

And that’s all you have to do! In this example, CodeIgniter’s output caching works great.

So then, what were the qualms I mentioned earlier?

Suppose we also cache user profile pages, which might be located at a URI similar to http://mysite.com/users/profile/kennyk. For whatever reason, we will assume that caching this page could be very beneficial due to heavy traffic on the site.

If a user profile is cached for 10 minutes, and a user updates his profile in some profile editing area, he will still see the older version of his profile page when he tries to view it. This can be confusing and inconvenient.

Other MVC frameworks (like Rails) handle this issue in a snap by allowing the developer to “sweep” caches at will. CodeIgniter does not offer any functionality similar to this.

My next post will document a cache helper I’ve whipped up to allow CodeIgniter to sweep caches for a given URI. Look out for “Flushing CodeIgniter’s URI-based Cache (Part II).”

Update: You can find KLogger on github.

Since the latest release of wpSearch, a couple issues have cropped up and are slated to be fixed shortly. Some of the issues, although, are a bit harder to catch without a good set of debugging tools for PHP. The classic example of such a tool would be a log file logger.

As soon as I realized the need for a logger while developing wpSearch, I decided to check to see if one had already existed on the internet — someone had surely created a simple logging class and made it available before .. I would think. I’m a believer in the C programmer’s motto “build upon the work of others”, so checking to see if someone else has done the same thing prior to starting a project comes naturally.

After a little browsing, I couldn’t find what I was looking for. Put plainly, I wanted a logging class that:

• Checked permissions prior to logging
• Had a priority heirarchy built in ( Debug, Info, Error, and Fatal Message Levels)
• Logged to plain old text files
• Managed file handling cleanly (Open the file once, close the file once)
• Managed resources (make sure the file gets closed)

Not too complicated. This logging class would require around 100 lines of code.

Another option involved using logging functions available in Zend, or the logging class provided in PEAR. These libraries were a little overkill for what I needed, so I passed.

I decided to write of the class myself, and it has turned out to be pretty handy. I figured someone else would probably find it useful as well, so I have posted it on it’s own project page. Click here to go to the KLogger project page.

Using KLogger is very straight-forward. Here’s an example:

require_once 'KLogger.php';
...
$log = new KLogger ( "log.txt" , KLogger::DEBUG );
 
// Do database work that throws an exception
$log->LogError("An exception was thrown in ThisFunction()");
 
// Print out some information
$log->LogInfo("Internal Query Time: $time_ms milliseconds");
 
// Print out the value of some variables
$log->LogDebug("User Count: $User_Count");

Depending on the priority level that is used when instantiating a new KLogger, only certain messages are actually logged to the file. If the most verbose priority level is used, ( KLogger::DEBUG ), all messages are logged. If the least verbose level is used ( KLogger::FATAL ), only Fatal-level errors are logged. Here’s a breakdown of the most verbose level to the least-verbose level:

• Debug (Most Verbose)
• Info …
• Warn …
• Error …
• Fatal (Least Verbose)

A sixth level is also available: KLogger::OFF, so if you need to release a site without logging, you can simply set the priority level to Off, and not have a single message logged. (In fact, a log file will never be opened).

There isn’t too much documentation on the class right now, but it shouldn’t be too hard to figure out.

A couple comments on design: A few log class examples I’ve seen implement a singleton pattern, essentially locking the programmer into using one logger at all times. I usually lean towards letting the developer decide those things: If he wants to use a single logger, he can create a global log object in his application.

An screenshot of KLogger:

I think at this point I’ve actually done a better job describing KLogger in this post than on the project page. A few more details are listed there, along with the download. If you find it useful, leave a comment and let me know.

Click here to go to the KLogger project page.