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

WordPress Trac noreply at wordpress.org
Sun Feb 21 05:31:41 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):

 While I'm not personally convinced (yet) that this feature will be used
 enough to warrant core inclusion, I don't get the impression that any
 numerical data or other outreach efforts will be conducted prior to making
 a decision. For some reason, several people really want to see this happen
 ASAP. Fine, but we need to make sure we're all on the same page.

 '''My biggest concern is the definition of this feature as a "theme"
 feature.''' There are multiple comments over the past week suggesting that
 this is a theme-specific feature. @michaelarestad and @melchoyce
 constructed a strong argument for logos as a theme feature in comment:38
 and comment:39, @johnjamesjacoby specifically mentioned "theme
 modification" in comment:85. However, in the patches, the setting is
 explicitly an `option`. This means that the same logo will be used when
 you use a different theme. It is not theme-specific, it is global.
 However, the UI is only shown when a theme explicitly adds support via
 `add_theme_support()`. This is somewhat different from what has been
 discussed on the ticket, but may still be okay with everyone and could be
 described as a theme feature in many ways.

 I'm worried, though, about the suggestions to possibly turn logo support
 on automatically regardless of theme so that it can be used on the login
 screen or elsewhere (#35807). As soon as that possibility comes up, we're
 no longer talking about adding a feature that themes can turn on, we're
 talking about a new option for all sites, and one that's likely to detract
 from the proper use of options from site title and tagline to site icon,
 which are critical to a site's identity well beyond the front-end/the site
 itself. We need to consider "decisions, not options," and whether this is
 an option that will be used enough to warrant the potential consequences.
 Personally, I think this will overlap with site icon for many users. In
 terms of user testing, I would want to see a couple of tests that attempt
 to determine whether this reduces proper usage of site icon and the title
 and tagline fields; usertesting.com tests probably aren't the best way to
 gauge this. And the logo should definitely be the last control in the site
 identity section - title, tagline, and icon are ultimately more important
 to the identity of a site because they affect its representation
 externally, whereas the logo is identity that is shown only within the
 site itself. The placement at the bottom also makes the most sense for a
 feature that is only available with certain themes, otherwise the
 placement of the other fields moves around.

 If nothing else, this feature warrants a make/core post for broader
 feedback before a final decision is made.

 I have a few additional technical comments (specifically relating to the
 use of a custom customizer control), but I'd like the dust to settle a bit
 first so that they don't get lost behind 20 comments in a day here. The
 patch definitely isn't committable just yet, so there's work to be done
 and I do think that the feature will be better-implemented with more time,
 even if that means introducing it after the first beta if there's some
 reason I'm missing that this absolutely has to make it into 4.5. This
 isn't a code quality issue as much as it's about making sure that the
 feature is implemented in the best approach for core and taking care of
 some detail items. It's going to be much more effort to go back and adjust
 after it's committed than to get it better the first time.

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


More information about the wp-trac mailing list