Tag: WordPress

Posted on
by

I recently added “Your LLM was trained on my blog” to the intro on my home page. I’m sort of being facetious, but it’s also true: my old site (hyperborea.org) has been in the Common Crawl data set for years, this blog has been online since 2002, and the major LLMs have used Common Crawl’s data in their training.

Way back when I switched to WordPress in 2003, one of the things I found annoying about it was that it would auto-convert punctuation from ASCII to “fancy” characters. Curly quotes, curly apostrophes, em-dashes instead of double-hyphens, ellipses…These were things that bugged the heck out of me when I saw them in broken emails and Word documents. Over the next year, seeing the difference it made in legibility, I came to appreciate real typography. Since then I’ve been happy to let WordPress, and later ClassicPress and Eleventy convert my plain typing.

Side note: I still have trouble using some apps with code snippets (ex: Apple Notes and Stickies), ’cause I haven’t figured out how to stop them from converting ASCII punctuation that means something in the code to Unicode punctuation that means something more specific in printed human language. Also, notice in that sentence that ClassicPress was smart enough to convert a straight up and down apostrophe used on a contraction to a curly apostrophe, and not to a curly single quote like it does with ‘here.’

Anyway, WordPress powers a huge amount of the web. I’ve seen stats bandied about such as 42% of all websites, 60% of content management systems, >50% of the top 10,000 websites (by some measure or another). The exact numbers aren’t important, it’s just important to know that a whole lot of the web uses WordPress to convert what people write into HTML pages for the web.

Now let’s get back to LLMs:

  • People think they can identify LLM-generated text because it tends to include em-dashes.
  • LLMs were trained on writing by actual people on the web.
  • A whole lot of that writing by actual people is presented by WordPress.
  • WordPress has auto-converted typography including em-dashes since 2003.
  • That means a large chunk of LLMs’ training data includes text by real people that uses real em-dashes.

“AI” doesn’t use em-dashes because real people don’t, it uses em-dashes because real people do [note: lots of swearing] (via).

The only place I can imagine it would be even a semi-reliable indicator would be in social media posts, on platforms where that kind of auto-conversion doesn’t happen. Even then, I can easily imagine someone writing a draft in Word, or copying a sentence or two from their WordPress post, or just hitting option+shift+hyphen on a Mac (or whatever the key combo is on Windows).

Posted on
by

I’ve been using the excellent ActivityPub Plugin for WordPress to connect this blog to the Fediverse for several years now, and it keeps getting better. The plugin makes any WordPress blog also work like a Mastodon server, so you can follow and interact from any site running Mastodon, Akkoma, Pixelfed (image posts only, of course), Snac or my favorite, GoToSocial.

Last year some features started breaking on here as WordPress and ClassicPress diverged, and I put some stop-gap fixes in place. I never quite got around to debugging it in my spare time, though. So I was very happy to see that starting with the 7.8.3 release a couple of weeks back, ActivityPub for WordPress now explicitly checks for ClassicPress to fall back to a compatibility mode!

You still need to trick it into thinking it’s on WordPress 6.5 or later (ClassicPress 2 split off from WordPress 6.2), but the latest version fixes all the problems I’d been working around on this site, including broken comment forms and missing images on the Fediverse view of a post.

Update: I missed a scenario with filtering comment authors in comment_reply_link. I’ve manually worked around it for the moment, and when I have a chance I’ll either do a proper bug report or suggest a proper fix.

So I’d like to give a shout-out to Matthias Pfefferle and the ActivityPub Plugin team and say: thanks for fixing it!

And if anyone reading this wants to connect their WordPress or ClassicPress site directly to the Fediverse (rather than just cross-posting or auto-posting links), this plugin is still the best way to do it.

On a related note…

I finally got around to fixing Share Classicly so it won’t add its link to the Fediverse view of a post. (Aside from cutting the clutter, boosting would make more sense anyway.) That’s the plugin I made that adds a ShareOpenly link to each post, so your readers can share to a Micropub, Mastodon, Bluesky, etc. account.

Posted on
by

Automattic has announced that they are “realigning” their contributions to WordPress due to fending off “attacks” from the “community” and WP-Engine.

