mithra62

Those of you who read this blog regularly (which, I admit hasn’t been that regular of late) probably noticed that I’ve been writing more and more about ExpressionEngine over the last year and a half. Obviously, I’ve been doing a lot of ExpressionEngine development. Mostly for client work but, like most things a good programmer does, I eventually built up a go to library of custom stuff for when new projects started. Just your normal stuff really; a couple extensions and modules to make my client’s lives easier and give that little “extra” to make a project sparkle.

Then, my CartThrob project ended. This is a project that will forever have a place in my heart. Not the site specifically mind you, which is pretty awesome BTW, but the clients tight budget combined with needing more from the site than they had initially outlined created a dilemma that presented an opportunity. I could either hand off the site as is, which was to the client’s spec but not to their expectations, or I could continue working without getting paid to make the client happy. Then, a third option came to mind.

I proposed to the client that I build an add-on to handle their needs on the condition that I retain ownership of the add-on. The plan was simple; I’d write this add-on and then sell it on Devot:ee in the hopes that eventually I’d recoup my loss in time investment. Hence, the birth of my first commercial add-on now called CT Admin. That… I then sat on for a couple months while I worked up the courage to put it up for sale.

The more I thought about releasing CT Admin the more nervous I became over the prospect of putting out an add-on that’s only useful for users of another third party add-on. Starting out with a customer base that’s a small slice of another company’s customer base isn’t exactly a good way to measure an industry. So, I decided to release a second add-on around the same time as CT Admin.

This second add-on, now named Backup Pro, was at the time a specialized backup add-on I’d written for my hosted clients which due to certain configuration conflicts couldn’t use any of the existing ExpressionEngine backup add-ons on the market. Releasing Backup Pro was also a gamble though of a different sort; as mentioned there were existing add-ons within that niche and and one of those competitors has fiercely loyalty customers (Hi Tom!). But still, two add-ons are better than one. Right?

So on June 10th I had a stiff drink and posted my add-ons to Devot:ee. And a whole 24 hours later I sold my first add-on. Immediately, I realized I was in. I was hooked. The joy I felt when I got the email notification from Devot:ee about the sale was absolute and total. Someone had paid me money for proprietary code I had written that I was going to be able to sell again. Fuck. That was the sweetest $24 I ever made.

But $24 also came with a weird sense of responsibility I never really felt writing OSS code. With OSS I’d always kept things at my pace and, unless there was anything critical that affected me personally, individual issues other users experienced weren’t that big of a priority. But, with the ExpressionEngine add-ons, that someone had paid real cash money for, the paradigm shifted from random and faceless users to clients. In essence my customers became my clients and that’s a dynamic I’ve always been comfortable with in terms of knowing how to respond. Put simple; complete and total support until they’re happy.

And that’s really the key to everything right there. What initially started out as a small experiment I personally likened to an OSS project morphed into me sharing some responsibility with other developer’s client work. Shit got real all of a sudden. People were paying money on my code with the belief that the code would help them solve their client’s problems. For those users who had issues (and there were more than a few) my responsibility could not be denied.

Initially, I was naive enough to think I could just post my add-ons to Devot:ee and go about my life. I had no concept of how much care would have to go into support and customer satisfaction or the amount of hours I’d spend in the Devot:ee forums and answering questions on Twitter. To give an idea of just how many updates there have been; at the time of this writing Backup Pro is at version 1.8.1. That’s a lot of bug fixes and feature requests in just under 4 months. Almost to the point of ridiculousness.

But it’s addictive. Extremely so. The more feedback I got, and the more features and bugs that were fixed or added, the better the products became. The process creates a really nice positive feedback loop wherein we’re all winners. The customer gets a better product, I get to create a better product which, in turn, makes my products more appealing to others. It’s really something to be a part of.

So after 4 months of progressively improving my products, networking within the community, building a dedicated site for marketing and having an absurd advertising appetite and a library of 7 add-ons now, I look around and realize that I’m a part of something I had never anticipated; the ExpressionEngine community. And it feels like home.

But then, after the pants come on and a moment to reflect is had and the obviousness of the overreaction becomes clear. This is ExpressionEngine after all; there’s bound to be some utility available to handle this with the least amount of pain possible. And there is: the Member Import Utility and, even better, it’s included into the core of ExpressionEngine so it’s already there.

