Breadcrumb NavXT 4.4.0

Holy API improvements Batman! As with 4.3.0, this release contains several smaller improvements rather than a single, or handful of ‘block buster’ new features. The largest set of these improvements is the addition, and improvement of several filters within Breadcrumb NavXT.

Of the new filters, bcn_template_tags has one of the larger impacts. It allows the addition of custom breadcrumb template tags. Other new filters include bcn_allowed_html, bcn_breadcrumb_template, and bcn_breadcrumb_url. For more information on these filters, please checkout the Breadcrumb NavXT Filters section of the documentation.

Additionally, the set of valid HTML for breadcrumb templates was revised and expanded. The basic set should now include a, img, span, h1, and h2 HTML tags. Added valid properties include:

  • aria-hidden
  • data-icon
  • itemprop
  • itemscope
  • itemtype

With the bcn_allowed_html filter the list of valid HTML tags and associated properties can be expanded upon without modification of the plugin.

The Translation Team:

[glot-translators=breadcrumb-navxt]

As always, you can grab the latest version of Breadcrumb NavXT from the Breadcrumb NavXT page. If you experience any issues with this version of Breadcrumb NavXT, please leave a comment on this post detailing the issue.

-John Havlik

[end of transmission, stay tuned]

How to Add li and Other Tags to Breadcrumb Templates

Since Breadcrumb NavXT 4.3.0, all settings that can contain HTML are passed through wp_kses(). With this change, only a basic set of acceptable tags and properties within tags were allowed. Naturally, this restricted users more than they were used to. The restriction wasn’t the biggest problem, the lack of a filter to allow users to add their own tags in to the allowed HTML tag list. However, with Breadcrumb NavXT 4.4, a new filter bcn_allowed_html has been introduced to fix this issue.

The default set of allowed HTML tags in Breadcrumb NavXT 4.4 consists of: <a>, <img>, <span>, <h1>, and <h2>. For the purposes of this guide, let’s assume you don’t want to use the built in bcn_display_list() function to output breadcrumbs wrapped in <li> tags. The reason you would want to do this is if you need additional properties within the tag (Breadcrumb NavXT will by default add a class but that’s it).

In Breadcrumb NavXT 4.4, adding a tag to the allowed HTML list for Breadcrumb NavXT is really easy. Just create a function with one input argument ($allowed_html in this example). Within that function append, using the HTML tag name as the array entry key, assign an array of properties that tag is allowed to have, using the property name as the array entry key and a value of true. Then add your filter function to the ‘bcn_allowed_html’ filter hook. Below is an example of this for the <li> tag with a selection of properties.

function my_bcn_allowed_html($allowed_html)
{
	$allowed_html['li'] = array(
		'title' => true,
		'class' => true,
		'id' => true,
		'dir' => true,
		'align' => true,
		'lang' => true,
		'xml:lang' => true,
		'aria-hidden' => true,
		'data-icon' => true,
		'itemref' => true,
		'itemid' => true,
		'itemprop' => true,
		'itemscope' => true,
		'itemtype' => true
	);
	return $allowed_html;
}
add_filter('bcn_allowed_html', 'my_bcn_allowed_html');

To get started quickly, just copy and paste the above code into a site specific plugin and start playing.

-John Havlik

[end of transmission, stay tuned]

Playing with the Olympus 60mm f/2.8 Macro

Even since purchasing my Panasonic GF5 last winter, I’ve wanted a macro lens. Those who are familiar with the micro four thirds system know that there are only two macro lenses for it. The quite expensive Panasonic/Leica 45mm f/2.8, and the newer and slightly less expensive Olympus 60mm f/2.8. Currently, Olympus has some decently sized instant rebates on a large selection of lenses, including the 60mm f/2.8 macro, so I picked one up.

Above is a side by side comparison of the Panasonic Lumix 14-42mm, Olympus 60mm macro, and the Panasonic Lumix 45-175mm. In comparison to all the Panasonic lenses I have, the Olympus is quite narrow. This makes it look much longer in the product photos than it really is.

Below is a set of sample picture I took when playing around with the Olympus 60mm on my GF5. A few things to note, in several instances the GF5 had trouble getting the lens to focus (lots of back and forth focusing). I had better luck using manual focus mode. Additionally, the depth of field of the Olympus 60mm at f/2.8 isn’t very great. I ended up going into aperture priority mode to stop down to f/5 to get a reasonable DOF.

-John Havlik

[end of transmission, stay tuned]

WordPress 10 Year Anniversary: Minneapolis Party

Today marks WordPress’ 10th year of existence. To celebrate, #wp10 parties are being held all over the world. In the Minneapolis/St. Paul area we met at Minnehaha Park. Unfortunately, the weather didn’t cooperate for the bike-ride/run that we planned to do before grilling. So, we stuck to socializing in the pavilion, grilling bratwurst (some hotdogs, chicken and a lonely hamburger made it to the grill as well), and eating birthday cake.

-John Havlik

[end of transmission, stay tuned]

Using ImageMagick to Batch Convert Photos

Back when I posted my photoset from WordCamp Minneapolis 2013, rather than performing any post processing, I just uploaded the full images from my camera’s SD card. Normally, I would open up the Gimp and reduce the resolution by 50% and then crop to a 3:2 or 16:10 ratio depending on what was appropriate for the images. This produces small files that are easy for the server to handle.

Since WordPress generally does a good job generating the image sizes it needs, I didn’t worry about uploading the full, unreduced images. Normally, the end users would never see the full size images, so no harm, right? Wrong. At least if you use Jetpack.

If you use the tiled gallery feature in Jetpack (like I do on this site) you end up using the WordPress.com CDN. Unfortunately, Jetpack tries to load the full image size when caching for the tiled gallery. Trying to pull 50 or so images, at 1 MiB to 2 MiB a piece to cache didn’t work too well. Naturally, Jetpack could do things slightly more intelligently and request for the closest, already existing, image size to be used, but that’s a topic for another day.

To get things to play nicely I needed to reduce the ‘original’ file sizes. Thankfully, Weblogs.us has ImageMagick installed. Thus, fixing the issue was as simple as running:

convert P*.jpg -resize 50% \
-quality 88 \
-set filename:newsize '50_%t' '[filename:newsize].jpg';

Then, after inspecting the results, all that was left to do was to rename the 50_ prefixed files back to the original file name.

-John Havlik

[end of transmission, stay tuned]

Updated: