ClassicPress 1.1.0-rc1 Release Notes

This is no longer the latest release of ClassicPress!
You can find the latest release at the top of the Release Notes subforum.

We’re happy to announce the first release candidate for ClassicPress 1.1.0. This release contains two new features that we think the community will be happy with, as well as several months’ worth of smaller bugfixes. We’re happy with these changes but they need more testing by the community before a full release including automatic updates.

We encourage you to try out this release candidate by pasting the zipfile URL into the “Advanced” section of the migration plugin, and let us know if you see any issues. See instructions and links below, under the “Download this releaseExisting ClassicPress sites” section.

New features since 1.0.2

Add an option to show the site’s custom logo on the login page instead of the ClassicPress logo. This is disabled by default, but it is a common way for sites to customize their own public-facing branding, and now changing this image doesn’t require any plugins. (details)

Add a new top-level Security page to the admin screen. This is a centralized place for plugins to register their security-related settings, to make them easier to find and audit. (details, documentation)

Minor changes and fixes since 1.0.2

  • Update the list of files to remove during installation. This ensures that no extra files are left over after migration from WordPress. (details)
  • Update the jQuery version string after the security patch applied in ClassicPress 1.0.2. (details)
  • Add ClassicPress changelog links to the dashboard’s About page. (details)
  • Fix potentially overlapping notices in the Themes section of the dashboard. (details)
  • Fix potential upload failures of common text file types. (details)
  • Fix an issue with published post dates when using the XML-RPC API, for example with external editors. (details)
  • Fix a PHP notice in the dashboard petitions widget. (details)
  • Fix a “Source map” browser warning related to a TinyMCE file. (details)
  • Remove unnecessary role="navigation" attribute from pagination elements. This is an improvement to HTML5 validation. (details)
  • Remove angle brackets from link in password reset email. This caused problems with some email clients. (details)
  • Update links to support/documentation pages in wp-config-sample.php. (details)
  • Include latest emoji code from WP. It will be possible to disable this feature in ClassicPress v2, but for now we’ve needed to keep it up to date to keep our builds passing. (details)

Development improvements and fixes since 1.0.2

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 “Advanced” section of the migration plugin to switch to the release build (same link as for “New sites” above). This version will be available using the built-in update mechanism when it is released as 1.1.0 final.

Full changelog

The full changelog is available on GitHub.


Successfully updated 2 sites, didn’t see any bugs.

Except Simple History’s notices:

" Found an update to WordPress. Available version* _custom_migration Installed version 4.9.11
“Updated WordPress to 4.9.11 from 4.9.11”


I’ve just done one site using the migration plugin and I now have this message:

Should I click it? It says I already have the new version?


Thanks for testing, both of you :slight_smile:

The _custom_migration thing is a quirk of the advanced mode of the migration plugin, not an issue with the new version. I’ve just reported it on GitHub:

If you go to “Dashboard > Updates” and click “Check Again”, then this should clear itself.

And this is because the “Simple History” plugin hasn’t been updated to know about ClassicPress yet.


A post was split to a new topic: Security Page Translation into Russian

Thanks James, clicking the update check button clears that message.

Edit: forget all this. I’m an idiot. I thought it was using the site icon on the login page. It is supposed to be the site logo.

1 Like

I’m not finding the logo idea works for me. For those sites where I actually have a logo, I’m getting this sort of effect:

I assume the image is being restricted to a small size?

1 Like

Me too, but maybe this is the problem of our logos.

An option to adjust logo size, or, better, a separate plugin, which manages logo appearance can solve this.

It seems to work best with a square logo. That’s why I had initially assumed it would be showing the icon which is typically something like 512x512.

1 Like

It’s really weird to see your prose in a language you don’t understand :wink: Very cool, but also weird :slight_smile:


Should this feature not be added to the Customizer >> Site Identity Panel for better customization?

Granular controls could then be added to further customize the logo i.e. size, margins, padding and so on.


I don’t think it’s necessary to be that complicated. At the moment it displays it as a 100x100 block. If the css is changed to be:

max-width: 320px; height: auto;

then it works much better for me…


I think this would be a good future improvement to consider…

though changing the CSS is also fine for the initial version (i.e. 1.1.0).

By the way, we’re planning to do the final 1.1.0 release on Tuesday, September 24.


Yes, I realise it’s a little late in the day to be making big changes. Sorry!

As I mentioned above, I’d always assumed this would be showing the site icon, not the logo. I have logos on less than half my sites, so it will only work sporadically for me. I’m wondering if it could be set up as: if logo use that, else if site icon use that.

Maybe something to think about in future releases.

1 Like

This would also be a good thing to keep in mind for a future version.

For now, I think it would be a good idea to add a filter called login_image_html that allows making this and other customizations. We can do this in 1.1.0, I’ve pushed up the code changes here:

1 Like

That’s a good idea. I’ve now put this onto about 8 sites and no problems that I can see.


Some atypical experience with custom logo)

I had no add_theme_support for this feature in one of my custom themes so it took some time to understand what’s going on. Maybe we should document this somewhere.

And I also realized that we have a small logical issue there. @zulfgani already mentioned that. If we keep this option in Settings -> General we probably shouldn’t rely on current theme settings and avoid this dependency. Otherwise, as we implement this via Customizer settings and theme mods API, we should probably move the “on/off” option to the Customizer, too.

Now it’s a bit messy. When the active theme doesn’t support custom_logo feature, logo field is not shown in Customizer. But the global switcher is still available. And it seems that user should set the logo image via site icon field. (It’s not obvious that another field exists). It sounds stupid, but I’ve done that personally. Twice :rofl:

Also. While debugging I referenced to functions.php of native Twenty* themes:

// Add theme support for Custom Logo.
		'width'      => 250,
		'height'     => 250,
		'flex-width' => true,

We can actually use these values, no need to limit size via CSS then. And we can override them via Customizer, too.

And globally we should carefully decide which API is responsible for the login page styling: theme mods or global admin controls, or some separate functionality. And try to keep everything close to this single responsibility.

P.S. Don’t mean to change anything in 1.1.0.


No! The Customizer is the next worst thing in WP, just after Gutenberg. If I remember correctly, we had a discussion on this forum some time ago.

1 Like

We’ve inherited the Customizer and it is now part and parcel of ClassicPress - being one of the worst WP inventions should not deter us from improving it just as we are doing with the Core itself. Under utilizing the customizer will not improve it or make it go away!


It can’t be improved, because of a bad Customizer idea. Even there was an idea to separate Customizer to the Core Plugin.

So, the adding anything to the Customizer sounds like a bad idea to me. Better to have a menu in the Settings menu, which may be duplicated to the Cusmomizer (options, not decisions).