Recently I was attempting to create some cron jobs to run PHP scripts on a DV server or at MediaTemple, with PHP installed as an Apache module (rather than CGI). I was able to execute the php file, however all of my include and require statements were totally failing.

My first idea was to set the include paths in PHP. This failed and the scripts still reported errors. My next attempt was to use absolute paths for my includes. This correctly found the includes, but resulted in safe mode errors.

I finally resolved the issue by creating a custom .ini file for PHP, making the appropriate setting changes and then supplying that ini file as an argument to PHP in the cron command.

SSH into the server, and copy the ini file. Something like:
#cp /etc/php.ini /var/www/vhosts/domain/includes/cron/php.ini

Now open up the new ini file in vi or emacs (I’m not getting into that debate). First you’ll want to disable safe mode by changing the line “safe_mode = On” to “safe_mode = Off”. Next, you can comment out the openbase_dir setting by changing the line “open_basedir = “/usr/share/pear” to be “; open_basedir = “/usr/share/pear”. And finally, set the includes path for your php scripts.

The last step is to make sure you execute the correct command in cron. Remember, you’ll need to pass the custom .ini file as an argument to PHP. Something like:

php -c /var/www/vhosts/domain/includes/cron/php.ini /var/www/vhosts/domain/includes/cron/test.php


This isn’t rocket science, and probably a no brainer to some. But, I found it useful and hope someone else does too.

The best thing about this, is I can leverage existing PHP code without having to write a ton of junk in PERL (yuck). Less code = less frustration.

http://www.adobe.com/choice/

A colleague of mine just forwarded this hilarious (and fake) response from Apple.

Personally I think both Apple and Adobe can suck it.

Essentially this is how things flow:

I’m not sure I like how I have the template wrapping working. I’d love to hear suggestions. Essentially I load the content page into a buffer. Before the template gets rendered, I use regular expressions and pull out the <head/> and the <body/> tags, and then stuff those both into an associate array. I then call a static method on a Page class to load the HTML, with the associate array as an argument. Inside of that method I than extract the associate array arg into the local scope, parse the template, and then return the rendered HTML. Seems messy, but I didn’t like the idea of putting the content of the page into the global scope before parsing it, and this was the quickest way I could come up to do it.

It’s kind of backwards how you might typically do includes where the outer page would get called first and then an include inside of that would render the inner content. I’m actually rendering the content first (so I can rip out the head and body content) and then rendering the outer page.

I know that these are incoherent ramblings that probably won’t get read by anyone, but it helps to put my thoughts down in words…

Base requirements:

1. Content pages are simple and only contain necessary markup for the content
2. Ability to target content areas in the template page
3. Simple way to designate which pages get decorated with which template to use

Content pages are simple and only contain necessary markup for the content

I want my content to only contain the necessary markup for the content and not be cluttered with page structure HTML, framework PHP fragments and the likes. I also want to be able to markup fully valid HTML pages, or simple HTML fragments. As a bonus, I think the templating should even work for things like HTML emails if needed.

Ability to target content areas in the template page

One of the things that annoys me about many templating engines is that your content pages can’t target specific areas in the template page. I guess by good OO design, this may be valid. However – I find that many times I have pages that need to include their own stylesheets. Rather than including these stylesheets in the master layout, I want to be able to include them from the content level. Most likely your content page is being rendered into the body of the page. By placing the <link> tags in the body would result in invalid XHTML.

Simple way to designate which pages get decorated with which template to use

In a few front control examples I looked at, template designation was hard coded into the PHP itself. That leaves a bad taste in my mouth, and so does dog shit (and that is why I don’t eat it and neither should you). I’m thinking of borrowing the way I’ve seen it handled in a stripes/sitemesh stack. There’s simple XML configuration that uses basic URL patterns to match to templates and some exclude tags for handling pages you don’t want decorated.

Seems simple enough. Then again, everything is easier said than done.

So I turn to the Front Controller Design Pattern. By modifying the .htaccess file in the root of the site, you can redirect all requests to a single place: the front end controller. Now all of the requests are being handled by single PHP script. This controller can now handle all authentication, templating, redirection, etc. all in one easy place.

Now I realize many frameworks out there utilize this pattern already, and probably to a much greater success than I ever will. Symfony, Zend Framework, Cake and Drupal just to name a few. However, I find some of these frameworks are often very heavy and overly complicated for a lot of uses. Also, I don’t like being forced to work within their paradigms. I want to work in my own. (Not to mention the fact that I like writing my own frameworks!)

So I’ve decided to write a very lightweight and simple front controller framework that I can reuse across sites. Nothing too fancy. Just enough to get the job done. I find for many simple sites, all I need is some simple templating, maybe some authentication, and some sort of navigation system. I don’t need a huge framework for doing this. I just need a simple front controller to route requests and enable me to implement those features.