And in traditional ExpressionEngine fashion its built in much the same and logical way most would design an import system. There are two different modes to work with: one to import an ExpressionEngine Member XML file and another to create said file from a CSV formatted file.

The CSV format conversion wasn’t really all that for the purposes of this project (mostly due to conditional rewriting of specific column entries) but it does have it’s uses. For instance, with smaller, self contained, exports it should be a snap to easily hand over the export straight from phpMyAdmin and convert it into an ExpressionEngine Member XML file. One big drawback though is that the CSV import doesn’t appear to create new custom member fields on import so manual mapping is required per import.

The flip side of the CSV format convertor is the straight ExpressionEngine Member XML import utility. The big drag with this, and only if you don’t use the CSV convertor, is that a script has to be written to handle the conversion. Not too big a deal but, considering most installations will vary, this is going to require manual intervention every time a new system is imported. But, unlike the CSV convertor, the Member XML importer does actually create missing custom fields so updating the system shouldn’t be too big  a drag.

For my purposes I wrote a dirty little script to create the XML file for me so it was simply a matter of importing. I’m lazy, in the long term, so keeping as much of this as simple as possible is always a priority for me. But, since it’s a throw away thing cleanliness and best practices is less important than getting me more time to do real work. A word of caution though; the XML parser within ExpressionEngine isn’t very helpful when it comes to error messages and telling you what went wrong. You will curse.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

<?php
$sql = "SELECT * FROM users";
$result = mysql_query($sql);
if(!$result)
{
	echo mysql_error();
	exit;
}
$ee = "<members>\n";
while($row = mysql_fetch_assoc($result))
{
	$ee .= "\t<member>\n";
	$ee .= "\t\t<username><![CDATA[".$row['first_name']." ".$row['last_name']."]]></username>\n";
	$ee .= "\t\t<screen_name><![CDATA[".$row['first_name']." ".$row['last_name']."]]></screen_name>\n";
	$ee .= "\t\t<legacy_subscriber_id><![CDATA[".$row['subscriber_id']."]]></legacy_subscriber_id>\n";
	foreach($row AS $key => $value)
	{
		if($value == '')
		{
			continue;
		}
		$ee .= "\t\t<".$key."><![CDATA[".$value."]]></".$key.">\n";
	}
	$ee .= "\t</member>\n";
}
 
$ee .= '</members>';
 
echo $ee;
exit;
?>

The above code is fine if your existing database is cool but, and this is weird, ExpressionEngine goes full retard when it encounters anything it doesn’t like in the XML and won’t let you proceed. It’s really quite stunning. The XML importer knows that duplicate email addresses are bad in the database but instead of, say, allowing you to skip or force things the importer will just die and scream about a duplicate leaving you the only option of then manually pruning your data. Why they couldn’t be bothered with a checkbox or something allowing you to skip bad entries is beyond me but it makes the experience really, really, painful if your data sucks.

Still though, if your data is good to begin with the importer is a nice touch.

Customizing ExpressionEngine 2.x Message Pages

The current method of modifying the message pages works as you would expect; this being an ExpressionEngine site you just go to the Design section and you’ll find them under “Message Pages” . There are 3 different types of message pages you can edit (Email Notifications, User Messages and Offline Template) and while it would seem logical on how what to do to get going you’d probably be wrong (if you hadn’t ever tried before). There are a couple problems here…

First, you can’t use EE template tags within those templates. It’s the damnedest thing too because some of those templates (User Messages and Email Notifications) do allow specific tags; they just don’t parse any others. So, if you’re a good little programmer and you build your site using global embeds for building your templates (head & footer for example) you’re hosed. Your only option is to hard code your HTML which, if you’ve built even a simple site, you’ll instantly be filled with remorse and guilt over creating such a maintenance nightmare.

Second, and after the above it’s a minor issue though if you’re good enough for the above to be an issue this’ll probably piss you off too; you can’t save those templates as files. This means version control is going to be a bit of a problem. After nearly 10 years of having version control beat into me this hurt pretty bad. To be honest, because of tight deadline and even tighter budgets I could have lived with the guilt and shame of hard coding just to finish the project but taking away my version control was like adding insult to injury.

