As a web developer, I actually don’t use cookies that often (mainly because I’m not interested in tracking users’ behavior). But I do need to use them occasionally, such as to remember when they’ve clicked the “X” to close a modal alert, so I don’t keep showing it to them on each new page they visit.
That’s what led me to today’s surprising discovery. My cookie wasn’t working properly, so I wanted to investigate a) whether or not it was actually being saved, and b) what data it was saving.
I work on a Mac, and Safari is my primary browser. But I already knew Safari doesn’t let you inspect the contents of cookies, so I fired up Chrome, which is my go-to for testing anything that I can’t test with Safari. I know Chrome always used to let you inspect the contents of cookies, so imagine my surprise today when I discovered that, at some point fairly recently, Chrome apparently removed that capability. You can still see which sites have stored cookies, and how many, but you can’t investigate the details any further than that. Seriously??
Next I tried Firefox. Nope, same.
At this point I was highly dubious that the fourth browser in my testing queue would handle things any differently, but I had no alternative, so I reached for that rarely-clicked-upon blue-green swirl icon in my Dock, loaded my page in Microsoft Edge, and… what do you know, Edge does still let you inspect the exact contents of stored cookies.
But for how long?
Anyway… for now, I have a justification for keeping Edge installed on my Mac.
I already mentioned this in an addendum to my last blog post, but it seems to warrant its own dedicated post.
I’m a self-employed, solo developer, not very actively engaged in the WordPress “community” even though my work is 95% WordPress. So I have apparently missed the memo that shortcodes were (prior to yesterday’s release of WordPress 6.2.1, anyway) the way people were injecting PHP into their HTML-based Block Theme templates. (Silly me… I was just misusing Block Patterns to the same effect.)
Well… as it turns out, allowing shortcodes in Block Theme templates apparently was a security issue, which the WordPress core team summarily “fixed” by just outright removing shortcode support in templates in this update.
This change did break a pair of sites for me (which are still just in final testing, not live, and which I need to go fix as soon as I finish writing this), but the problem was relatively minor. It sounds like a lot of people are using shortcodes extensively as a backdoor hack for adding PHP functionality to templates, and they are… um… not happy.
At what point does the Gutenberg team collectively take a step back and realize that maybe they’ve been the ones Doing It Wrong™ all this time? I feel like that reckoning is approaching.
This is not as defeatist as it seems by the title. I’ve actually had a huge breakthrough in my ongoing battle journey with the WordPress Block Editor (a.k.a. Gutenberg).
My biggest problem throughout the process of trying to build a Block Theme has been finding myself hamstrung by the lack of PHP in a Block Theme’s all-HTML template structure. I’ve ended up brute forcing my way into having access to PHP with a combination of ACF Blocks and Block Patterns. But it should have been obvious to me that both approaches were wrong, because I found myself creating ACF Blocks that didn’t have any custom fields and Block Patterns that didn’t have inserters.
The fact that I was using both of these tools in ways that they are patently not intended to be used should have been my first clue, but the problem has always been that documentation of all of this new technology is so scarce, inconsistent, poorly organized and out-of-date by the time it’s written, that it’s hard to really know in advance how they work, and whether or not you’re using them properly. And as my recent series of blog posts have indicated, I am the proud king of Doing It Wrong™.
But as I said at the beginning, I’ve had a revelation, which is this:
The only reason to create a pure “Block Theme” is if you intend to use the new Site Editor (a.k.a. Full Site Editing).
I emphatically do not intend, now or ever, to use the Site Editor, because I have always coded themes from scratch, and the people I am building sites for do not want to modify the overall design themselves, nor should they be given access to the tools to do so.
I am completely locking down access to the Site Editor on the sites I build, so why should I design my themes to work with it? Well… until now, I kind of just thought that was The Way Forward. Maybe it is, but it’s a way that does not, at all, align with how I do business or what my clients want/expect from me.
Luckily, core WordPress team member Carolina Nymark has written an excellent introduction to using PHP templates in block themes. It’s as simple as this. Just… use the old PHP-style of templates. There are a few tricks to be aware of, most of which are addressed by Carolina’s article, but some more I discovered along the way.
I’ve spent the last year and a half of building my block theme constantly butting up against this frustrating limitation. Now after about 4 hours of work, I’ve managed to convert my nascent Block Theme to using PHP templates.
I’ve eliminated my custom field-less ACF Blocks.
I’ve eliminated my un-insertable Block Patterns.
Things are working like they should. Well, mostly. This is an ongoing process. But the key test of the change has been that everything that was working in the theme before is working now, and I have the full capabilities of PHP and the long history of PHP-based WordPress development back at my disposal for future work.
I’ll write more about this in the coming weeks as I refine my process, including an overview of my general setup for a Block-friendly but PHP-rich base theme.
Update: Well, it seems rather fortuitous that I chose this undertaking when I did, because it coincides perfectly with the release of WordPress 6.2.1 which breaks shortcodes in Block Theme templates (which is even more of a shitshow for some people than it is for me, since it hadn’t occurred to me that shortcodes could be used as a workaround to the absense of PHP in Block Theme templates), including a pair of sites I’m currently developing using this theme. Switching those sites to the new PHP-based version of my theme should fix this issue automatically.
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:
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.
