/dev/null

Running PHP cron jobs on a MediaTemple DV server

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.

Templating/Page Decoration

I believe I’ve got my templating working the way I want. It needs to be refactored, but it works. FYI – my terminology can be confusing, but when I say decorate the page, I essentially mean apply the template to the requested content. I guess was originally thinking I was going to model templating after the decorator design pattern.

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…

Templating

In thinking about how I want to implement a templating system in my homegrown php framework, I guess it would be good to start with some basic requirements. The goal is a simple and easy to use templating system.

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.

Front Controller Pattern

I’m not a huge fan of tons of repetitive code and mark-up. I find it inefficient, sloppy and difficult to maintain. So, I’ve never been a fan of using includes on every page of a site for the headers, footers, blah blah blah in PHP. It’s also very difficult (to me) to implement good templating this way. It’s something that has continuously bothered me when developing sites in PHP.

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.

PHP5 + JSON + as3corelib = a beautiful thing

I’ve decided to play around with an experimental front end for viewing projects in Flash. Since I OOPified (yes, that’s a technical term) the site and modeled the data, all of my objects can be easily serialized into JSON strings and passed back to the front end. Then using the as3corelib’s JSON classes, I can deserialize those objects and blammo. So much easier than having PHP output XML, then parsing that XML in flash, and then creating objects from… yeah, that sucks.

So I’ve got all of my stuff coming back into Flash in a format that’s really easy to consume and use and did it with very little work. I like that.

If I wanted to pass back a project object to the front end. I would make a request that would execute something like the following in PHP:

$prj = Alien109DAO::getProjectByPageRef($_REQUEST['p']);
$key = Alien109DAO::getKeywordsByProjectId($prj['id']);
$results = ProjectFactory::createProject($prj, $key);
print_r(json_encode($results));

First I get the project from the database. Then I get all of the associated keywords for that project. I then pass both of those results as arguments to my ProjectFactory which is a static class whose primary job is to just return a full Project object. Then the object is serialized, and returned in the response.

In Flash, in my event listener, I simply deserialize the JSON string back into an ActionScript object using the as3corelib’s JSON decoder class.

private function dataLoaded(e:DataReadyEvent):void
{
var projectObject:Object = JSON.decode(e.data);
...

w00t!

Wordpress XML Parsing Error

XML Parsing Error: XML or text declaration not at start of entity

> Warning: MagpieRSS: Failed to parse RSS file. (Reserved XML Name at
> line 3, column 38) in [...]
>
> Warning: Invalid argument supplied for foreach() in [...]

Yesterday it was called to my attention that the RSS parser that was pulling the feed from my blog into my web site was throwing some rather nasty errors. Upon further investigation I discovered that the feed itself was the culprit.

Something was throwing in extra white space before the document declaration in the XML file. Some people have found that old plug-ins or themes can cause this problem. I searched through every PHP file and finally found the issue in my config (wp-conifg.php) file.

I just updated to the latest version of WordPress yesterday and when updating the config with the most recent settings, I accidentally added two empty lines before the opening PHP tag.

Ooops. Thanks to Jared over at ShareBrained Technologies for noticing!

Rewriting the back-end, again…

I’ve decided to rewrite the back end for alien109.com again, taking advantage of OOP in PHP. Man, such a difference. Everything is so much easier to maintain and follow now. Plus, I’ve implemented more of an MVC pattern. Seemed like overkill for such a small site, but proved to be educational, if nothing else.

Site updates!

So I’ve finally updated my web site.
www.alien109.com

• Ported all of the javascript over to jQuery and ditched those ancient JavaScript libraries I’d written years ago
• Implemented some keyword searching on projects so you can see projects based on languages or technologies.
• Reworked the backend so that everything was a little more search engine friendly (url rewritting for prettier urls and hidden javascript calls)
• Added a bunch of new (and old) work into the mix.

Creating a search engine friendly ajax app is a pain in the butt, if it’s an after thought

Installing Apache, PHP and MySQL on Vista

I was expecting the worst, but got everything up and running in about 30 minutes due to some damn easy to follow tutorials. I guess I probably could have figured it out myself, but it’s nice to just get it done.

Installing Apache on Vista
Installing PHP on Vista

Installing MySQL is a no-brainer. Hell, even I could do it.