[wp-trac] [WordPress Trac] #33755: Add Site Logo to WordPress Core

WordPress Trac noreply at wordpress.org
Wed Feb 24 07:52:17 UTC 2016


#33755: Add Site Logo to WordPress Core
-------------------------------------------------+-------------------------
 Reporter:  fatmedia                             |       Owner:
     Type:  feature request                      |      Status:  reopened
 Priority:  normal                               |   Milestone:  4.5
Component:  Customize                            |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  ux-feedback has-patch needs-testing  |     Focuses:  ui
  needs-unit-tests has-screenshots               |
-------------------------------------------------+-------------------------

Comment (by celloexpressions):

 In [attachment:33755.14.diff]:
 - Remove the custom customizer control in favor of the core-provided
 `WP_Customize_Media_Control`. A site logo is not a complicated usage of an
 image control. A logo control is a great example of a use case for the
 standard image control that ships with core. In fact, the UI in the
 patches is essentially the same as the core image control. Core customizer
 controls are a demonstration of how to interact with the customizer API,
 and this complex usage is unreasonable for a theme or plugin to consider
 when evaluating the approach to adding their own controls. Themes and
 plugins should be able to accomplish what the previous patches
 accomplished with a custom control with the existing core-provided
 controls, and core should too. We can't launch this feature with the
 custom control class, then go back and remove it later, because customizer
 controls added to the API become available for general use - themes and
 plugins could start using it and core gets stuck with maintaining it. The
 custom control adds a lot of bloat, most notably in the ever-ballooning
 list of CSS selectors for all of the media control styles, for very little
 benefit (also note the significantly reduced patch size, and that even if
 we were to keep a custom control, the implementation could be simplified
 and better future-proofed without functional changes). Due to the time
 crunch, the patch removes the custom control and associated code. I was
 able to roughly implement the custom things (see items below), but someone
 should review as I don't have time to fully test and debug tonight. We
 can't ship with a custom logo control and go back and change it, though,
 so we'll need to live with slightly different button labels and no
 postMessage if it can't be figured out soon.
 - Don't put the logo control at the top of the site identity section. We
 could claim that it's the most important setting, but being firmly theme-
 specific, putting it there would cause the other options to move around,
 which would be disorienting. Additionally, it makes sense to put global
 options before theme options, since they're probably more important to
 set. This area could use further improvement, but placement at the top
 feels like a mistake, much like the former behavior of custom customizer
 sections defaulting to priority 0 (placement at the top). Let's not let
 this hinder existing site-wide settings, especially not in a first pass.
 - The `button_labels` parameter is supposed to be customizable, but I
 messed that up when I wrote the original `WP_Customize_Media_Control` and
 the new image control patches and I guess we never caught it. I added
 those to the control registration, so that element of the custom control
 is preserved (may not fully be working yet though - could use another set
 of eyes). This change is backwards compatible for subclasses that
 previously set button labels by overriding the whole array in a custom
 class constructor - that still works.
 - I added the custom JS that the custom control was doing to the core
 control - I think it could be generally useful. However, I don't have time
 to closely test this or look at any potential side effects so someone
 should review more carefully. If it's not working we should just remove
 the postMessage support for now and revisit later (it's not worth the
 custom control). Situations where the setting is not an id could be
 problematic (instances of `WP_Customize_Image_Control` store a URL).

 Additional things I think should be changed or considered:
 - the `wp-site-logo` body class seems really excessive. Do we want to get
 locked in to having this? There are a lot of body classes already, and I
 don't think there would be common enough usage to warrant it in core; it
 could be added by a theme if there is a specific need for it.
 - There is still a `@todo` in the patch. The comment above it doesn't make
 sense to me, so not sure what's left to do there, but this should be
 resolved (or clarified) before committing to core.
 - We could probably consolidate the site icon control display to show the
 icon next to the browser preview; that would make it take up less vertical
 space if the logo is below.
 - If this is explicitly a theme feature, adding theme support for
 `site_logo` may not the best terminology.
 - Can we add support to Twenty Fifteen? I think at least two bundled
 themes should support this out of the box, possibly more. Fourteen and
 Fifteen could put it at the top of the sidebar.

 Generally, this feels over-engineered to me. However, I don't have time to
 dig in further, so hopefully cleaning up the customizer parts is enough.
 This absolutely should not be committed with the custom control though, it
 dilutes the core objectives of the customizer API and adds a lot of
 duplicated code that isn't needed. Definitely needs some work tomorrow to
 finish cleaning up; I won't be around to help but can circle back at the
 end of the week.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33755#comment:102>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list