April 30th, 2023

Customizing the Separator Based on Position Within Breadcrumb Trail

With Breadcrumb NavXT 7.0, updates to the internals of the plugin added support for more than a single dimension for the breadcrumb trail, allowing portions of the plugin to be cleaned up. As a consequence, non-hierarchical terms now are separated by an actual separator that is controllable. While this separator was not exposed in the settings page, Breadcrumb NavXT 7.2 introduced the bcn_display_separator filter which allows us to control the breadcrumb separator.

The combination of these two features allows new breadcrumb trails that were only possible with lists and CSS in the past. Which, while a valid method, can be a little clunky.

An Example

Suppose the site design requires changing the last separator for non-hierarchical terms (e.g. tags) from the default , to & resulting in a breadcrumb trail for an example post to look like:

Home > Blog > Tag 1, Tag 2 & Tag 3 > Awesome Post

To accomplish this, the bcn_display_separator filter can be used to dynamically replace the separator. Below is an example implementation that does just that:

add_filter('bcn_display_separator', my_bcn_separator, 10, 4);
function my_bcn_separator($separator, $position, $last_position, $depth)
{
    //On the 2nd level and lower, change the last separator to an ampersand
    if($depth > 1 && $position == $last_position - 1)
    {
        return ' &amp; ';
    }
    return $separator;
}

This code will, for any breadcrumb that is beyond the first dimension/level (indicated by $depth) set the separator to & before the final breadcrumb in that dimension/level. Using this code is straightforward, just place it in a site specific plugin (and activate the site specific plugin if it isn’t already active). Naturally, the example code can be modified to use a different separator and to target different positions within the breadcrumb trail, should that be required.

-John Havlik

September 17th, 2020

Mapping Terms to Posts in Breadcrumb Trails

Posted by John Havlik in Guides

In certain site configurations, it makes sense to replace the WordPress built-in term archives with a post (an instance of some post type). Typically, a page (instance of the page post type) is used in place of the term archive. Since version 1.5, Breadcrumb NavXT Paths supports mapping terms to pages (with regards to where the breadcrumb links to). To facilitate this, Breadcrumb NavXT Paths provides a metabox in the term editor for establish this mapping.

Sometimes, the page post type does not make sense for this mapping. In that case, the bcn_paths_map_term_post_args can be used to change the post type that the term editor metabox added by Breadcrumb NavXT displays. Note that this filter was introduced in Breadcrumb NavXT Paths 1.6.0.

The Code

Placing the following code into a site specific plugin, will allow Breadcrumb NavXT Paths to map terms to the post post type:

add_filter('bcn_paths_map_term_post_args', 'my_bcn_paths_map_term_post_args', 10, 3);
function my_bcn_paths_map_term_post_args($args, $term, $taxonomy)
{
     $args['post_type'] = 'post';
     return $args;
}

Naturally, this can be modified to specify post types other than post. Should multiple post types be desired, just replace the string 'post' with an array of the post type names. Since this filter affects the arguments sent to get_post, other arguments may be set as well.

-John Havlik

August 23rd, 2020

Notes on LUKS + EFISTUB

Posted by John Havlik in Guides

Running off of an encrypted root filesystem has been one of those things that never seemed to float to the top of the todo list. However, back in December (2018, this article lived in the drafts bin for quite some time), it finally made it to the top of the todo list. At the time, one was preparing the Dell XPS 15 9550 to replace the Ideapad s405 for travel. Encrypting everything seemed prudent for a travel laptop.

As of the writing of this article, LUKS is the standard way of encrypting a filesystem in Linux. Generally, a boot loader is used to kick off an initramfs which loads the basics (need LVM, dm-crypt, and LUKS) and prompts for the passphrase for decrypting the root filesystem. If you’re fine with running a boot loader, most guides will get you going with LUKS quite quickly.

However, running a full boot loader on UEFI systems feels archaic. There is just something about using the kernel’s built-in EFISTUB that feels more elegant. And, this is where things divert from the bog-standard path. Typically, when using the EFISTUB, one does not bother with an initramfs (compile the kernel for you known hardware set and you’re good to go). However, an initramfs is integral to having an encrypted root partition.

initramfs Woes

The first problem started with trying to get a working initramfs. Since one had not used an initramfs with EFISTUB previously, there were a few hurdles to overcome. Initially, one tried to use an external initramfs. However, the 9550 does not allow/pass UEFI parameters nicely, and using the built-in kernel command line to specify an external initrfamfs in the EFI boot partition did not work. So, the initramfs needs to be built into the kernel for the XPS15 9550. This lead to a second problem.

Initially, the initramfs that genkernel builds was tried. Unfortunately, it appears this is (as of late 2018) broken/not-suitable for situations where the initramfs needs to be bundled into the kernel. Luckily, betterinitramfs can be bundled into the kernel.

Naturally, there is one gotcha to keep in mind regarding betterinitramfs. As distributed, betterinitramfs does not populate /dev/disk/by-uuid et al. as it does not provide udev (or eudev). The end result is real root needs to be specified using /dev/BLOCKDEVICENAME rather than using PARTUUID.

Conclusion

While the setup of using EFISTUB with an LUKS encrypted root partition is a little esoteric, it is possible to get working. There are a bunch of UEFI related pitfalls waiting to snare you—different platforms will have a different mix of issues. Then again, all UEFI systems should be able to use the initramfs embedded in the kernel when using the EFISTUB boot loader. Regardless, this path is not advised for those learning about/using LUKS for the first time.

-John Havlik

August 16th, 2020

Remove ‘Private:’ from bbPress Private Forum and Topic Titles

Posted by John Havlik in Guides

Helpfully, and in some cases, annoyingly, WordPress, by default, prepends the text ‘Private: ‘ to the titles of private posts. While this may be helpful for the user, sometimes it is unnecessary. In the case for bbPress, it may get tiresome to see ‘Private: ‘ everywhere, and for logged in users with permissions to see said forums and topics, it is redundant. Luckily, WordPress provides the handy private_title_format filter which can be used to control the format of titles for private posts.

The Code

The below code, when placed in a site specific plugin, will remove the ‘Private: ‘ text from private forums and topics:

add_filter('private_title_format', 'my_private_title_format', 10, 2);
function my_private_title_format($format, $post)
{
	if($post instanceof WP_Post and ($post->post_type === 'forum' || $post->post_type === 'topic'))
	{
		$format = '%s';
	}
	return $format;
}

Note that this can be adapted to apply to any post type, or post types that are not forum and topic. Simply, change the post type checks in the if statement to target the desired post type(s).

-John Havlik