Stephan Sokolow's Blog

Having used Fat-Free Framework 2.x for a little while now, I’m still generally quite happy with it… aside from one thing.

The built-in templating engine’s syntax doesn’t offer many advantages over raw PHP, it’s more verbose in certain common cases, and, as Fabien Potencier wrote when he took over maintainership for Twig, template languages have evolved a lot since PHP began its life as one in 1995. …so I decided to use Twig.

Why Twig?

It does help that I also work in Django sometimes but it’s not as big a factor as you might think. The main reason is that Twig is both the fastest, lightest templating engine I know (benchmark) and also one of the most featureful. Both good reasons to use FatFree and Twig together.

Here are a few of the reasons I switched:

• Fully extensible
• Auto-escaping for cleaner, safer code and less stressful coding.
• Let’s me choose my preferred mix of template inheritance and template includes.
• Supports macros for tidying up repeated code snippets like form fields.
• Has clever constructs like for/else to clean up common cases like “List results or display a ‘no results’ message”
• Syntax is easier for me to read and write in data-heavy templates with many nullable fields.
• Generally more amenable to the kinds of factoring-out of duplicated boilerplate that I want to do.

Setup Instructions

Unsurprisingly, I couldn’t get integration with F3::get() as concisely as in F3 templates, but I did pretty well, all things considered.

The simplest way I’ve found to set this up is to add something along these lines to the top of your index.php:

require_once __DIR__ . '/lib/Twig/Autoloader.php';
Twig_Autoloader::register();

$twig_loader = new Twig_Loader_Filesystem(__DIR__ . '/templates');
$twig = new Twig_Environment($twig_loader, array(
    'cache' => __DIR__ . '/twig_cache',
    'auto_reload' => true,
));

$twig->addFilter('f3', new Twig_Filter_Function('F3::get'));
$twig->addGlobal('is_ajax', Web::isajax());

This will set up the following:

Template Location

Templates will be stored in a folder named templates so they don’t conflict with any templates you continue to use with the default F3 templates. (Assuming you’re still using the default ui folder you probably kept from the sample code)

Template Caching

Twig templates will be cached in a folder named twig_cache to avoid conflicts and the cache will be automatically regenerated when the templates change

F3::get()

The f3 filter gives you 'foo'|f3 as a slightly inelegant but not overly verbose equivalent to @foo in templates. Things like 'result'|f3.title will work as desired.

Also, if you’re only using F3::get to expose things to the templates, you can use Twig globals, which let you use {{ foo }} instead of {{ @foo }}. The syntax for doing so is as follows:

$twig->addGlobal('foo', $foo);

is_ajax

This global allows you to do the switching between full templating and minimal responses for AJAX requests entirely in the templates using this snippet of code (source):

{% extends is_ajax ? "base_ajax.html" : "base.html" %}

Rendering

global $twig;
echo $twig->render('page.html', array('bar' => $bar));

Important: Compatibility Fix

The one caveat is that there’s a little incompatibility between the current versions of Twig and Axon. When using {% if my_hydrated_axon.my_null_valued_field %}, you’ll get

Undefined method Axon->my_null_valued_field()

The problem is:

1. Twig’s dot operator uses isset() to determine whether a property exists, then fails over to assuming you wanted a method call with no arguments.
2. Axon.__isset() uses isset() on its internal array of fields.
3. isset() on an array returns false if the field exists but has a value of NULL.
4. Even with strict_variables set to false, current Twig has a bug that makes it error out rather than producing an empty value when accessing axon properties.

You have two options. First, you can use my_hydrated_axon.cast.my_null_valued_field everywhere (Axon.cast() returns an ordinary associative array, which doesn’t have this problem) or you can make a small patch to  FatFree’s lib/db.php and change this…

function __isset($field) {
 return isset($this->fields[$field]) || isset($this->adhoc[$field]);
}

…to this…

function __isset($field) {
 return (is_array($this->fields) && array_key_exists($field, $this->fields)) ||
  (is_array($this->adhoc) && array_key_exists($field, $this->adhoc));
}

The only caveat with this approach is that, in your PHP code, if (!$axon->property) won’t work properly.

I just discovered Desura’s Linux client and, given the opportunity to have a DRM-free package repository system for my Humble Bundle games, I jumped at the chance.

Of course, I still wanted to keep all my games together in one launcher menu, so I went looking for a way to give the manually installed things like Super Meat Boy proper icons. Luckily, Desura turned out to have a pretty simple approach to specifying icons. Just a couple of columns in an ordinary SQLite database.

Here’s a little Python script I wrote which, in theory, should let you set/change the icon on ANY game in your Linux Desura library. I’ve only tested it on local ones though.

I’ve been meaning to minimize Google’s ability to track me and my visitors for quite a while now, but this post about Google+ which I stumbled across recently came as an appropriately timed reminder.

I’d like to announce that every site I remember running (it’s conceivable I forgot ones on free hosting similar to GitHub Pages) is now free of Google Libraries API and Google Analytics (I use a private Piwik install for stats now and I can assure you I’ve dialed data retention way down). I’ve never had a need to use reCAPTCHA even back when they weren’t owned by Google.

I still need to find alternatives to FeedBurner, FriendFeed (owned by Facebook), and Google Docs and find time to replace GMail and Google Talk with stuff I host myself, but it’s a good start.

(You never really realize how much Google knows about you until you start migrating yourself off them)

In the interest of full disclosure, here’s an up-to-date list of all 3rd-party dependencies in my sites which could theoretically be reworked for abuse:

blog.ssokolow.com

• ProjectWonderful Ad
• FriendFeed sidebar widget
• Flattr buttons (Live counts require external requests)
• FeedBurner feed analytics

Vanished FanFic Archive

• Fic downloads are currently served separately from Dropbox.com
• FeedBurner feed analytics

GitHub Pages: QuickTile

• Flattr button
• GitForked Button

GitHub Pages: The Procrastinator’s Timeclock

• Flattr Button
• GitForked Button

Gender-Bending Index

• FeedBurner feed analytics

Fanfiction Story Ideas

• FeedBurner feed analytics

While I love a well-configured copy of Spam Karma 2 as an effortless way to keep my blog free of spam, it doesn’t seem to have a way to automatically purge/expire comments after they sit in the spam bin for a while.

Until I can come up with a more automatic solution, here’s the simplest way to purge all binned spam in a few seconds using the phpMyAdmin SQL query window (it’s an icon in the sidebar once you’ve picked a database):

1. Delete all comments marked as spam:

   DELETE FROM wp_comments WHERE comment_approved="spam";

2. Look up all newly orphaned comment metadata entries:

   SELECT m.comment_id FROM wp_commentmeta AS m 
     WHERE (SELECT COUNT(c.comment_ID) FROM wp_comments AS c 
       WHERE m.comment_id = c.comment_ID) = 0;

3. Click “Check All” at the bottom of the results list. (MySQL doesn’t let you subquery a table you’re deleting from)
4. Click “Delete” to the right of “Check All”.

How much faster is this? In the same time it took me to purge 20 comments via the WordPress web interface, I used this process to remove the remaining thousand or so. The actual SQL statements took fractions of a second.

Still… this is a bit outside my usual area of SQL expertise (I normally work mostly with SQLite and simple INNER JOINs), so I welcome cleaner, more automatic ways to do this without resorting to a little PHP or Python script to pass lists of IDs between statements.