Automatticians who contributed to core will instead focus on for-profit projects within Automattic, such as WordPress.com, Pressable, WPVIP, Jetpack, and WooCommerce. Members of the “community” have said that working on these sorts of things should count as a contribution to WordPress.

In the interest of, as you put it, “secur[ing] the future of WordPress for generations to come,” I trust you’ll be releasing the WordPress trademark, core project management and the infrastructure at WordPress.org, (the latter of which which CEO Matt Mullenweg has repeatedly pointed out that he owns personally) over to the community so you can “focus on for-profit projects within Automattic” without the distraction of the wider WordPress ecosystem.

Either that, or you’ve just told the entire WordPress community — excuse me, “community,” I forgot to include the scare quotes you so meticulously included throughout your article — that we should never trust you to have the community’s interests at heart, only your own.

I suppose this means I should start looking for alternatives to the handful of Automattic-built plugins I’m still using, as it sounds like I shouldn’t anticipate them continuing to be maintained.

Update January 10: It gets worse. Mullenweg just deactivated the accounts of several high-profile people at WordPress-adjacent companies who dared to question his leadership, in a post that goes increasingly off the rails.

Posted on
by

Back in 2002, I set up this blog on b2. A year later, b2 updates had stagnated, I migrated it to a fork of b2 called WordPress.

In the intervening 21 years, WordPress has gone on to power a huge fraction of the web. But in my opinion the project has lost its way, starting with the move to the Gutenberg block editor in 2018 and trying to become everything to everyone instead of just really good blogging software.

In response to the Block Editor merge, another project forked WordPress to create ClassicPress. Initially it was more or less WordPress Minus Gutenberg, but they’ve continued to do their own development as well, from cleaning up old complex code to improving the way media management works. I sorta kept up with it for a while, but finally decided to really evaluate it this month, and it’s actually really good! So I migrated a couple of test blogs, then Katie’s Feral Tomatoes.

