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…
3 Likes
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.
5 Likes
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: Add new 'login_image_html' filter by nylen · Pull Request #497 · ClassicPress/ClassicPress · GitHub
1 Like
That’s a good idea. I’ve now put this onto about 8 sites and no problems that I can see.
3 Likes
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 
Also. While debugging I referenced to functions.php of native Twenty* themes:
// Add theme support for Custom Logo.
add_theme_support(
'custom-logo',
array(
'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.
2 Likes
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!
3 Likes
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).
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.
3 Likes
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.
6 Likes
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.
3 Likes
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.
2 Likes
This is here: Issues · ClassicPress/ClassicPress · GitHub
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.
2 Likes
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’. 
2 Likes
I’m also in favor of delaying till 1.2.0
3 Likes
+1, I like this option.
2 Likes