I use thumbsup to generate my galleries. That’s worth a whole other post–the short version is that the metadata is written to the images themselves, and then that metadata generates a series of static html pages for albums, tags, and categories. The resulting site is easy to host–no database and a minimum of CSS and Javascript. I’ve used Cloudfront and S3 on Amazon for several years but as I previously mentioned I’m moving my stuff off Amazon.

GitHub pages isn’t suitable on its own: I have about 13 GB of images. The generated site structure looks like this:

1
2
3
4

album/
media/
public/
index.html

Read More

I’ve used Hexo to build this site for two years. At the time, I kept my existing S3+Cloudfront hosting stack with a few minor tweaks. Yesterday I moved the whole thing over to GitHub pages.

I had a few reasons for doing this. One, I’m doing a project at work to roll out GitHub Campus and I want to get more familiar with the architecture. Two, for various reasons I want to be less dependent on the Amazon environment. I figured moving a static site from one architecture wouldn’t be a big deal, and I was right.

Hexo has a few deployment options. When I was using an S3 bucket I just rsynced the generated output, which won’t work here. The “right way” of handling the deployment would involve pushing source files and letting a GitHub Action build the site. My local environment is a little unclean–I have some uncommitted package dependencies–so that’s not a great option. I can however use the one-command deployment option with hexo-deployer-git. Per Hexo’s documentation, you add this to _config.yml:

Read More

I have an AWS account with a few dozen Cloudformation stacks deployed. Among other resources are some Route 53 hosted zones, and I was pretty sure that I’d created these manually. I wanted to get them imported into a stack, and then make some changes, but first I needed to be sure that they weren’t part of a stack already. There are enough stacks in this account that manual inspection isn’t a good option.

Turns out that a good way to do this is with the AWS CLI, and I’d like to thank Nik Rahmel on Stack Overflow for the pointer. You can use the describe-stack-resources command and pass the PhysicalResourceId of the resource instead of the StackName. Here’s an example of querying a Route 53 hosted zone:

1

aws cloudformation describe-stack-resources --physical-resource-id Z99999999AAAAAAAAAAAA

Read More

As of October 22, 2024, ACF now supports installing ACF and ACF Pro via Composer. This blog post remains up for historical reasons.

On Saturday, October 12, Matt Mullenweg usurped the popular Advanced Custom Fields plugin on the WordPress.org plugin repository and rebranded it as “Secure Custom Fields” while retaining the original plugin. I’ve written at length about why he shouldn’t have done that and the broader consequences of that action.

This post is devoted to a far more prosaic question: how do I, as a person using Composer to bundle a WordPress deployment, install the free version of Advanced Custom Fields?

Read More

Fear, uncertainty, and doubt (FUD) is as old as time. In a nutshell, it’s a disinformation tactic. You put out false information, engendering fear, in the hope that you can manipulate people toward a particular outcome favorable to you. No, I’m not talking about Donald Trump and the 2024 US election. I’m talking about Matt Mullenweg, WordPress.org, and Automattic over the last month.^[1]

My introduction to FUD was in the late 1990s. I was in high school, I was playing around with Linux, and I was a regular poster on Slashdot. This was the high-water point of Microsoft trying to undermine public confidence in open source in general and Linux in particular. This was the period of the “Halloween documents” and SCO v. IBM. Rather than compete on the technical merits, Microsoft sought to create an environment where companies were afraid to adopt open source technologies because of nebulous licensing or patent concerns. The fact that these efforts ultimately failed doesn’t change how much time and money was spent combatting them. The opportunity cost was high.

Which brings me back to WordPress. I wrote yesterday (“The call is coming from inside the house”) about Matt Mullenweg’s seizure of Advanced Custom Fields on the WordPress.org plugins repository. I mentioned in passing that he also banned WP Engine from the repository. Something I didn’t mention is that logging into WordPress.org now requires you to attest that “I am not affiliated with WP Engine in any way, financially or otherwise.”

Read More

I’ve written a few times about challenges with plugins on WordPress.org. Eleven years ago, as a comparative newcomer to WordPress, I wrote “Draining the swamp,” about a difficulty with an abandoned plugin. Later, I wrote “The Changelog Is A Lie” after a user usurped a plugin, hollowed it out, and replaced it with something else. I never thought we’d be in the situation that we are today, where WordPress.org has undermined the trust in the WordPress.org plugin repository. As they first said in Black Christmas, the call is coming from inside the house.

