Background

In September I had no intention of creating v5.4 at all; v6.0 was nearly ready for public Beta testing and I was 100% focused on that.

Then in October and seemingly out of nowhere, the WP vs. WPE drama started. For a while it looked like anything with "WP" in the name was at risk, so I paused work on v6.0 and started building v5.4 - just in case.

Although it turned out that an emergency release wasn't needed, the WordPress environment is now fundamentally and permanently different.

The changes in v5.4 directly address the new reality.

Canonical Version on GitHub

From the very first release WPf2b has been in the WordPress.org plugin directory. It hasn't been without its problems - hence moving support away - but on balance it's been more good than bad.

However, WPf2b is a security plugin; I cannot ignore the attack on ACF.

Thus, as of v5.4, the canonical version of WPf2b will be the GitHub release repository. The release archives will be mirrored here.

LTS on WordPress.org

I am not pulling WPf2b from the plugin directory, nor do I have any plans to do so. There are many WPf2b users who are stuck using the WordPress.org plugin repository and it would be irresponsible to abandon them. Equally, it would be foolish to pretend nothing has changed.

Therefore, the "flavour" of WPf2b on the WordPress.org plugin directory will now be for Long-Term Support.

Flavour

I've borrowed the term from FreeBSD. Basically, it's version X of program Y with or without various features.

The flavour of WPf2b in the WordPress.org plugin directory must comply with the directory guidelines, and not all features in the canonical version do.

Those features will be removed from the WordPress.org flavour.

Long-Term Support

There are no hard-and-fast rules around LTS, but roughly it means the LTS flavour will:

• primarily receive bug fixes; features will be added only if they are necessary to support new versions of WordPress
• target PHP 7.4; it's going to be around for many more years
• be at least one major version behind Canonical

Support

The farther LTS falls behind Canonical the more difficult support becomes, so there will be an upgrade cycle. I don't know what that will look like yet, but I wouldn't be surprised if v5.4-LTS were supported through 2025.

There will be times when the only sensible answer is "switch to Canonical"; it would be easy to make this the default position, but as far as possible I want to allow users to switch in their own time.

Being able to say "switch to Canonical" is yet another benefit of moving support way from the WordPress.org forums.

Other Benefits

Support for composer

The Premium version has had support for composer via Freemius for some time, and the Free version is available via WordPress Packagist.

Unfortunately, WordPress Packagist is just a direct mirror of the WordPress.org plugin directory, which means it also mirrored the ACF attack.

Thus, v5.4 will be available directly from packagist.

If you simply must use composer right now, the GitHub release repository already contains all the previous releases; however, there is no composer installer support yet, so you'll have put things where you want them.

Self-Updater and Support for GitHub Updater

The built-in updater will seamlessly keep WPf2b up-to-date directly from GitHub, just as if it were updating from WordPress.org.

If GitHub Updater is installed it will take precedence, as will composer.

Signed Releases

Last but very much not least, both the release tag and the release archives are signed. It is now possible to check that the WPf2b you're about to install is the WPf2b you should be installing.

Today you have to do the checks by hand (How To post will follow), but soon I expect this to be fully automated. Further, because the release tag is signed, security plugins will be able to validate existing Canonical WPf2b installs.

This is a very, very significant improvement in security, and one that is currently impossible on the WordPress.org plugin directory.