More blog srcset

I took three hours out of tonight to add srcset capability to my image upload script.

Knocksink Woods, Co. Wicklow

The srcset test was hand-everything: hand-copied, hand-mogrified, hand-uploaded and the HTML assembled by hand. The updated script:

  1. Copies images to the thumbnail folder.
  2. Shrinks thumbnail images and resizes them into each size in the srcset array.
  3. Generates link and image HTML for each photograph.
  4. Put the HTML into my clipboard.
  5. Upload images to my server over scp.

The big changes are:

  • The script no longer does a wildcard recursive rm, because that is fucking stupid.
  • Reads server and file size variables from a configuration file.
  • More capably fork mogrify operations into the background.
  • More optimizations in mogrify. Thumbnail images might look a bit shittier, but the size savings are substantial.


  • Spawn a default config file in it doesn’t exist or isn’t readable.
  • Proper temp folder for images (again).

Config file:

# Name of image thumbnail folder.

# SSH username@server (or alias) and remote path.

# Image hyperlink prefix and domain name.

# Responsive image sizes.
   1024 840 768 640 424

Fetch the raw WordPress menu associated with a menu location, and add attributes to a menu item’s HTML

Today I signed the contract on a frontend developer position here in Dublin, so with any luck this might be my last post on WordPress, ever.

The menus users create in the WordPress backend are stored in the wp_posts database table as discrete post objects, and the usual method to access the menus is through the wp_nav_menu call, where you fetch a menu location. The menu location then fetches the menu attached, which fetches the menu items (etc.). The end result is a HTML blob. I had need to access the raw menu items as data objects in order for me to wrap my own HTML template around them. I came up with this after a few hours on Google:

function get_menu_from_location($location) {
    if (!($location = get_nav_menu_locations()[$location])) {
        return false;

    if (!($menu = get_term($location, 'nav_menu')->term_id)) {
        return false;

    if (!($menu = wp_get_nav_menu_items($menu))) {
        return false;

    return $menu;

Menu location slug goes in, raw menu comes out.

But wait-there’s more! The reason I need to extract raw menu items was that, in one specific menu, I needed to attach a Knockout data-bind attribute to top-level menu items. WordPress gives us ways to manipulate menus, menu containers, menu child links and menu link interiors. WordPress does not give any way to easily manipulate a specific menu item and attach attributes. This might be because menu items are stored in the wp_posts table as post objects.

whatever; this was a fucking pain to implement. The $output variable, for example, is a single string at a point where an associative multidimensional array would make sense. I am forced to search the string for <li id="menu-item-$id" and insert the directive with regex.

I add this code in the sincere hope that none of you ever get stuck in this hole.

 * Add Data Attribute to Menu Item
 * -----------------------------------------------------------------------------
 * Rant: WordPress /really does not like it when you fuck with menu items/. 
 * Menus? Yes! Menu links? Yes! Menu span items? Yes! Menu items? Fuck no!
 * So:
 *  * Individual menu items are nightmare to extract.
 *  * There is /no function whatsoever/ through which you can add custom attributes.
 *  * Menu items are stored in the wp_posts table as post objects (WTF?), and so have
 *    no fields for things like data attributes.
 *  * The menu walker output a string. Not an array or something easy
 *    to manipulate. Seriously, what the fuck WordPress? The WordPress has the
 *    dubious honour of being one of the most fucked-up and pointlessly convoluted
 *    pieces of code with which I've had to work.
 *  * I would rather take a vacation with my ex-wife than have to ever again deal
 *    with the menu code.
 * This Walker_Nav_Menu class:
 *  1. Identifies topmost menu items (those without a parent ID).
 *  2. Searches the string for their <li id="menu-item-$foo" string and replace it
 *     with the provided Knockout.js data binding.
 *  This code is liable to break at some future point if WordPress changes menu
 *  structure.

class Custom_Dingdong_Walker extends Walker_Nav_Menu {
    function start_el(&$output, $item, $depth = 0, $args = array(), $id = 0) {
        // Reduce code by extending the parent function.
        parent::start_el($output, $item, $depth = 0, $args, $id);
        $directive = 'data-bind="event: { mouseover: setFocusMenu, touchstart: setFocusMenu }"';

        if (!$item->menu_item_parent) {
            $match = '/\<li\sid="menu-item-' . $item->ID . '"/';
            $replace = '<li id="menu-item-'. $item->ID . '" ' . $directive;

            $output = preg_replace($match, $replace, $output, 1);

You can call this with:

    'theme_location' => 'my-theme-location',
    'walker' => new Custom_Dingdong_Walker()

No more jQuery

Here’s a change: your Sheepie experience is now free of jQuery unless you are a dirty IE9 peasant.

This morning I removed the last piece of jQuery-dependent code, a preprocessor for highlight.js. highlight.js operates on <pre> tags with a <code> child element. Since I have a few hundred older posts without code that I didn’t want to hand-edit, I used jQuery’s .wrapInner() function to prepare them:

if ($('pre').length) {
    $('pre:not(:has(> code))').wrapInner('<code></code>');

I replaced it with my own version that uses vanilla JS:

function wrapInsideElement(selector, wrapper) {
    selector = document.querySelectorAll(selector);
    wrapper = wrapper.replace(/(^<.*\/|>$)/g, '');

    [], function(element) {
        if (!element.querySelectorAll(wrapper).length) {
            var newChild = document.createElement(wrapper);
            while (element.childNodes.length) {


wrapInsideElement('pre', '<code></code>');

Update: No jQuery at all. You can still load it as a script dependency if necessary.

Srcset test

I have wanted to play with srcset, but the effort involved to apply it backward to all of my prior posts was scary.

I’ve settled on this configuration:

<img src=""
srcset=" 414w, 768w 640w, 840w,
" alt="Srcset image test (and Killer hijacking my seat)" />

Srcset image test (and Killer hijacking my seat)