It’s beyond the scope of this post to fully review the dispute between Matt Mullenweg and WP Engine (see this article in The Verge for a good summary as of October 4). The latest development is that Mullenweg has usurped the free version of Advanced Custom Fields on the WordPress.org repository. The official announcement implies that the ACF team abandoned the plugin. This is inaccurate at best: Mullenweg banned the WP Engine developers from the WordPress.org repository, and blocked WP Engine-hosted sites from accessing it. Under the circumstances, switching the updating mechanism away from WordPress.org was the only responsible course of action available.

It’s a neat trick. You ban a developer from the repository, then announce that you’ve found a security issue, don’t let them release a patch for that issue, and then usurp the plugin because they haven’t fixed the issue. A tweet from WordPress claims justification under Guideline 18 of the plugin guidelines. It’s difficult to see how that guideline justifies this action. The developer hasn’t abandoned the plugin. The security issue wasn’t serious, and it’s been fixed. Put another way, if this is justifiable under Guideline 18, then there is no limiting principle.

Read More

On a shelf on a Barrister bookcase in my library, between Leonard Mosley’s The Druid and Marie Vassiltchikov’s Berlin diaries, is the 1941 edition of William L. Shirer’s Berlin Diary. Shirer was an American journalist who spent 1934-1940 reporting from Nazi Germany. Although he subsequently authored several books, his real value is as an eyewitness to what was happening there and his impressions of the people.

His entry for August 9, 1939, records a conversation with a “World War [I] officer of proved patriotism.” Germany’s unprovoked invasion of Poland is three weeks in the future. In March, Germany had abrogated the Munich agreement and occupied Prague, along with the rest of Czechoslovakia. Shirer records the officer asking of him:

Why do the English butt in on Danzig and threaten war over the return of a German city? Why do the Poles [sic] provoke us? Haven’t we the right to a German city like Danzig?

Read More

I’ve been playing around with Cypress for end-to-end testing ever since I heard Paul Gilzow’s talk on the subject (“Introduction to Automated End-to-End Testing”) at the 2024 WPCampus conference. We did a pilot ten years ago to implement some limited E2E testing using Behat but it didn’t get very far. Building your own Behat suite without core support was a heavy lift (our Moodle plugins are a different matter).

We did build out some functional testing for our Microsite, which is a static copy of our WordPress theme, implemented in Twig. I took the opportunity of yet another chromium/selenium issue to reimplement our tests in Cypress, and to add visual regression testing for our components. An added complexity is that the tests need to work cross-platform: in developer local environments and in our continuous integration environment. It’s working, but there were a few challenges.

First, I got started by installing the Cypress Visual Regression package. Unsurprisingly, you’ll need the virtual framebuffer (xvfb) package installed. You’ll also want a consistent headless browser across all systems. Chrome is an easy answer, but I’m sure others would have worked. This is what my CI configuration looked like on a Debian-derived container:

Read More

I maintain a project that still uses PHP 7.4 (long story) so I need to build out my local environment with that version. Sourcing a Nix package for PHP 7.4 isn’t an issue; the nix-phps repository maintains PHP 5.6-PHP 8.4. The tricky part was adding that package to my local devenv.sh environment. Devenv supports PHP, but by default the PHP versions are limited to what’s in the devenv-nixpkgs repository, which starts at PHP 8.0.

I went down a few blind alleys, followed some outdated documentation, and generally overthought this. Devenv has awareness of older PHP versions; they’re simply not enabled by default. The first thing you need to do is enable the nix-phps repository. You can do that with this command:

1

devenv inputs add phps github:fossar/nix-phps --follows nixpkgs

Read More

I have a Moodle development project coming up and this is a good a time as any to experiment with setting up a Moodle environment in devenv.sh. One immediate issue is that Moodle depends on background tasks running almost constantly. Devenv has a set of supported services and cron isn’t one of them. Devenv does support the concept of processes, which are just background tasks. Can I apply that Techmint article on How to Schedule a Linux Job Without Cron?

Sure can:

1
2
3

processes.cron.exec = "while true; do php public/admin/cli/cron.php ; sleep 60 ; done";

Read More