“Upgrading” from the iPhone 13 mini to iPhone 16e is a lateral move, at best

Yesterday Apple announced the iPhone 16e, and I briefly considered trading in my iPhone 13 mini for one.

Bear in mind, the name I chose for my Personal Hotspot on the phone is “You can pry my iPhone 13 mini from my cold, dead hands.”

So, is the iPhone 16e worth abandoning that bold stance? Uh… no.

There are definitely some ways it’s better that I would appreciate: faster CPU, better battery life, USB-C port.

There are ways it’s “better” that are either irrelevant to me or actually a downgrade, from my idiosyncratic perspective: a larger screen (too big to reach across with one hand, and too big for my pocket), Apple Intelligence. (I suppose as a “techie” I should care, but I am utterly disinterested in AI in general, and in “Apple Intelligence” in particular.)

There are ways it’s clearly worse, but that I don’t care about, most specifically MagSafe. I like MagSafe in concept, but I don’t have a MagSafe charger and am indifferent about getting one.

And then there are ways it’s worse, that I very much do care about. Again, the size. My eyeballs would appreciate a bigger screen but no other part of me wants my phone to grow. Even the 13 mini is slightly larger than my ideal phone size.

But above all, the real deal-breaker, is the camera situation.

I am not heavily invested in the iPhone for high-end photography. Obviously I’m not, or I wouldn’t still be using an iPhone 13 mini. But I do shoot all of my YouTube videos on my iPhone, and there are two specific features of the iPhone 13 mini camera system that I use extensively: Cinematic Mode, and the 0.5x zoom, wide-angle lens.

The iPhone 16e lacks both of these camera features. Without them, I would be giving up too much.

Of course, I actually own two iPhone 13 minis. (I inherited my dad’s when he died.) So I could trade in my 13 mini and upgrade to the 16e for my day-to-day phone, while still using the spare 13 mini for shooting video.

I considered it. But… back to the size thing. I don’t want to carry a larger phone. So until Apple makes another small phone, or until it just stops working altogether (a far more likely scenario), you can pry my iPhone 13 mini from my cold, dead hands.

How spammers, scammers and botnets know your website is a target

I was just mulling this over as I spent a few minutes looking at the monitoring tools I have running on the large number of websites I maintain, both for myself and my clients.

Unscrupulous types have plenty of reasons for trying to infect a website with malicious code, and they have tools that are designed to help them find websites that are ripe for exploit.

Specifically, there are telltale signs that a website might be running a particular platform, or they might just assume it’s a popular platform (*cough* WordPress *cough*) and run with that. Either way, they have lists of known exploits, and they just need to run a program that tries to find those exploits on a given website.

If they find one, jackpot.

It’s been interesting to see how this has evolved over the years. A decade or so ago, the most common exploit I saw was silently infiltrating a WordPress site and injecting code into its pages, either via JavaScript or a 1-pixel iframe, that would load data from an external site or redirect the user’s browser to a scam site that would throw ads at them, infect their computer with a virus, run a keylogger, etc.

More recently, what I see most often — and it’s maybe because as a matter of course I run tools that block those aforementioned actions — is surges of fake e-commerce transactions for the cheapest item in a store. Clearly in those cases the scammers have gotten their hands on a list of stolen credit card numbers, and they’re testing to see if any of them are still active.

God, these people suck.

Anyway… the thing I was thinking about today was kind of a meta-level factor in all of this. It’s not just that the botnets only infect sites that haven’t been kept up to date and therefore are exploitable. It seems like they only even try to infect sites that are very low traffic, with rarely updated content, which correlates reasonably to the idea that the site owners may be neglecting their site and not running important software updates.

But how do they know these sites have low traffic? How do they know their content is rarely updated?

How do they know these sites even exist?

The big tech companies — and I’m thinking especially Google and Meta here — have amassed huge data sets about not just users and their behavior, but the websites users interact with. In short, if Google crawls a site on a regular basis — and if Google knows about a site, it crawls it, unless you specifically tell it not to — then Google has data on how often that site’s content is updated, and how much traffic it gets. (Traffic in relative terms, at least, in the form of click-through from Google search results. But traffic in absolute terms, if the site has Google Analytics running on it. Which a huge percentage of websites do.)

Google shares a lot of the data it collects. But it also doesn’t share a lot of the data it collects, and this is specifically the type of data Google does not make publicly available. Or sometimes even privately available to the site owners.