It’s quite the head scratcher when you get right down to it; a smart and clever company redesigns their entire product from the ground up and completely drops the ball when it comes to the messaging system. It’s a shame…

There is another option though it does require money; a really nice extension called Custom System Messages. The extension was written by Brian Litzinger and is available for $12 through the ExpressionEngine marketplace Devot:ee.

Custom System Messages

Custom System Messages works exactly as you would expect ExpressionEngine to work; through a nice interface you choose custom templates for specific messages. You can set a different template for both message scenarios (General Error and Form Submission Error) as well as change the behavior of the {link} template tag so it doesn’t use the lame ass JavaScript “back link”.

The best part though is that Custom System Messages allows you to set special templates based off of all the actions your site has (even those from other modules and extensions). So, for example, if you have a CartThrob site you can set a special template for when adding an item to your cart fails and separate template for when updating an item within a cart fails. It’s really quite slick and for only $12 it’s very reasonable. Priced just enough to dissuade any developer from rolling their own solution.

I do have to say how disappointing it is to see ExpressionEngine lacking this built in. To me, it’s reminiscent of buying a car and being charged extra for the gas cap. Sure, I can just go buy a gas cap for a couple bucks but it really should be a part of the car to begin with.

Doing some quick Googling turned up an article that seemed to fit the bill: Zend Framework: Connecting to 2 databases written by Wenbert Del Rosario. Unfortunately though, while it was a good read and very informative, my circumstances were a little different. The database I had to connect to was hosted on an external network that I wouldn’t have local access to. I had to go over the wide Internet to connect. Using Wenbert’s tutorial would entail a constant connection on every request whether it needed it or not and that just wouldn’t do.

Anyone who’s ever had to connect to an external database can tell you it’s far from an ideal scenario. The latency involved with this strategy is noticeable and caching is pretty much required for any sane strategy. Still, Wenbert’s article was definitely helpful for developing my strategy.

As in Wenbert’s article I started with putting the connection information into my config.ini file

//config.ini
resources.db.adapter = PDO_MYSQL
resources.db.params.host = localhost
resources.db.params.username = ****
resources.db.params.password = ****
resources.db.params.dbname = local_db 
 
externaldb.adapter = PDO_MYSQL
externaldb.params.host = example.com
externaldb.params.username = ****
externaldb.params.password = ****
externaldb.params.dbname = external_db

Then, I created a standard Zend_Db_Table class that handled the connection:

<?php
//Model/DbTable/External.php
//name made up to protect the client but do yourself a favor and name your shit logically
class Model_DbTable_External extends Model_DbTable_Abstract
{
   /**
     * Doesn't matter for use but ZF demands a $_name variable
     * @var string
     */
	protected $_name = "content";
 
	public function init()
	{
		$settings = Zend_Registry::get('settings');
		$this->db = Zend_Db::factory($settings['externaldb']['adapter'], $settings['externaldb']['params']);
 
	}
}
?>

With the above out of the way I can now connect to the external database. I just have to pipe all my SQL through the above class. To that end, and to provide a nice wrapper for the caching, I create a Model that has methods for all the SQL my app will need:

<?php
class Model_External extends Model_Abstract
{
	/**
	 * The key to use for the cache items
	 * @var string
	 */
	public $cache_key = 'external_db';
 
	public function __construct()
	{
		parent::__construct();
		$db = new Model_DbTable_External;
		$this->db = $db->db;
	}
 
	public function testSystem($id)
	{
		$key = $cache_key.__FUNCTION__.$id;
		if(!$data = $this->cache->load($key)) 
		{	
			//just a random query with joins and whatnots to show  it's possible :)
			$sql = $this->db->select()->from(array('e' => 'example_table1'), array('e.id', 'e.title'))->where('e.id = ?', $id)->limit('6');
			$data = $this->db->fetchAll($sql);
			$this->cache->save($data, $key, $this->cache_key));
		}
		return $data;
	}
}
?>

So, using the above class I’ve abstracted out the SQL and provided caching through the below class Model_Abstract:

<?php
//models/Abstract.php
abstract class Model_Abstract
{
	/**
	 * The database object
	 * @var object
	 */
	public $db;
 