I’m sure as I get into development, I’ll start adding more and more features. Discover many benefits to using well established frameworks over the roll-your-own ones. I’ll post some code soon so people can start beating me down.

Next up – templating. I have a few ideas on how I want to implement this, just need to spend some time hashing it out. More on this later.

Anyway – I’m sitting in my office listening to music and realized that the speakers, while okay for what they are, suck by most standards. So I pop over to my PC and fire up iTunes, hit play, and use my sound system that’s hooked up to it. Sounds great. But, I’m lazy and I got tired of switching over to it change tracks, stop, pause, etc. I figured there had to be a way to control iTunes remotely from the Mac. Doing a bit of research, I found some stuff for the Mac and a PHP script that did me no good.

Finally I came across a Perl script (can’t remember where…) that simply runs a Daemon. Everything that I needed was already there! All I needed to do, was point a browser at the box and it had a nice simple stripped down interface for play, pause, stop, next, etc…

After some time, I realized I hated having to keep the browser window open. Enter MacOS dashboard widgets.

After some quick fiddling with Dashcode, I came up with this little dashboard widget to send the requests to the PC. The current track name only updates after a command is sent, so it isn’t updated dynamically.

Now my iTunes controls are at my fingertips, and I don’t have to spend the time moving my hands the whole 24 some inches to the right to do it on the PC.

So how do you serve gzipped js files?

There a few methods out there. I chose the one below since it was fast, easy and I’m hella freakin’ lazy.

The first step is to gzip all of the javascript files that you might be serving up. The fastest way I found was to just telnet into the server, and execute the following bash command:

gzip -cr <javascript directory>

Of course you’ll need to replace <javascript directory> with the correct directory that your javascript files are located in. The -c option tells gzip to keep the originals. This is important so that you can still serve non gzipped versions to browsers that don’t handle gzip! The -r option tells it to recurse through the directory. Now you should have a directory full of javascript files and their gzipped counterparts.

init.js
init.js.gz
jquery-ui.js
jquery-ui.js.gz
jquery.easing.js
jquery.easing.js.gz
jquery.history.js
jquery.history.js.gz
jquery.js
jquery.js.gz
swfobject.js
swfobject.js.gz

Yay. How exiciting, no?

The next step is to modify .htaccess to do some URL rewriting.

AddEncoding gzip .gz
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [QSA,L]

Essentially your telling the web server to server up gzip files, if the browser accepts them and the user is not on Safari and if there is a compressed version of the file available.

That’s really about it.

Here’s the difference in file sizes:

Pretty significant size difference!

So, I uploaded to a remote server and tried again. Blammo. Chit just worked the way it was supposed to. This left me scratching my head however.

I installed Charles (www.charlesproxy.com), which is a great debugging HTTP proxy/monitor, to see what was going on. Everything worked as it should in FireFox, but still no dice in IE.

Then I noticed that traffic wasn’t being captured for Localhost when using IE. After a bit of stumbling around the net I found that if you add a period right after localhost, Charles will capture the traffic.

http://localhost:8080/ajaxTest.html

becomes:

http://localhost.:8080/ajaxTest.html

When I reloaded the page, I got a very nice surprise. Not only did Charles capture the traffic, but the XHR returned with a proper responseXML property!

I’m no network engineer, so I’m not even going to try and guess as to WTF. But, I’m happy it works as expected and thought I’d post about it in case someone else ever runs into this issue.

Since the dimensions of the interface have been reduced to fit in this blog post, things might be a bit small (try zooming in). You can also drag nodes around. Helpful when things get pushed off the screen. Nodes can be opened and closed by clicking on them.

Here’s a video of the force directed layout interface in action.

So, what is a force directed layout?

It is a method for positioning nodes of a graph in a way that is aesthetically pleasing as well as easy to digest. This is accomplished by creating a simulated physical system where all nodes are like electrically charged particles (Coulomb’s law) and the connections or associations are like springs (Hooke’s law). After running through thousands of iterations, the entire system begins to become stable until all the forces are in somewhat of an equilibrium.

Fig. 1 Interface with only the category and technology nodes expanded.

Fig. 1 is a screenshot of the layout. In this example there are only a few nodes expanded, but it gives you an idea of how things end up looking. There are two base nodes: “Category” and “Technology”. Clicking these returns the appropriate set of subnodes. The association of these subnodes is shown with a line connecting the child and parent node. When clicking on a specific technology keyword or category, that category/keyword subnode expands into another set of nodes which are projects.

Fig. 2 Interface with more nodes expanded

Fig. 2 shows the cross associations between categories and keywords.

So far it’s been a cool and somewhat successful little experiment. I’m not sure it would work as an interface as the node labels overlap too much and when there a lot of cross associations, things don’t look as organized and it’s much harder to read.

I still need to add node collapsing and make it so projects can be viewed. I’ll try to post a working example soon.