Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

I just completed a major update to my website. Two things at once. I’ve moved my site from blog.andrewshell.org to andrewshell.org (dropping the subdomain) and migrated it from 11ty to WordPress.

I put a lot of effort into setting up redirects, so everything should keep working (I hate broken links). If you find I missed something, please contact me.

I have a few reasons for doing this:

First, I’m very excited about adding ActivityPub support (you can follow @andrew@andrewshell.org on Mastodon), so anything I post will hopefully show up in AP easily.

Second, I manage several WordPress sites for friends and realized I was getting rusty on my day-to-day WordPress skills.

The theme I created is still a “classic theme,” which isn’t what I initially planned, but good enough for now. I do a lot of microformats/indieweb stuff, and I’m not sure how much control I have over this with the block editor.

So for now, everything looks like it’s in a good place while I figure out what I want to keep or change. I’m happy to be back in the WordPress ecosystem.

One of the reasons I migrated my site to WordPress was all of Dave Winer's evangelism. One of the things Dave has done is an external editor for WordPress called WordLand. I had tested it out briefly with a test site on WordPress.com, but now that my main site is on WordPress, I'll see how it works. This post, was written with WordLand. I wasn't sure if it worked with self-hosted apps, but I guess because my site is linked up with WordPress.com via Jetpack, it just works.

I’ve been out of the WordPress plugin game for a while now. I closed my Nofollow Links plugin back in 2021 and haven’t kept up since then.

However, now I’m running WordPress again and looking to get back up to speed.

Since I built and maintain the RssCloud Server and wanted to make sure my blog supports RssCloud, I installed the RSS Cloud plugin, which seems to work, despite not having been updated since December, 2022.

I decided to put a copy of the plugin on GitHub so I can work on it and share it with the plugin maintainer. Boy, plugin development has changed a lot since 2021.

It took a lot of effort to pull together a coherent view of all the new tooling, so I wanted to jot it all down here, not only for myself, but also for anyone else interested in plugin development. Once I have my head wrapped around it, I’ll start trying to see if I can contribute changes to the official documentation to bring it up to date.

Plugin Integration Tests and WP-CLI Scaffolding

I started reading the Plugin Integration Tests documentation in the WP-CLI Handbook. Despite saying it was updated on July 1, 2025, it has signs of being out of date. For instance, it talks about Travis CI, but the default CI included by wp scaffold plugin-tests my-plugin is CircleCI. Travis CI no longer seems to be available.

This page also directs you to look at sample-plugin, which hasn’t been updated in 9 years and isn’t what WP-CLI generates. Those files are defined in scaffold-command/templates.

Since I’ll be hosting this plugin on GitHub, I needed to run wp scaffold plugin-tests rsscloud --ci=github to generate the correct files for GitHub Actions.

Testing With Different Versions

Initially, I was going to configure Docker so I could run the plugin in different versions of WordPress and PHP. I already have WordPress Studio to run a local copy of WordPress on my Mac mini, but I discovered that for development it’s easier to use wp-env, which is a command-line tool that spins up Docker environments.

I was struggling to figure out how to use wp-env with the flow from the previous documentation. I couldn’t run any of the scripts locally (needs Apache and MySQL installed locally), and running wp-env cli phpunit wasn’t working either.

What connected the dots for me was looking at the source for the Gutenberg plugin.

Now, Gutenberg is a massively complex plugin, and its tooling seems overkill for the RSS Cloud plugin. But I was able to start pulling pieces over. In particular, I needed to set up package.json and composer.json files with appropriate scripts. I won’t replicate them all here, but this is a taste of what needed to be added:

"scripts": {
    "test:unit:php:setup": "wp-env --config .wp-env.test.json start",
    "test:unit:php:base": "wp-env --config .wp-env.test.json run --env-cwd='wp-content/plugins/rsscloud' wordpress vendor/bin/phpunit -c phpunit.xml.dist --verbose",
    "test:unit:php": "npm-run-all test:unit:php:setup test:unit:php:base"
}

As you can see, they use wp-env along with a custom .wp-env-test.json file, and it specifies the --env-cwd to point at the plugin directory.

Now, in my terminal, I can just call npm run test:unit:php and have it work properly in the test environment.

I also found I can update .wp-env.test.json to specify the specific version of WordPress and PHP I want to use. This will make it very easy to run tests in various environments.

Missing Subversion

After getting this all working locally, I created a few simple tests and created a pull request on my repo. This should trigger the GitHub Action workflow to run the unit tests in three different PHP versions (7.4, 8.0, and 8.2), which seemed reasonable.

First, the tests failed because the setup script (from the scaffolding) required Subversion to be installed. This should have been included in the .github/workflows/testing.yml file, but it wasn’t. I just had to add an additional step, “Install SVN” and everything worked.

Final Touches

I’m now mostly experimenting with this setup. I’ve added new scripts to generate test coverage reports so I can look for cases that I still need to write tests for. The existing plugin doesn’t seem to have any existing unit tests, so I’m starting from scratch.

I also have linting configured so I can make sure the code follows WordPress Coding Standards.