	/**
	 * The Cache Object
	 * @var object
	 */
	public $cache;
 
	/**
	 * The stored cache name
	 * @var string
	 */
	public $cache_key = null;
 
	public function __construct()
	{
		$c = new Model_Cache;
		// getting a Zend_Cache_Core object
		$this->cache = Zend_Cache::factory(
	                    'Core',
	                    'File',
	                    array('lifetime' => 720, 'automatic_serialization' => true),
	                    array('cache_dir' => '/path/to/cache/')
		);		
	}
}
?>

Putting it all together I now have a mechanism to connect to an external database, perform queries against said database and can cache the results pretty easily and with minimal code. One of the advantages of this approach is that connections to the database only happen when needed instead of on every page request as in Wenbert’s article. So, for example, so long as the cached items exist then no database connection is created and no latency (outside of hitting the filesystem of course) is created.

Still though, there are ways to improve on this approach. For example, using APC instead of the file system for the caching would help as would increasing the cache lifetime from 2 hours to something more but, overall, the above should be a good starting point.

CartThrob

Of course this presented the problem of actually using an unknown package to build a site with. Thankfully though, while CartThrob has a steep learning curve and is most certainly missing key functionality, it’s an overall nice package that allowed us to do what we needed. Sure, there’s pain involved (lots of configuration, testing and set up) but with a little elbow grease it all worked out.

As mentioned, CartThrob is an ExpressionEngine module for managing an online store. It’s available for both ExpressionEngine branches (1.x and 2.x) and was voted Module of the Year by Devot:ee in 2010 (for the 1.x version only). This being an ExpressionEngine project CartThrob would, in theory, be a nice fit.

One of the really nice things about using CartThrob is that it uses the ExpressionEngine admin panel for managing your store. This meant there wouldn’t be a second administration site that the client would have to learn. (Personally, I always found dual admins to be janky at best and sloppy/lazy at worst so this was a definite bonus in favor CartThrob.)

But this is also double edged because, well, pretty much everything about your store is saved into the entries system within ExpressionEngine. This, of course, causes your Entries panel to become an eye sore whenever you have to do anything there. Instead of having a dedicated section to manage products you use the Entries section. Instead of a dedicated section to manage your orders you use the Entries section. Instead of a dedicated section to manage… well, you get the idea; everything is managed through the entries. This makes sense for the product management but when you have to dig through entries to find orders and coupons and discounts (etc) things get a little jarring for some people (even internally with my team) so it’s a concern.

Still, single freaking admin so it was kind of a lesser evil compromise.

The unusual thing though is that, for how thoroughly the management of items was punted (though, to be fair, it looks to be a feature versus bug debate more than “punting”), CartThrob has an extremely deep configuration section where you can customize CartThrob to function just right. CartThrob has all the basic customization functionality one would expect from any modern shopping cart platform (tax, shipping, payments with lots of merchant options, etc) plus a bunch of settings just to get CartThrob working (CartThrob is NOT an out of the box solution). It’s all presented in an easy to use interface that’s designed to mesh with the ExpressionEngine administration panel design which makes for an easier experience.

As far as merchant accounts go (for accepting payments through your site) there’s the usual suspects of Authorize.net, Paypal and SagePay built right in but also some offline solutions for pay by check and credit accounts. For this project we used Authorize.net which went smooth for the most part but I can’t speak for the other options though if they’re anything like the Authorize.net one they’re probably cool. CartThrob also includes some extensions and hooks so writing your own payment gateway is possible if you need.

CartThrob can also hook into the ExpressionEngine member module so your customers can be registered internally. Like pretty much everything else with CartThrob there’s a bit of configuration involved to get it up and working though. Unfortunately though, there’s not really any out of the box functionality for your members to take advantage of. For example, there isn’t any way for your customers to view their past orders when logged in and when using the control panel and viewing a member’s profile there’s no relationship with CartThrob. You’re gonna have to write all that stuff yourself but, and I don’t know why, but CartThrob doesn’t store any relationships between ExpressionEngine members and it’s customers so expect a challenge.

