Make WordPress Core

Opened 6 weeks ago

Closed 4 weeks ago

Last modified 4 weeks ago

#65538 closed enhancement (fixed)

Block Supports: Guard test for element hover styles with a missing hover selector

Reported by: aaronrobertshaw Owned by: ramonopoly
Priority: normal Milestone: 7.1
Component: Editor Version: trunk
Severity: normal Keywords: gutenberg-merge
Cc: Focuses:

Description (last modified by aaronrobertshaw)

This is a backport of Gutenberg PR https://github.com/WordPress/gutenberg/pull/79511.
Related: https://github.com/WordPress/gutenberg/pull/77894

Earlier fix to elements hover styles guard wasn't backported to Gutenberg. The Gutenberg PR for this also adds a test against regressions for this. So this ticket tracks the backporting of the test to core.

Change History (10)

#1 @naimur444
6 weeks ago

I took a look at this backport. On current trunk the warning doesn't seem to reproduce, because wp_render_elements_support_styles() already guards the :hover branch with a two-argument isset() that includes the selector key:

// src/wp-includes/block-supports/elements.php
if ( isset( $element_style_object[':hover'], $element_config['hover_selector'] ) ) {
        wp_style_engine_get_styles(
                $element_style_object[':hover'],
                array(
                        'selector' => $element_config['hover_selector'],
                        'context'  => 'block-supports',
                )
        );
}

isset() with multiple arguments is true only when every operand is set, and it never warns on a missing key. The only read of hover_selector is inside that guard, so for button/heading (which don't define a hover_selector) the branch is simply skipped -- no "Undefined array key" notice and no empty selector reaches the style engine. Core's copy looks to have diverged from the Gutenberg one here; the linked PR is changing Gutenberg's still-single-argument isset( $element_style_object[':hover'] ) to add && ! empty( $element_config['hover_selector'] ), which is the equivalent guard.

Confirming the two conditions in isolation (button config with no hover_selector, style object carrying :hover):

trunk:   isset( $obj[':hover'], $config['hover_selector'] )  => branch skipped, no warning
old GB:  isset( $obj[':hover'] ) only                        => reads $config['hover_selector'] => Warning: Undefined array key "hover_selector"

So the code change looks like a no-op for core as it currently stands. The part that does seem worth bringing over is the PR's new regression test ("button hover styles are skipped without a hover selector"), to lock the behavior in core's phpunit/block-supports/elements-test.php. Happy to put that together if it's useful -- and equally happy to be corrected if I'm missing a path that still reaches the unguarded access.

This ticket was mentioned in PR #12312 on WordPress/wordpress-develop by @aaronrobertshaw.


6 weeks ago
#2

  • Keywords has-patch has-unit-tests added

Trac ticket: https://core.trac.wordpress.org/ticket/65538

## What?

Backport of Gutenberg PR https://github.com/WordPress/gutenberg/pull/79511.

Only render :hover element styles for element types that actually define a hover selector.

## Why?

In wp_render_elements_support_styles(), only the link element type defines a hover_selector. If a block's style.elements carries a :hover object for button or heading, the code reaches for $element_config['hover_selector'] on a type that doesn't have it. That emits an "Undefined array key 'hover_selector'" warning and passes an empty selector to the style engine.

It's hard to reach through the default UI, but the attribute data can be persisted on a block directly, so the warning stands on its own.

## How?

Adds a ! empty( $element_config['hover_selector'] ) guard to the :hover condition so hover processing is skipped for element types without a hover selector. Extends the existing elements styles test with a button :hover case that errors on the warning today and confirms only the base rule is emitted.

## Testing Instructions

  1. The updated Tests_Block_Supports_WpRenderElementsSupportStyles should pass.

#3 @ramonopoly
6 weeks ago

  • Keywords has-patch has-unit-tests removed

#4 @aaronrobertshaw
6 weeks ago

  • Description modified (diff)
  • Summary Block Supports: Guard elements hover rendering against a missing hover selectorBlock Supports: Guard test for element hover styles with a missing hover selector

#5 @wildworks
6 weeks ago

  • Milestone Awaiting Review7.1

@westonruter commented on PR #12312:


6 weeks ago
#6

Core already has a fix protecting against undefined array index that WordPress/gutenberg#79511 addresses.

See https://github.com/WordPress/wordpress-develop/commit/fc826ae8a79b5ad11fa3aad4aea37c2a897a99e8

@wildworks commented on PR #12312:


5 weeks ago
#7

I would appreciate it if you could proceed with this PR and commit it in time for the 7.1 Beta1 release on July 15.

@ramonopoly commented on PR #12312:


4 weeks ago
#8

I'll get it in, thanks @t-hamano

#9 @ramonopoly
4 weeks ago

  • Owner set to ramonopoly
  • Resolutionfixed
  • Status newclosed

In 62701:

Block Supports: guard test for element hover styles with a missing hover selector

This commit adds a test to cover the following behaviour: elements (such as buttons) should only render :hover element styles when they define a hover selector.

Props aaronrobertshaw, ramonopoly, westonruter, wildworks.

Follow-up to [65435].

Fixes #65538.

@ramonopoly commented on PR #12312:


4 weeks ago
#10

Committed in r62701 / 13488fa3099995fbe7043023b04c4007ca0fdf53

Note: See TracTickets for help on using tickets.