Traditionally, the Breadcrumb NavXT settings page has only allowed published/publicly visible pages be the root page for custom post types. This follows what WordPress core does with the homepage and posts page. However, in some circumstances, having a private page be the root page for a custom post type makes sense.
Introduced in Breadcrumb NavXT 7.4, the bcn_admin_post_root_args filter allows for control over the arguments passed into the root page drop down. Below is an example of using the bcn_admin_post_root_args filter to allow private pages to show up in the root page drop down:
This can be extended to only allow private pages to be the root page for specific post types (by checking the $post_type_name parameter for the desired post type). Lastly, while the setting is for the root page, it does not have to be limited to the page post type.
If your posts are presenting the above message to users that are not logged in (can test in a private browser window), there is an easy fix. In the post editor, look for the “Access” metabox within the editor sidebar. Make sure to change the value to “Everyone” from what it is currently set to and update your post. Now your post should be visible to everyone.
I ran into this feature accidentally, the previous post on this site ended up having the access set to “Anyone subscribed” instead of “Everyone”. This went unnoticed by me for several weeks until I ended up visiting while not logged in and noticed the ‘Subscribe to continue reading’ message. Of course, the Access metabox was minimized so it wasn’t immediately clear what was amiss.
Additional Thoughts
While the access feature is neat (if you want to use the various Jetpack features for managing subscribers), it somewhat clashes with the existing Visibility field for posts (which WordPress has had for nearly ever). It would be nice if this feature integrated as additional Visibility options (where it really belongs). Additionally, it would be good if, as with the visibility modes (private/password protected), there was an indication in the front-end that the post is not accessible to everyone while logged in (to help avoid surprises).
Previously, if one wanted hardware accelerated transcoding in one’s Plex Media Server, the options were to either use a Nvidia card, or use an Intel CPU with QuickSync (and a platform that enables the iGPU). With Intel releasing the Arc series of GPUs, a 3rd option emerged. Recently, low profile variants of both the Arc A380 and Arc A310 have become widely available, presenting a low cost, low power, and easy to fit hardware transcoding option. On the software side, not much is needed to get hardware accelerated transcoding working with the Arc A380/A310.
Drivers
First up, you will need the Intel graphics drivers in your kernel. Check your distro’s guides for how to do this (Gentoo has a fairly good wiki entry on this). One item to note, the choice of whether to compile the driver as a module or include it in the kernel depends on your setup. A general rule of thumb that has worked for me: if you use an initramfs, compile the DRM_I915 driver as a module; if you use efistub as your bootloader, build the driver into your kernel and include the firmware into the kernel image.
If you need to include the firmware into the kernel image (building the DRM_I915 driver into the kernel instead of as a module), you will need to install the linux-firmware package before compiling your kernel. Under the firmware loader settings, you’ll need to include the following firmware blobs: the dg2_dmc, dg2_guc, and dg2_huc. As of Linux 6.4.13 these are the versions the i915 driver will want: i915/dg2_dmc_ver2_08.bin i915/dg2_guc_70.bin i915/dg2_huc_gsc.bin
Userland
After rebooting with the new kernel, within the Plex Settings, under the Transcoding section, enabling hardware acceleration should be available. Additionally, the Arc A380/A310 should show up in the Hardware transcoding device dropdown. Make sure both “Use hardware acceleration when available” and “Use hardware-accelerated video encoding” are checked. For the “Hardware transcoding device” option, if you have other GPUs, you may want to select the Arc device so it is targeted. Don’t forget to press the “Save Changes” button.
While Plex is now finding the device, it still may not be able to use it just yet. If libva isn’t installed, Plex will not be able to use the Arc GPU for transcoding. For funtoo users, ensure that your profile has the gfxcard-intel mix-in (for Gentoo make sure you have intel in your VIDEO_CARDS setting in make.conf) and then install libva. At this point, hardware transcoding should work. You can double check this by using intel_gpu_top while playing a video. Another method of checking if hardware transcoding is working is through the “Now Playing” section of the Plex dashboard. If you see a (hw) next to the codec and the word Transcode in the video section, hardware transcoding is working.
Note that getting hardware transcoding working with Plex Media Server only required the Intel graphics Linux kernel driver, some firmware blobs, and libva. X server, Wayland, a window manager, and desktop environment were not needed or installed.
Recently, I ran into a problem with an old SSD formatted with btrfs. The filesystem refused to mount. Checking dmesg I had an error stating that "the device total_bytes should be at most NUMBER1 but found NUBMER2", where NUMBER1 is less than NUMBER2.
The solution is to use the relatively new fix-device-size feature in btrfs rescue. This was added sometime after 2022, likely in Linux 6.3 (the patch to add this feature was submitted in the kernel developer mailing list in mid-2022). At the moment, I can confirm that 6.4.13 has this feature. Syntax wise, the command is:
btrfs rescue fix-device-size <device>
Just replace <device> with the /dev/ path to the device you are having issues mounting due to the size missmatch. This should work for most cases where the total_bytes for the device is only ‘slightly’ larger than the actual device size.
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 ' & ';
}
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.