In terms of the user side, the actual storefront, everything is done using ExpressionEngine templates and template tags. There are lots of module methods available and even though it’s far from a complete package of the expected functionality. In fact, on our team, we got into a habit of thinking of CartThrob as a Lego set for creating what we want instead of having what we want already.

For example, to view the details about a users cart you’d use the template code below:

{exp:cartthrob:cart_info}
	{total_items} <br />
	{total_unique_items} <br />
	{cart_entry_ids} <br />
	{cart_shipping} <br />
	{cart_tax_rate} <br />
	{cart_tax} <br />
	{cart_subtotal} <br />
	{cart_total} <br />
{/exp:cartthrob:cart_info}

On the surface this appears to be nice because it keeps things within the core ExpressionEngine development process. And it would be except, well, CartThrob isn’t abstract enough. Too many times I would try to do something that seemed obvious, like checking for shippable items within a users cart, and would come up short; that functionality doesn’t exist.

Still though, don’t get me wrong. Yes, some of the above sucks. Absolutely. But CartThrob is still under development. Plus, since it’s a commercial script ($99) there’s financial incentive to improve it. And, truth be told, for as painful as certain points were it’s still way more fun to build a site with CartThrob than most of the other options I’ve used or reviewed like OpenCart or Avactis.

Plus, again, single freaking admin!

random, the lion

My first and automatic reaction when coming up against some random and meaningless output string is to just Google it and see what happens. Unfortunately though, this particular search, at the time at least, returned around 35,000 sites that were outputting the string and only 1 that had a reference to the issue with a possible explanation. All of a a sudden this became an actual thing.

Putting aside the fact that there are around 35,000 sites with the string within Google for the moment (and that’s really a problem to be discussed) it took a bunch of digging but I finally found a few things:

First, this is an issue that has been within ExpressionEngine for years. Doing a search on the ExpressionEngine site lists the first entry of this string at 2007 (sorry for the lack of a link; ExpressionEngine search is cached so old search URLs don’t work sometimes). My initial reaction was that this was kind of sloppy; EllisLab updated ExpressionEngine to 2.0 recently, from the ground up to use CodeIgniter I believe, yet this issue got ported over?

After doing further research though, I came to believe the above is more to do with the design of ExpressionEngine than anything else like copying code. Turns out, there’s some logic to that random and oblique string.

Basically, that string (M00o93H7pQ09L8X1t49cHY01Z5j4TT91fGfr) is a template holder for the content you want to output. It’s a little complicated in how it works but thanks to Derek Jones over at the ExpressionEngine forums there’s a succinct, though still a little complicated but less complicated than I could explain it, explanation of what’s going on.

…

The template parser is an extremely complex gizmo, so let me try to explain it stripped of what techno mumbo jumbo I can. This will still be long, so bear with me.

The template parser intelligently saves on resources by only processing a given tag once, no matter how many times it occurs on the template. This means that if your tag is exactly the same, including its tagdata, EE only execute’s that modules code once, and replaces all copies of that tag with the output.

So first, when the template parser goes through the template finding tags, it replaces them all with temporary markers (the gibberish), and adds each tag to a list of tags to be parsed, in the order they are encountered on the template, top down. Each marker starts with the letter “M” followed by the number (starting at 0) that tag is sitting in on The List.

Second, the parser goes down its list of tags. It parses tag #0, and then replaces all of #0’s marker with that tag’s output.

——————-

Ok that’s the setup. Here’s why it affected you, and why this side effect is not a problem (and also extremely, extremely rare). Remember, top down, tags will be assigned 0, 1, 2, etc. So I’m abstracting it out to show the nesting and the positioning only. Just focus on the numbers.

{exp:tag0}foo{/exp:tag0}
{exp:tag1}
    bar
    {exp:tag0}foo{/exp:tag0}
{/exp:tag1}

Step 1, the tags are grabbed and replaced with markers. The first tag encountered is replaced first.

M0
{exp:tag1}
    bar
    M0
{/exp:tag1}

And then the next tag:

M0
M1

All tags have been collected and put on The List, so step 2, the parser goes down The List, and parses tag #0:

foo
M1

See the problem? The second M0 is sitting protected inside the marker for tag #1, so it doesn’t get replaced. Then tag #1 gets parsed.

foo
    bar
    M0