Then I started looking at what it would take to migrate this 22-year-old, 3,255-post behemoth of a blog. (And that’s after moving a bunch of posts to other parts of my site, and deleting a bunch of no-longer-useful posts like ‘Migrated from 1.1 to 1.2. Let me know what’s broken.” or “Check out this weird link!” with no commentary (especially when the weird link is long-dead by now anyway).

Continue reading →

Posted on
by

I’ve been meaning to disconnect from Jetpack for a while now. This seems like a good time to do it, and to finally clear out the older Tumblr and WordPress.com blogs I don’t use anymore.

Tumblr and WordPress to Sell Users’ Data to Train AI Tools — 404 Media

It’s the kind of thing that you expect from Google or Facebook, or from any number of start-ups, but there’s been this sense that Automattic should know better — and with Tumblr being login-walled and ad-saturated, and the push to upsell in their WordPress plugins, and now this…it’s looking like they don’t.

I don’t think they’ve hit the “trust thermocline” yet, but selling user data is a pretty clear line.

As for AI access to the Firehose: My previous understanding of the firehose is that it’s basically an aggregation of what you’d see in a bunch of blogs’ public RSS feeds. Which, OK, fine. Analyze your heart out. Display my posts in your RSS reader. Just make sure private posts and comments don’t leak.

But LLM training isn’t the same as analytics, or showing a properly attributed post in a reader. And quietly changing the terms to allow more kinds of re-use on something most people using the service don’t know about? Not cool.

And not making it clear what is and isn’t included for which purposes? That breaks down trust.

Before this, I wasn’t worried about the Firehose. But now I’m not sure I can trust Akismet, never mind Jetpack, and I’m looking for a new spam filter.

Originally posted across several threads through my GoToSocial test site.

Update: Automattic did clarify that self-hosted blogs with Jetpack are not included in the training data. Only company-hosted blogs on Tumblr and WordPress.com. But I still uninstalled Jetpack from this site, just to be sure. Like I said, I’d been meaning to for a while.

Posted on
by

Since I started converting parts of my website to use 11ty as a static site generator, I’ve been able to automatically generate tag and category pages that are *just there* as plain html files. And since they’re plain HTML, the old local site search engine I have on there still finds all the Eleventy-generated pages. And again since it’s all static, it doesn’t go down when the database does (which has been happening on an annoyingly frequent basis lately).

And this would be perfect if I was using a single Eleventy instance to build the entire site, but I’m not. I’ve got separate instances building the Les Misérables blog, the reviews, the tech tips, the creative writing collection, and so on, plus I have this WordPress blog and a bunch of hand-coded HTML from the old days.

Which leads to a few problems:

  1. Tags are per-section, not universal.
  2. The site search, which indexes html files on the server, sees everything except the WordPress posts, and the WordPress search *only* sees the WordPress posts.

Some ideas I’ve had to combine the tag pages:

  • Rebuild everything in a single Eleventy instance with a deeper hierarchy. Upside: Still static pages for everything except WordPress. Downside: Time-consuming, still leaves the main blog separate.
  • Write a post-build script that combines all the the tag pages from each subsite. Upside: Same. Downside: Need to either run on the server or make sure my local copies of the *other* subsites are current.
  • Write a server-side page that combines the backend HTML pages into a dynamic frontend for only the tag being viewed. Upside: simple. Downside: tag pages now depend on PHP. Update: I went with this one (see below)
  • Write some client-side JavaScript for the tag pages that will check whether other subsites have tag pages, and add those to the end of the list in a “See also…” section. Upside: simple, and the “local” tag pages are still usable as long as I make sure the script doesn’t block anything. I could even have it check the other static subsites first and then check the blog, so if the blog times out I still display everything else. Downside: requires JavaScript and additional network requests. But as long as I stick to vanilla JS, I can make it pretty small.

And for unifying the search:

  • Write a post-site-indexing script that adds the WordPress posts to the index. Could be done with direct DB access.
  • Write a pre-site-indexing script that generates a bunch of files for it to index. Seems like overkill.
  • Update the search code to send the same search terms to WordPress and combine the results.
  • Use a new search engine that indexes the served pages instead of the files on the server.
  • Point the search box at a remote search engine like Googl…yeah, never mind.

I haven’t settled on anything. I’m just kind of writing down ideas in public. If you have any suggestions, please let me know!

Update January 2026: I finally got around to actually implementing part of this for tags. I went with the PHP front-end that pulls in all the pre-generated HTML tag pages as sections, plus a custom tag search on the blog that returns the same format. Each website segment’s tag pages now include a link to the collected tag page, so if you click on a tag on a review or a tech article it keeps that context. So far it only includes the 11ty and ClassicPress sections (plus a couple of individual pages). I’m contemplating a back burner project to tag pages in other parts of the site and pull them in too.

Posted on
by

I’m not ready to give up on the flexibility of WordPress for my main blog yet, but holy crap are these pages heavy. Even with compression. There’s no reason it should take 450K (before compression) and 20 requests to display a 500-word post.

And I don’t even do ads, popups, social sharing buttons or anything else like that.

By contrast, my Les Mis blog, where I post about once a year, is currently generated by Eleventy using a custom minimal theme that only takes around 10K of HTML, 3K CSS, and a third request for the icon. And another 40K for the header font, which I recently set up locally so it no longer has to call out to Google Fonts.

One domain, just four requests, and only 50K for the first hit and 10K for each subsequent page.

Never mind the Gemini version of the blog which is around 2-5K per page and a single request per page!

Compression cuts down on those 500Kb WordPress pages — all the text and code compresses really well so only around 200K bandwidth is needed. But it’s still got multiple JavaScript and CSS requests going on.

I was able to cut it down significantly by switching to a lighter theme and turning on the minimize/combine feature in WP-Optimize so it’s making fewer script calls. But it’s still way bigger than the minimalist setup I have with 11ty.

Some of it is images, though. I still have my latest Flickr posts in the sidebar, and I’m using Jetpack’s related posts feature which includes thumbnails. I could cut out a big chunk by removing those, but I kind of still like the idea of having them in there.

I think I need to take a look at how much extra stuff I really want on this site and rip some of it out. Eventually I’d like to replace all the JetPack features because they just seem to keep adding more scripts. Plus I want an entirely local stats package instead of one that’s offloaded to a third party even if they’re less awful than, say, Google or Facebook.

On the other hand, I want to keep Gravatar on the comments sections (on the older posts where people actually commented) because that’s actually useful to readers as an aid for following a conversation better. But that’s all on top of the base page size.

»All pages site-wide with this tag