How do scammers get it?

I don’t have an answer. I don’t even have proof that they’re getting it. I just have my anecdotal observation that the scammers don’t even seem to try hacking into the sites I work on that get a lot of traffic and frequent updates. But they’re constantly prodding and poking at sites and servers that don’t see much other traffic.

Curious.

Why I still use WordPress and prefer self-hosted websites over Software-as-a-Service (e.g. Squarespace)

I don’t hate Squarespace. I’ve used it for a few sites. But I still strongly prefer building my own self-hosted WordPress sites, for a variety of reasons. But I think I just found the best one.

SaaS website builders like Squarespace have come a long way, especially in terms of letting you write your own code. But there are still some deeply ingrained, user-hostile lock-in elements to these platforms, and perhaps there’s no clearer example of this than the Asset Library in Squarespace.

As I write this, I’m in the process of migrating the website for a big band I play in from Squarespace to WordPress. The first step in the move, of course, is setting up a new WordPress site, and since I’m basically just trying to roughly recreate the single-page site we currently have (at least as a starting point), I need to download the assets for the current site: images and videos.

Squarespace has a very elegantly designed Asset Library section, where you can view and organize all of the files you’ve uploaded to your site. There’s just one thing you can’t do: download the files.

Um, what?

Yes… Squarespace offers no way to download the files from your Asset Library. Not in bulk, and not even individually. Seriously.

Sure, it’s not too hard to download the images. You can just drag them from your browser window to your desktop. Even if you drag the thumbnails, you’ll get the original full-sized image. That’s almost enough to make me not hate the experience. But then there are videos.

Video on the web is kind of weird. HTML5 has broad support for videos in an open way, just like with images. The problem is, the early web didn’t really support video because no one had the bandwidth for it, and by the time it gradually gained support — initially through proprietary plugins like Flash — the web had “matured” to a point where companies were trying to find ways to lock down their assets.

So again, even though HTML5 supports video, the way videos are presented on Squarespace, even in the admin, is through multiple layers of wrappers that obscure access to the actual files. Even if you view the raw source of the page, there’s no way to get the direct URL of the file. There is no way to download videos from your Squarespace Asset Library. At all.

Fuck.

Sorry… although my daily speech is liberally seasoned with profanity, I usually abstain from it here on the blog. But it is absolutely warranted here. Seriously, fuck Squarespace for preventing us from downloading our own files.

Their support forum has a thread where it’s spelled out quite clearly that they do not offer a means of downloading your video files. And their support staff spins it like this some kind of super-complicated functionality that they’d like to offer if only they could, but they just haven’t been able to achieve it yet.

Give me a break. They’ve put considerable resources into making it hard to download the files. It would be an order of magnitude easier to build a straightforward system that at least didn’t actively block you from directly downloading the files one-at-a-time.

Yes, some kind of bulk download feature would actually require them to do some development work. But simply allowing the browser to do what it’s designed to do with HTML5 video tags would at least give us a way to download the files individually.

So, make no mistake: the only reason you can’t download your video files on Squarespace is because Squarespace explicitly does not want you to be able to do that.

That’s reason enough for me never to choose to use their platform.

I guess I need to take back what I said at the beginning. I do hate Squarespace.

The core team (i.e. Matt) doesn’t want WordPress to be a general purpose CMS

For various reasons, I’ve kind of taken a step back from heavy client project development in WordPress over the past few months.

Today I’m back at it, trying to really actively work on something new for the first time since before the big kerfuffle started, and the time away has given me new perspective on what WordPress really is, and what the core team (let’s be honest, Matt) wants it to be.

I’ve frequently argued that WordPress owes its broad success to the malleability its plugin architecture provides. The platform is not, inherently, a general-purpose Content Management System (CMS), but thanks to plugins like Advanced Custom Fields, it can be turned into one.

The funny thing is, the platform clearly was moving in the general CMS direction for much of its early life. The availability of custom fields (not ACF specifically, but the more rudimentary open-ended key/value pair system created by the wp_postmeta table), not to mention custom post types and taxonomies, and the extensible template system, really pointed things in the direction of a system much broader than simply “blogging.”

But Matt really just wants WordPress to be about blogging. Because that’s how he uses it. And he only sees what he wants to see.