And the marker is left in the output. EE doesn’t go back and parse tag #0 again, it’s already done that once, and will not do it again.

So the circumstances required for this problem to exist each are uncommon, and combined, very very rare:

1) Multiple exact copies of a given tag
2) One or more copies nested inside another tag (tag nesting itself is also rare, and usually not recommended)
3) The tag of which there are copies must sit at a position in the template above any occurrences of it being nested in another tag.

From the above it was easy to conclude that the template parsing stuff was breaking down in my module. Why, I had no idea, but at least I had a known starting point. While it was easy to conclude that my issue lay with the template parsing though, it was 100% off point for my particular issue which had to do with, of all things, the case of the module name. But, I digress.

The point is that for years now, and through multiple versions and rewrites, ExpressionEngine has consistently carried the same “issue”. Understanding the intent of the design for the template parsing helps put some perspective on things: it’s definitely a side effect of the particular approach. It bugged, and surprised, me that ExpressionEngine would have such oblique and useless output on such a widespread basis (35,000 site’s with that string within Google is a bit much in my opinion) but the more I thought about it the more I came to understand the complexity of what was involved in being helpful when the issue cropped up. Aside from abandoning the approach what could really be done?

It’s a nice reminder that development is often a balancing act between getting what you want and dealing with a counter issue. The ExpressionEngine team developed a strategy to enable them to effectively and efficiently meet their requirements but there’s sometimes an issue; a random string gets output instead of the template data. Plus, since the cause could be for anything from bad module installation data (as I had) to an issue within a template there’s no real way to provide helpful error messages when the template parsing does fail. But, on the other hand, the template parser does exactly what it was designed to do (and it does it well).

Which would you choose?

3 little lines of code to fix the timezone bug, disappearing stats bug and random timestamp issues.

Also, please keep in mind that Wp-Click-Track is a labor of love; I work full time as a freelance programmer and try to keep a healthy social life so sometimes my priorities are a little wacked. Point being, I try to stay on top of these things but sometimes life gets in the way. But, I will get to it I can promise that.

Road Signs by orudge

Recently though, I took on a project to build a sort of quick and dirty CMS with a couple unique requirements:

1. It had to use the Zend Framework
2. URLs would be broken down into a /category/page/subpage scheme.

This was the first time I’ve ever had a client demand a project use the Zend Framework. Pretty cool. But, this presented a problem because, as mentioned above, by default the Zend Framework has URL schemes based on the controller and action you’re looking to access like /controller/action/. This just wouldn’t work.

Since the clients URLs would mostly be based on user generated strings, what we were calling URL slugs, the default routing scheme just wouldn’t do. I say mostly because there were other areas of the project that would use the normal scheme for a couple modules. Either way, thankfully, using Zend_Controller_Router_Route made this pretty much a snap (a little head bashing but not too much).

First though, a little background. Because of the above requirement from the client on URL schemes, I was thinking the best thing to do was to route all user generated URLs to to a single controller and handle the rest from there. I looked but there didn’t seem to be any easy way to route all URLs except the specific modules I wanted to exclude which meant I had to pull out the categories and iterate over them to create each route individually. (If anyone knows of a way to reverse the design and create a route for everything but certain strings let me know.)

To do this, in my bootstrap class I just created a new _init function like the below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

//bootstrap
public function _initRoutes()
{
	$url_data = $this->cat->getCategoryUrls();
	$frontController = Zend_Controller_Front::getInstance();
	$router = $frontController->getRouter();
	foreach($url_data AS $url)
	{
 
		$route = new Zend_Controller_Router_Route (
			$url['url_slug'].'/*',
			array('controller' => 'pages', 
			'action' => 'index')
		);
 
		$router->addRoute($url['url_slug'], $route);
	} 
}

In a nutshell, all the above is doing is looping over an array of category URL slugs and adding a custom route for each category that sends all requests to the Pages controller and the Index action. From there I parse the URL and proceed accordingly for the rest of the module.

For this example I’m doing a couple thing; using the Zend_Controller_Router_Route class and using wild cards (*). The Zend_Controller_Router_Route class takes two parameters, the first being the route and the second being an array of options (I’m only passing the controller and action but it’s possible to send others). For the route, and because it’s using the wildcard (*), I’m basically saying take any requests for the “url_slug” and anything after it and use the controller “Pages” and the “Index” action to handle everything.

