Victorinox Mini Champ Alox “Swiss Army” knife feature guide

I’m not really a “knife guy,” but for most of my adult life I have carried some variety of Victorinox “Swiss Army” knife around in my pocket almost everywhere I go. I just find that very often I need the blade to cut open a box, or the small scissors to cut hangnails, or the screwdriver, and having an unobtrusive object in my pocket that can handle these tasks is very convenient.

“Unobtrusive” is key. When I’m not using it, I want to forget it’s even there. It can’t be too heavy or too big, so I really like the smallest knives they make… usually a variety of the Classic SD. But when I (once again) misplaced the latest in a string of those tiny knives, and decided I needed to buy (yet another) replacement, I splurged on the Mini Champ Alox.

Most Victorinox knives have an outer shell made of plastic, but they also make slim profile variants with this “Alox” outer shell… embossed aluminum with anodic oxidation — hence the “Alox” name. Since these are thinner, they usually lose a couple of features — typically the removable toothpick and tweezers (and in some cases, the ballpoint pen or flashlight). I owned a Classic SD Alox that I really liked, but then I realized that with the thinner shell, the Mini Champ Alox was exactly the same size as the Classic SD, but instead of three tools, it had eight. Yes, it also costs 3 times as much, but it was too intriguing not to buy.

I really do love it and would feel lost without it. But I’ve come to realize that I pretty much actually only use the three tools on one side, and almost never touch the five on the other side. In fact, I have trouble even remembering the purpose of some of those tools. So for my own future reference, I’ve checked online sources, and documented their functions in the annotated image below:

So… yeah. Some of these, I really just don’t get. I don’t know how many people use a cuticle pusher; personally it is not something I have ever used or wanted to use (in fact, pushing my cuticles back is something I find so unpleasant that it’s nearly a phobia). And yet, one entire blade of this pocket knife is apparently devoted to that sole function.

Likewise, I don’t ever really need an orange peeler — the only oranges I eat semi-regularly are mandarins, which peel very easily without a tool. That particular blade has two functions; the tip is apparently a “scraper,” whatever that’s supposed to mean. My understanding was that some part of this was supposed to be a fish scaler but again… not something I need. (Update: the flat edge between the hook and the pointy tip is sharpened, so I suppose that edge, not the point, is the scraper.)

Then there’s the tool that is alternately referred to as a “letter opener” and an “emergency blade.” One of those functions sounds extremely banal and the other gives me visions of… well… this:

Dr. Hibbert makes use of his trusty pocket knife. Source:

I do actually use the nail file/cleaner and screwdriver/ruler from time to time. But for sure, it’s those three bottom tools that make this an essential daily “carry” for me. (Yes, I hate the “nouning” of verbs… almost as much as the “verbing” of nouns.) And the funny thing is, two of the three are also on the Classic SD.

That last tool does a lot of heavy lifting for the overall utility of this knife, with its 3-in-1 design. The bottle opener… works. The wire stripper… probably works. I actually do need to use a wire stripper from time to time, but not often enough to remember it’s on here. But the Phillips screwdriver… oh man, is that handy. Except…

Except, the way the flathead screwdriver is designed, it actually works on just about any Phillips screw you may come across. And it’s part of the regular Classic SD. There’s also one problem with the Phillips screwdriver on here. Last night I needed to use it, and I couldn’t open it. Today I investigated, and the issue seems to be that at some point I used it on a screw that must have been made of a harder alloy than the screwdriver itself, and it nicked/bent the tip slightly. That was getting it stuck in the closed position. I was able to pry it open (using, of all things, an iPhone SIM card remover tool), and then I filed down the edges of it using… the file on another, larger (knock-off no-name) Swiss Army knife. Now it works again.

Anyway… my day started off just trying to figure out why the Phillips screwdriver in my Mini Champ Alox was stuck, and now after writing this, I’ve come to realize that this entire tool is kind of a waste of money and a failure of design. In the future, if I lose this knife, I most definitely will not be getting another one. The extra tools are kind of useless and the extra expense is unjustifiable. Stick with the Classic SD, or maybe the Rambler. It’s basically the Classic SD with the 3-in-1 blade added.

More Gutenberg Doing It Wrong™: making Navigation blocks editable… sort of

By this point I have more-or-less embraced Gutenberg, a.k.a. the WordPress Block Editor. But I have not embraced Full Site Editing, a.k.a. the Site Editor, and I am not sure I ever will. I do not know who it is for, although I suspect it is for people who do not yet exist… namely, future WordPress freelancers who don’t know how to write code. The types of power users/professionals who currently spend their time in the ecosystems of tools like Divi, Elementor, Beaver Builder, etc.

