Twenty Twenty background image setting

[afercia]

Not sure if this was already discussed and considered. Thought to report it anyways as the current behavior doesn't seem ideal to me.

Twenty Twenty declares support for custom background.

However, it handles only custom colors and doesn't provide a UI in the Customizer to handle background images.

This leads to an inconsistency in the WordPress admin UI: in the admin menu, a "Background" link is displayed:

Clicking this link opens the Customizer but it doesn't do anything else. The customizer opens and displays its main panel in the sidebar.

Instead, the expected behavior is that it opens the Customizer and then it switches the left panel to the "Background" one. You can check what the expected behavior is by using another bundled theme that supports a background image, e.g. Twenty Sixteen:

• click on the "Background" link in the admin menu
• the Customizer opens
• after a brief delay, the "Background" panel appears sliding in from the right

Instead, with Twenty Twenty active, the Background link doesn't do what users would expect. It just opens the Customizer and... well where's the background setting?

Moreover:
it's still possible to access the legacy background page at wp-admin/themes.php?page=custom-background if users know the URL or if they bookmarked it. In this page I can set a background image for Twenty Twenty :)

After that, the Customizer displays the background image:

But then again, the Customizer doesn't provide any UI to manage the background image.

[kebbet]

I noticed the same thing, and created a ticket for it in the Github repo, where the theme is developed.
​https://github.com/WordPress/twentytwenty/issues/858

And a Core issue for the underlaying problem.. #48330

[afercia]

@kebbet thanks! Yup I now see it's intentional in Twenty Twenty:

https://core.trac.wordpress.org/browser/trunk/src/wp-content/themes/twentytwenty/classes/class-twentytwenty-customize.php?rev=46551&marks=29-33#L28

$wp_customize->remove_section( 'background_image' );

However, this leads to a user experience that's not ideal, IMHO.

Also, at this point of the release (we're in Release Candidate) development should really happen on Trac / SVN and not on GitHub as any change must be reviewed and "signed off" by two core committers.

[mukesh27]

Patch that enable custom background support.

[ocean90]

Closing as reported upstream.

Development still happens on GitHub. If there's something to import we'll reopen #48110 again to review and sign-off any patches.

[afercia]

For future releases I'd propose to discuss when a bundled theme development should be moved to Trac / SVN. To me, from the moment a bundled theme gets merged in core, development should happen in core.

Also: @ocean90 if you're closing tickets because "reported upstream" it would be greatly appreciated if you could add the details reported here to the "upstream" issue.

[desrosj]

#48330 was marked as a duplicate.

[poena]

The removal of the setting was reverted in the theme itself.

That the background image and background color are set together in the same theme support is still an issue.

[afercia]

@poena thanks for the update! Shall we close this ticket then and create a new one to explore splitting custom background support in two separate pieces as mentioned in ​https://github.com/WordPress/twentytwenty/issues/858#issuecomment-543568847 ?

[poena]

There is a new ticket here: https://core.trac.wordpress.org/ticket/48241

[afercia]

Cool, thanks! Closing as fixed "upstream" (whatever that means, as this is in core).