ClassicPress 1.2.0 Release Notes

We’re happy to announce the release of ClassicPress 1.2.0. Here are the highlights from this release:

  • Full support for PHP 7.4 in all known core code
  • Our first new feature that started as an organic idea from our own community
  • and a lot of smaller bugfixes and polishing.

If your ClassicPress site has automatic updates enabled (the default configuration), then the new version will be installed automatically. Otherwise, you can upgrade your site(s) to 1.2.0 as you have time.

New features since 1.1.4

A new setting to allow specifying a custom image on the login screen, based on a community petition. This is our second try at implementing this feature. More details including screenshots are available on the main GitHub PR (#601), and see also PR #618 for a small update that was made during testing of our release candidate version. Thanks to @omukiguy for helping to code this feature.

Full support for PHP 7.4 at least when running ClassicPress itself. Plugins and themes may still need updating for full PHP 7.4 compatibility with no notices or warnings, and there may still be some cases where ClassicPress can work together better with plugins or themes in order to ensure compatibility. Here is one example of non-standard theme code causing a notice that will be fixed in a future ClassicPress release. Thanks to @MattyRob for helping to backport some of these changes (see #541 and #603).

Minor changes and fixes since 1.1.4

  • Update wording that links to privacy policy (#615)
  • Fix a backward compatibility issue with the new set_screen_option_{$option} filter (#589, thanks @MattyRob and WP contributors)
  • Fix PHP notice and unexpected behavior when editing a post with an invalid author (#572, thanks @MattyRob)
  • Prevent update notices from the default Twenty Fifteen, Sixteen, Seventeen themes for new sites (#559, thanks @1stepforward for reviewing)
  • Improve compatibility with more MySQL server configurations (#558)
  • Guard against duplicate MIME-Version header in outgoing emails (#528, thanks @MattyRob and WP contributors)
  • Fix the return value of the classicpress_version_short() function for some build types (#511)
  • Fix the admin bar logo position with the Twenty Twenty theme (#533)
  • Use robots meta tag to better discourage search engines (#535, thanks @MattyRob and WP contributors)
  • Remove angle brackets from password reset URL in email to avoid broken links (#536, thanks @MattyRob and WP contributors)
  • Add rel="noopener noreferrer" to plugins screen links (#532, thanks @omukiguy)
  • Improve readability of the About page in the dashboard (#512, #513, thanks @williampatton and @omukiguy for reviewing)
  • Add unique classes to the user profile editing page <h2> tags to facilitate styling (#448, thanks @Code_Potent)

Development improvements and fixes since 1.1.4

  • Decrease the number of npm dependencies required to build ClassicPress by about 40% (#606, #607, #608). There is still more to do but these changes have already made the process of preparing builds and releases much faster!
  • Improve PHPUnit testing documentation (#563, #566, thanks @omukiguy for reviewing)
  • Prepare the translation extraction script for our new translation system (#547)
  • Keep all build dependencies up to date (multiple PRs, thanks renovate-bot)
  • Several changes and fixes to the script we use to backport changes from WordPress (#540, #548, #549, #554, #585, #620)

Download this release

New sites Download (9.9 MB)
and follow the installation instructions.
Existing WordPress sites Download the migration plugin and follow the migration instructions.
Existing ClassicPress sites Use the built-in update mechanism (more info).

Full changelog

The full changelog is available on GitHub.


I beat the auto-update for once! :slight_smile: My sites are now running 1.2.0. No issues to report. This is something I really love about ClassicPress: the confidence that an update is just going to be an update…and not a headache. It gives me the confidence to just go ahead and apply the updates early rather than putting them off until I have a big block of time “just in case”. BTW, the update seemed to go remarkably fast. Really great work!


I can’t take credit for this part :wink:

But thank you! Using semantic versioning seems like a very obvious win to me… of course, when combined with careful development and testing.


I’m part way through updating all my CP installs.

Most are going fine and when they complete everything is of course OK as I would expect.

However I’ve noticed 2 issues with some of the updates:

  1. Sometimes when it’s trying to download the new zip, I get:

Download failed.: cURL error 28: Connection timed out after 10000 milliseconds

However I think that’s just the interwebs from my corner of the world.

  1. The interesting one is that sometimes the install succeeds but, just before it redirects to the welcome screen, I get this:

An unexpected error occurred. Something may be wrong with or this server’s configuration. If you continue to have problems, please report this issue in our support forum. (ClassicPress could not establish a secure connection to Please contact your server administrator.) in /Users/USERNAME/Sites/DOMAIN/wp-includes/update.php on line 160

As I say, the install still succeeds. But I’m curious: why does it need to try and phone home at this point, when the zip is from Github and it’s already done the update?


If I remember correctly, ClassicPress (and WordPress) will try to check for an update again immediately after applying an update, which may be helpful in some situations (for example, if there are multiple new versions available and the user manually installs a newer version but not the latest).

Same issue with the “ClassicPress could not establish a secure connection to” error, I think.


Ah yes, that would make sense, thanks.