Windows Server + IIS + PHP 5.3 + ImageMagick + PDFs

After 3 days and hours of frustration, here is the steps to follow for getting php_imagick working on Windows server running IIS:

  • make sure everything you install is 32-bit – this is because PHP is 32-bit, and introducing any 64-bit component will break the whole thing
  • download php_imagick here:
  • place only the php_imagick.dll file in the “ext” subdirectory of PHP
  • install a legacy version of ImageMagick – this is because as the forum thread points out, PHP 5.3 is compiled with a different version of MSVC than the latest version of ImageMagick, and the two don’t talk to each other. Unfortunately, ImageMagick doesn’t keep archives of old versions, but thankfully other sites do:
    For simplicity sake, install the file in “C:\ImageMagick”
  • install a legacy version of GhostScript – again, this is to make sure the versions are compatible with each other. Again, Ghostscript themselves don’t seem to keep legacy files, but you can get them SourcrForge:
    For simplicity sake, install the file in “C:\Ghostscript”
  • After all this, ImageMagick still won’t see Ghostscript as a delegate for handling PDF’s – you must edit the “config\delegates.xml” file and replace all instances of “@PSDelegate@” with the full path to the Ghostscript binary (note the forward slashes) as described C:/Ghostscript/8.62/bin/gswin32c.exe
  • At this stage, any command-line testing of the ImageMagick to Ghostscript communication will probably work – but it won’t work under IIS. This is because by default, Ghostscript uses “C:\Windows\Temp”, but IIS doesn’t have permission to that directory. You must grant read/write access to that directory to “IIS_IUSRS” (or php_imagick will keep reporting that there is no delegate) as explained here:
  • Finally – REBOOT! None of this will work without rebooting at least once so the entire OS has references to the newly installed software and libraries.

With any luck, you should now have a working php_imagick installed – you can confirm (at least part) of this using phpinfo() – although this may report php_imagick installed, it’s not a guarantee that PDF support will be working. You won’t know that part until you actually try to read in a PDF.

WordPress Shortcodes – My Way

As anyone whose work in WordPress whose tried to create their own shortcodes knows, it can be a nuisance. Trying to come up with unique names for the shortcodes so as not to cause conflicts, supporting nested shortcodes, etc., etc. It can be a challenge.

Instead of using functions, however, I’ve started using enclosures and classes. Such a class itself registers shortcodes which it can have embedded. And to overcome the actual shortcode tag itself conflicting – I’ve found you can “namespace” those, too. Here’s an actual example:


namespace sunsport\shortcodes;

 * This class provides the functionality for creating the HTML structures for
 * the frontpage tiles
 * @author ncrause
class Tiles {
    public function __construct() {
        add_shortcode('sunsport:tiles:create', array(&$this, 'create'));
        wp_enqueue_style('sunsport-tiles', '/css/tiles.css');
    public function __destruct() {
    public function start($atts = array(), $content = null) {
        include __DIR__ . '/fragments/tiles/start.php';
   public function create($atts = array(), $content = null) {
            'href' => '/',
            'img' => '/img/image_missing.png'
        ), $atts));
        include __DIR__ . '/fragments/tiles/create.php';

add_shortcode('sunsport:tiles:start', function($atts, $content) {
    $instance = new Tiles();
    return $instance->start($atts, $content);

So, what we have here is a shortcode “sunsport:tiles:start” which creates an instance of our class. That instantiation registers a new shortcode “sunsport:tiles:create”, which would be unavailable otherwise, thus we avoid have to check to make sure it’s properly enclosed in a parent “start” shortcode, and we gracefully deregister it at the end of the run.

It’s probably worth include the “fragments/tiles/start.php” file just for reference:

<div class="sunsport-tiles">
    <?= do_shortcode($content) ?>
    <div class="clear"></div>

And here’s the actual usage:

  [sunsport:tiles:create img="img/tiles/photo_button01.png" href="/products"]Vinyl Lettering[/sunsport:tiles:create]
  [sunsport:tiles:create img="img/tiles/billboard_photo.png"]Billboard[/sunsport:tiles:create]
  [sunsport:tiles:create img="img/tiles/photo_button03.png"]The Company[/sunsport:tiles:create]

There’s is one word of warning – do not do a naming convension like this:

  • parent shortcode – sunsport:tiles
    • child shortcode – sunsport:tiles:create

The child shortcode will never fire. For some reason, it seems WordPress doesn’t actually read in the full shortcode in this scenario – instead of “sunsport:tiles:create” firing, WordPress will simple re-run “sunsport:tiles”.

That caveat aside, I find this feels a lot cleaner and less collision-prone than other examples I’ve seen.

Lithium Problem on Rackspace

Today I came across a situation where I was deploying a PHP-based webapp written in Lithium and running on a Rackspace cloud site. In my scenario, I noticed 2 symptoms (appearing differently, but having the same cause).

  1. if the Lithium app is a subdirectory of another webapp (in my example, the main site is WordPress), you will always get a WordPress “Oops! The page you are looking for does not exist.” error.
  2. if the Lithium app is in the root, you will get an “Internal Server Error” page.

As it turns out, the problem is the .htaccess file included with Lithium.

I don’t think there’s anything wrong with the .htaccess per se, but under Rackspace you seem to have to include the “RewriteBase” directive.

So, as a result, you must edit all 3 .htaccess files in your Lithium project thus:

  • /.htaccess – RewriteBase /
  • /app/.htaccess – RewriteBase /app/
  • /app/webroot/.htaccess – RewriteBase /app/webroot/

If your webapp is a subdirectory, this subdirectory name will need to prepended to RewriteBase path:

  • /.htaccess – RewriteBase /subdir/
  • /app/.htaccess – RewriteBase /subdir/app/
  • /app/webroot/.htaccess – RewriteBase /subdir/app/webroot/

And presto, it now magically works!

Lithium Filters – What’s the Point?

I’ve used Lithium for 2 projects now, and I have one major issue – I honestly don’t see the benefit of “filters” vs. “callback” methods.

I understand that conceptually it’s supposed to “decouple” the filter logic from the model itself. However, every example of applying filters to Models show the filter being applied to an individual model directly using the 2 methods below:

class MyModel extends \lithium\data\Model {
    public static function __init() {
        // ...
        static::applyFilter('save', function(...) {
            // ...


class MyModel extends \lithium\data\Model {
MyModel::applyFilter('save', function(...) {
    // ...

In my humble opinion, neither of this is “decoupling”, since the actual code for the filters exists directly within the model itself anyway.

One would think you can overcome this my applying the filter to the “Model” class directly – WRONG! The filter never fires.

So, since I have a filter which is shared, I created a method in some other class which my individual filters call. How is this any different than simply having a callback which invokes the external method, too?

No – to me filters are thus-far fairly useless in the Model context (I’ve successfully used it on the Dispatcher).