All of that natural growth in the direction of general-purpose CMS use was effectively pruned by the shift to all things Gutenberg: the Block Editor, and now the Site Editor (formerly Full Site Editing).

I won’t deny that — now that they’re reasonably mature — the elements of Gutenberg are powerful and (somewhat) intuitive tools for building an engaging blog without having to write code.

But for many of us who helped get WordPress to where it is, that’s not what we want, or need. These tools are not only irrelevant to our work, they make the work we need to do much more difficult.

Specifically I’m talking about template design. In their pure intended form, Block Themes can’t have any PHP code in page templates. Which severely limits their functionality. Even if you end up creating a theme — like I have — that’s somewhat of a hybrid of the old and new ways, you’ll find it absolutely maddening how your PHP code may no longer have access to such obvious and basic variables as the post ID.

Meanwhile, core functionality for things like custom fields has been all but killed. It seems like, at the very least, there should be a way in the Block Editor to reference a custom field value. Nope.

Even Advanced Custom Fields’ efforts to extend Block Editor support require a bunch of convoluted hoops. Assuming that creating your own ACF Blocks is overkill, in some cases you can reference ACF values using the [acf] shortcode, but that only works for certain types of fields and, as I’m learning right now, it only seems to work in the Block Editor itself, not in templates.

I’m not saying Advanced Custom Fields is the entire reason for Matt’s extreme actions against ACF owner WP Engine, or for his subsequent deranged steps, seemingly intent on tearing apart the WordPress community itself. But it’s hard to deny that Matt hates ACF for what it represents: a WordPress he can’t control, and one that doesn’t look like what he thinks it should be.

Unfortunately, that’s the only kind of WordPress I care about.

Well… that’s enough for now. Time to go and unravel my theme so I can make this new site I’m building actually do what my clients need it to do. Why did I choose WordPress again? I seem to be asking myself that question more and more frequently.

Update: The morning after I wrote this, I stumbled upon this forgotten bit of code in my theme:

function r3423_acf_disable_shortcode() {
    acf_update_setting('enable_shortcode', false);
}
add_action('acf/init', 'r3423_acf_disable_shortcode');

So, uh… yeah, that part was my fault. But I was just following ACF’s instructions since I generally don’t ever use the shortcode.

The only “Apple Intelligence” I want is for my Mac to stop being so dense about which languages I want to translate emails into

Don’t get me wrong, I greatly appreciate the fact that the Mac has built-in translation features (which predate the marketing appellation “Apple Intelligence”). I just don’t get why it lacks so much context.

ICS Calendar Pro is a big (and growing, slowly) part of my business. And a big (and growing, faster than the business as a whole) chunk of it is in Europe. I’m a lame American, who really only speaks English. Sure, I studied French for three years in high school, and Russian (!) for two years in college. And I have enough of a general understanding of most common European languages that I can at least identify on sight what language something is written in, even if I have some trouble actually reading it — and I most definitely can’t respond in that language. (Well, I almost can in French, sometimes. But it definitely wouldn’t sound professional.)

Enter the Mac’s built-in system-wide translation feature. Just highlight a block of text, right-click on it, and the contextual menu offers translation as an option. It can’t translate to every known living language, of course, but I am mainly dealing with four languages other than English, in this order: German, Dutch, French and Italian.

I just don’t understand why the Mac is so stupid about what kinds of translations I want to do.

My Mac system language is set to U.S. English. So the Mac is usually pretty good, when I’ve selected a block of text that is not in English, at recognizing such, and choosing the correct “from” language in the dropdown.

The “to” language… not so much. It generally just remembers the last language I translated something into, and uses that. But shouldn’t it be smart enough to figure out that if the “from” language is not my system default, the language I want to translate it into is probably the system default?

When the “from” language is English, I get that it is harder for it to know what I want to translate into. There’s context that the system-wide translation tool is probably isolated from.

Ideally, the translation tools would have the context available, such as “this text is inside an email being sent to an address with the .de TLD.” In that context, it should be obvious that if I’m bothering to translate some text out of English, the most likely language I’d want to translate it into would be German.

Yeah, I have a lot of users in countries where it’s not so straightforward — e.g. Belgium and Switzerland — but in general, it seems like there’s a more logical starting point than, “OK, here’s a block of text written in English. Let’s try translating it from German into Spanish.” Sheesh.