Medium-inspired Parallax Blur Effect For WordPress

2016-01-22T00:00:00+00:00

Are you are running a WordPress blog, but secretly dying to have that Medium parallax blur effect? I recently implemented this, and would like to share it with you. By the way, while I was working on the article, the effect was removed from Medium, which only makes having one on the website more precious.

Let’s assume that we have our custom theme class MyTheme. In functions.php:

class MyThemeBaseFunctions {
  public function __construct() {
    add_image_size('blurred', 1600, 1280, true);
    add_filter('wp_generate_attachment_metadata', array($this,'wp_blur_attachment_filter'));
  }
}

We added a custom image size blurred, and a callback wp_blur_attachment_filter to wp_generate_attachment_metadata. Here’s where the magic happens.

Before that let’s talk a little about ImageMagick, a powerful library for image processing that we will use to create the blurred effect. After some experimenting I figured that the image needed to be darkened, and then a regular blur should be applied with sigma=20. You can read more about these settings at ImageMagick Blur Usage. I used Gaussian Blur at first, but found the processing was extremely slow, and there wasn’t much difference in the end result compared to other blur methods.

Now we are ready to write a blurring function:

public function wp_blur_attachment_filter($image_data) {
    if ( !isset($image_data['sizes']['blurred']) )
       return $image_data;
       $upload_dir = wp_upload_dir();
       $src = $upload_dir['path'] . '/' . $image_data['sizes']['large']['file'];
       $destination = $upload_dir['path'] . '/' . $image_data['sizes']['blurred']['file'];
       $imagick = new \Imagick($src);
       $imagick->blurImage(0, 20, Imagick::CHANNEL_ALL);
       $imagick->modulateImage(75, 105, 100);
       $imagick->writeImage($destination);
       return $image_data;
 }

I darken the image:

$imagick->modulateImage(75, 105, 100);

And I blur the image:

$imagick->blurImage(0, 20, Imagick::CHANNEL_ALL);

Now we are able to use the custom image size in the template. Place the helper function in functions.php:

public static function non_blurred($src) {
  $url = get_site_url() . substr($src, strrpos($src, '/wp-content'));
  $post_ID = attachment_url_to_postid($url);
  list($url, $width, $height) = wp_get_attachment_image_src($post_ID, 'large');
  return $url;
}

public static function blurred($src) {
  $url = get_site_url() . substr($src, strrpos($src, '/wp-content'));
  $post_ID = attachment_url_to_postid($src);
  list($url, $width, $height) = wp_get_attachment_image_src($post_ID, 'blurred');
  return $url;
}

And now use it in the template like this:

<div class="blurImg">
  <div style="background-image: url('<?php echo MyTheme::non_blurred(get_theme_mod( 'header' )); ?>')"></div>
  <div style="background-image: url('<?php echo MyTheme::blurred(get_theme_mod('header')); ?>'); opacity: 0;" class="blur"></div>
</div>
<header></header>

Add CSS:

.blurImg {
  height: 440px;
  left: 0;
  position: relative;
  top: 0;
  width: 100%;
  z-index: -1;
}

.blurImg > div {
  background-position: center center;
  background-repeat: no-repeat;
  background-size: cover;
  height: 440px;
  position: fixed;
  width: 100%;
}

header {
  padding: 0 20px;
  position: absolute;
  top: 0;
  width: 100%;
  z-index: 1;
}

Add JavaScript magic sauce to gradually replace the non-blurred image with the blurred version as the user scrolls:

(function() {
    jQuery(window).scroll(function() {
      var H = 240;
      var oVal = jQuery(window).scrollTop() / H;
      jQuery(".blurImg .blur").css("opacity", oVal);
    });
  }).call(this);

Generating the blurred version can be very strenuous on the server. I would oftentimes receive the error PHP Fatal error: Maximum execution time of 30 seconds exceeded. There are ways to work around that. One way is to use a quicker method of blurring the image by shrinking it, blurring, and resizing it back. Another way is to use a background job, something like this:

add_action( 'add_attachment', array($this, 'wp_blur_attachment_filter') );
add_action( 'wp_blur_attachment_filter_hook', 'wp_blur_attachment_filter_callback');
function wp_blur_attachment_filter_callback($path) {
  $path_parts = pathinfo($path);
  $imagick = new \Imagick($path);
  $imagick->blurImage(0, 20, Imagick::CHANNEL_ALL);
  $imagick->modulateImage(75, 105, 100);
  $destination = dirname($path) . "/" . $path_parts['filename'] . "_darken_blur." . $path_parts['extension'];
  $imagick->writeImage($destination);
}

public function wp_blur_attachment_filter($post_ID) {
  $path = get_attached_file( $post_ID );
  wp_schedule_single_event(time(), 'wp_blur_attachment_filter_hook', array($path));
}

Or better yet, use cloud image processing—I wrote about that here.

I hope you found this writeup useful!

Image Processing In The Cloud With Blitline and Wordpress

2015-12-01T00:00:00+00:00

Working with ImageMagick can be difficult. First, you have to get it installed on your OS (do you have Dev libs in place?), then you have to enable it in the language of your choice, then get it working in your application. After all that, do it all over again on the staging server where debugging may be complicated, and you may not have Admin rights. Meet Image Processing in the Cloud. Meet Blitline.

I’m doing a lot of things with Wordpress now, so we’ll set it up with Wordpress and PHP.

Step 1

Get a free developer account with Blitline, and note your application id.

Step 2

Get the Blitline PHP wrapper library Blitline_php. It’s clean and awesome, but unfortunately at the time of writing it was missing a few things, like being able to run your own Image Magick script and set a postback URL for when the job is finished. Yes, those are all useful features of Blitline cloud image processing! I’m still waiting on my pull request to be incorporated into the official version, so you can use mine that has these two useful features for now in my Blitline_php

Step 3

Now it’s time to integrate it in our application. Since it’s Wordpress, I’m doing it in the ‘wp_generate_attachment_metadata’ callback in functions.php

require_once dirname(__FILE__) . '/blitline_php/lib/blitline_php.php';
...
add_filter( 'wp_generate_attachment_metadata', array($this,'wp_blur_attachment_filter'), 10, 2 );
...
public function wp_blur_attachment_filter($image_data, $attachment_id) {
  $url = wp_get_attachment_url($attachment_id);
  list($src, $width, $length) = wp_get_attachment_image_src($attachment_id);
  $data = pathinfo($src);
  $dest = $data['filename'] . '_darken_75_105_100_blur_0_20.' . $data['extension'];
  $Blit = new Blitline_php();
  $Blit->load($url, $dest);
  $Blit->do_script("convert input.png -blur 0x20 -modulate 75,105,100 output.png");
  $Blit->set_postback_url( get_site_url() . '/wp-json/myapp/v1/blitline_callback');
  $results = $Blit->process();
  if ($results->success()) {
    foreach($results->get_images() as $name => $url) {
      error_log("Processed: {$name} at {$url}\n");
    }
  } else {
    error_log($results->get_errors());
  }
}

We are sending a JSON POST request to Blitline to make the blurred and saturated version of the uploaded image. You can track the progress of your jobs here. The request will return a URL to the image on the Blitline server, but the image may not be there right away, because the processing is asynchronous.

I tried to set up S3 bucket integration (yes, Blitline can upload to S3 for you!), but the setup procedure is quite tedious. You have to manually enter your AWS Canonical ID (and obtain it first from Amazon) on the Blitline page. Then you have to create a special policy in your bucket for Blitline. This is a lot of hassle, and giving permissions to someone else might not be the way to go for you. For me personally it didn’t work, because my policy was being automatically overwritten all the time. I don’t even know why. So here’s where the postback URL comes in play.

Step 4

I’m using this plugin WP-API V2 that soon will become part of Wordpress to make REST endpoints. In wp-content/mu-plugins/my-app-custom-endpoints/lib/endpoints.php

add_action('rest_api_init', function () {
  register_rest_route('portfolio/v1', '/blitline_callback', array(
    'methods' => 'POST',
    'callback' => 'process_blitline_callback',
  ));
});

In wp-content/mu-plugins/loader.php

require_once dirname(__FILE__) . '/blitline_php/lib/blitline_php.php';
require_once dirname(__FILE__) . '/my-app-custom-endpoints/api.php';

