Tag: WordPress

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.

Posted on
by

Wow. Automattic bought Tumblr from Verizon for less than $3 million. Considering Yahoo bought it for $1.1 billion back in the day…

Yahoo really squandered it. And Verizon, I think, just wanted to get rid of it.

At least it’s going to an actual social media company not to another conglomerate. And one that’s more responsible than the big two! I was half expecting Verizon to try to monetize it into the ground and close it once everyone but the die-hard users had given up on it. But they found a blogging company for Tumblr, just like they found a photography company for Flickr. That’s encouraging. And Matt Mullenweg (who turns out to be a long-term Tumblr user as well!) understands that Tumblr and WordPress are different types of experiences, so they’re unlikely to try to merge them into a single service.

Though apparently they’d like to move the back-end to WordPress, while keeping the front-end experience of the Tumblr site and apps. I can sort of see the appeal: they’ve got over a decade of experience making WordPress scale, and they have to migrate Tumblr off of Verizon’s servers anyway. If they can run Tumblr on top of the WordPress infrastructure, it’s just a matter of adding capacity.

But it kind of runs the risk of creating a frankenblog. I guess it depends on how seamless the conversion is. If Tumblr looks and works the same from the user-facing perspective, it shouldn’t drive anyone away. If they try to turn it into a subset of WordPress.com…I’d expect another exodus.

Speaking of which, I doubt they’ll get anyone returning who left directly due to the adult content ban. Especially since they don’t plan on reversing it. But they might get back at least some people who left because they saw the ban as a sign of a dying platform. And they might be able to bring in new users, who knows? Having corporate overlords who actually understand and appreciate the space could be a big help.

Though frankly, even if all they do is keep it running in maintenance mode for those who are still there, that’s still better it would have been staying at Verizon!

As for me, I haven’t been active on Tumblr for a while. I took a final archive after cleaning up a bunch of old stuff, imported some posts here, and I’ve checked in to read maybe…once a month? I’m still in wait-and-see mode. We’ll see how the data migration goes, what they end up doing with the terms of service, whether they change the way ads and promoted posts appear.

But I am more confident that Tumblr will still exist next year than I was a few months ago!

»All pages site-wide with this tag