After passing the Zend_Controller_Router_Route object to the $router, passing the unique name for the route as the first parameter, I was good to go.

That said, there’s a lot more that can be done with the custom routing stuff within the Zend Framework above what’s outlined above. There’s a pretty good article by Jason Gilmore that goes into some detail into how to create default URL parameters to make the URLs look even prettier. Definitely worth checking out.

The HTPC Dream is Finally Realized

Back in 2002 I was a lowly intern level scrub with the pay to match and computers capable of running Windows Media Center were a little expensive and required a shit ton of upgrades hardware wise. You couldn’t just buy an inexpensive model off the show room floor and expect to have any cash left over. I don’t recall the specific prices involved for all the components but I do remember knowing with a complete and total certainty that getting an HTPC at that time just wasn’t going to happen. So, broken hearted, I moved on and focused on my career and drinking for the next 9 years.

Then, last August, I started looking into getting one put together again. I had some other, business, needs that required a dedicated desktop computer, to be placed in a closet, and I just figured, what the hell, why not kill two birds with one stone; have my utility computer and look into getting a Windows Media all at the same time. I mean, why not? The main purpose was for a backup machine which would only be ran on a slim time window and the rest of the time it’ll just be sitting there. Kind of a waste to just leave it sitting there doing nothing most of the day, right? Right?

Now, since I had done all the research into what it would take to build an HTPC back in the day I started looking up all the parts to build one. For my preferred system I was thinking about:

1. ATX Media Center case $75
2. An ATX Mother Board that can have a decent amount of RAM $299
3. A decent amount of RAM $149
4. A processor to match the motherboard $269
5. HDMI Video Card $99
6. 1 Blu Ray Disk Drive $90
7. 500 Gig HDD (with a few extra external terabyte drives for the media) $60

I figured I’d get the parts and put it together myself; these things are like legos with how everything snaps together only where it belongs. Add a little MythTV (go FOSS) and I’d be good to go for a bit of time and around $1,100 (after shipping). But, the practical side of me couldn’t accept that like I assumed I would. $1,100 is still a lot of money regardless of how you look at it and, I couldn’t kid myself, it was going to take a bunch of effort to learn MythTV as a platform, not to mention how long it would take to put the thing together (I try to never underestimate my ability to procrastinate). So I decided to look up good old Dell and see what my options were. My mind blew.

Turns out that the lowest Dell desktop model available at the time had HDMI outputs native and is only $299. I don’t know when it started to be “standard” for commodity PCs to come with HDMI outputs but that was a good call. Plus, since the Dells come with Windows 7 Premium, and that it comes with Windows Media Center as a part of the OS, there’s no need to learn MythTV (something I just wasn’t motivated to do).

Still, the specs for the Dell wasn’t really all that great; only 2 Gigs of RAM and a Celeron processor (why do they still make these?) just wasn’t going to cut it. After upping the specs on the CPU and ordering 6 Gigs of RAM from Crucial the total cost ran around $450 and came with a year warranty which was something unexpected but nice.

It’s pretty cool that getting a home HTPC set up is now as easy as ordering any other computer.

Then, one day, out of nowhere, it comes up. The perfect problem where the Reflection API appears to be the perfect solution. For me this came up a couple months ago while I was working on a European zip code radius project that had to be built using one of those obfuscated and ill documented 3rd party commercial programs (nothing worse than when the platform is forced on you). So, I had to use this program that was intentionally encoded to prevent me from doing what I wanted to do. I couldn’t even look at the code; it was completely obfuscated.

Before getting into things it should be noted that the Reflection API is capable above and beyond what I’m outlining; usually for the kind of high level stuff like core Zend Framework components and anything you’d want way abstracted.

So, yeah, weird problem.

This is where reflection comes in for me. It was made for problems like the above; according to the manual:

PHP 5 comes with a complete reflection API that adds the ability to reverse-engineer classes, interfaces, functions, methods and extensions. Additionally, the reflection API offers ways to retrieve doc comments for functions, classes and methods.

