[wp-trac] [WordPress Trac] #60922: get_custom_logo returns an empty link when no logo image is set

[WordPress Trac]

#60922: get_custom_logo returns an empty link when no logo image is set
-------------------------------------------------+-------------------------
 Reporter:  afercia                              |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  6.6
Component:  Themes                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback needs-        |     Focuses:
  testing commit                                 |  accessibility
-------------------------------------------------+-------------------------

Comment (by SergeyBiryukov):

 Replying to [comment:4 afercia]:
 > After some debugging, turns out the root problem is that
 `get_custom_logo()` first retrives the logo ID by retrieving
 `get_theme_mod( 'custom_logo' )`. That option is set when setting a site
 logo but it's not cleared when the image is deleted from the Media Library
 (or deleted from the file system).

 After some more debugging in a coding session with @afercia, it looks like
 there is a difference between  how Site Logo is handled for classic themes
 and block themes:
 * For classic themes, when deleting an image previously set as the site
 logo, the `custom_logo` theme mod is properly cleared by the
 `_delete_attachment_theme_mod()` function, hooked to `delete_attachment`.
 * For block themes, it's a bit more complicated: the Site Logo block uses
 a different data source, a `site_logo` option instead of a theme mod (see
 [https://github.com/WordPress/gutenberg/issues/32065 GB #32065]), and
 contains some code to sync between the two. The option is supposed to be
 cleared by `_delete_site_logo_on_remove_custom_logo()` when the theme mod
 is removed, but that does not happen when deleting the attachment. It
 [source:tags/6.5/src/wp-includes/theme.php?marks=3446#L3439 this
 conditional] is adjusted to also take the `site_logo` option into account,
 then the option can be properly cleared too.

 To summarize, while the existing PR essentially fixes the symptom, it
 might still be good to go, as it does make `get_custom_logo()` and
 `has_custom_logo()` more future-proof.

 Ideally, the root cause should also be fixed by clearing the `site_logo`
 option when the related attachment is deleted.

 It can also be up for a future discussion whether or not it's a good idea
 to store the site logo globally, not depending on the theme, as themes
 might have different requirements for the logo size, and the image
 cropping step is no longer a part of the process. This appears to be a
 relatively recent change from the previous behavior, see
 [https://github.com/WordPress/gutenberg/issues/32065 GB #32065].

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