In wp-content/mu-plugins/my-app-custom-endpoints/api.php

if( ! defined( 'ABSPATH' ) ) exit;

require_once dirname(__FILE__) . '/lib/endpoints.php';

Here’s the fun part. Add to wp-content/mu-plugins/my-app-custom-endpoints/lib/endpoints.php

use Aws\S3\S3Client;

function process_blitline_callback($request) {
  if( !class_exists( 'WP_Http' ) )
    include_once( ABSPATH . WPINC. '/class-http.php' );

  $s3Client = S3Client::factory(array(
    'credentials' => array(
      'key'    => 'YOUR S3 KEY',
      'secret' => 'YOUR S3 SECRET'
    )
  ));
  $photo = new WP_Http();

  $body = $request->get_body_params();

  $var = (array) json_decode(stripslashes($body['results']), true);

  if (isset($var['images'][0]['error'])) {
    error_log('Error ' . $var['images'][0]['error']);
  return;
  }

  $photo = $photo->request( $var['images'][0]['s3_url'] );

  $photo_name = $var['images'][0]['image_identifier'];

  $attachment = wp_upload_bits(
    $photo_name, null, $photo['body'],
    date("Y-m", strtotime($photo['headers']['last-modified']))
  );

  $upload_dir = wp_upload_dir();

  $s3Client->putObject(array(
    'Bucket' => "yourbucket",
    'Key'    => 'wp-content/uploads' . $upload_dir['subdir'] . '/' . $photo_name,
    'SourceFile'   => $attachment['file'],
    'ACL'    => 'public-read'
  ));
}

In the callback we download the processed image from the temporary Blitline URL. One little bonus in here is the upload to Amazon S3 bucket. I use Amazon PHP SDK to achieve that. Note the permissions. This was one last thing when I actually almost gave up trying to make Blitline postback URL work. When the image finally appeared in my bucket, it wasn’t accessible from the outside, because I didn’t set permissions.

Step 5. If it doesn’t work. Debugging.

I used Firefox add-on HttpRequester to post the mock response from Blitline to my application. If you don’t want to deploy each time you change the code, here’s another useful thing LocalTunnel, so you can expose your localhost to the internet and set the postback to your local app.

And that’s how you do image processing in the cloud!

The more the merrier? Not always...

2014-02-05T00:00:00+00:00

Recently we were working on an image manipulation function for a customer that used ImageMagick’s convert command. We had spent tons of time working on the program and the associated system that was going to use it. Everything was working fine. The whole system was nice and snappy. Great job everyone!

Until we moved it into production where the page load times were 8 to 10 times slower than in our camps development system …

We all sprang into action to try to figure out why the page load times were so slow now. We reviewed system settings, configuration files for the database and application, and anything else we could think of. We made sure the OS packages, ImageMagick version, and various other things were the same, and everything looked right. The production hardware has twice the RAM and 4 times the number of processors as development does. So what the heck is going on?

To distract ourselves and hope for more insight, we tried to optimize the code a bit and while making it a bit better we were still 6 to 8 times slower than in development. We deactivated the section of the site overnight so we could sleep on it. Luckily this was a new product line so it wasn’t tragic to turn it off.

The next morning while discussing, a co-worker mentioned that the larger number of processors in production could be relevant. At first I was a bit taken aback because this goes against everything we think about more being better. How could it be that having 4 times the number of processors was a bad thing?!

Well, it turns out that ImageMagick is a threaded program and will use as many processors in parallel as it can to accomplish whatever task it is asked to do. In doing this instead of splitting up the convert over 8 processors, it was now splitting it up over 32 processors. The extra work it was taking to manage the work being split between those extra 24 processors actually greatly slowed down the processing work!

Luckily ImageMagick respects an environment variable setting to limit the maximum number of threads it will use. We set the OMP_NUM_THREADS environment variable to 4, re-ran the code, and then it performed as expected in production. It could be set to more or less threads, but we found that was fine and aside from keeping performance high, it keeps this one process from dominating CPU usage while it is running.

It was a very interesting riddle to solve so I figured I’d share it.