Anyway… the present-day moving target of using the Block Editor as a professional site building interface has some weird gaps in its capabilities. And site navigation, in particular, is a chasm, a crevasse, a gaping maw of unfinished business.

Navigation has never been a particularly strong suit of WordPress, since WordPress was envisioned as a blogging tool and not a general-purpose CMS. Going back to the early days of constructing navigation piecemeal by setting a parent page and menu order on each individual page, to plugins like CMS Tree Page View, to the well-designed but weirdly detached custom menus that have been a staple of WordPress development lo these many years, building menus in WordPress has always been a bit “off.” I get what the core team is going for with the new Navigation blocks, but they’re still not quite flexible enough for code-centric developers like myself, and more importantly, there’s no way to just edit them directly.

The Block Editor has introduced a couple of types of “reusable” content that gets stored as standalone entries in the wp_posts table. First you have Reusable Blocks which are awesome. And then you have Navigation Blocks, i.e. the purpose of this post.

Something that’s a bit sticky about both of these types of reusable content is that there isn’t really a standalone way to edit them. And it doesn’t always make sense — despite what the core team apparently thinks — to always edit them in context (either the Site Editor or the Block Editor within a page). Because sometimes a theme developer might want to put them right into a template. (And a theme developer might not want to use the Site Editor to build their templates, which I believe will always be a legitimate approach.)

So, what do we do? Well, Bill Erickson has a great post showing how to add Reusable Blocks to the admin menu. This works incredibly well, and I’ve built it into my new base block theme. What I really like about it is that it works just the way you would expect — you get the Block Editor, but the only thing in it is the reusable content itself.

Building off of this, I thought I might be able to take the same approach, just using the wp_navigation post type instead of wp_block. And it works, at least, to the extent of getting a Navigation Blocks item to appear in the admin menu, taking you to an index page that lists all of the stored Navigation blocks, and an editing screen for those blocks.

But it’s a classic editor screen. Without the editor. You can change the title of the Navigation block, but if you want to actually edit its contents, you’re out of luck.

Digging around in the WordPress source code reveals some clunky code (includes/admin-filters.php, lines 87-89) designed specifically for the purpose of preventing direct editing of the Navigation blocks:

add_action( 'use_block_editor_for_post_type', '_disable_block_editor_for_navigation_post_type', 10, 2 );
add_action( 'edit_form_after_title', '_disable_content_editor_for_navigation_post_type' );
add_action( 'edit_form_after_editor', '_enable_content_editor_for_navigation_post_type' );

(This bit of code also reveals that even the core team has trouble telling the difference between actions and filters.)

I haven’t figured out why the core team doesn’t want us to do something it seems obvious that we’d want to do but… well, when have I ever let that stop me?

I’m still trying to figure out how to actually get the Block Editor to load. Removing the use_block_editor_for_post_type (ahem) “action” doesn’t do it, and neither does adding my own (ahem) filter that does the opposite. So, for now, we are left with the classic editor. But I did figure out a way to get it to always default to the Text tab, since the Visual tab won’t display anything. (I haven’t bothered to put in the effort to figure out how to only display the Text tab, but anyone who wades this deep ought to know what they’re getting themselves into.)

Here, then, is my variation on Bill Erickson’s Reusable Blocks code. This will get the Navigation Blocks item to appear in your admin menu:

function rm34_admin_menu_navigation() {
        'Navigation Blocks',
        'Navigation Blocks',
add_action('admin_menu', 'rm34_admin_menu_navigation');

And once you have that going, then you can use this to get the editor to appear, and to default to the Text tab:

function rm34_enable_wp_navigation_editor() {
    add_post_type_support('wp_navigation', 'editor');
add_action('edit_form_after_title', 'rm34_enable_wp_navigation_editor', 11);

function rm34_enable_wp_navigation_editor_text_mode($r) {
    global $post;
    if (get_post_type($post) == 'wp_navigation') { $r = 'html'; }
    return $r;
add_filter('wp_default_editor', 'rm34_enable_wp_navigation_editor_text_mode');

(Note: You could use the private _enable_content_editor_for_navigation_post_type() function instead of the add_post_type_support() line, since it does the same thing, but I’m avoiding using private functions. Even I am not that much of an iconoclast. What I’m doing here, specifically with the 11 priority, is turning the editor back on for wp_navigation posts immediately after it has been turned off, rather than on a later action as the above code excerpt from includes/admin-filters.php does.)

What you choose to do from here… well, I don’t really want to know. You need to be able to edit raw Gutenberg comment tags, because that’s what you’ll be working with. And just be aware that the code does not include the <!-- wp:navigation --> tags that wrap everything when the block actually gets used in a page.

In my case, I just wanted to get the data to paste directly into my template, so I wasn’t just stuck with a ref number for a menu I had no direct way to modify. Once I got the code, I deleted the saved Navigation block altogether.

All of which is to say, the old nav menus made a lot more sense from a coding perspective.

Radiohead albums as a timeline of my work history

I’m in a Radiohead mood today, listening to A Moon Shaped Pool, and I decided to kill some time (a.k.a. distract myself from work) by looking for a “listicle” ranking their albums, to see if I agreed with it. Here’s what I found. Pretty good. I would swap the positions of Amnesiac and Pablo Honey, and probably knock The Bends down to fifth (moving A Moon Shaped Pool and In Rainbows up by one each). Honestly I have barely listened to Pablo Honey (ever) or King of Limbs (beyond about a month after its release)… and I haven’t really listened to Hail to the Thief since In Rainbows came out.

It’s also hard for me to process the fact that they only have 9 studio albums… back in the early 2000s when I listened to them a lot there were a handful of EPs, extended singles, a live album, etc. that made their catalog seem a lot bigger.

(Also yes I did notice the author got the release year of Pablo Honey wrong… it was 1993, not 1995!)

I can tell when some of these were released by the mental image I have of where I was when I was listening to them.

Pablo Honey (1993) and The Bends (1995) — I didn’t really listen to Radiohead in the ’90s, but I remember these being on the periphery of my awareness in college.

OK Computer (1997) — I first heard this one in a friend’s studio apartment in Loring Park, Minneapolis shortly after it was released, and now I was paying attention to these guys. (We were living in California at the time, but I spent the night hanging out with some college friends when I came back to visit my family in Minnesota.)

Kid A (2000) — I remember first talking about it with my bandmates (one of whom was a coworker at my job at the time) at a rehearsal in our drummer’s basement in the northwest suburbs of Minneapolis.

Amnesiac (2001) — I was working from home for the first few months after we moved to Atlanta, and I listened to this sitting in my basement workspace.

Hail to the Thief (2003) — Another basement… this time I was working for a travel industry startup with a terrible early 2000s tech startup name (and long-since defunct), and my desk was in the basement of a converted house in the northern Atlanta suburbs.

In Rainbows (2007) — The first pay-what-you-want album! I splurged for the big vinyl-plus-CD-plus-coffee-table-book set. I most associate it with my home office in the back bedroom of our first house in Minneapolis.

The King of Limbs (2011) — My wife was teaching at the University of Minnesota when this came out, and I was already self-employed at that point. I would meet up with her on campus for lunch once a week, and on those days I would generally just hang around somewhere on campus with my laptop working. I always associate this album with sitting in the open area on the lower level of the then-brand-new Bruininks Hall.

A Moon Shaped Pool (2016) — Another one I immediately purchased on vinyl. This was spinning frequently in the storefront studio space I was renting at the time in the East Nokomis area of Minneapolis.

Oh yeah… since that listicle I linked to will probably be as dead as my old travel industry tech startup’s website when I want to look back on this in 10 or 20 years (eek), here’s my ranking as of right now:

9. The King of Limbs
8. Pablo Honey
7. Amnesiac
6. Hail to the Thief
5. The Bends
4. A Moon Shaped Pool
3. In Rainbows
2. OK Computer
1. Kid A

The lengths to which I will go to “Do It Wrong™”

First, let’s get one thing straight: WordPress is built on PHP. The Gutenberg/Block Editor team may love React more than anyone else outside of Facebook, but ultimately WordPress is still built on PHP, and the WordPress developer community is built of PHP developers.

It doesn’t have to be PHP. I mean, PHP is kind of a garbage language if I’m honest. But the point is, there is server-side processing happening. It is what makes it possible to dynamically assemble page output, and create separate data, functionality, and design layers in a web application. But for reasons I barely understand and certainly do not agree with, the Gutenberg team decided to make templates pure HTML. No PHP allowed. I feel like they’ve separated the wrong layers.

Anyway, the problem I’ve run into here is that I have perhaps become a bit too dependent upon the one place in Gutenberg where you can still write PHP: block patterns. Block patterns are PHP files, not HTML files like templates or template parts. So naturally I’ve been tempted to misuse block patterns. (Although it didn’t really become apparent to me that I was misusing them, until I was past the point of no return.)

I have always used Advanced Custom Fields extensively in my WordPress site development. And in the Gutenberg era, it’s made it possible for me to create custom blocks while still working primarily in the familiar world of PHP.

I’m getting better at creating block patterns, but today I discovered a way that I may be fundamentally misunderstanding them. I’m really kind of using them as template parts, I guess, but as a cheat way to get access to PHP. Specifically, I’ve been putting block patterns into my templates. Not as ways of dropping in a pre-formatted set of editable blocks in the Block Editor itself, but as “hardcoded” ways to include some PHP-driven elements in the non-editable parts of my page templates.

This has all been working perfectly well until today, when I decided I wanted to be able to drop the contents of an old-school ACF field into a block pattern I created. This pattern is for displaying some of the meta data about a post: post date, categories and tags, and now a new custom field: the byline.

Don’t say I should just use author fields; if you don’t understand a context where a news post might have an author who is not the person who is entering the post in WordPress (and who, in fact, does not even have a WordPress login) I don’t know what to tell you.

I figured, OK, this will be a no-brainer. I’ll just put this into the block pattern PHP file:


Oops… that didn’t work. Let’s try this:

the_field('byline', $post);

Hmm… still didn’t work. Oh sure, I need to get the global variable first:

global $post;
the_field('byline', $post);

Wow, that doesn’t even work. Well, what about this?

the_field('byline', get_queried_object_id());

Take a guess.

So, here’s the problem. Block patterns have no context. When a block pattern gets inserted into a page, then it does have context. So if I were to go and edit the post, and insert this block pattern into the actual post content, then it would display the data. (I guess… I didn’t try that until several steps later.) But that isn’t what I want. I don’t want the client to have to remember to insert this “post meta” block pattern at the top of every post. I want it in the template. That’s the whole point.

But if the block pattern is directly in the template, it doesn’t know the current post ID. More importantly, it has no way to even access the current post ID. I’m Doing It Wrong™.

Fine, I know I’m doing it wrong. But once again I feel like WordPress itself is fundamentally wrong here.

And I’m determined to do it my way, even if it’s “wrong,” dammit.

After probing several further layers deep on this (including trying to use the ACF shortcode in the block pattern — which is where I realized it does work if you insert the block pattern into the actual post content, but not in the template), I determined that there was really only one way to do it wrong that still actually works.

I created a custom ACF block designed solely to just output the value of any arbitrary custom field.

This is so unbelievably WRONG I can taste it. But it’s the only way I’ve found to do what, in all of my experience across nearly two decades of working with WordPress and PHP in general, seems like it should be a really freaking easy thing to do.


OK. First, you need to have Advanced Custom Fields Pro installed, so you can use ACF Blocks. In your theme’s functions.php file, do this:

register_block_type(dirname(__FILE__) . '/blocks/acf-diw');

Then you need to make sure you have this hierarchy of files in your theme:


We’re not actually going to put anything in acf-diw.css at this point, but you might want it later.

Here’s what goes in the block.json file:

	"name": "acf/acf-diw",
	"title": "ACF DIW",
	"description": "",
	"style": "file:./acf-diw.css",
	"script": "",
	"category": "",
	"icon": "editor-code",
	"apiVersion": 2,
	"keywords": [],
	"acf": {
		"mode": "preview",
		"renderTemplate": "acf-diw.php",
		"postTypes": []
	"supports": {
		"inserter": false
	"styles": []

Then in your acf-diw.php file you need this. Note this is the absolute bare minimum code you need for this to work; I would recommend actually using the get_block_wrapper_attributes() function to allow you to include CSS classes, styles, an ID, etc. in the output — and my actual version does have that. This is just to key you in on what specifically makes this trick work. It’s not highly secure, but I think it’s reasonably safe, specifically because we’re checking to make sure we’ve passed in the name of a field, and that there’s actually a custom field on this page/post with that name, and we’re sanitizing the output.

global $post;
if (!empty($block['data']['field']) && $field_value = get_field(esc_attr($block['data']['field']), $post)) {
	echo '<span>' . wp_kses_post($field_value) . '</span>';

OK, now with all of that in place, here’s what you can put into a block pattern file and actually get the output of an ACF custom field that exists on that page/post:

<!-- wp:acf/acf-diw {"name":"acf/acf-diw","data":{"field":"byline"}} /-->

Replace “byline” with the name of your ACF field.

It works. But you didn’t hear it from me.

Side note: This does not work properly when it’s actually inserted into the page content as a regular block. As configured, it is strictly for use in block pattern files where you want to break what block patterns are apparently intended for. (That’s why we have the "inserter": false line in the JSON file.) You could build this in a way that would make it work properly as an inserted block, but why bother? That is, expressly, what the ACF shortcode is for.