So, the theory was that I could use the Reflection API to look into the obfuscated code and get some insight into what was going on and what I had to work with. I figured that, at the least, if I could see what methods, properties and comments the code had; maybe I’d get some clue about what the code was about. Using, for example, the internal PHP class “SimpleXMLElement” it’s real simple to get a nice map of the class by calling the class ReflectionClass and passing the name of the class you want to get details on as a parameter like the below:

1
2
3
4

<?php
$reflector = new ReflectionClass("SimpleXMLElement"); 
echo $reflector;
?>

The above outputs an eye gouging but verbose class map:

Class [ <internal:SimpleXML> <iterateable> class SimpleXMLElement implements Traversable ] {
 
  - Constants [0] {
  }
 
  - Static properties [0] {
  }
 
  - Static methods [0] {
  }
 
  - Properties [0] {
  }
 
  - Methods [14] {
    Method [ <internal:SimpleXML, ctor> final public method __construct ] {
    }
 
    Method [ <internal:SimpleXML> public method asXML ] {
    }
 
    Method [ <internal:SimpleXML> public method saveXML ] {
    }
 
    Method [ <internal:SimpleXML> public method xpath ] {
    }
 
    Method [ <internal:SimpleXML> public method registerXPathNamespace ] {
    }
 
    Method [ <internal:SimpleXML> public method attributes ] {
    }
 
    Method [ <internal:SimpleXML> public method children ] {
    }
 
    Method [ <internal:SimpleXML> public method getNamespaces ] {
    }
 
    Method [ <internal:SimpleXML> public method getDocNamespaces ] {
    }
 
    Method [ <internal:SimpleXML> public method getName ] {
    }
 
    Method [ <internal:SimpleXML> public method addChild ] {
    }
 
    Method [ <internal:SimpleXML> public method addAttribute ] {
    }
 
    Method [ <internal:SimpleXML> public method __toString ] {
    }
 
    Method [ <internal:SimpleXML> public method count ] {
    }
  }
}

As you can see, the above lists every property, method and constant about a class along with any parent classes and interfaces. If there were any variables the methods accepted it would also list those as well but SimpleXMLElement doesn’t have any.

It’s also possible to get the individual elements on a one by one basis while using the ReflectionClass object; for example the below methods returns the class name, any comments (if they’re in docblock format), the constants, parent class, constructor and default properties for the class DateTime.

<?php
$reflector = new ReflectionClass("DateTime");
echo "Class name: ".$reflector->getName()."\n";
echo "Doc Comment:".var_dump($reflector->getDocComment())."\n";
echo "Contants: ".var_dump($reflector->getConstants())."\n";
echo "Parent Class: ".var_dump($reflector->getParentClass())."\n";
echo "Constructor: ".var_dump($reflector->getConstructor())."\n";
echo "Default Properties: ".var_dump($reflector->getDefaultProperties())."\n";
?>

Outputs

Class name: DateTime
Doc Comment: bool(false)
Contants: array(11) {
  ["ATOM"]=>
  string(13) "Y-m-d\TH:i:sP"
  ["COOKIE"]=>
  string(16) "l, d-M-y H:i:s T"
  ["ISO8601"]=>
  string(13) "Y-m-d\TH:i:sO"
  ["RFC822"]=>
  string(16) "D, d M y H:i:s O"
  ["RFC850"]=>
  string(16) "l, d-M-y H:i:s T"
  ["RFC1036"]=>
  string(16) "D, d M y H:i:s O"
  ["RFC1123"]=>
  string(16) "D, d M Y H:i:s O"
  ["RFC2822"]=>
  string(16) "D, d M Y H:i:s O"
  ["RFC3339"]=>
  string(13) "Y-m-d\TH:i:sP"
  ["RSS"]=>
  string(16) "D, d M Y H:i:s O"
  ["W3C"]=>
  string(13) "Y-m-d\TH:i:sP"
}
 
Parent Class: bool(false)
Constructor: object(ReflectionMethod)#2 (2) {
  ["name"]=>
  string(11) "__construct"
  ["class"]=>
  string(8) "DateTime"
}
Default Properties: array(0) {
}

Check out the documentation; there are a bunch of other details you can get from other methods.

This is really just the tip of the iceberg though. There are other classes that allow even deeper insight into functions, methods, extensions and much more. Definitely worth checking out.