ClassicPress 1.1.0-rc1 Release Notes

Customizer integration is very deep. I don’t think it’s possible to separate it from the core without ruining legacy and general architecture. We can’t remove it. (To my opinion). And since we have to support Customizer anyway, we have to consider related content structure and UX. If we try to ignore this functionality, we’ll have to run two parallel systems of theme customization. Duplication is very expensive (it multiplies all development costs: time, complexity, support, documentation, testing). And it is quite unsafe on a long distance, because it brings chaos which will progressively increase each time we add a new feature.

Yes, I agree that Customizer is hell-alike. It’s slow, it has poor usability and it’s absolutely senseless when you build projects with only 1 exclusive theme per site. But it’s a kinda build-in standard, so I think we have to use its api just in order to stay consistent.


I already mentioned this on the PR, long ago. The logo is a core option, but implemented on the front end by the theme. The theme only does front end stuff, and has nothing to do with the login page. Styling the login page should be done in core or a plugin.
The site icon is handled by core only, because it is out of scope for a theme.


When I’m using the GeneratePress theme, I find it excellent for changing layouts and heading and font sizes for each device. Being able to see it in real time is invaluable.

I used it today to figure out whether to use a featured image or an inline one for posts in single and archive views when using Elementor. I was getting both in some instances and couldn’t figure out which one was the culprit.

1 Like

Yes, there are several years now that it has been required for themes in the WP repository to only use the Customizer for options, because it was too difficult to review them with every theme doing things a different way.

1 Like

First of all, this cut was a bit incorrect, as it breaks the context and changes the original sense:

It’s slow, it has poor usability and it’s absolutely senseless when you build projects with only 1 exclusive theme per site.

I understand that there are different ways of using anything and different particular cases with different priorities. But I also understand some technical disadvantages of Customizer and replied to Linas, knowing he shares that point of view and, if I remeber it right, uses WP in a similar way (builds custom solutions for clients). I’m not saying that my opinion is universal.

Second is that if you are pleased with Customizer features this doesn’t mean that Customizer is perfect. There are plenty of ways to implement the same functionality (including real-time customization, wysiwyg etc.). And many of them could give better speed and usability.

Example: if you look through the Customizer code files, you’ll find that the markup of theme boxes duplicates three times there (first one is default PHP markup and others are JavaScript templates for “real-time”). This makes tons of mess. E.g. you have to edit 4 php files just to update a simple notice string and copypaste a block of markup several times. (And do it attentively, because those pieces are not consistent and each one slightly differs from the others). Customizer is full of antipatterns. And it’s rather hard to rewrite it due to the legacy reasons.

So, yes, I think Customizer is hell-alike) However, this doesn’t mean I hate or disrespect it. Just admitting a fact to deal with it properly.


Alright, so I don’t think we can release the login image change as-is. This should not be linked to add_theme_support in any way, which means that we can’t use the “custom logo” image since it may not be possible to set it for some sites.

As @joyously says, this was mentioned during development, but we didn’t follow up on it properly:

(We did address the issues with backwards compatibility (at least, to my satisfaction) by making the new option disabled by default and making sure the default behavior is the same as before. And for multisite, there were no changes needed in order to make this work correctly.)

Using the site icon doesn’t really make sense here either, because the site icon has to be square, but there should be no such requirement for the login image. The site icon also serves a different purpose (the favicon for the whole site) and there is no reason this should have to be the same as the login image.

So I think we need to add a new field to select an image just for this purpose, and while we are at it we might as well add a way to customize the size of the image. This shouldn’t live in the Customizer because displaying the login page is not the theme’s job. I think Settings > General is still the right place for this, but it’s debatable because this section is going to grow somewhat after these changes.

We should still release 1.1.0 soon, but obviously this isn’t going to get done in time. So I think the best thing to do is to back out the login image changes, release 1.1.0 with the rest (security screen and accumulated bugfixes) and try the login image again with 1.2.0.


This is here:

Feel free to leave your vote and/or comments there, but fair warning, I think this would be exceptionally difficult due to the reasons mentioned above.


I’d leave it to the plugins, which do it better and can be switched out for a different one, rather than have it hard-coded into core. Why add bulk to core for something that few users want?

1 Like

I don’t disagree with delaying until 1.2.0.

I do disagree with @joyously, this is one of the most upvoted petitions and it fits really well with CP being ‘business-focused’. :slightly_smiling_face:


I’m also in favor of delaying till 1.2.0


+1, I like this option.


I agree it should be left out of 1.1.0 but just to be contrary, I do agree with @joyously in that I’d also be content to leave it to a core plugin.