Make WordPress Core

Opened 8 months ago

Last modified 4 months ago

#61265 new enhancement

Add class name for block variations

Reported by: bernhard-reiter's profile Bernhard Reiter Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch needs-testing-info
Focuses: Cc:

Description

In order to allow block authors to add custom styling for individual block variations, it would be convenient to have a class name automatically added for the variation.

There's some precedent in the Social Icon block, which e.g. for its WordPress variation adds the wp-social-link-wordpress class name (in addition to wp-social-link).

Attachments (2)

61265-test-before.jpg (98.6 KB) - added by jessedyck 4 months ago.
61265-test-after.jpg (100.3 KB) - added by jessedyck 4 months ago.

Download all attachments as: .zip

Change History (16)

This ticket was mentioned in PR #6602 on WordPress/wordpress-develop by @Bernhard Reiter.


8 months ago
#1

  • Keywords has-patch added

For a given block my/block with a variation myvariation that's registered on the server side (via `variation_callback` or `get_block_type_variations`), add a class wp-block-my-block-mynavigation to the block wrapper.

### Design choiced

This PR introduces a new function called get_active_block_variation(), which is modelled after its client-side counterpart, `getActiveBlockVariation()`. The signatures are _almost_ identical, the major difference being that the client-side version accepts a block type _name_, whereas the server side one expects a WP_Block_Type object.

Inference. Note that while get_active_block_variation respects the isActive field to determine the variation of a block given its attributes, it also has a fallback mechanism, which is to compare the variation's set of defining attributes to the block's.

I believe that this is a reasonable technique to determine a block variation, especially in the absence of an isActive field (which on the server side is furthermore limited to an array of attributes that need to be considered in determining a variation, as opposed to the client side, where arbitrary callbacks are allowed for isActive).

If we agree with this fallback mechanism, I'm inclined to add it to the client side's getActiveBlockVariation as well.

### TODO

  • [ ] Test coverage
  • [ ] PHPDoc
  • [ ] scope arguments

### Testing Instructions

Test with a Block Theme (such as TT4) that uses Template Part block (and ideally also Navigation Link blocks), as those are among the few blocks with server-side registered variations. Inspect the page source and verify that the aforementioned blocks have indeed a variation-specific classname added, e.g. wp-block-template-part-area_footer or wp-block-navigation-link-page.

### Screenshots

https://github.com/WordPress/wordpress-develop/assets/96308/d49678b8-2a94-4a2c-95aa-424fc742b4c0

---

https://github.com/WordPress/wordpress-develop/assets/96308/11b0a1e4-16ee-4b28-be25-f535aba262a7

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

@tomjcafferkey commented on PR #6602:


8 months ago
#2

I'm assuming we're going to need to open a GB counterpart to deal with the same logic for adding variation class names in the editor too?

@Bernhard Reiter commented on PR #6602:


8 months ago
#3

I'm assuming we're going to need to open a GB counterpart to deal with the same logic for adding variation class names in the editor too?

Oh, good point! I was originally just focused on dynamic blocks, but you're right, we'll probably need something somewhere around addGeneratedClassName and/or getBlockDefaultClassName.

@Bernhard Reiter commented on PR #6602:


8 months ago
#4

I'm assuming we're going to need to open a GB counterpart to deal with the same logic for adding variation class names in the editor too?

Oh, good point! I was originally just focused on dynamic blocks, but you're right, we'll probably need something somewhere around addGeneratedClassName and/or getBlockDefaultClassName.

@tjcafferkey Mind giving that a stab? 😄

@tomjcafferkey commented on PR #6602:


8 months ago
#5

Mind giving that a stab? 😄

I'd love to!

This ticket was mentioned in Slack in #core by oglekler. View the logs.


8 months ago

#7 @oglekler
8 months ago

  • Keywords needs-testing-info added

Hi @bernhard-reiter It looks quite well-defined, but we have just a few days before Beta 1, it can possibly go into 6.6 if we hurry up. Can you please provide testing instructions? Thank you!

#8 @faisal03
8 months ago

== Test Report

Please ignore, it was meant for https://core.trac.wordpress.org/ticket/60236

Last edited 8 months ago by faisal03 (previous) (diff)

#9 @oglekler
7 months ago

  • Component changed from General to Editor

#10 @gziolo
7 months ago

  • Milestone changed from 6.6 to 6.7

Moving to WordPress 6.7.

This ticket was mentioned in Slack in #core by chaion07. View the logs.


4 months ago

#12 @jessedyck
4 months ago

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: https://github.com/WordPress/wordpress-develop/pull/6602

Environment

  • WordPress: 6.7-alpha-58576-src
  • PHP: 8.2.14
  • Server: nginx/1.25.3
  • Database: mysqli (Server: 8.0.39 / Client: mysqlnd 8.2.14)
  • Browser: Safari 17.6
  • OS: macOS
  • Theme: Twenty Twenty-Four 1.2
  • MU Plugins: None activated
  • Plugins:
    • Test Reports 1.1.0

Steps to Test

  1. Open a Post post in edit mode
  2. Add a 'Categories' block (or any other block variation) to the page content. Settings for the block can be the default
  3. Assign the 'Uncategorized' category to the post and publish the post
  4. View the front end of the site
  5. Inspect the 'Uncategorized' text (the Categories block) and ensure that the markup contains a new class showing the active variation

Expected Results

  • ✅ An additional class should be added to the block, using the format wp-block-<block name>-<variation name>

Actual Results

  • ✅ The class wp-block-post-terms-category is added to the block

Additional Notes

  • I tested using the default WP develop repo following the Readme's instructions, and used gh pr checkout 6602 to check out the specific PR

Supplemental Artifacts

Before patch:

After patch:

This ticket was mentioned in Slack in #core-test by jessedyck. View the logs.


4 months ago

#14 @desrosj
4 months ago

  • Milestone changed from 6.7 to Future Release

It seems like there are still some unanswered questions on the PR. With beta 1 deadline in less than 24 hours, I'm going to punt this one.

If a committer has the time today to review and commit, it can be moved back.

Note: See TracTickets for help on using tickets.