Since there is no reason to waste syslog to report various things for PHP, I decided to write my own wrapper. It’s still quite young, and not overly featureful, but it now exists. It will log to a file of your choice, only dropping to syslog when things break.

function logger($facility=”user:notice”, $message = “”) { global $mylogfile umask(0177); if ($logger != “yes” || empty($message) || empty($logfile)) return; if (!$fp = fopen($logfile,”a+”)) syslog(0,$_SERVER[“PHP_SELF”] . ”: cannot open $mylogfile\n”); $format = (isset($_SERVER[“REMOTE_ADDR”])) ? date(“M-d-Y H:i:s ”) . $_SERVER[“REMOTE_ADDR”] . ” ” : date(“M-d-Y H:i:s ”) . ” unknown ”; $format .= $_SERVER[“PHP_SELF”] . ”$facility” . ucfirst($message) . ”\n”; fputs($fp, $format); fclose($fp); }

It’s that time again… no, not time to make a “googy”, it’s time for another MKVToolNix release!

Mosu’s fixed up a few more things, most pertaining to the mmg system (which is still broken on MacOS X), as well as a few features.

You can get your very own “googy” release here.

After extensive testing and rewriting, I’ve broken out of my former mold, and have taken dbshim out of the works, instead, I’m now using my rewritten rollatorDB.

While doing so, I re-implemented my RSS feeds, cleaning up quite a bit of the cruft in that code while extending it a bit more.

You, the end user can now decide how many articles you want to view, and if you want to view the entire article, or only a section. By appending “fullcontent” unto your query, it will display the full article within the feed. “num=xx” will allow you to view the last xx entries, and last, but not least, “length=xx” will break the feed at the specified number, by default, 250 characters into the article. Keep in mind that “fullcontent” is a boolean, and will override length.

So, the query of:

http://www.holwegner.com/rss.php?fullcontent&num=30

will display the entire article for the last 30 entries, whereas,

http://www.holwegner.com/rss.php?num=10&length=74

will display the last 10 articles, cutting off at the 74th character, good enough for a brief synopsis (usually).

Working with PHP classes is quite a bit different than just creating, and calling subroutines, but it is a rather pleasant abstraction – with my rollatorDB::fetchAssoc, and rollatorDB::fetchAssocRow making life much easier than manually stepping through everything with the archic ways of old, which looked similar to:

$result = my_db_query(“SELECT …”); while (list($myID, $myTitle, $myContents, $entryDate, $lastModDate, $entryType) = mydb_fetch_row($result)) {; ... do stuff… }

It’s now as simple as:

$myVariable = $rollatorDBvar->fetchAssocRow(“SELECT ….”) ... dostuff…

Of course, due to this the flow has slightly changed, but it’s for the better since I have all of my data in a local array, and all of the DB work is done by the time I’m parsing it, making for a much faster system!

I must admit to having been quite busy over the last few weeks, with my relocation to my old state of Nevada, and finishing up my contracts..

I’ve managed to get rid of the last bit of bloat which was my external RSS parser. I’ve written a slightly odd code snippit which uses PHP’s (now) native XML routines to parse an RSS feed. It will stuff an associative array with variable data it accumulates.

No caching, hence, no ‘if changed’ resources – as of yet. Regardless, it works quite well, and is under 3k.

Since the rewrite of rollator into a full-fledged OOP structure, I’ve been asking myself, as well as been queried a few times by curious parties: “How will it work?”

I’ve tried to make it as painless as possible. If you note my prior post, you’ll see that all DB specific queries have been made abstract, so you need not know what the DB is. You are, however, required to format proper SQL queries. ;)

Here’s how it might look:

$myDB =& new rollatorDB(”$myHost”, ”$myUser”, ”$myPass”, ”$myName”, ”$mydbType”);
$array = $myDB->fetchAssoc(‘SELECT id, content FROM mycontentdb LIMIT 1’);
echo “fetchAssoc ”;
print_r($array);

$rowArray = $myDB->fetchAssocRow(‘SELECT urltitle, fullurl FROM urldb LIMIT 1’);
echo “fetchAssocRow ”;
print_r($rowArray);

$myDB->dbClose();
?>

It’s pretty simple, no? Sure, it can use a bit of further abstraction, but for the most part, the logic’s entirely written. It works with single array and row queries, raw queries, and as demonstrated above, it will fetch all associative fields, either in an array, or in the fairy common ‘row’ format.

The difference lies in that arrays return the type searched for with the name, and the row merely returns the data. For our test sample, let us assume the following is returned:

fetchAssoc Array ( [0] => Array ( [id] => 1 [content] => Hey this is my content. Is it not great? I think it is so! Please, send me much money so I might make such wonderful content for you! )

)
fetchAssocRow Array
( [0] => Array ( [0] => Sweet Cuppin Cakes [1] => http://www.homestarrunner.com/main18.html )

)

You’ll find that the array query returns the variable name as the identifier of the data, whereas the row merely returns the data.

Personally, I like the ability to discern the data type more with the array, but if one is entirely sure that they will continue to use the same exact format and return their data, er, proper, the row lookup does have a trivial amount of speed increase.

Of course, to fully see what rollatorDB supports, you might just want to see the source.